Здравствуйте, __kot2, Вы писали:

S>>Требовать точные сроки -- это маразм. А вы уж сами решайте, готовы ли вы тратить часть своей жизни в этом маразме.
__>да не маразм это, а инструмент манипуляции. "ты сам дал обещание, что сделаешь это за столько.."

Значит, надо обещать столько, за сколько по-любому не обидно сделать.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, __kot2, Вы писали:

S>>>Требовать точные сроки -- это маразм. А вы уж сами решайте, готовы ли вы тратить часть своей жизни в этом маразме.
__>>да не маразм это, а инструмент манипуляции. "ты сам дал обещание, что сделаешь это за столько.."

Pzz>Значит, надо обещать столько, за сколько по-любому не обидно сделать.
да причем тут обида. я вот планирую до работы ехать полчаса. ну 40 минут. но если авария, то полтора часа может занять. однажды 3 часа ехал. сколько мне обещать? и этом при том, что я уже это много раз делал

Здравствуйте, __kot2, Вы писали:

Pzz>>Значит, надо обещать столько, за сколько по-любому не обидно сделать.
__>да причем тут обида. я вот планирую до работы ехать полчаса. ну 40 минут. но если авария, то полтора часа может занять. однажды 3 часа ехал. сколько мне обещать? и этом при том, что я уже это много раз делал

Ну как, просто в свою оценку закладываешь возможные риски, с учётом их вероятности. Ну и несёшь их потом на себе, если что.

Всё равно кто-то в цепочке должен это сделать. Не ты, так твой наниматель. И в принципе, кто на себя берет риски, тому и достаётся сверхприбыль.

Pzz>Всё равно кто-то в цепочке должен это сделать. Не ты, так твой наниматель. И в принципе, кто на себя берет риски, тому и достаётся сверхприбыль.
у меня есть друг — директор аварийной службы по чистке труб-канализации и т.д.
какие у него проблемы с сотрудниками?
— они при наличии срочных заявок сидят гоняют чаи час с утра
— они не мотивированы получать больше. им и так их зарплаты хватает
— они ничего не помнят и все забывают, даже руководители, когда это их прямая обязанность
— они бухают
— они не умеют считать и считают, "раз они заколебались", то много и успешно поработали

вот когда люди с таким опытом приходят в ИТ и начинают с программистами разговаривать так, как они привыкли с такими работягами, получается хреново.

Здравствуйте, __kot2, Вы писали:

Pzz>>Значит, надо обещать столько, за сколько по-любому не обидно сделать.
__>да причем тут обида. я вот планирую до работы ехать полчаса. ну 40 минут. но если авария, то полтора часа может занять. однажды 3 часа ехал. сколько мне обещать? и этом при том, что я уже это много раз делал

Зная вероятность соотв. событий (можно на глаз прикинуть по кол-ву раз за все время), то вычислить мат. ожидание. Где-то будет 45 минут, наверное.

Здравствуйте, imh0, Вы писали:

I>Тут недано столкнулся с ситуацией, приятель рассказал — им на онбординге-обучении на менеджеров в одном из бигтехов сказали "вы должны знать, что ценность для компании IT-менеджера с девелоперским бекграундом в несколько раз выше чем любого разработчика" Причем это сказали в мотивации к анти синдрому самозванца — "Типа не бойтесь увольнять, даже если у вас получилась ошибка — вы для компании ценнее чем любой эксперт-архитектор на соответсвующих уровнях"

I>Так как опытных мереджеров именно с опытом разработки в 1000 раз сложнее найти чем любого разраба.

судя по викпедии в офисе где я работаю 5+ тыс инженеров
при этом открыто 62 позиции менеджеров и 0 программистов

я не буду писать сколько у нас в тиме программистов а сколько менеджеров ибо это позор

S>Зная вероятность соотв. событий (можно на глаз прикинуть по кол-ву раз за все время), то вычислить мат. ожидание. Где-то будет 45 минут, наверное.
Но это не является гарантированным временем

Здравствуйте, __kot2, Вы писали:

