Итак, эпоха НИОКР. На заре IT, когда компьютеры были большими и стояли в только научных центрах, университетах и крупных корпорациях, разработка софта была похожа на опытно-конструкторские разработки, да еще со значительной исследовательской составляющей. Целью проекта было создание совершенной системы в единственном экземпляре. И выполнялись методами, характерными для НИОКР. Тогда была разработана принципиальная схема V-модель для описания этапов процесса разработки и ее разомкнутая линеаризация в виде водопадной модели (Ройс, 1970). Отметим, что итерации обратной связи, которые представлены на V-модели, принципиально отличаются от современных итераций большой длительностью и тщательной проектированием системы. Ни о каком выделении минимального продукта (MVP) речи не шло, проекты длились годами. А условия для большинства из них были стабильными, потому что речь шла о расчете физических процессов, таких как полет ракет и самолетов, которые происходят по неизменным законам.

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

По мере того, как потребность в IT-проектах возрастала, а область использования IT начала включать не только военные и научно-исследовательские проекты, но и коммерческие проекты, росло желание каким-либо образом обеспечить результат. И менеджмент пошел по известному ему пути ввода правил и регламентов, ресурсного планирования, нормирования работ и учета рисков. Вот тут-то проявилась особенность IT – регулярный менеджмент плохо работает для организации умственного труда. Как общий вызов современности мы ее обсуждали в ранее, в главе «Цифровой мир: от физического труда – к умственному». А тогда, в 1960-х она ярко проявилась в проекте IBM разработки новой операционной системы OS/360. Результаты попыток применить привычные менеджменту подходы в IT-разработке были хорошо проанализированы Фредериком Бруксом, который как раз руководил этим проектом, в книге «Мифический человеко-месяц» (1975), обобщающей опыт многих проектов и ставшей бестселлером. В частности, он сформулировал парадоксальных закон «Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше», и этот закон не является единственным результатом.

Собственно, в чем смысл подхода проектного управления? В том, чтобы всю неопределенность движения по V-диаграмме перенести на стадию проектирования, а то, что не получается – явно выделить как риски, оставив на стадии разработки только типовые операции с предсказуемой трудоемкостью. Тогда после завершения проектирования ход разработки становится предсказуемым, и менеджеры смогут управлять им в классическом треугольнике объем (scope) – сроки – стоимость в одном из его вариантов.

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