Процесс, который ФБР изначально использовало для «Стража», мы называем предиктивным, или последовательным. По сути, до 2005 года большинство проектов по разработке программного обеспечения использовали предиктивные процессы, которые при определенных обстоятельствах наиболее подходят и могут обеспечить успех. Эти обстоятельства, однако, скорее исключение, чем правило. Если кто-то может создать окончательное видение, определить все требования к нему и затем разработать детальный план по воплощению их в жизнь, тогда предиктивный процесс будет эффективным. Но любое отклонение от изначального видения, требований или плана создает большой риск. При частой смене требований бизнеса и технологий, которые присутствуют в реальных условиях, очень редко встречается, чтобы все элементы проекта оставались неизменными. Как результат, о чем и сообщает отчет The Standish Group, 86 % проектов по разработке программного обеспечения, основанных на предиктивных процесах, неуспешны. На самом деле мы считаем использование предиктивных процессов самой распространенной причиной проблем при разработке программного обеспечения.

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

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

1. Выпуск продукта занимает все больше и больше времени. «Каждый релиз занимает больше времени, требует больше усилий и затрат до момента передачи потребителю. Несколько лет назад выпуск новой версии занимал 18 месяцев, теперь на разработку, комплектацию и установку требуется 24 месяца. И при этом каждый релиз становится стрессом и требует значительных усилий. Мы тратим все больше, при этом получаем все меньше и меньше.

2. Срыв графиков релизов. «В проспектах мы даем обязательства нашим нынешним либо потенциальным клиентам, которые делают определенные приготовления в соответствии с нашим графиком релиза. Им нужен наш релиз с обещанным нами функционалом именно тогда, когда запланировано. И мы обычно подводим их в самый последний момент. Их планы нарушаются, они теряют деньги и доверие в глазах своих клиентов. Следовательно, мы можем не получить от них новые заказы, их отзывы о нашей работе вряд ли будут хорошими, и они могут начать поиск другой компании разработчиков».

3. Создание стабильной версии перед релизом занимает все больше и больше времени. «Мы установили разработчикам четкие, неизменяемые даты выполнения заказа. Они уложились в эти сроки, но программное обеспечение было нестабильным, не функционировало, как требуется. У нас даже не получилось отгрузить этот софт как бета-релиз, так что мы смогли получить отзывы только от ограниченного количества пользователей. Дефекты оказались настолько значительными, что наши бета-тестеры отказались участвовать. Нам потребовалось еще девять месяцев, чтобы выпустить релиз, и даже тогда он был нестабилен и требовал множества доработок и оправданий перед пользователями».

4. Планирование занимает слишком много времени и выполняется неправильно