Pzz>>Всё равно кто-то в цепочке должен это сделать. Не ты, так твой наниматель. И в принципе, кто на себя берет риски, тому и достаётся сверхприбыль.
__>у меня есть друг — директор аварийной службы по чистке труб-канализации и т.д.

У меня нет опыта по чистке труб. У меня есть опыт ИТ-ного фриланса.

Здравствуйте, __kot2, Вы писали:

S>>Зная вероятность соотв. событий (можно на глаз прикинуть по кол-ву раз за все время), то вычислить мат. ожидание. Где-то будет 45 минут, наверное.
__>Но это не является гарантированным временем

Ну по идее есть теоремы и формулы, которое с помощью этой величины могут оценить вероятность адекватного времени.
Т.е. с вероятность столько-то будет столько-то времени и т.п. И далее зная нужную вероятность можно получить +- гарантированное время.

S>Ну по идее есть теоремы и формулы, которое с помощью этой величины могут оценить вероятность адекватного времени.
S>Т.е. с вероятность столько-то будет столько-то времени и т.п. И далее зная нужную вероятность можно получить +- гарантированное время.
Да, одно событие может выбиваться, но в среднем все идет по плану. Поэтому чем больше временной интервал и сложнее задача, проще назвать гарантированное время ее выполнения. Если тебя спрашивают с утра гарантированное время выполнения задач на сегодня включая получасовые задачи, это хрень

Здравствуйте, __kot2, Вы писали:


S>>Ну по идее есть теоремы и формулы, которое с помощью этой величины могут оценить вероятность адекватного времени.
S>>Т.е. с вероятность столько-то будет столько-то времени и т.п. И далее зная нужную вероятность можно получить +- гарантированное время.
__>Да, одно событие может выбиваться, но в среднем все идет по плану. Поэтому чем больше временной интервал и сложнее задача, проще назвать гарантированное время ее выполнения. Если тебя спрашивают с утра гарантированное время выполнения задач на сегодня включая получасовые задачи, это хрень

А вот мне кажется, ровно наоборот -- на большом временном интервале может произойти многое, тут сроки как раз будут не надежными.
А вот на коротких интервалах более-менее сроки будут биться. Проще оценить сроки небольших задач. И это хрень, если с такими задачами
человек впервые сталкивается, а не после нескольких лет работы. Если ТС видит кодовую базу впервые и не знаком с предметной областью,
это, безусловно, хрень. Иначе это -- норма.(с)

S>А вот мне кажется, ровно наоборот -- на большом временном интервале может произойти многое, тут сроки как раз будут не надежными.
S>А вот на коротких интервалах более-менее сроки будут биться. Проще оценить сроки небольших задач. И это хрень, если с такими задачами
S>человек впервые сталкивается, а не после нескольких лет работы. Если ТС видит кодовую базу впервые и не знаком с предметной областью,
S>это, безусловно, хрень. Иначе это -- норма.(с)
если посмотреть на математическую модель, то вот у нас есть план работ типа этапы abcdef и каждый из них занимает два дня плюс-минус день по статистике, тогда матожидание будет 6*2 = 12 дней и чем больше этапов, тем меньше будет колебание вокруг этого общего значения дней. проблема возникает когда возникают новые этапы, либо оценка для каждого этапа не средняя, а излишне оптимистичная была взята. то есть были такие случаи когда вместо двух дней успевали каждый этап сделать за день и какой-то горе-менеджер ставит 1 день норматив и 6 дней ожидания в сумме. а получает 12. оттуда и торчат уши разных поправочных коэффициентов, типа берем план и умножаем на два. это все недоработка планирования.

Здравствуйте, __kot2, Вы писали:

__>вот когда люди с таким опытом приходят в ИТ и начинают с программистами разговаривать так, как они привыкли с такими работягами, получается хреново.
А в ИТ всё ровно также, разве что бухают меньше.

Здравствуйте, __kot2, Вы писали:

