Том Демарко

Среди наиболее важных источников неопределенности можно назвать:
1. Требования к системе: Что именно должна делать система?
2. Обеспечение стандартов взаимодействия: Как будет система взаимодействовать с людьми-операторами и другими система

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

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

Главный риск №1: Изъяны календарного планирования

Первый главный риск появляется из-за каких-то изъянов (или полной несостоятельности) процесса планирования бюджета времени и средств.

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

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

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

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

Мы определяем общие потери времени как число месяцев, которое потребуется типичному новичку на достижение того же уровня производительности, который был у замененного им работника. Обычно это время составляет от 2 месяцев на самых простых позициях в IT-отделах до 24 месяцев для компании, производящей очень сложные приложения.