Почему же построить процесс проектирования самолетов, исключив человеческий фактор, так, что после принципиального проектирования новый самолет можно контрактовать Боингу удалось, а вот решить аналогичную задачу в IT – не получается? Причина заключается в природе IT-разработки. Это тоже было выяснено давно, этому посвящена статья Джека Ривза (Jack W. Reeves) «What is software design» (1992, перевод). Дело в том, что при сопоставлении разработки софта с НИОКР в других отраслях, например, проектирование самолетов, мы должны отнести написание кода не к производству, а к низкоуровневому проектированию. То же, что делают заводы на опытном производстве в IT делает среда разработки, собирая проект, делает быстро и дешево и потому ошибки проектирования не критичны, их исправляют не тщательной предварительной проработкой, а тестированием и отладкой. Это сильно дешевле статистически, но делает выполнение конкретной задачи слабо предсказуемым, вернее, получается распределение с жирным хвостом, так, что для срок для 90% уверенности в три раза превышает мат. ожидание. Об этом был интересный доклад Андрея Бибичева «Пуассоново горение сроков». Схематично это изображено на рисунке. А я отмечу, что задачу IT-разработка оказалась как раз той областью, где Боинг тоже постигла неудача: множество скандалов вокруг его самолетов связаны как раз с бортовым софтом.

Впрочем, и менеджеры и инженеры редко верят в то, что какие-либо вещи являются невозможными. И невзирая на статистику проектов и объяснение причин в 1990-х была предпринята масштабная попытка создать предсказуемый процесс. Компания Rational Software собрала гуру IT-разработки и поставила такую задачу. В результате появился Rational Unify Process (RUP), универсальный процесс, включающий все возможные варианты, из которого надлежало выбрать нужное для проекта и использовать. В дальнейшем он послужил основой PMBOK. Эксперимент окончился неудачей: стоимость разработки с соблюдением всех процедур возросла многократно, а гарантий успеха – не получилось.

Одним из громких провалов проектов в IT является история нового денверского аэропорта (1993—1995). Его пуск в эксплуатацию был задержан на полтора года из-за того, что не была готова система управления автоматической доставкой багажа к самолетам. При этом проектировщики аэропорта не заложили возможности доставлять багаж вручную: доставка должна была осуществляться по подземным туннелям, диаметр которых не позволял использовать средства с водителем. Представьте размер убытков: все эти полтора года новый построенный аэропорт не могли запустить, а старый, в центре города и уже проданный инвесторами – продолжал работать. История рассказана в книге Тома ДеМарко и Тима Листера «Вальсируя с медведями», а я ее услышал от авторов, когда они в 2012 приезжали в Москву. Еще одна провальная история регулярного менеджмента в IT – свежая, 2013 год – это история ObamaCare. Создание сайта для регистрации страховок национальной программы HealthCare.gov по первоначальным оценкам требовало 94 млн$, еще до старта работ сумма выросла до 292 млн$, а фактически сайт обошелся в 1.7 млрд.$. И при этом на момент старта сайт был практически не работоспособен: при планируемой нагрузке в 60000 посетителей тесты показывали максимум 1100, только 1% посетителей в первом месяце смогли завершить регистрацию из-за множественных ошибок и так далее. Интересно, что провал проекта в некоторых статьях приписывают как раз применению agile-методов отдельными подрядчиками. Но факт состоит в том, что это – государственный проект, в нем участвовало более сотни подрядчиков, генподрядчиком была одна из крупных IT-компаний с мировым именем, и его вели по тем методикам проектного управления, которые были приняты в США как стандарт, там есть регулирование. И блистательно провалился. Провал имел политические последствия и Обама после него озверел и организовал US Digital Service, который начал разрабатывать нормативку для ведения госпроектов по гибким методологиям. Историю я услышал в 2015 на AgileKitchen по применению Agile в госпроектах (