Почему-то считается, что планы и оценки создаются для того, чтобы потом точно (тютелька в тютельку) в них вписаться. В этом утверждении заключается распространённая ошибка. Бытует утверждение, что если какой-либо из планов не был выполнен или время выполнения какой-либо задачи не совпало с первоначальной оценкой, то план — сорван, а прогноз — неправильный.
Такой подход считаю в корне неверным. Планы и оценки делаются совсем для другой цели
— для того, чтобы не потерять контроль над проектом. Конечно, самый оптимальный вариант — когда сроки и планы совпадают с реальными. Однако если что-то пошло не так, это вовсе не означает, что проект сорван. Срыв сроков по какой-либо задаче — это основание для принятия инженерного, управленческого или продюсерского решения, а именно:
1. Ведущий программист может помочь менее опытному коллеге найти другое, более дешёвое техническое решение.
2. Менеджер проекта может передать задачу другому разработчику или подключить дополнительные силы.
3. Продюсер может переформулировать фичу таким образом, что её реализация в обновлённом варианте займёт гораздо меньшее время, или же сделать фича-кат.
Такой подход считаю в корне неверным. Планы и оценки делаются совсем для другой цели
— для того, чтобы не потерять контроль над проектом. Конечно, самый оптимальный вариант — когда сроки и планы совпадают с реальными. Однако если что-то пошло не так, это вовсе не означает, что проект сорван. Срыв сроков по какой-либо задаче — это основание для принятия инженерного, управленческого или продюсерского решения, а именно:
1. Ведущий программист может помочь менее опытному коллеге найти другое, более дешёвое техническое решение.
2. Менеджер проекта может передать задачу другому разработчику или подключить дополнительные силы.
3. Продюсер может переформулировать фичу таким образом, что её реализация в обновлённом варианте займёт гораздо меньшее время, или же сделать фича-кат.
Источник картинки: http://kolobuga.ru/wp-content/uploads/2013/06/plan.jpg
1) менее опытный - будет убиваться и копать, только потом признает что нужно спросить, иначе он просто не перейдет в состояние мидл или лид дева
ОтветитьУдалить2) еще более ужасная ситуация для девелопера - передача задачи (или подключение еще кого то)
3) продюсер должен просто признать, что взял цифры с потолка, а потом уже заниматься, обновлением таймменеджмента, или простой переформулировкой тз
в разработке оч сложно держать сроки изначально, нужно иметь хотябы пяток похожих проектов в релизе
не врубаешься в проект, получай все три пункта сразу - на каждую задачу
1. Такое происходит, когда менеджер не следит за ходом проекта. В нормальной ситуации estimate задачи, над которой ведётся работа (сколько времени осталось до завершения) обновляется каждый день. В случае, если он увеличивается, а не уменьшается, или уменьшается не так, как прогнозировалось, - это повод поговорить с разработчиком, чтобы выяснить, в чём заключается проблема.
Удалить2. Подключение к задаче технического руководителя или более опытного разработчика - нормальная практика.
3. Продюсер не занимается оценкой проекта. Он занимается придумыванием и документированием фич, объяснением разработчикам того, как программа должна работать, и что хочет видеть пользователь. Оценку сроков производит инженер под руководством ведущего инженера.
Ну, если был пяток похожих проектов, то можно уже заводить речь о мелкосерийном конвейерном производстве, а там тип менеджмента несколько иной (цепочка операций, у каждой свои нормативы по часам, главная неопределённость - остановка конвейера). А нестандартные проекты действительно не больше чем прогнозируются (как погода). План уточняется по ходу работ, и главный талант менеджера тут - уметь держать руку на пульсе + чуточку вперёд.
Удалить> Почему-то считается, что планы и оценки создаются для того, чтобы потом точно (тютелька в тютельку) в них вписаться
ОтветитьУдалитьВы преувеличиваете, никто так не считает
Если бы не считали, то мне бы не пришлось писать эту заметку.
УдалитьИзначально нужно брать толковых программистов, а не экономя на бабках, набирать с улицы.
ОтветитьУдалить