Один крест (+) означал, что посыльный мог ехать к месту назначения шагом, два креста (++) означало рысь, три креста (+++) — незамедлительный галоп. Поэтому в армии галоп носил неофициальное название аллюр три креста, а позже это выражение вошло в русский язык, имея смыслом максимально быстрое выполнение поручения начальства. [Википедия]
Tar pit (англ., дословно смоляная яма) — 1) неразрешимая проблема, 2) битумное озеро (место, где подземный битум выходит на поверхность, создавая участок природного асфальта). [Англо-русский словарь] Животные, попавшие в битум, не могут выбраться обратно, поэтому такие озера являются отличным местом для раскопок доисторических скелетов [Википедия].
«Воображение представляет динозавров, мамонтов и саблезубых тигров, пытающихся высвободиться из смолы. Как бы ни был силен или ловок зверь, в конечном итоге ему уготована гибель. Такой смоляной ямой в последнее десятилетие было программирование больших систем...» [1, с.16] С этого яркого образа начинается классическая книга Фредерика Брукса, впервые увидевшая свет в далеком 1975 году. Другая классическая книга, опубликованная в столь же древнем 1987-м, начинается ничуть не лучше: «А в это время где-то гибнет проект» [2, с.23]. Идут годы, человечество вступает в новое тысячелетие, но и в 2014 году очередной бестселлер начинается все с той же вечной истории: «3 марта 2010 года Федеральное бюро расследований решило приостановить свой крупномасштабный и многообещающий план модернизации управления информацией… В бюро пытались обновить свою компьютерную систему уже более десяти лет, и, похоже, их постигла катастрофа» [3, с.14].
Через 44 года после Брукса мы можем с чистой совестью повторить: сейчас, когда вы читаете эти строки, очередной проект, подобно своим предшественникам, тонет все в той же смоляной яме. Шансы на успех в управлении проектами меньше, чем при подбрасывании монетки, и не похоже, чтобы они сильно росли:
По данным CHAOS Studies от Standish-Group [4]
Почему прогресс в науке управления (воплотившийся в 6 изданий PMBoK и нескольких десятках других толстых книг) за 40 лет (!) так и не привел к улучшению качества самого управления (если, конечно, под качеством управления понимать вероятность прибытия в заданную точку)? Чтобы разобраться с этим вопросом, начнем с основной проблемы любого проекта, обозначенной во всем известной книге Брукса.
Первая проблема: сложность создаваемого продукта
Если спросить первого попавшегося айтишника — «Что главное в Мифическом человеко-месяце?» — ответом скорее всего будет: «Что все человеко-месяцы разные, у новых работников совсем не те, что у старых». Даже сам Брукс называет «законом» положение, сформулированное в самом начале книги («Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше»). Но это лишь эмпирическое наблюдение, известное каждому, что хоть раз «менял коней на переправе»; вопрос заключается в том, как же планировать проект, когда все человеко-месяцы — разные?
«Мифический человеко-месяц» потому и стал бестселлером, что дает ответ на этот вопрос. Вот как Брукс формулирует свое понимание основной проблемы проектирования:
"… классические трудности разработки программного обеспечения проистекают из этой сложности сущности и ее нелинейного роста при увеличении размера. Сложность служит причиной трудности процесса общения между участниками бригады разработчиков, что ведет к ошибкам в продукте, превышению стоимости разработки, затягиванию выполнения графиков работ. Сложность служит причиной трудности перечисления и тем более понимания всех возможных состояний программы, а отсюда возникает ее ненадежность… Сложность структуры служит причиной трудностей при развитии программ и добавлении новых функций так, чтобы не возникали побочные эффекты..." [1, с. 167]
Принципиальное отличие проекта от любого другого производства заключается в том, что создаваемый в нем проект производится впервые [мы в курсе, что многие задачи вроде «прикрутить счетчик посещений на сайт» тоже называются «проектами», но речь-то о настоящих проектах]. Как и любая реальная вещь, этот новый продукт (неважно, программный или «аппаратный») состоит из большого числа компонентов, способных на самые неожиданные взаимодействия (как негативные — талидомид, так и позитивные — виагра). Предвидеть заранее, как все это будут работать вместе, чрезвычайно сложно, и для этого требуются в буквальном смысле «лучшие умы», а вовсе не бесконечные «человеко-месяцы»:
«Выдающиеся проекты создаются выдающимися проектировщиками. Создание программ является творческим процессом. Крепкая методология может придать силу и освободить творческий ум, но она не может воспламенить или вдохновить того, кто занят нудной работой… Поэтому… я считаю, что единственное и наиболее важное усилие, которое мы можем предпринять — это развивать способы воспитания выдающихся проектировщиков» [1, с. 185-186]
Из основного положения Брукса (проектирование это творчество, а творческий процесс невозможно осуществлять толпой) прямо вытекает все реальное содержание «Мифического человеко-месяца»: и требования «диктатуры архитекторов», и «эффект второго проекта», и рекомендация «планируйте выбросить первую версию». Но из него же следует и самый забываемый тезис Брукса — что в управлении проектами «нет серебряной пули»! Сложность проектов объективна, ее невозможно преодолеть ни с помощью новых языков программирования (даже графических), ни подключением искусственного интеллекта. Справляться со сложностью приходится каждый раз заново, и если таланта проектировщика для этого не хватит — проект не будет успешным.
Главный враг проекта по Бруксу — сложность создаваемого продукта. С каждой строчкой нового кода, с каждой страницей технологической документации эта сложность растет, и растет нелинейно. А одновременно с этим в распоряжении менеджера остается все меньше ресурсов — как времени, оставшегося до конца проекта, так и денег, оставшихся до конца бюджета:
В точке пересечения, или незадолго до нее становится ясно, что на самом деле проект требует намного больше денег и времени, чем предполагалось первоначально:
К следующему проекту, названному «Страж», ФБР приступило сразу, в 2005 году. Цена вопроса — 451 миллион долларов, и система «Страх» будет полностью работоспособной в 2009 году… В марте 2010 года компания Lockheed Martin, подрядчик, опаздывала на год, осуществив лишь половину проекта и потратив 405 миллионов. Для завершения, по оценкам независимых экспертов, ей потребовалось бы еще от шести до восьми лет, и дополнительно 350 миллионов долларов. [3, с.17-18].
Но позвольте! Если мы с 1975 года знаем, что сложность проектов растет, к примеру, квадратично, — что мешает точно так же квадратично увеличивать бюджет и команду? Почему все новые поколения менеджеров продолжают вести проекты с прогнозируемой успешностью в 30%, когда можно просто добавить денег?
Вот теперь пришло время перейти к следующей книге.
Вторая проблема: сложность совместной работы
Как мы уже знаем, появившийся через двенадцать лет после «Мифического человеко-месяца» мировой бестселлер «Peopleware» («кадровое обеспечение», переведенное на русский как «Человеческий фактор») начинается с констатации высокой смертности проектов. «Около пятнадцати процентов проектов кончились ничем… В случае крупных проектов картина еще хуже, крах постиг двадцать пять процентов проектов, длительность которых составляла от двадцати пяти человеко-лет» [2, с.24] Это написано в 1987 году (еще был жив СССР!), со ссылкой на исследования 1981 года (еще был жив Брежнев); а что у нас на сегодняший день?
По данным CHAOS Report 2015 [5]
Средний разработчик стоит сегодня 100К долларов в год, добавив накладные расходы, получим, что 25 человеко-лет — это примерно 3-6M долларов. Как видите, с тех давних лет ситуация не изменилась: провал ожидает 26% средних проектов и 43% больших, и мы ничего не можем с этим поделать. Но почему так происходит? Демарко и Листер спросили разработчиков о причинах провалов, и вот что получили в ответ:
«В подавляющем большинстве случаев не было ни одной объясняющей неудачу причины из области технологии. Чаще всего участники наших опросов в качестве причины краха называли »политику"
Вовсе не сложность разрабатываемого продукта, и не недостаточность ресурсов, как можно было бы ожидать, глядя на «крест Брукса»! «Политика», взаимоотношения людей внутри и вовне команды (то, что Демарко и Листер предпочли назвать «социологией») — вот что по мнению разработчиков больше всего мешало добиться успеха.
Вдумайтесь в этот факт: те самые люди (разработчики, начальство и заказчики), которые на первый взгляд были больше всего заинтересованы в успехе, объединившись ради проекта, устраивали в нем «политику», чем и доводили проект до краха! «Мы встретили врага, и он это мы» [6]; у проекта обнаружился второй злейший враг — его собственная команда.
Интуитивно понятно, что чем больше людей заняты в проекте, тем больше времени им придется тратить на организацию совместной работы, и тем меньше — на собственно разработку продукта. Вопрос в том, насколько меньше:
Рис. 2 из статьи Putnam, Myers [7]
Собрав численные характеристики 491 проекта по разработке программ от 35 до 95 тысяч строк кода, Патнэм и Майерс пришли к результатам, в которые практически невозможно поверить. Сопоставимые по размерам проекты завершались командами разной численности практически в одно и то же время, причем командам большей численности требовалось не меньше, а больше времени. Закон Брукса («добавить разработчиков — замедлить проект») оказался работающим не только при угрозе срыва проекта, но и с самого начала, начиная с добавления девятого программиста. Если представить те же результаты в терминах пресловутых человеко-месяцах, получается еще более выразительный график. Сколько денег (в месячных окладах) требуется, чтобы решить одну и ту же задачу силами команд разной численности:
Рис. 3 из статьи Putnam, Myers [7]
Полученные данные примерно укладываются в совершенно фантастическую закономерность: производительность разработчика в команде обратно пропорциональна ее численности. В этом случае срок разработки будет одинаков у любых команд, что примерно и демонстрируют данные Патнема и Майерса. Верить этим данным или нет, личное дело каждого; но даже если и не верить, придется признать, что затраты времени на политику растут с размером команды нелинейно — а следовательно, на собственно работу в больших командах остается куда меньше времени.
Книга Демарко и Листера содержит массу примеров «социологии», подменяющей работу над проектом работой по поддержанию «порядка» в коллективе. Офисы опен-спейс, где начальству видно, кто отлынивает от работы (а работники постоянно отвлекают друг друга); детальное планирование и постоянные требования выдерживать сроки (заставляющие торопиться и ведущие увеличению числа ошибок); мелочная регламентация (заставляющая тратить массу времени на отчетность о проделанной работе и сдвигающая мотивацию работников с кода на «бумажку»). Все эти меры кажутся необходимыми для организации совместной работы — но, будучи применены в полном объеме, на саму работу уже не оставляют времени.
Вот теперь мы можем понять, почему не работает способ «просто добавьте денег». Увеличение численности проекта при современной организации работы (опен-спейс, жесткие сроки, детальная отчетность) не приводит к существенному росту производительности. Наоборот, чем больше команда проекта, тем выше риск, что она полностью погрязнет в бумажной работе по согласованию, кто чем занимается и на чьей стороне проблема. Крест Демарко ставит крест на попытках повысить результативность проектов «экстенсивным» путем.
Но что если поменять сами принципы организации совместной деятельности? Демарко и Листер рекомендовали это еще в 1987 году: Чтобы эффективно управлять людьми в области интеллектуального труда, необходимо принимать меры, противоположные перечисленным выше. [т.е. регламентации, стандартизации, работы под страхом увольнения и запрета на какую-либо инициативу]. Предполагалось, что в Peopleware достаточно ясно написано, как должны выглядеть «противоположные» меры [на самом деле, нет]. Посмотрим еще раз на график успешности проектов. И где результат от книги, до сих пор входящей в must read любого менеджера? Что-то не видать.
Так почему? Неужели на пути к эффективному управлению проектами стоит еще один крест?
Третья проблема: сложность планирования нового
На первый взгляд, третье препятствие на пути к совершенному управлению проекта заключается в необычности правильного способа руководства творческим процессом. Один из таких способов, ныне широко известный как Scrum, был описан в статье [8] еще в 1986 году, даже до выхода «Peopleware». Уже через несколько лет, в 1993 году Джефф Сазерленд впервые применил в своем проекте отдельные элементы Scrum, и остался доволен результатом:
Мы сдали комании Easel программный продукт в срок, уложившись в шесть месяцев, не выйдя за рамки бюджета и с минимальным количеством ошибок, — раньше такого никому не удавалось сделать
Однако подробное описание основных идей Scrum было издано лишь через двадцать лет, буквально на днях, в 2014-м году [3]. Все это время Scrum существовал как полусектантская методология, передаваемая буквально от учителя к ученику, и набирал популярность исключительно за счет «сарафанного радио». Все дело в том, что основная концепция Scrum, прямо вытекающая из его философии, не вписывалась в любую разумную логику управления:
Вот о чем я постоянно твержу руководству: «Я смогу назвать срок, только когда увижу, насколько эффективно будет действовать команда» [3, с.28).
Если понимать под «управлением проектом» обеспечение создания продукта с заданными свойствами в заданный срок в пределах бюджета, получится, что Scrum вовсе не является «управлением»! Центром философии Scrum является категорический отказ от придумывания «заданного срока» с потолка (в отрыве от реальной команды и ее производительности), а первым следствием такого отказа — полностью нетрадиционный подход к планированию проекта:
Я пошел к главе компании и заявил, что мы отказываемся от диаграмм Ганта. Возмущенный услышанным, он потребовал объяснений.
— Со сколькими диаграммами Ганта вы сталкивались за свою профессиональную деятельность? — спросил я.
— С сотнями, — сказал он.
— Сколько из них соответствовали действительности?
— Ни одна, — ответил он, на минуту задумавшись.
Тогда я объяснил, что вместо никому не нужных графиков и таблиц к концу месяца мы дадим ему часть вполне работоспособной системы, которую он сам сможет опробовать и воочию убедиться, в правильном ли направлении идет разработка" [3, c.50]
В рассказываемой Сазерлендом истории босс согласился попробовать. Но мы знаем, что такое «ошибка выживших», и прекрасно понимаем, что на одного такого босса найдется десять, которые пошлют подальше подобного «менеджера проектов». Что за бред, платить деньги под честное слово, что «мы будем работать и через месяц кое-что покажем»? Какой идиот так делает?
Из книги Сазерленда мы довольно точно знаем, какой: тот, кто уже пробовал сделать проект классическим способом, и потерпел катастрофическую неудачу. Лишь загнанный в угол руководитель, которому нечего терять, осмелится отказаться от базового принципа управления «ресурсы — только под план их использования». Конечно, через двадцать лет применения Scrum отношение к нему несколько изменилось, но и сегодня большинство разговоров «срок и сумму я назову, когда соберу команду и начну работать» рискуют на этом и закончиться.
Идеология Scrum настолько противоречит общепринятым представлениям о проекте («Заказчик обязуется оплатить, а Исполнитель выполнить следующие работы...»), что впору задаться вопросом: а почему Сазерленд вынужден был пойти на такой революционный шаг? Неужели нельзя было оставить диаграммы Ганта «для галочки» и сосредоточиться на организации работы команды (например, на ежедневных совещаниях стоя, в которых многие видят самое главное в Scrum)?
Судя по горячности, с которой Сазерленд атакует в своей книге «диаграммы Ганта», нельзя:
При управлением проектами традиционно требуется наличие двух вещей — подконтрольность и предсказуемость. Такой подход неминуемо приводит к возникновению огромного количества документации, таблиц и диаграмм… Месяцы труда тратятся на то, чтобы предусмотреть все до мельчайших деталей, не допустить ни единого сбоя, не перерасходовать финансовых средств и продвигаться согласно графику. [3, c.23] Беда лишь в том, что как только этот превосходно отточенный план сталкивается с реальностью, он сразу рассыпается в прах. Но вместо того чтобы выбросить в мусорную корзину и сам план, и свой подход к нему, руководители делают вид, будто план работает… По сути, они платят людям за то, что те им лгут. [3, с.20]
Платят за то, что им лгут — вот в чем дело! Составление детального плана и сметы проекта (обобщенно называемых Сазерлендом «диаграммой Ганта») не только само по себе требует значительных трудозатрат, но и ведет к принятию огромного числа проектных решений на основе фантазий планировщиков. Будучи утвержденными заказчиком, эти фантазии оказываются обязательными к исполнению, поскольку на них теперь завязан авторитет начальства («у нас все идет по плану!»). Результат вполне предсказуем:
Как правило, руководство не в курсе, что проект катится в пропасть, по крайней мере до того момента, пока не будут растрачены впустую миллионы долларов и тысячи часов работы [3, с.23]
Сазерленд обнаружил и описал совершенно объективную особенность любого процесса управления: планирование подменяет реально необходимые задачи (возникающие по ходу проекта) задачами умозрительными (придуманными заранее), и отдает безусловный приоритет последним. И хотя сам Сазерленд не сформулировал соответствующего «закона», мы можем сделать это за него, нарисовав:
Любая команда (даже организованная по последнему слову аджайла, фасилитации и тимбилдинга), работающая по заранее составленному детальному плану, обречена выполнять тем больший процент работы «для галочки», чем сложнее и детализированнее был этот план. Роль планирования в управлении творческой деятельностью напоминает анекдот: «Палка, которую я схватил, чтобы ударить змею, оказалась змеей».
Хочешь быстрее — тормози! [9]
Теперь мы гораздо лучше представляем себе, что означает «аллюр три креста» в управлении проектами. Привычные методы, которые мы применяем для улучшения ситуации, на деле ее ухудшают. Тщательный сбор требований «лишь бы не пропустить что-то важное» приводит к огромному числу функций, которые практически невозможно реализовать в разумные сроки. Привлечение большого числа разработчиков влечет за собой резкий рост управленческих расходов («на одного работающего десять менеджеров») и снижает общую продуктивность команды. Тщательное планирование с целью не потратить ни одного лишнего цента создает огромный объем лишней работы, из-за которой тратятся зря миллионы долларов.
Почему так происходит? Что за проклятие тяготеет над проектированием новых вещей? Да все то же — сложность. Как только вместо борьбы с самой сложностью (упрощения) мы пытаемся взять ее под контроль с помощью другой сложности — вызванный демон набрасывается на нас с новой силой. Единственный способ справиться с проектом — это справиться со сложностью.
Предложенные в мировых бестселлерах способы сводятся именно к этому. Использовать гениальных проектировщиков, умеющих отсеять лишние требования и организовать оставшиеся в «собирающуюся» систему. Дать людям работать, минимизировав управляющие воздействия (то есть «политику»). Отказаться от избыточного планирования, направив сэкономленное время на саму работу. Простые по смыслу способы, единственный недостаток которых — отсутствие подробных инструкций, как это сделать. Борьба со сложностью ждет своего воплощения в развитую методологию управления, которая позволит наконец поменять неутешительную статистику успешности проектов.
- [1] Брукс Ф. «Мифический человеко-месяц или как создаются программные системы», СПб, Символ-Плюс, 2007
- [2] Демарко Т., Листер Т. «Человеческий фактор: успешные проекты и команды», СПб, Символ-Плюс, 2005
- [3] Сазерленд, Джефф. «Scrum. Революционный метод управления проектами», М., Манн, Иванов и Фербер, 2016
- [4] de.wikipedia.org/wiki/Chaos-Studie
- [5] CHAOS REPORT 2015
- [6] We have met the enemy
- [7] Putnam, Myers «Familiar Metric Management — Small is Beautiful-Once Again», 1998
- [8] Такеучи, Нонака «Разработка нового продукта: новые правила игры» (1986), русский перевод
- [9] Маковецкий П.В. «Смотри в корень!», М., 1966
Автор: Сергей Щеглов
