4 простых шага, которые помогут вам улучшить оценку проектов
Как проектному менеджеру перестать срывать сроки разработки и избавиться от нервного тика.
Дата публикации: 04.03.2016
Когда я трудился разработчиком в разных компаниях, ко мне часто приходили менеджеры проектов и просили оценить — за сколько я сделаю ту или иную работу. Через некоторое время я стал руководить разработчиками, и уже сам стал просить их оценивать время. Поток проектов постепенно рос, и в какой-то момент вопрос адекватной оценки стал жизненно важным — из-за неправильно оцененных проектов мы могли понести реальные убытки.
Рядом не было человека, который мог бы научить меня оценивать проекты, так что информацию пришлось добывать самостоятельно. И здесь мне очень помогла книга известного в узких кругах Стива Макконнелла «Software Estimation: Demystifying the Black Art». Она довольно скучная и сухая, вышла 10 лет назад, но все равно очень полезная. Принципы, которые в ней даются, можно легко применить на практике, притом в любой сфере — программировании, дизайне или ремонте квартиры.
Типичные ошибки менеджеров при планировании
1Вы забываете, что оценка — это не обязательство. Любая оценка — это вероятность. Ни один человек в здравом уме не будет подписывать договор на основании вероятности. Несколько кроваво сорванных дедлайнов могут научить проектного менеджера вообще никогда не давать никаких обещаний. Но лучше до этого не доводить. Помните, что не каждый клиент готов пойти навстречу. Поэтому лучше заранее обезопасить себя с юридической, моральной, а также всех других точек зрения.
2Вы безоговорочно доверяете оценке команды. Вы сэкономите кучу нервов, если будете помнить, что люди всегда говорят самую оптимистичную оценку. Они это делают не потому, что врут, хвастаются или хотят вашей смерти. Просто так устроена наша психология, мы склонны представлять самый благоприятный сценарий (который сбывается примерно никогда).
Однажды у нас был проект с голландской фирмой. Разработчики сделали оценку, но заказчик решил, что мы просим слишком много, и попросил порезать цифры. У меня было два выхода — либо согласиться на его оценку, либо отказаться от проекта. Я предположил, что разработчики проекта в любом случае оценили работу с запасом. А так как я сам неплохо умею программировать, мне порезанные цифры показались вполне реалистичными.
Поэтому я принял неверное решение — согласился урезать оценку. В итоге мы зафакапили все сроки и ничего не заработали на этом проекте. Из этой истории я извлек еще один важный урок — никогда не разрешайте трогать оценку человеку извне. Можно торговаться с клиентом о цене, составе требований, календарных сроках, но никогда — об оценке.
4 простых принципа, которые улучшат жизнь проектного менеджера
1Никогда не занижайте оценку специалиста. То, что вам назвал человек — уже очень оптимистичная, практически недостижимая оценка. Если ваш опыт подсказывает, что эту работу можно сделать быстрее, не слушайте его. Возможности, знания и умения у всех специалистов разные. Снизив оценку, вы выроете себе яму, в которую обязательно попадете.
2Ориентируйтесь на две цифры. После того, как вы получили оптимистичную оценку специалиста, сядьте и подумайте над тем, что может пойти не так. Продумайте худший сценарий из возможных и оцените, какова будет дата окончания проекта в этом случае. Вы получите две оценки, и истина обычно располагается где-то посередине. Оценку можно сделать более точной, если использовать не две, а три цифры.
3Спрашивайте нескольких специалистов. Вы можете использовать покер планирования или просто обсудить сроки на общей встрече без карточек и правил. Главное — в итоге команда должна договориться по дате сдачи проекта.
4Помните о рисках. Всегда могут быть неучтенные и неожиданные обстоятельства — баги в браузере или операционной системе, землетрясения, потопы. Они случаются крайне редко, но все-таки случаются. Есть широко известная в узких кругах идея — чтобы учесть непредвиденные факторы, итоговую оценку нужно умножать на два. Но это ненаучный подход.
Как в итоге работаем мы сами
Заносим все требования в табличку. При этом нам не важно, в какой форме нам их представили — абзац в письме, майндмэп или ТЗ — работаем с тем, что есть.
Потом рядом с каждым пунктом пишем три оценки — оптимистичную, пессимистичную и наиболее вероятную. Цифры можно получить разными способами, например по историческим данным, но это тема для отдельной беседы. Дальше все это считается по специальной формуле и в итоге мы получаем трудозатраты.
Функция | Наиболее вероятная оценка Mi |
Оптимистичная оценка Oi |
Пессимистичная оценка Pi |
Средняя трудоемкость Ei |
Средне- квадратичное отклонение |
---|---|---|---|---|---|
Нарисовать барашка | 2,00 | 1,00 | 5,00 | 2,33 | 0,44 |
Найти колодец | 10,00 | 5,00 | 15,00 | 10,00 | 2,78 |
Починить самолет | 20,00 | 10,00 | 40,00 | 21,67 | 25,00 |
Суммарно | 34,00 | 5,31 | |||
Гарантированные трудозатраты с вероятностью 95% | 44,62 чел*дней |
Обычно на риски мы закладываем 10–20%. Тут многое зависит от заказчика — если известно, что клиент не привык идти навстречу, мы можем и больше заложить, чтобы обезопасить себя.
Полный текст статьи читайте на CMS Magazine