Хабрахабр

[Из песочницы] Аллюр три креста, или Почему проекты так трудно закончить в срок

Поэтому в армии галоп носил неофициальное название аллюр три креста, а позже это выражение вошло в русский язык, имея смыслом максимально быстрое выполнение поручения начальства. Один крест (+) означал, что посыльный мог ехать к месту назначения шагом, два креста (++) означало рысь, три креста (+++) — незамедлительный галоп. [Википедия]

[Англо-русский словарь] Животные, попавшие в битум, не могут выбраться обратно, поэтому такие озера являются отличным местом для раскопок доисторических скелетов [Википедия]. Tar pit (англ., дословно смоляная яма) — 1) неразрешимая проблема, 2) битумное озеро (место, где подземный битум выходит на поверхность, создавая участок природного асфальта).

Как бы ни был силен или ловок зверь, в конечном итоге ему уготована гибель. «Воображение представляет динозавров, мамонтов и саблезубых тигров, пытающихся высвободиться из смолы. 16] С этого яркого образа начинается классическая книга Фредерика Брукса, впервые увидевшая свет в далеком 1975 году. Такой смоляной ямой в последнее десятилетие было программирование больших систем...» [1, с. 23]. Другая классическая книга, опубликованная в столь же древнем 1987-м, начинается ничуть не лучше: «А в это время где-то гибнет проект» [2, с. 14].
Идут годы, человечество вступает в новое тысячелетие, но и в 2014 году очередной бестселлер начинается все с той же вечной истории: «3 марта 2010 года Федеральное бюро расследований решило приостановить свой крупномасштабный и многообещающий план модернизации управления информацией… В бюро пытались обновить свою компьютерную систему уже более десяти лет, и, похоже, их постигла катастрофа» [3, с.

Шансы на успех в управлении проектами меньше, чем при подбрасывании монетки, и не похоже, чтобы они сильно росли: Через 44 года после Брукса мы можем с чистой совестью повторить: сейчас, когда вы читаете эти строки, очередной проект, подобно своим предшественникам, тонет все в той же смоляной яме.

По данным CHAOS Studies от Standish-Group [4]

Чтобы разобраться с этим вопросом, начнем с основной проблемы любого проекта, обозначенной во всем известной книге Брукса. Почему прогресс в науке управления (воплотившийся в 6 изданий PMBoK и нескольких десятках других толстых книг) за 40 лет (!) так и не привел к улучшению качества самого управления (если, конечно, под качеством управления понимать вероятность прибытия в заданную точку)?

Первая проблема: сложность создаваемого продукта

Даже сам Брукс называет «законом» положение, сформулированное в самом начале книги («Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше»). Если спросить первого попавшегося айтишника — «Что главное в Мифическом человеко-месяце?» — ответом скорее всего будет: «Что все человеко-месяцы разные, у новых работников совсем не те, что у старых». Но это лишь эмпирическое наблюдение, известное каждому, что хоть раз «менял коней на переправе»; вопрос заключается в том, как же планировать проект, когда все человеко-месяцы — разные?

Вот как Брукс формулирует свое понимание основной проблемы проектирования: «Мифический человеко-месяц» потому и стал бестселлером, что дает ответ на этот вопрос.

Сложность служит причиной трудности процесса общения между участниками бригады разработчиков, что ведет к ошибкам в продукте, превышению стоимости разработки, затягиванию выполнения графиков работ. "… классические трудности разработки программного обеспечения проистекают из этой сложности сущности и ее нелинейного роста при увеличении размера. 167] Сложность служит причиной трудности перечисления и тем более понимания всех возможных состояний программы, а отсюда возникает ее ненадежность… Сложность структуры служит причиной трудностей при развитии программ и добавлении новых функций так, чтобы не возникали побочные эффекты..." [1, с.

Как и любая реальная вещь, этот новый продукт (неважно, программный или «аппаратный») состоит из большого числа компонентов, способных на самые неожиданные взаимодействия (как негативные — талидомид, так и позитивные — виагра). Принципиальное отличие проекта от любого другого производства заключается в том, что создаваемый в нем проект производится впервые [мы в курсе, что многие задачи вроде «прикрутить счетчик посещений на сайт» тоже называются «проектами», но речь-то о настоящих проектах]. Предвидеть заранее, как все это будут работать вместе, чрезвычайно сложно, и для этого требуются в буквальном смысле «лучшие умы», а вовсе не бесконечные «человеко-месяцы»:

Создание программ является творческим процессом. «Выдающиеся проекты создаются выдающимися проектировщиками. 185-186] Крепкая методология может придать силу и освободить творческий ум, но она не может воспламенить или вдохновить того, кто занят нудной работой… Поэтому… я считаю, что единственное и наиболее важное усилие, которое мы можем предпринять — это развивать способы воспитания выдающихся проектировщиков» [1, с.

Но из него же следует и самый забываемый тезис Брукса — что в управлении проектами «нет серебряной пули»! Из основного положения Брукса (проектирование это творчество, а творческий процесс невозможно осуществлять толпой) прямо вытекает все реальное содержание «Мифического человеко-месяца»: и требования «диктатуры архитекторов», и «эффект второго проекта», и рекомендация «планируйте выбросить первую версию». Справляться со сложностью приходится каждый раз заново, и если таланта проектировщика для этого не хватит — проект не будет успешным. Сложность проектов объективна, ее невозможно преодолеть ни с помощью новых языков программирования (даже графических), ни подключением искусственного интеллекта.

С каждой строчкой нового кода, с каждой страницей технологической документации эта сложность растет, и растет нелинейно. Главный враг проекта по Бруксу — сложность создаваемого продукта. А одновременно с этим в распоряжении менеджера остается все меньше ресурсов — как времени, оставшегося до конца проекта, так и денег, оставшихся до конца бюджета:

В точке пересечения, или незадолго до нее становится ясно, что на самом деле проект требует намного больше денег и времени, чем предполагалось первоначально:

Цена вопроса — 451 миллион долларов, и система «Страж» будет полностью работоспособной в 2009 году… В марте 2010 года компания Lockheed Martin, подрядчик, опаздывала на год, осуществив лишь половину проекта и потратив 405 миллионов. К следующему проекту, названному «Страж», ФБР приступило сразу, в 2005 году. 17-18]. Для завершения, по оценкам независимых экспертов, ей потребовалось бы еще от шести до восьми лет, и дополнительно 350 миллионов долларов. [3, с.

Если мы с 1975 года знаем, что сложность проектов растет, к примеру, квадратично, — что мешает точно так же квадратично увеличивать бюджет и команду? Но позвольте! Почему все новые поколения менеджеров продолжают вести проекты с прогнозируемой успешностью в 30%, когда можно просто добавить денег?

Вот теперь пришло время перейти к следующей книге.

Вторая проблема: сложность совместной работы

«Около пятнадцати процентов проектов кончились ничем… В случае крупных проектов картина еще хуже, крах постиг двадцать пять процентов проектов, длительность которых составляла от двадцати пяти человеко-лет» [2, с. Как мы уже знаем, появившийся через двенадцать лет после «Мифического человеко-месяца» мировой бестселлер «Peopleware» («кадровое обеспечение», переведенное на русский как «Человеческий фактор») начинается с констатации высокой смертности проектов. 24] Это написано в 1987 году (еще был жив СССР!), со ссылкой на исследования 1981 года (еще был жив Брежнев); а что у нас на сегодняший день?

По данным CHAOS Report 2015 [5]

Как видите, с тех давних лет ситуация не изменилась: провал ожидает 26% средних проектов и 43% больших, и мы ничего не можем с этим поделать. Средний разработчик стоит сегодня 100К долларов в год, добавив накладные расходы, получим, что 25 человеко-лет — это примерно 3-6M долларов. Демарко и Листер спросили разработчиков о причинах провалов, и вот что получили в ответ: Но почему так происходит?

Чаще всего участники наших опросов в качестве причины краха называли »политику" «В подавляющем большинстве случаев не было ни одной объясняющей неудачу причины из области технологии.

«Политика», взаимоотношения людей внутри и вовне команды (то, что Демарко и Листер предпочли назвать «социологией») — вот что по мнению разработчиков больше всего мешало добиться успеха. Вовсе не сложность разрабатываемого продукта, и не недостаточность ресурсов, как можно было бы ожидать, глядя на «крест Брукса»!

«Мы встретили врага, и он это мы» [6]; у проекта обнаружился второй злейший враг — его собственная команда. Вдумайтесь в этот факт: те самые люди (разработчики, начальство и заказчики), которые на первый взгляд были больше всего заинтересованы в успехе, объединившись ради проекта, устраивали в нем «политику», чем и доводили проект до краха!

Вопрос в том, насколько меньше: Интуитивно понятно, что чем больше людей заняты в проекте, тем больше времени им придется тратить на организацию совместной работы, и тем меньше — на собственно разработку продукта.

2 из статьи Putnam, Myers [7] Рис.

Сопоставимые по размерам проекты завершались командами разной численности практически в одно и то же время, причем командам большей численности требовалось не меньше, а больше времени. Собрав численные характеристики 491 проекта по разработке программ от 35 до 95 тысяч строк кода, Патнэм и Майерс пришли к результатам, в которые практически невозможно поверить. Если представить те же результаты в терминах пресловутых человеко-месяцах, получается еще более выразительный график. Закон Брукса («добавить разработчиков — замедлить проект») оказался работающим не только при угрозе срыва проекта, но и с самого начала, начиная с добавления девятого программиста. Сколько денег (в месячных окладах) требуется, чтобы решить одну и ту же задачу силами команд разной численности:

3 из статьи Putnam, Myers [7] Рис.

В этом случае срок разработки будет одинаков у любых команд, что примерно и демонстрируют данные Патнема и Майерса. Полученные данные примерно укладываются в совершенно фантастическую закономерность: производительность разработчика в команде обратно пропорциональна ее численности. Верить этим данным или нет, личное дело каждого; но даже если и не верить, придется признать, что затраты времени на политику растут с размером команды нелинейно — а следовательно, на собственно работу в больших командах остается куда меньше времени.

Офисы опен-спейс, где начальству видно, кто отлынивает от работы (а работники постоянно отвлекают друг друга); детальное планирование и постоянные требования выдерживать сроки (заставляющие торопиться и ведущие увеличению числа ошибок); мелочная регламентация (заставляющая тратить массу времени на отчетность о проделанной работе и сдвигающая мотивацию работников с кода на «бумажку»). Книга Демарко и Листера содержит массу примеров «социологии», подменяющей работу над проектом работой по поддержанию «порядка» в коллективе. Все эти меры кажутся необходимыми для организации совместной работы — но, будучи применены в полном объеме, на саму работу уже не оставляют времени.

Увеличение численности проекта при современной организации работы (опен-спейс, жесткие сроки, детальная отчетность) не приводит к существенному росту производительности. Вот теперь мы можем понять, почему не работает способ «просто добавьте денег». Крест Демарко ставит крест на попытках повысить результативность проектов «экстенсивным» путем. Наоборот, чем больше команда проекта, тем выше риск, что она полностью погрязнет в бумажной работе по согласованию, кто чем занимается и на чьей стороне проблема.

Демарко и Листер рекомендовали это еще в 1987 году: Чтобы эффективно управлять людьми в области интеллектуального труда, необходимо принимать меры, противоположные перечисленным выше. [т.е. Но что если поменять сами принципы организации совместной деятельности? Предполагалось, что в Peopleware достаточно ясно написано, как должны выглядеть «противоположные» меры [на самом деле, нет]. регламентации, стандартизации, работы под страхом увольнения и запрета на какую-либо инициативу]. И где результат от книги, до сих пор входящей в must read любого менеджера? Посмотрим еще раз на график успешности проектов. Что-то не видать.

Неужели на пути к эффективному управлению проектами стоит еще один крест? Так почему?

Третья проблема: сложность планирования нового

Один из таких способов, ныне широко известный как Scrum, был описан в статье [8] еще в 1986 году, даже до выхода «Peopleware». На первый взгляд, третье препятствие на пути к совершенному управлению проекта заключается в необычности правильного способа руководства творческим процессом. Уже через несколько лет, в 1993 году Джефф Сазерленд впервые применил в своем проекте отдельные элементы Scrum, и остался доволен результатом:

Мы сдали комании Easel программный продукт в срок, уложившись в шесть месяцев, не выйдя за рамки бюджета и с минимальным количеством ошибок, — раньше такого никому не удавалось сделать

Все это время Scrum существовал как полусектантская методология, передаваемая буквально от учителя к ученику, и набирал популярность исключительно за счет «сарафанного радио». Однако подробное описание основных идей Scrum было издано лишь через двадцать лет, буквально на днях, в 2014-м году [3]. Все дело в том, что основная концепция Scrum, прямо вытекающая из его философии, не вписывалась в любую разумную логику управления:

28). Вот о чем я постоянно твержу руководству: «Я смогу назвать срок, только когда увижу, насколько эффективно будет действовать команда» [3, с.

Центром философии Scrum является категорический отказ от придумывания «заданного срока» с потолка (в отрыве от реальной команды и ее производительности), а первым следствием такого отказа — полностью нетрадиционный подход к планированию проекта: Если понимать под «управлением проектом» обеспечение создания продукта с заданными свойствами в заданный срок в пределах бюджета, получится, что Scrum вовсе не является «управлением»!

Возмущенный услышанным, он потребовал объяснений.
— Со сколькими диаграммами Ганта вы сталкивались за свою профессиональную деятельность? Я пошел к главе компании и заявил, что мы отказываемся от диаграмм Ганта. 50] — спросил я.
— С сотнями, — сказал он.
— Сколько из них соответствовали действительности?
— Ни одна, — ответил он, на минуту задумавшись.
Тогда я объяснил, что вместо никому не нужных графиков и таблиц к концу месяца мы дадим ему часть вполне работоспособной системы, которую он сам сможет опробовать и воочию убедиться, в правильном ли направлении идет разработка"
[3, c.

Но мы знаем, что такое «ошибка выживших», и прекрасно понимаем, что на одного такого босса найдется десять, которые пошлют подальше подобного «менеджера проектов». В рассказываемой Сазерлендом истории босс согласился попробовать. Какой идиот так делает? Что за бред, платить деньги под честное слово, что «мы будем работать и через месяц кое-что покажем»?

Лишь загнанный в угол руководитель, которому нечего терять, осмелится отказаться от базового принципа управления «ресурсы — только под план их использования». Из книги Сазерленда мы довольно точно знаем, какой: тот, кто уже пробовал сделать проект классическим способом, и потерпел катастрофическую неудачу. Конечно, через двадцать лет применения Scrum отношение к нему несколько изменилось, но и сегодня большинство разговоров «срок и сумму я назову, когда соберу команду и начну работать» рискуют на этом и закончиться.

Неужели нельзя было оставить диаграммы Ганта «для галочки» и сосредоточиться на организации работы команды (например, на ежедневных совещаниях стоя, в которых многие видят самое главное в Scrum)? Идеология Scrum настолько противоречит общепринятым представлениям о проекте («Заказчик обязуется оплатить, а Исполнитель выполнить следующие работы...»), что впору задаться вопросом: а почему Сазерленд вынужден был пойти на такой революционный шаг?

Судя по горячности, с которой Сазерленд атакует в своей книге «диаграммы Ганта», нельзя:

Такой подход неминуемо приводит к возникновению огромного количества документации, таблиц и диаграмм… Месяцы труда тратятся на то, чтобы предусмотреть все до мельчайших деталей, не допустить ни единого сбоя, не перерасходовать финансовых средств и продвигаться согласно графику. [3, c. При управлением проектами традиционно требуется наличие двух вещей — подконтрольность и предсказуемость. Но вместо того чтобы выбросить в мусорную корзину и сам план, и свой подход к нему, руководители делают вид, будто план работает… По сути, они платят людям за то, что те им лгут. [3, с. 23] Беда лишь в том, что как только этот превосходно отточенный план сталкивается с реальностью, он сразу рассыпается в прах. 20]

Составление детального плана и сметы проекта (обобщенно называемых Сазерлендом «диаграммой Ганта») не только само по себе требует значительных трудозатрат, но и ведет к принятию огромного числа проектных решений на основе фантазий планировщиков. Платят за то, что им лгут — вот в чем дело! Результат вполне предсказуем: Будучи утвержденными заказчиком, эти фантазии оказываются обязательными к исполнению, поскольку на них теперь завязан авторитет начальства («у нас все идет по плану!»).

23] Как правило, руководство не в курсе, что проект катится в пропасть, по крайней мере до того момента, пока не будут растрачены впустую миллионы долларов и тысячи часов работы [3, с.

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

Роль планирования в управлении творческой деятельностью напоминает анекдот: «Палка, которую я схватил, чтобы ударить змею, оказалась змеей». Любая команда (даже организованная по последнему слову аджайла, фасилитации и тимбилдинга), работающая по заранее составленному детальному плану, обречена выполнять тем больший процент работы «для галочки», чем сложнее и детализированнее был этот план.

Хочешь быстрее — тормози! [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
Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть