Почему оценки IT-проектов почти всегда ошибочны - и что с этим делать
Разрыв между оценочными и фактическими сроками IT-проектов - известная и устойчивая проблема. Разбор структурных причин, по которым это продолжается, и практик, которые её уменьшают.
Спросите любого руководителя, который несколько лет управлял IT-проектами, - и он скажет одно и то же: оценка оказалась слишком оптимистичной. Проект занял больше времени, обошёлся дороже или принёс меньше. Это настолько распространено, что большинство опытных менеджеров теперь неформально применяют множитель к любой IT-оценке перед тем, как представить её совету.
Интересный вопрос - не в том, ошибочны ли оценки. Почти всегда - да. Интересный вопрос - почему это продолжается даже в опытных командах, и что реально поддаётся улучшению.
Структурные причины провала оценок
Самое распространённое объяснение - разработчики оптимистичны. Это правда, но неполная. Более глубокая проблема в том, что оценки делаются в момент максимального незнания - до начала работы и до полного понимания проблемы.
Разработка ПО предполагает обнаружение формы проблемы по мере работы с ней. Требования, которые казались ясными, обнаруживают неоднозначности при старте реализации. Всплывают зависимости от других систем, не попавшие в область оценки. Тестирование выявляет взаимодействия, которые не предвиделись. Это не халатность. Это присуще природе работы.
Вторая структурная причина - разница между временем задачи и календарным временем. Задача, требующая 10 часов работы, не занимает 10 календарных часов. Есть совещания, переключения контекста, ревью, ожидание зависимостей и накладные расходы на координацию. Оценки, игнорирующие это, систематически занижают календарную продолжительность.
Третья причина - оценки нередко делаются под давлением необходимости выдать определённую цифру. Если проект должен быть завершён за три месяца к бизнес-дедлайну, оценки неосознанно калибруются к этой цели. Оценка становится обязательством, замаскированным под прогноз.
Что снижает погрешность
Наиболее надёжная практика, которую я видел, - разбивать работу на меньшие части и оценивать, и отслеживать каждую часть отдельно. Крупные оценки для крупных проектов почти всегда ошибочны. Оценки для двухнедельных инкрементов работы можно измерять, сравнивать с фактическими результатами и использовать для калибровки будущих оценок. Со временем команда накапливает историю, которая заменяет угадывание.
Вторая практика - разделять «то, что мы знаем» и «то, что нам придётся открывать». Часть работы хорошо понята и оценивается с разумной уверенностью. Другая требует сначала исследования. Обращаться с ними одинаково в плане проекта - источник систематической ошибки. Явно маркировать исследовательскую работу, выделять фазу открытия и оценивать оставшуюся работу после неё - более честный подход.
Третья практика - держать буфер на уровне проекта и не поддаваться давлению его сократить. Не закладывать запас в каждую отдельную задачу, а держать общий буфер на уровне всего объёма. Когда случаются сюрпризы - а они случатся - буфер их поглощает без немедленной необходимости переговоров о скопе или дедлайне.
Что говорить бизнесу
Всё это не меняет того факта, что бизнесу нужна дата поставки. Быть честным о неопределённости, оставаясь полезным, - значит давать диапазон вместо точечной оценки, объяснять, что должно быть правдой для реализации оптимистичного сценария, и принимать на себя обязательство по регулярным обновлениям вместо одной цифры в начале.
Большинство руководителей, с которыми я работал, предпочитают честную неопределённость уверенным цифрам, которые потом оказываются выдумкой. Проблема в том, что во многих организациях система поощряет уверенные цифры в момент одобрения и наказывает изменения скопа позже. Это организационная проблема стимулов, а не только проблема оценки - и о ней стоит говорить прямо, когда вы её видите.