Миф о человеке-месяце, или почему проекты не сдаются вовремя
Расхоже мнение, что виной постоянному срыву сроков отсутствие методологии. Ирония в том, что эту позицию продвигают продавцы методологий. Другие винят скудный инструментарий, а третьи и вовсе считают причиной инфантильность и слабую дисциплину программистов.
В исследовании Энди Коула «Неконтролируемые проекты — причины и следствия» главенствуют два фактора: чересчур оптимистичная оценка и изменение требований на ходу.
Заблуждения масштабны
Планирование бывает настолько оторвано от реальности, что попросту бесполезно. Исследования из книги Роберта Гласса «Факты и заблуждения» говорят, что разработчики недооценивают объем работы на 20-30%. Суммарная оценка программных проектов склонна к ошибкам в сроках сверх 100%.
Еще чаще оценка делается не вовремя. Большинство оценивает сроки до формулирования требований, а значит — до изучения задачи и без той информации, которая помогла бы точнее определить сроки.
Проект чаще выходит из-под контроля не из-за недостатков методики или инструментов, а из-за пропасти между поставленными задачами и реальностью.
Конус неопределенности
Пропасть возникает из-за недостатка информации. У каждой стадии проекта своя прогнозируемая степень неопределенности в оценке. Конус неопределенности показывает, что точность оценки растет по ходу продвижения работы.
На старте, когда нет ничего кроме обобщенных вводных, погрешность в оценке достигает 400%. Когда спроектирован пользовательский интерфейс — 25%. Поэтому рекомендуем создавать прототип до оценки сроков.
Если разрабатываете систему ввода заказов, но еще не сформулировали требования к формату телефонных номеров, возникнет масса факторов неопределенности, которые влияют на оценку.
Нужно ли проверять введенный номер на действительность? Если нужно, то какую систему проверки захочет клиент — дорогую или дешевую? Если поставить дешевую, то не захочет ли клиент позже перейти на дорогую Использовать готовое решение или разрабатывать с нуля?
Опытный руководитель проектов задумывается над этими и десятками других вопросов, касающихся каждого программного узла будущего проекта.
Различия в определении, проектировании и реализации одних и тех же возможностей накапливаются и растягивают сроки в сотни раз. В проекте с тысячами функций и программных узлов неопределенность колоссальна, и риски не складываются арифметически, а растут в геометрической прогрессии.
Куда спешат менеджеры
Оценку проектов доверяют топ-менеджерам и маркетологам, а не разработчикам, а значит — оценку делают не те люди. Менеджеры стараются сократить сроки сдачи проекта по трем причинам.
Во-первых, руководство боится переоценить сроки из-за закона Паркинсона: работа заполняет все отведенное время. Если дать команде полгода на работу, требующую 4 месяца, она непременно найдет, чем заполнить оставшиеся два.
Во-вторых, менеджеры внушают разработчикам срочность. Они считают, что если программисты оценивают проект в 6 месяцев, то в расчетах есть допущения, за счет которых сроки можно сжать.
Также в проект закладывают плановую срочность, поэтому называется срок в 3 месяца, даже если менеджер сам не верит, что это возможно. Логика в том, что если он прав, разработчикам хватит 4 или 5 месяцев, а в худшем случае —успеют за 6.
В-третьих, возможно, обязательства уже взяты, а значит — нужна не оценка, а календарный план разработки проекта.
Между менеджерами и программистами нет контакта. В исследовании одного проекта с несоблюдением параметров на основании оценки говорится, что разработчики сочли его самым удачным. Несмотря на это, руководство рассматривало его как неудачный. Из исследования очевидна недопустимая разобщенность менеджеров и разработчиков.
Заниженные оценки — враг продукта
Заниженные оценки убивают ценность планирования и приводят к неверному определению численности групп разработчиков. Также под угрозой координация работы — если одна группа не успевает, другой вовремя недоступны результаты ее работы.
Из-за заниженной оценки проектированию и постановке требований отводится недостаточно времени, а значит, их придется переделывать на поздних стадиях, когда это дороже.
При опозданиях возникают лишние задачи:
- Дополнительные совещания с обсуждением мер, которые позволят вернуть проект во временные рамки;
- Постоянные переоценки и уточнения новой даты сдачи;
- Общение с клиентом и объяснение задержки;
- Подготовка промежуточных и сырых версий для демонстраций и выставок.
Эти действия не нужны, если команда идет по графику. Они отвлекают от работы и задерживают сдачу проекта.
Миф о человеке-месяце
При фиксированной функциональности срок сокращается только новым персоналом, выполняющим больше работы за меньшее время. Ошибка такого рассуждения в единице измерения — человеко-месяце.
Стоимость и правда равна произведению количества сотрудников и затраченных месяцев, но результат так не измерить, потому что люди вносят в проект неодинаковый вклад. Поэтому человеко-месяц как единица измерения объема — опасная ловушка для проекта. Проблема подробно описана Фредериком Бруксом в книге «Мифический человеко-месяц, или как создаются программные системы».
Исследования сходятся в том, сокращение номинального срока увеличивает объем работ. Если срок для группы из 7 человек — 12 месяцев, то увеличение группы до 12 человек не даст уменьшения срока до 7 месяцев.
Большими группами сложнее управлять из-за растущего числа путей контактов внутри команды. Если части задания координируются между собой, то затраты на координацию растут квадратично, а продуктивность команды — линейно. Трем работникам нужно втрое, а четырем вшестеро больше попарного общения, чем двум.
Если 8 человек напишут программу за 10 месяцев, сможет ли команда из 80 написать за месяц? Ответ — нет, ведь очевидно, что 1600 людей не напишут ее за сутки.
Практические советы
Если проект опаздывает — сократите задачу. Все равно заканчивается этим, когда команда не укладывается. Вместо того, чтобы форсировать сроки, пусть менеджер аккуратно и официально сократит задачу или изменит график.
Не давите на оптимистичные оценки разработчиков — избегать закона Паркинсона поможет улучшение менеджмента. Уделяйте внимание автоматизации тестирования и закладывайте под тесты больше времени. Создавайте прототипы. Нанимайте лучших и делите на группы до семи человек, не подключайте новых специалистов на ходу. Следуйте плану и двигайтесь итерациями.
Мы в «Стартап-кафе №1» помогаем стартапам получать инвестиции и развиваться. Подписывайтесь на канал в Telegram, чтобы следить за нашими публикациями и получать дельные советы.