Комментарии 10
Ваша история в конце статьи называется жизнью. Как только вы поймете, почему она произошла таким образом (причем со стороны всех участников), и кто какие цели достигал, то сразу поймете почему ваши начальные тезисы не верны.
+1
а какие именно тезисы? вижу два «разные руководители проектов применяют разные подходы к оценке сроков выполнения задач» и «не всегда они совпадают с моим (авторским) отношением к этому делу».
0
Вот эти
* Конечную оценку задаче может дать только непосредственный исполнитель;
* Оценки времени всегда слишком оптимистичны;
* Оценить целиком время на задачу, требующую дробления на подзадачи, невозможно.
Они неверны. Ну или верны изредка в очень частных случаях
* Конечную оценку задаче может дать только непосредственный исполнитель;
* Оценки времени всегда слишком оптимистичны;
* Оценить целиком время на задачу, требующую дробления на подзадачи, невозможно.
Они неверны. Ну или верны изредка в очень частных случаях
0
> Конечную оценку задаче может дать только непосредственный исполнитель;
либо просветленный лид, который использует коэффициент для оценков с учетом человека, который будет задачу делать.
> Оценки времени всегда слишком оптимистичны;
опять же, для непросветленных.
> Оценить целиком время на задачу, требующую дробления на подзадачи, невозможно.
невозможно назвать конечное кол-во работ, потому что зависит от слишком многих факторов (если мы говорим о программерских задач, более сложного, чем maintenance, порядка.
т.е. я к чему — тезисы автора верны для 80% случаев (для непросветленных специалистов :).
либо просветленный лид, который использует коэффициент для оценков с учетом человека, который будет задачу делать.
> Оценки времени всегда слишком оптимистичны;
опять же, для непросветленных.
> Оценить целиком время на задачу, требующую дробления на подзадачи, невозможно.
невозможно назвать конечное кол-во работ, потому что зависит от слишком многих факторов (если мы говорим о программерских задач, более сложного, чем maintenance, порядка.
т.е. я к чему — тезисы автора верны для 80% случаев (для непросветленных специалистов :).
0
Ведущий программист, распределяя задачи по подчиненным-исполнителям, контролирует только рамки сроков, называемых исполнителями. Он имеет представление о том, какую задачку исполнитель сделает максимум за 3 часа, а на какую уйдет не меньше 3 дней.
Конечно, бывают и исключения — люди, которые максимально тщательно анализируют всю проходящую через них информацию. Но если лид поступает таким образом, он просто делает часть работы, которую должен делать исполнитель.
Конечно, бывают и исключения — люди, которые максимально тщательно анализируют всю проходящую через них информацию. Но если лид поступает таким образом, он просто делает часть работы, которую должен делать исполнитель.
0
В таком случае можете просветить насчет распространенных случаев? Не исключаю, что мой опыт недостаточно полон в этой части.
0
*Конечную оценку задаче может дать только непосредственный исполнитель;
Непосредственный исполнитель не видит задачу целиком и не может оценить все риски. В свою оценку он включит перекуры, ненапряжный интернет серфинг, накинет время на «типа случайности» и забудет про смежные зависимые задачи. Т.е. если задача не очевидная на 1 час работы — оценка будет взята с потолка, при этом без всякой ответсвенности.
Но конечно его мнение всегда надо послушать.
*Оценки времени всегда слишком оптимистичны;
Если забыть подумать про риски и внешние факторы.
* Оценить целиком время на задачу, требующую дробления на подзадачи, невозможно.
Это никого неволнует. Оценить время нужно. Неспособны? Боитесь взять ответственность?
Тогда это сделают за вас. Как впрочем и получат совсем другие деньги :)
Как то так.
Непосредственный исполнитель не видит задачу целиком и не может оценить все риски. В свою оценку он включит перекуры, ненапряжный интернет серфинг, накинет время на «типа случайности» и забудет про смежные зависимые задачи. Т.е. если задача не очевидная на 1 час работы — оценка будет взята с потолка, при этом без всякой ответсвенности.
Но конечно его мнение всегда надо послушать.
*Оценки времени всегда слишком оптимистичны;
Если забыть подумать про риски и внешние факторы.
* Оценить целиком время на задачу, требующую дробления на подзадачи, невозможно.
Это никого неволнует. Оценить время нужно. Неспособны? Боитесь взять ответственность?
Тогда это сделают за вас. Как впрочем и получат совсем другие деньги :)
Как то так.
0
Какое же «хорошо выглядело», когда они сами же себя и дискредитировали, сказав, что у них просто ужасные разработчики и ничего хорошего их заказчикам ждать не приходится…
0
До заказчика (в данном случае это был инвестор проекта) даже не дошла реальная история замороженного проекта, ему сказали, что виноваты программисты. К настоящему моменту половина из них наверняка уволена. В целом, конечно, эта история не столько о неправильной оценке задачи, сколько о «слитом» проекте руководством фирмы. Просто поучительная история.
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Оценка времени выполнения задачи