ФБР перевело всю команду по разработке проекта «Страж» в подвал здания в Вашингтоне и сократило персонал с 400 человек до 45, 15 из которых были программисты. Технический директор ФБР лично возглавил проект. Целью управления разработкой стало предоставление части функционала «Стража» каждые 30 дней. Все приращения функционала обязаны были соответствовать окончательным характеристикам, это не должен был быть «сырой продукт». Каждые три месяца ФБР объединяло три ранее полученные части в единый пилотный проект.

К ноябрю 2011-го, через год после возобновления работы с использованием нового подхода, все стадии проекта «Страж» были закончены. Программное обеспечение установили для пилотной группы агентов ФБР, оснащение оставшихся агентов новым программным обеспечением было запланировано к июню 2012 года. ФБР удалось закончить проект «Страж» за 30 миллионов долларов в течение года. Экономия средств составила более 90 %. Сотрудники так же усердно трудились и над первыми стадиями проекта «Страж», но сам подход к разработке программного обеспечения отбрасывал их назад. После применения нового метода, описанного в этой книге, они продолжили работать столь же усердно, как и раньше, но наградой им стали гораздо лучшие результаты. Если такая организация, как ФБР, смогла сделать это, почему не может ваша?

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

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

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

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

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

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

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