Развитие и провал регулярного менеджмента в IT

Седьмая статья серии «Менеджмент цифрового мира». В предыдущей статье я дал краткий обзор истории менеджмента в IT, показав на смену эпохи НИОКР пришел RUP, а затем Agile. А в этой подробно рассмотрю развитие регулярного менеджмента в IT и причины его провала. Как пишет Эдвард Йордан в книге «Смертельный марш», история IT – это история безнадежных проектов. К этой книге мы еще вернемся, а пока отметим, что с развитием цифровизации эта же ситуация воспроизводится в других отраслях, и потому этот материал интересен не только IT- шникам. Тем более, что миф о том, что существует правильный способ выполнения IT-проектов, обеспечивающий гарантированный результат, и он точно известен компетентным инженерам, которых просто надо найти, является чрезвычайно распространенным и заманчивым, и в эту ловушку неоднократно попадались и продолжают попадаться и те, кто заказывает IT-проекты, и те, кто их делает.

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

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

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

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

Почему это не работает? Причина – в том, что работа в IT нормируется очень плохо, скорость ее выполнения существенно зависит от человеческого фактора. Не просто от конкретных людей, а от людей в конкретных условиях, знания о том, как человек раньше решал аналогичные задачи не помогает предсказать, как он решит очередную. Влиянию человеческого фактора на ход проектов посвящена классическая книга Тома ДеМарко «Peopleware» (1987), которая в русском переводе так и называется «Человеческий фактор».

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

Непредсказуемость IT-проектов имеет еще одну причину – быстрое развитие технологий. Есть шкала Technology rediness level (TRL), разработанная NASA для оценки технологий, закладываемых при проектировании космических кораблей. И для гарантии детального проектирования и разработки самолета Боинг разрешает закладывать при принципиальном проектировании в новый самолет со зрелостью не ниже 8 из 10. Если же мы посмотрим на современную IT-разработку, то там активно используются технологии уровня 4-5. И не из-за тяги к новизне и риску, а потому, что технологии не успевают созреть, и без этого мобильные телефоны оставались без софта несколько лет после изготовления, а новые возможности железа не были задействованы софтом. Как легко догадаться, такая картина невозможна. А использование незрелых технологий чревато непредвиденными рисками при осуществлении проекта, потмоу что задачи, которые оценивали как легко решаемые с помощью каких-либо новых фреймворков или библиотек, вдруг оказываются сложными, и не потому, что сама технологий не подходит в принципе, а потому что в рамках фреймворка эта задача еще не является стандартной, и надо не просто воспользоваться готовой библиотекой, а дописать эту библиотеку в процессе решения. Кстати, сейчас это достаточно распространено: вендоры не успевают за развитием технологий, поэтому по многим новым подходам, например, реактивному программированию, разработчики используют open source библиотеки, дорабатывая их в ходе проекта.

Статья содержит очень многобукв, но я не нашел способа поделить ее на две без ущерба для цельности восприятия. И несмотря на объем я хочу в конце вернуться к тому, с чего начал – к книге Эдварда Йордана «Смертельный марш». Эта книга написана в 1997 и подводит почти 40-летний опыт IT-менеджмента, и он заключает, что «безнадежные проекты являются нормой, а не исключением», несмотря на то, что каждое новое поколение менеджеров, вооружаясь новыми методологиями, обещает этого не допустить. Безнадежный проект – это такой, вероятность провала которого более 50%, иногда существенно, ввиду дефицита одного или нескольких ресурсов в два или более раз по сравнению с нормальными оценками или по другим причинам. Как он пишет, наиболее простой ответ на то, почему так происходит, состоит в том, что люди – идиоты. Но поскольку «слишком тягостно представить себе, что вы идиот, окружены идиотами и руководят вами идиоты», то он приводит более развернутый список причин, по которым появляются безнадежные проекты.

И далее он подробно разбирает эти причины и логику развития проекта. И, поскольку попытки сделать проекты в логике «настоящего проектного управления» не прекращаются до сих пор, эта книга тоже сохраняет актуальность. Ищите и читайте!

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