Мы утверждали выше, что большинство главных рисков не относятся к низкой производительности команды. Это справедливо относительно риска ошибки календарного планирования, но только если игнорировать качество работы менеджмента. Руководители, предложившие или согласившиеся взять обязательства с серьезными ошибками календарного планирования, работают плохо. Ключевой момент здесь состоит в том, что когда проект не укладывается в график, то это происходит несмотря на работу разработчиков, а не благодаря ей. Команда, отдельно от руководителя, могла работать оптимально.
Главный риск №2: Раздувание требований
Программное обеспечение, которое вы со своей командой разрабатываете, всегда предназначено для того, чтобы вписаться в область деятельности вашего клиента. В одном вы можете быть уверены – в том, что эта область не останется статичной за время создания программного обеспечения. Она будет изменяться со скоростью, диктуемой рынком и собственными темпами технологического развития. Если вы в январе обязались поставить продукт X через 10 месяцев, то к моменту истечения этих 10 месяцев ваши бизнес-партнеры уже хотят не X. На самом деле они уже хотят Х-штрих. Разница между тем, что они хотят в начале и в конце этого периода возникает из-за изменений, которые произошли в данной области бизнеса за это время.
С точки зрения проекта, это изменение всегда является раздуванием. Даже удаление того, что уже создано – своего рода раздувание, поскольку требует дополнительной работы.
Сколько именно дополнений разумно ожидать? Если вы согласны с нашим мнением, изложенным в последних двух параграфах, то понимаете, что 0% не будет правильным ответом. Но именно такой ответ подразумевается при нашем обычном планировании нового проекта. Наши рассуждения выглядят примерно так:
Если вы хотите X, мы можем дать вам его через 10 месяцев; если окажется, что вам нужно что-то иное, чем X, это ваши трудности.
Но это не так. Поразить движущуюся цель – общая задача. Планировать поставить в будущем именно то, что заказчики хотят сегодня, все равно, что отсылать футбольный мяч туда, где раньше стоял игрок.
Логичнее поступить как-то так: «Вы говорите, что хотите X, наш опыт подсказывает, что в процессе работы возникнут изменения в требованиях и вы в итоге захотите что-то слегка иное, поэтому мы будем планировать создание X с некоторой готовностью к ожидаемым изменениям».
Но какой именно готовностью? В середине 1990-х министерством обороны США было предложено количественное определение того, как должны вести себя хорошо управляемые проекты. Они количественно измерили размер разумно ожидаемых изменений примерно на уровне менее 1% в месяц. Итак, проект, по созданию продукта размером в 20000 функциональных точек