S>>А вот мне кажется, ровно наоборот -- на большом временном интервале может произойти многое, тут сроки как раз будут не надежными.
S>>А вот на коротких интервалах более-менее сроки будут биться. Проще оценить сроки небольших задач. И это хрень, если с такими задачами
S>>человек впервые сталкивается, а не после нескольких лет работы. Если ТС видит кодовую базу впервые и не знаком с предметной областью,
S>>это, безусловно, хрень. Иначе это -- норма.(с)
__>если посмотреть на математическую модель, то вот у нас есть план работ типа этапы abcdef и каждый из них занимает два дня плюс-минус день по статистике, тогда матожидание будет 6*2 = 12 дней и чем больше этапов, тем меньше будет колебание вокруг этого общего значения дней. проблема возникает когда возникают новые этапы, либо оценка для каждого этапа не средняя, а излишне оптимистичная была взята. то есть были такие случаи когда вместо двух дней успевали каждый этап сделать за день и какой-то горе-менеджер ставит 1 день норматив и 6 дней ожидания в сумме. а получает 12. оттуда и торчат уши разных поправочных коэффициентов, типа берем план и умножаем на два. это все недоработка планирования.

Поэтому оценки и спускают непосредственно исполнителям, чтобы получить более адекватную оценку.

S>Поэтому оценки и спускают непосредственно исполнителям, чтобы получить более адекватную оценку.
а нужно это делать на основе статистики

а вообще, для этого очень хорошо подходят нейросети. надо брать им скармливать записи о работе и ходе выполнения и просить оценить новую задачу

Здравствуйте, __kot2, Вы писали:

S>>Поэтому оценки и спускают непосредственно исполнителям, чтобы получить более адекватную оценку.
__>а нужно это делать на основе статистики

В целом да, основываясь на пред. опыте решения подобных\похожих задач. Но вот если задача относительно новая, то тут уже статистика может не помочь.

__>а вообще, для этого очень хорошо подходят нейросети. надо брать им скармливать записи о работе и ходе выполнения и просить оценить новую задачу

Обычная линейная регрессия.

Здравствуйте, Sharov, Вы писали:

S>Поэтому оценки и спускают непосредственно исполнителям, чтобы получить более адекватную оценку.

Их как-то странно спускают: за сколько времени вы построите дом? В процессе выясняется, что дом трёхэтажный, его надо строить на склоне горы, время постройки — середина весны и к стройке ведёт грунтовая дорога. Это образно.
Типичная ситуация выглядит так: за сколько времени поправишь эту багу? Допустим, сумма не сходится. Соответственно в процессе выясняется, что там кривой многопоточный код, который работает правильно иногда, а для того чтобы большую часть времени оно выдавало правдеподобный результат, подсчёт подпёрт костылями. О том, что перед тобой костыли, ты понимаешь через 2 дня дебага.

Какое будет мат. ожидание, если уже была подобная бага, но проблема там была в том, что в условии цикла была ошибка, и последний элемент не учитывался? Грубо говоря, ты в прошлый раз снаружи похожую проблему решил за полчала.

Здравствуйте, Философ, Вы писали:


Ф>Их как-то странно спускают: за сколько времени вы построите дом? В процессе выясняется, что дом трёхэтажный, его надо строить на склоне горы, время постройки — середина весны и к стройке ведёт грунтовая дорога. Это образно.
Ф>Типичная ситуация выглядит так: за сколько времени поправишь эту багу? Допустим, сумма не сходится. Соответственно в процессе выясняется, что там кривой многопоточный код, который работает правильно иногда, а для того чтобы большую часть времени оно выдавало правдеподобный результат, подсчёт подпёрт костылями. О том, что перед тобой костыли, ты понимаешь через 2 дня дебага.
Ф>Какое будет мат. ожидание, если уже была подобная бага, но проблема там была в том, что в условии цикла была ошибка, и последний элемент не учитывался? Грубо говоря, ты в прошлый раз снаружи похожую проблему решил за полчала.

В теории ожидал бы от получаса до 2 дней. Зависит от бага, если похож на тот, что за полчаса -- это одно, иначе -- ожидал бы 2 дней.