Ошибочная оценка сроков, как причина провала проекта

estimates Самая известная мне причина неудовлетворенности клиента — несоответствие ожидаемого результата реальному. Данная ситуация может возникать по разным причинам – отсутствие эффективного управления проектом, часто изменяемые требования, низкий уровень команды, высокие технические риски, недостаточная обратная связь с клиентом, завышенные ожидания, срыв сроков. Именно срыв сроков наиболее часто встречаемая и явная проблема в управлении проектами. Одна из вероятных причин – плохо проведенная первоначальная оценка (estimation).

Проблематике оценки сроков проектов уделяется много внимания, существует ряд подходов от математических моделей до оценки в попугаях. Но команды всегда ошибаются с оценками. На моей практике ни на одном проекте оценки сроков проектов не совпали с реальными. Оценивали разными способами: на основе опыта команды, на основе статистики, на основе экспертной оценки, story points функциональные points, попугаи… Погрешность в оценках была во всех случаях.

Интересно, но большинство проектов в конечном итоге укладывались в условно приемлемые сроки (с погрешностью от нескольких дней до месяца). Как вы уже поняли, не благодаря точным оценкам. Приходилось прибегать к разным приемам – урезание функционала, снижение критериев качества, игнорирование рисков. Но в первую очередь приемлемых сроков сдачи удается достичь благодаря героизму людей работающих в команде. Проекты были из разных доменных областей и размеров, и как продуктовые, так и заказные. Команды и менеджеры были хорошего уровня. Тогда почему не соблюдаются сроки? Потому что оценки сроков проекта самая ошибочная, не точная и изменчивая информация, которой обладает менеджер.

Все выше описанное не означает, что не нужно заниматься оценкой сроков проекта. Сроки и планирование важны как для заказчика и руководства, партнеров, маркетологов, продавцов и других зависимых сторон. Плохая оценка сроков может «завалить» проект еще до начала проектирования. Есть достаточно примеров, когда продукт не выстреливал из-за задержек– срыв рекламных компаний, появление на рынке конкурентов.

Можно ли без оценок? Можно, если такой подход явно устраивает всех участников проекта, в первую очередь стейкхолдеров. Есть интересный факт:

Проекты, оценка которых не делалась во все, были лучшими в смысле продуктивности [Jeffery, Lawrence, 1985].

Вполне логично, но нужно быть готовым к увеличению сроков на 100 % и более со всеми вытекающими. Линберг в своем исследовательском проекте [1999] описывал проект, где срок проекта сдвинулся на 193 % (27 месяцев против 14). Опираясь на своей практике, я могу подтвердить этот факт – без давления сроков работа делается гораздо основательней и качественней, но совсем медленно.

