Дедлайн близко! Как делать правильные эстимейты проектов

В современной индустрии разработки ПО есть один аспект, при упоминании которого у многих опытных программистов наверняка всплывают недобрые воспоминания, связанные с головной болью из-за необходимости закончить проект до дедлайна, работой овертайм и т.д. Речь идет о сроках и оценке времени, а точнее, количества человеко-часов, которые необходимы для выполнения проекта. Как отмечают эксперты, и с ними трудно спорить, оценка количества времени на разработку тех или иных проектов — это просто-таки ахиллесова пята для многих, если не для большинства разработчиков. По данным исследования компании McKinsey, 66% проектов по разработке корпоративного программного обеспечения требуют больших расходов, чем планировалось изначально. Из этих 66%, треть выходят за рамки изначального графика, а около 20% не выполняют поставленные задачи и цели вообще. Это еще не все. Исследователи выяснили, что 17% всех ИТ-проектов на практике реализуются настолько не в соответствии с изначальными планами, что начинают угрожать самому существованию компании. А общая сумма перерасхода средств из-за неправильных эстимейтов при планировании проектов и вовсе колоссальна. “В рамках совместного исследования, специалисты McKinsey и Оксфордского университета проанализировали более 5400 ИТ-проектов в разных индустриях. Сравнив бюджеты, графики и прогнозируемые улучшения в производительности с реальными затратами и результатами, мы выяснили, что общий объем перерасходов бюджетных средств в ходе реализации данных проектов превысил $66 млрд — это больше, чем ВВП Люксембурга,” — говорится в исследовании. “Мы также обнаружили, что чем дольше по плану должен продлиться проект, тем более вероятно, что он выйдет за рамки времени и бюджета. С каждым следующим годом работы над проектом перерасход средств увеличивается на 15%,” — добавляют аналитики. В сегодняшнем материале мы поговорим о том, как проводить оценку времени на разработку наиболее эффективно и на что обращать внимание в первую очередь. А также узнаем, как опытные разработчики советуют подходить к эстимейтам.

Методы оценки времени на реализацию программных проектов

1. Сравнение с уже реализованными проектами (метод по аналогу)

Найти уже реализованный проект с максимально похожим функционалом и взять время, которое потребовалось на его реализацию за основу — это один из классических методов эстимейта. Одно из его основных преимуществ в том, что при рассмотрении уже реализованного проекта можно увидеть, сколько времени закладывалось на его разработку изначально, насколько точно этот план был реализован, с какими сложностями сталкивались разработчики и на каких этапах. Чтобы облегчить процесс оценки и увеличить общую точность эстимейта, зачастую делается разделение общего проекта на ряд составных частей, время реализации которых оценивается отдельно (метод по параметрам).

2. Командная оценка

Данный способ в некоторых англоязычных источниках также называют “покерным методом.” В его основе лежит независимая оценка времени на реализацию разными членами команды программистов, а также бизнес-аналитиками. Каждый делает свою оценку, после чего результаты сравниваются и обсуждаются. Те, кто был автором самого низкого и самого высокого из эстимейтов, приводят свои аргументы в пользу такой точки зрения, и в ходе обсуждения команда стремится установить реалистичные и адекватные сроки.

3. Снизу вверх и сверху вниз

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

4. Сторонняя оценка

Для тех команд, которым особенно сложно определиться с эстимейтом при оценке проекта (или противоречия среди членов команды не удается разрешить), есть вариант обратиться к сторонней команде, которая сможет посмотреть на проект со стороны и выдать более взвешенное и объективное решение.

5. Тройная оценка

В рамках данного метода команда формирует три варианта оценки времени на реализацию проекта: оптимистичный (О), пессимистичный (П) и наиболее приближенный к реальному (Р). Далее финальная оценка вычисляется по одной из двух формул: (О+П+Р)/3 или (О+4Р+П)/6.

Советы и мнения бывалых

1. Индивидуальные эстимейты не могут переходить к другим членам команды без изменений

Как отмечают многие опытные разработчики, при планировании нужно помнить о том, что разные программисты сильно отличаются друг от друга по способностям и опыту, как с индивидуальной точки зрения, так и в работе с определенными языками и технологиями. Именно это одна из основных причин, по которым компаниям и командам разработчиков бывает очень сложно точно рассчитать время на реализацию того или иного проекта. Поэтому при оценке времени, которое понадобится члену команды для выполнения работы, следует оценивать индивидуальный уровень и опыт каждого разработчика, а не “среднюю температуру по больнице.”

2. Закладывайте в план на 15-20% больше времени, чтобы застраховаться от рисков

Еще один распространенный совет — закладывать в официальный план на 15-20% больше времени, чем требуется согласно первоначальной оценке, чтобы застраховаться от возможного перерасхода времени в случае непредвиденных проблем и задержек. Наиболее рискованными с точки зрения временных затрат, как правило, являются самые сложные и/или самые непонятные части проекта.

