Comments 15
Делается так:
1. Спрашивают сроки. Сказать срок «за сколько вы предполагаете сделать» * 3.5
2. Сразу возмущаются, что так долго. Предлагаете назвать срок, за который хотят чтобы было сделано.
3. Говорите, что это их срок, и вы за него ответственности не несете. Если получится — хорошо. Нет — сами виноваты, не умеете в сроки.
…
4. PROFIT
P.S. часто помогает «почасовая» декомпозиция задачи. Чтобы обосновать ваш срок.
Главное не забыть, про тестирование, время на «CI/CD» (если не автоматизировано) и «неопределенность ТЗ».
Более менее точная почасовая декомпозиция требует ресурсов больше чем выполнение самой задачи и потому не имеет смысла.
С завышением оценок затрат помогает бороться лишь альтернативный исполнитель.
Например, у так расписал за ~6 часов проект на пол года.
Но там из ТЗ было понятно какие будут экранные формы и количество элементов на них.
Так же в принципе понятно, по времени, с интеграцией через soap.
А вот альтернативный исполнитель, на моей памяти, никогда не помогал бороться с завышением оценок.
Т.е. как бы он делал, но по времени выходило не меньше, чем мои оценки.
Сколько контрольных точек в вашем почасовом плане за 6 месяцев было? 1000 или меньше? Каким образом контролировали? По сумме Earned Value раз в неделю?
Я не PM, а программист (писатель).
Просто PM попросил оценить объем работ и успеем ли мы к сроку.
Я прикинул. Посчитал. Получалось, что срок срываем ~3 месяца.
Где-то так и вышло. Правда чуть, больше, т.к. там по ходу дела были изменения в ТЗ.
Я надеюсь, вы увидели, что ваш план вовсе не почасовой. Просто у вас в пакете работ много коротких повторяющихся задач. Но вы не планировали выполнение каждой из них с точностью до часа. Вы планировали весь пакет работ целиком, с общим запасом.
Можно сделать декомпозицию проекта (если это не R&D), до «атомарных» задач.
Т.е. тех, которые уже «не делятся».
И время для этих задач ~ 1-2 часа.
Не ровно 1 час. А можно сделать в течении часа.
Ну или не более часа.
Вполне нормальная точность. Если оценку по времени наложит на производственный календарь, то можно узнать «приблизительные сроки».
А в чем смысл такой точности? Я понимаю смысл перечня задач, т.е. WBS объединенных в пакеты work package. И понимаю смысл оценки времени исполнения пакетов с точностью до исполнителя: например, этот пакет делает вася 5 дней, маша 10 дней, и по 1 дню вася и дима. И для каждого пакета пригодится оценка даты начала и завершения + запас. В данном примере, допустим 30%. Итого на диаграмме ганта полоса на 13 дней. И, если она окажется на критическом пути, я, имея указанную выше информацию, смогу ее оптимизировать. И на диапазоне в пол года в моем ежедневном плане будет больше тысячи строк. Плюс зависимости, плюс неопределенности. Что даст мне почасовой план? 10 000 строк и еще больше зависимостей? В чем смысл такой точности?
А так хотя бы можно выдать оценку с приемлемой точностью.
Для PM не знаю, т.к. с кем я встречался в сроки они не умеет совсем.
В лучшем случае спрашивают у программиста.
В худшем ставят «палец потолок».
Ну и как обычно проект сделан в лучшем случае на половину, а дедлайн подкрался незаметно. :-)
Что по моему мнению — правильно.
Но я чаще сталкиваюсь ситуацией, когда ПМ просто не умеет в сроки.
И перекладывает ответственность за сроки на программиста.
Вот тут и приходиться делать декомпозицию, чтобы выжать срок не «палец потолок», а что-то более-менее близкое к истине.
Несколько соломинок для прокрастинатора