Миф о человеке-месяце, или почему проекты не сдаются вовремя

Шалом стартаперы! Я Лёша Марков, главред «Стартап-кафе №1». Поговорим о том, что все не любят и что постоянно происходит — о срыве сроков.

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

В исследовании Энди Коула «Неконтролируемые проекты — причины и следствия» главенствуют два фактора: чересчур оптимистичная оценка и изменение требований на ходу. Сегодня поговорим об оценке, а в следующий раз — о требованиях.

Планирование бывает настолько оторвано от реальности, что попросту бесполезно. Исследования из книги Роберта Гласса «Факты и заблуждения» говорят, что разработчики недооценивают объем работы на 20-30%. Суммарная оценка программных проектов склонна к ошибкам в сроках сверх 100%.

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

Проект чаще выходит из-под контроля не из-за недостатков методики или инструментов, а из-за пропасти между поставленными задачами и реальностью.

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

На старте, когда нет ничего кроме обобщенных вводных, погрешность в оценке достигает 400%. Когда спроектирован пользовательский интерфейс — 25%. Поэтому рекомендуем создавать прототип до оценки сроков.

Если разрабатываете систему ввода заказов, но еще не сформулировали требования к формату телефонных номеров, возникнет масса факторов неопределенности, которые влияют на оценку.

Нужно ли проверять введенный номер на действительность? Если нужно, то какую систему проверки захочет клиент — дорогую или дешевую? Если поставить дешевую, то не захочет ли клиент позже перейти на дорогую Использовать готовое решение или разрабатывать с нуля?

Опытный руководитель проектов задумывается над этими и десятками других вопросов, касающихся каждого программного узла будущего проекта.

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

Оценку проектов доверяют топ-менеджерам и маркетологам, а не разработчикам, а значит — оценку делают не те люди. Менеджеры стараются сократить сроки сдачи проекта по трем причинам.

Во-первых, руководство боится переоценить сроки из-за закона Паркинсона: работа заполняет все отведенное время. Если дать команде полгода на работу, требующую 4 месяца, она непременно найдет, чем заполнить оставшиеся два.

Во-вторых, менеджеры внушают разработчикам срочность. Они считают, что если программисты оценивают проект в 6 месяцев, то в расчетах есть допущения, за счет которых сроки можно сжать.

Также в проект закладывают плановую срочность, поэтому называется срок в 3 месяца, даже если менеджер сам не верит, что это возможно. Логика в том, что если он прав, разработчикам хватит 4 или 5 месяцев, а в худшем случае —успеют за 6.

В-третьих, возможно, обязательства уже взяты, а значит — нужна не оценка, а календарный план разработки проекта.

Между менеджерами и программистами нет контакта. В исследовании одного проекта с несоблюдением параметров на основании оценки говорится, что разработчики сочли его самым удачным. Несмотря на это, руководство рассматривало его как неудачный. Из исследования очевидна недопустимая разобщенность менеджеров и разработчиков.

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

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

При опозданиях возникают лишние задачи:

• Дополнительные совещания с обсуждением мер, которые позволят вернуть проект во временные рамки;
• Постоянные переоценки и уточнения новой даты сдачи;
• Общение с клиентом и объяснение задержки;
• Подготовка промежуточных и сырых версий для демонстраций и выставок.

Эти действия не нужны, если команда идет по графику. Они отвлекают от работы и задерживают сдачу проекта.

При фиксированной функциональности срок сокращается только новым персоналом, выполняющим больше работы за меньшее время. Ошибка такого рассуждения в единице измерения — человеко-месяце.

Стоимость и правда равна произведению количества сотрудников и затраченных месяцев, но результат так не измерить, потому что люди вносят в проект неодинаковый вклад. Поэтому человеко-месяц как единица измерения объема — опасная ловушка для проекта. Проблема подробно описана Фредериком Бруксом в книге «Мифический человеко-месяц, или как создаются программные системы».

Исследования сходятся в том, сокращение номинального срока увеличивает объем работ. Если срок для группы из 7 человек — 12 месяцев, то увеличение группы до 12 человек не даст уменьшения срока до 7 месяцев.

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

Если 8 человек напишут программу за 10 месяцев, сможет ли команда из 80 написать за месяц? Ответ — нет, ведь очевидно, что 1600 людей не напишут ее за сутки.

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

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

Подписывайтесь на телеграм-канал венчурной экосистемы «Стартап-кафе №1»: каждый день рассказываем, как запустить стартап и найти инвестиции.

Регистрируйтесь на сайте, там уже доступна база знаний. На днях релизим шесть новых модулей: мастермайнды, витрина стартапов, эйчар-площадка, база экспертов, трекинг стартапов, календарь мероприятий.

#управление #менеджмент #проекты