3. Не забывайте о времени, которое уходит на коммуникации

В своем бестселлере Manage the Unmanageable об управлении командой разработчиков авторы Микки Мантл (Mickey W. Mantle) и Рон Лишти (Ron Lichty) утверждают, что в среднем у девелоперов уходит на кодинг только около 55% времени, тогда как остальные 45% они тратят на взаимодействие и общение с коллегами, менеджерами, тестерами, дизайнерами, представителями клиента и т.д. Кроме того, эксперты пишут, что только одна шестая от общего времени работы над проектом приходится непосредственно на написание кода. Половина времени, а то и больше, уходит на тестирование и исправление ошибок. Поэтому опытные разработчики советуют всегда помнить эту статистику и учитывать ее при составлении планов. Особенно это важно для команд, которые насчитывают достаточно много разработчиков. По наблюдениям, добавление новых кодеров в команду, как только их общее число начинает превышать определенный порог (обычно это 5-6 человек максимум), начинает неизбежно замедлять работу над проектом в целом. Происходит это из-за того, что новому разработчику всегда требуется какое-то время на то, чтобы познакомиться с членами команды и уже существующим кодом проекта.

Своевременно корректируйте ошибки в эстимейтах

“Обновлять и корректировать первоначальную оценку после того, как проект запущен и находится в процессе реализации, совершенно нормально. Чем больше информации предоставляет клиент, тем лучше вы понимаете, сколько человеко-часов потребуется на его реализацию. И чем быстрее вы поймете, что план нужно скорректировать, и сделаете это — тем лучше. Не стесняйтесь обсуждать этот вопрос с клиентом, даже если требуется перенести дедлайн или добавить в команду новых специалистов,” — советует Серхио Акоста (Sergio Acosta), опытный разработчик мультиплатформенных приложений. “Конечно, прежде всего за всем этим должен следить проджект менеджер или тимлид, но в реальности им часто не обойтись без участия рядовых разработчиков. Особенно в тех случаях, когда проджект менеджер/тимлид занимается несколькими проектами одновременно или слишком занят, чтобы следить за деталями реализации той или иной составной части проекта,” — добавил Акоста.

5. Варианты оценки времени на проект для клиента не должны сильно различаться

Если вы отправляете клиенту два или больше варианта эстимейтов (например, упоминавшиеся выше оптимистичный, пессимистичный и реалистичный), убедитесь в том, что они не слишком отличаются друг от друга с точки зрения выделенного времени. По мнению экспертов, разница во времени между вариантами не должна быть больше 20%. Если она будет больше — это может напугать и оттолкнуть клиента, который не будет знать, чего ждать. Единственный случай, когда значительные колебания в оценке времени на проект допустимы — это если клиент предоставил очень мало информации о проекте, и оценить ресурсы на его реализацию точнее не представляется возможным.

6. Оценивайте разные виды работы над проектом отдельно

Также эксперты советуют оценивать ключевые виды работы над проектом отдельно. Это поможет увеличить точность эстимейта и быстрее вычислять его слабые стороны. Так, отдельно можно и даже нужно оценивать следующие виды работ: кодинг, дизайн, аналитика, менеджмент, QA и тестирование, анализ кода, создание документации и руководств пользователя, автоматизацию и т.д.

Вместо эпилога

Впрочем, некоторые эксперты считают, что эстимейты в сфере разработки софта — это зло, и от них нужно отказаться совсем, по крайней мере в жесткой форме. Об этом в своей статье Software Estimation is a Losing Game пишет Ричард Клейтон (Richard Clayton), старший разработчик в компании LotMonkey. “Нужны ли нам эстимейты времени при разработке ПО? Я задавал этот вопрос проджект-менеджерам и корпоративным боссам неоднократно, когда меня просили сделать оценку для какого-нибудь клиента, совершенно не имея достаточной информации и понимания задач. “Конечно нужны, ведь иначе клиент не подпишет с нами контракт,” отвечали они. И, к сожалению, это верный ответ. Он верный, потому что мы позволяем системе работать таким образом, несмотря на то, что разработка софта плохо подходит под данную систему,” — пишет Клейтон. “В реальности команда разработчиков может только реализовать набор возможностей, пропорционально тому количеству времени и ресурсов, которые были выделены. В каком-то смысле, в этом мы похожи на туристическую индустрию — мы не можем гарантировать гостю, что за неделю в нашем резорте он отлично отдохнет и полностью восстановится. Все что мы можем — пообещать, что чем дольше гость у нас остается, тем более отдохнувшим он будет уезжать,” — считает эксперт. Пишите в комментариях, что вы думаете по этому поводу. Какие методы эстимейтов вам кажутся наиболее эффективными, устраивает ли вас нынешний подход к оценке проектов, и стоит ли в корне менять данную систему, как предлагает Ричард?