Что можно попробовать сделать, чтобы повысить точность оценок.

  • Владельцы проектов не до конца осознают, какие задачи будет решать их продукт. Не всегда осознается масштаб проектов. Поэтому важно провести тщательный анализ требований. Оценка должна происходить только после того как все технические требования и бизнес требования согласованы и имеют окончательный вариант (оно конечно еще сто раз поменяется, об этом чуть позже).
  • Исключите оптимизм в оценке. Только строгий прагматизм.
  • Дробите функциональность на мелкие куски. Фильтруйте документацию перед оценкой. Сведите документацию в Feature List. Он должен быть предельно лаконичен и одновременно с тем понятен оценщику.
  • Не давайте быстрых оценок. На оценку должно быть выделено достаточное количество времени.
  • Оценка должна отображать реальность, а не желание клиента или руководства. Не позволяйте выкручивать вам яйца продавливать себя/команду. В последствии будет только хуже.
  • Оценка, спущенная сверху должна быть пересмотрена и доведена до сведения руководства.
  • Выбирайте подходящую форму оценки проектов. Считается, что гибкие методологии помогают добиться большей результативности. Но не всем проектам они могут подойти.
  • Для получения более точных значений можно использовать несколько различных методов оценки.
  • Не допускайте ошибок во время оценок. Например, ошибка может заключаться в самой единице измерения. Фредерик Брукс в своей книге «Мифический человеко-месяц» приводит следующие зависимости задач, которые, как правило, не учитываются: задача полностью распараллеливается между несколькими программистами, задача вообще не распараллеливается, задача имеет сложные взаимосвязи. Рассмотрите все детали.
  • Используйте вилку оценок (от и до), но давайте оценку с адекватной разбежкой.
  • Оценку должна давать команда проекта. Чтобы оценка получилась объективной, она должна быть коллективной и затрагивать все аспекты разработки.
  • К оценке должны быть привлечены эксперты в доменной области и эксперты в соответствующей технологии, инструментах.
  • Привлекайте к ревью полученных оценок разработчиков, не участвующих в проекте.
  • Оценивайте все возможные зависимости – сторонние исполнители, зависимые задачи и т.д.
  • Обязательно учитывайте все рутинные задачи – демки, командные собрания, митинги с клиентом, настройка инструментов, обучение, подготовка отчетов и т.д.
  • Учитывайте все возможные форс мажоры и стопперы – bus factor, праздники, отпуска, болезни, увольнения, сезонные запои сотрудников и т.д.
  • Во время оценки не оказывайте влияние на процесс рассуждений. Не нужно делиться своими предварительными оценками.
  • При согласовании оценок нужно найти компромисс между всеми участниками проекта. Каждый должен быть согласен с оценками.

В ходе работы над проектом мы должны опираться не только на изначально данные сроки и оценки, но и на другие факторы. Роберт Гласс предлагает учитывать и руководствоваться следующей информацией:

  • Ориентация на продукт, на ту часть функционала, которая уже закончена.
  • Ориентации на проблемы. Как часто возникают проблемы, как быстро и качественно мы их решаем.
  • Ориентация на риски. Как преодолеваются риски определенные вначале проекта.
  • Бизнес цели проекта.
  • Качество как индикатор готовности проекта.

Как контролировать сроки выполнения проекта.

  • Создавайте контрольные точки разработки проекта (а-ля дипломные процентовки). На этих этапах оценивайте ход разработки, бюджет, риски и конечно качество приложения. Если вы видите, что сроки не соблюдается, то вашей задачей является предпринять меры по устранению отставания, в самых плохих случаях начать обсуждать перенос даты выпуска продукта и предупредить все заинтересованные стороны. Чем раньше вы это сделаете, тем лучше. В любом случае, ваша задача привносить реальность в проект.
  • Оценивайте сроки и результаты постоянно.
  • Оценки должны быть пересмотрены при изменении требований.

    Часто меняющие требования называют одной из причин неуправляемости проекта.

    Клиент должен отчетливо понимать, как изменение или добавление требований сказывается на прогнозируемой дате выпуска продукта. Если вы видите, что могут быть проблемы с клиентом на данной почве, то переоценкой нужно заниматься регулярно.

    Увеличение сложности задачи на 25 % приводит к усложнению программного решения на 100%.

  • Этот совет будет полезен, как для специалистов по качеству, так и для руководителей проектов. Общайтесь с командой —

    технические специалисты замечают грядущие проблемы гораздо раньше своего руководства (на 72 %) [Cole, 1995]

  • Примите во внимание первый закон Брукса:

    Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.

  • Избегайте героизма в виде переработок команды.
  • Сроки не должны давить на команду. Чем сильнее давление графика, тем больше стресс. Стресс порождает много опасных факторов. Которые, в свою очередь, точно приведут к срыву сроков.

А что думаете вы по этому поводу?

В тексте я использовал факты и материалы озвученные Робертом Глассом в книге «Факты и заблуждения профессионального программирования». Эта книга удачно попалась мне под руку. В книге озвучены факты с полемикой, обсуждением, конкретными цифрами и ссылками на источники. Факты настолько всем известны, что часто игнорируются.