Как стать автором
Обновить

Комментарии 10

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

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

Они неверны. Ну или верны изредка в очень частных случаях
> Конечную оценку задаче может дать только непосредственный исполнитель;

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

> Оценки времени всегда слишком оптимистичны;

опять же, для непросветленных.

> Оценить целиком время на задачу, требующую дробления на подзадачи, невозможно.

невозможно назвать конечное кол-во работ, потому что зависит от слишком многих факторов (если мы говорим о программерских задач, более сложного, чем maintenance, порядка.

т.е. я к чему — тезисы автора верны для 80% случаев (для непросветленных специалистов :).
Ведущий программист, распределяя задачи по подчиненным-исполнителям, контролирует только рамки сроков, называемых исполнителями. Он имеет представление о том, какую задачку исполнитель сделает максимум за 3 часа, а на какую уйдет не меньше 3 дней.

Конечно, бывают и исключения — люди, которые максимально тщательно анализируют всю проходящую через них информацию. Но если лид поступает таким образом, он просто делает часть работы, которую должен делать исполнитель.
В таком случае можете просветить насчет распространенных случаев? Не исключаю, что мой опыт недостаточно полон в этой части.
*Конечную оценку задаче может дать только непосредственный исполнитель;

Непосредственный исполнитель не видит задачу целиком и не может оценить все риски. В свою оценку он включит перекуры, ненапряжный интернет серфинг, накинет время на «типа случайности» и забудет про смежные зависимые задачи. Т.е. если задача не очевидная на 1 час работы — оценка будет взята с потолка, при этом без всякой ответсвенности.
Но конечно его мнение всегда надо послушать.

*Оценки времени всегда слишком оптимистичны;
Если забыть подумать про риски и внешние факторы.

* Оценить целиком время на задачу, требующую дробления на подзадачи, невозможно.
Это никого неволнует. Оценить время нужно. Неспособны? Боитесь взять ответственность?
Тогда это сделают за вас. Как впрочем и получат совсем другие деньги :)

Как то так.

Какое же «хорошо выглядело», когда они сами же себя и дискредитировали, сказав, что у них просто ужасные разработчики и ничего хорошего их заказчикам ждать не приходится…
До заказчика (в данном случае это был инвестор проекта) даже не дошла реальная история замороженного проекта, ему сказали, что виноваты программисты. К настоящему моменту половина из них наверняка уволена. В целом, конечно, эта история не столько о неправильной оценке задачи, сколько о «слитом» проекте руководством фирмы. Просто поучительная история.
но не для нас — программистов, которые назначают LOE и Due Date. Если фирма загоняет нас в рамки, в которых нам приходится занижать эти оценки — проблемы не наши, а руководства. Поэтому абсолютно согласен, проект слит именно руководством.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории