Ошибки календарного планирования можно рассматривать как тенденцию неправильно судить о размерах продукта, который предстоит создать. Существует серьезная возможность недооценки, даже если вы прилагаете большие усилия по определению величины программного продукта, скажем, методом функциональных точек, по модели СОСОМО KLOC[22] или любым другим способом. Вы чаще упускаете какие-то работы, которые оказываются нужными, чем включаете в расписание работы, которые впоследствии окажутся ненужными. Любая переоценка размера работ, оказавшаяся в вашем плане, редко оказывается достаточной, чтобы компенсировать недооценку.

Если вы не предпринимаете серьезных усилий по определению величины программного продукта, то ваши оценки календарного планирования основаны всего лишь на принятии желаемого за действительное: «Ого! Клиент хочет получить это в мае, до мая еще 7 месяцев, поэтому наугад можно поставить в график 7 месяцев». Когда календарное планирование строится без учета размера продукта, весьма вероятен перерасход времени на 50-80%. Когда семимесячный проект в конце концов занимает 12 месяцев, разъяренные топ-менеджеры редко винят график, вместо этого они ругают тех, кто должен был воплотить этот график (каким бы смехотворным он ни был) и жизнь. Но проблема в ошибочном календарном планировании, а не в плохом исполнении. В ретроспективе это выглядит так: размер продукта был недооценен по приказу; ограничение продолжительности проекта свело его размер к такому, какой мог быть создан за это время, но это ограничение оказалось нереалистичным.

Насколько большой проблемой являются ошибки календарного планирования в целом по отрасли разработки программного обеспечения? Чтобы ответить на этот вопрос, нам нужно было осмыслить данные по просрочкам, в том числе данные, собранные другими, а затем исключить воздействие остальных главных рисков. Это позволяло убедиться, что мы выделили воздействие именно ошибок календарного планирования. Такое выделение причинных факторов является нетривиальной задачей, и мы не претендуем на то, что достигли совершенства в своих результатах, но следующая диаграмма неопределенности – наша лучшая оценка отклонения от графика только из-за неверного календарного планирования:

Как показывает рисунок, если ничего больше не известно о вашем проекте или вашей организации, то можно с уверенностью утверждать, что первоначальная оценка размера продукта (как вычисленная непосредственно вами, так и декларативная) вынудит вас перерасходовать запланированное время, по крайней мере, на 30%. Например, горизонталь, проведенная на уровне 0,50 пересечет кривую в точке, показывающей увеличение времени в 1.3 или более.

Показанная здесь ситуация значительно хуже, чем ей следовало бы быть. Общеотраслевая тенденция скомпрометирована тем фактом, что так много компаний не выполняет предварительной работы по определению размера проекта, выбирая вместо этого календарное планирование от конца к началу или просто принимая желаемое за действительное. Хотя отрасль в целом управляется с этим не лучше, чем показано на рисунке выше, те компании, которые прилагают серьезные усилия для определения размера продукта, могут сократить влияние ошибок календарного планирования до 15% и менее. Сбор данных по нескольким проектам относительно масштабов недооценки размера научит вас закладывать необходимый резерв на это в ваших будущих проектах. В конечном счете, вы можете построить сбалансированную диаграмму риска, где точка 50 на 50 соответствует перерасходу на уровне 0%, а вероятность закончить проект досрочно (с учетом только этого главного риска) равна вероятности закончить с опозданием.

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

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

Программное обеспечение, которое вы со своей командой разрабатываете, всегда предназначено для того, чтобы вписаться в область деятельности вашего клиента. В одном вы можете быть уверены – в том, что эта область не останется статичной за время создания программного обеспечения. Она будет изменяться со скоростью, диктуемой рынком и собственными темпами технологического развития. Если вы в январе обязались поставить продукт X через 10 месяцев, то к моменту истечения этих 10 месяцев ваши бизнес-партнеры уже хотят не X. На самом деле они уже хотят Х-штрих. Разница между тем, что они хотят в начале и в конце этого периода возникает из-за изменений, которые произошли в данной области бизнеса за это время.

С точки зрения проекта, это изменение всегда является раздуванием. Даже удаление того, что уже создано – своего рода раздувание, поскольку требует дополнительной работы.

Сколько именно дополнений разумно ожидать? Если вы согласны с нашим мнением, изложенным в последних двух параграфах, то понимаете, что 0% не будет правильным ответом. Но именно такой ответ подразумевается при нашем обычном планировании нового проекта. Наши рассуждения выглядят примерно так:

Если вы хотите X, мы можем дать вам его через 10 месяцев; если окажется, что вам нужно что-то иное, чем X, это ваши трудности.

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

Логичнее поступить как-то так: «Вы говорите, что хотите X, наш опыт подсказывает, что в процессе работы возникнут изменения в требованиях и вы в итоге захотите что-то слегка иное, поэтому мы будем планировать создание X с некоторой готовностью к ожидаемым изменениям».

Но какой именно готовностью? В середине 1990-х министерством обороны США было предложено количественное определение того, как должны вести себя хорошо управляемые проекты. Они количественно измерили размер разумно ожидаемых изменений примерно на уровне менее 1% в месяц. Итак, проект, по созданию продукта размером в 20000 функциональных точек[23] за два года, должен быть рассчитан на создание примерно 25000 функциональных точек программного обеспечения (20000 фт х (1.00 + 24 месяца х 1 % в месяц)). Реальный размер будет где-то посередине, поскольку часть изменений потребует отмены уже выполненных и оплаченных работ.

Опыт Минобороны США, может быть, трудно применить к вашему проекту. Поскольку типичные программные продукты для Минобороны велики, проекты часто выполняются с привлечением субподрядчиков (иногда нескольких уровней) и их продолжительность дольше, чем у большинства коммерческих проектов, более того, приближение, предложенное Минобороны США выражено, скорее, «терминах самого объема, чем в его влиянии на продолжительность по времени.

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