Фреймворк управления и анализа проектов DaShe

В один из долгих зимних вечеров, когда спать еще рано, а все дела уже сделаны, в мессенджер к исследователю власти постучался продакт-менеджер.

– Про Власть у тебя замечательно получилось, – написал он после обычных расшаркиваний, – но есть задачка потруднее.

– Еще труднее? – удивился исследователь. – И какая же?

– Управление проектами, – ответил продакт-менеджер. – Мы должны написать об этом книгу.

– Да этих книг уже столько написано… – начал было исследователь и вдруг остановился.

– Да, – подтвердил его догадку продакт-менеджер. – Именно поэтому.

Когда-то для жизни хватало умения пахать землю, стрелять зверя и строить избу. Промышленная революция заставила нас производить товары – больше, дешевле, надежнее. XX век потребовал сделать из товаров продукты – красивые, удобные, в привлекательной упаковке. А затем пришел век XXI, и выяснилось, что даже этого недостаточно. Теперь потребитель желает новых продуктов – модных, современных, не таких, как вчера.

Популярность «проектов» (проявляющаяся, например, во все большей востребованности проджект-менеджеров по сравнению с просто менеджерами) – естественная реакция бизнеса на требования времени. Чтобы производить товары и просто продукты, нужен завод с настроенными бизнес-процессами; но чтобы сделать новый продукт, его нужно сначала спроектировать – то есть в буквальном смысле придумать «то, не знаю что».

«То, не знаю что» здесь не метафора, а точное описание задачи. От 80 до 95 % новых продуктов терпят неудачу на рынке – как раз потому, что их разработчики (и заказчики) не смогли узнать, чего же хотят потребители. Около 30 % проектов заканчиваются безрезультатно – задачу создания нового продукта не получается решить даже неправильно. В отличие от процессной деятельности по производству уже известных продуктов (в которой достаточно соблюдать правила – и результат будет), проектная деятельность до сих пор остается в значительной степени непонятной.

Сотни написанных книг по управлению проектами – лучшее тому подтверждение. Почти сто лет проектный менеджмент шел по стопам процессного (диаграммы Ганта придуманы в 1910-е годы, метод критического пути создан в 1950-е, первое издание PMBoK вышло в 1987 году), пока в самом начале XXI века не выяснилось, что это был путь в никуда. Аджайл-манифест, или манифест гибкой разработки продуктов, зафиксировал, что проектная деятельность является полной противоположностью процессной: люди в ней важнее регламентов, работающий продукт – важнее документации, готовность к изменениям – важнее согласованных планов. За следующие 20 лет аджайл-методологии стали мейнстримом (71 % компаний в 2020 году использовали для проектирования именно аджайл, а не PMBoK и аналогичные «тяжелые» методологии), и сегодня из трех собравшихся в баре проджект-менеджеров четверо оказываются скрам-мастерами, отвечающими за работу команды. Но в срок и в бюджет по-прежнему укладывается лишь треть проектов, а выпущенные продукты все так же чаще всего «не попадают» в цель. Отказ от процессных методологий оказался немногим более продуктивен, чем их бездумное применение.

А значит, нужно двигаться дальше.

0.1. Основная идея: сложность и риски

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

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

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

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

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

Технологии управления проектами развиваются более 50 лет, но, несмотря на это, шансы на успех среднего проекта все еще меньше 50 %. Причина – нелинейный (квадратичный и более) рост сложности по мере увеличения объема проекта (количества функций, реализуемых создаваемым продуктом). Сложность влечет за собой появление неконтролируемых рисков, которые реализуются в возникающих непредвиденных ситуациях, влекущих за собой перерасход бюджета, увеличение сроков и в худшем варианте – принципиальную невозможность выпуска продукта. DaShe нацелен на систематическое ограничение сложности всех составляющих проектной деятельности, что позволяет сохранить контроль над рисками и обеспечить тем самым благополучное завершение проекта.

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

0.2. DaShe: методология – «швейцарский нож»

DaShe – фреймворк управления проектами, нацеленный на максимизацию вероятности успеха, под которым понимается получение ожидаемого результата (продукта) с соблюдением заданных сроков, бюджета и отсутствием скрытых рисков.

Прагматический подход, реализуемый в DaShe на основе парадигмы «сложность – риски», заключается в том, чтобы:

1) предоставить проджект-менеджеру достаточно обширный чек-лист потенциальных рисков и методов их минимизации;

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

Если PMBoK можно сравнить с целым заводом по производству проектной документации, а скрам (от англ. scrum – «схватка») – с курилкой при этом заводе, то DaShe окажется «швейцарским ножом» или чемоданчиком с инструментами, которые всегда полезно иметь под рукой.

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

Как система знаний DaShe состоит:

1) из концепции (парадигмы, принципов и постоянно употребляемых терминов);

2) фреймворка (последовательности применения методов при реализации проекта);

3) библиотеки методов (которые можно применять и независимо от фреймворка в целом).

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

Таким образом, DaShe дает пользователю три уровня возможностей. На нижнем уровне DaShe – это набор работающих методов, применяемых на разных этапах проектной деятельности. Каждый из этих методов автономен, проверен практикой (в большинстве случаев – мировой, в остальных – практикой авторов) и успешно устраняет соответствующие риски. Использовать DaShe в качестве справочника «Что делать, если…» можно и не вникая в оставшиеся два уровня; однако они становятся необходимыми, когда перед вами возникает проблема, для которой в текущей версии DaShe еще нет метода. Следующий уровень DaShe – фреймворк – представляет собой оптимальную последовательность применения методов. Фреймворк позволяет пользователю понять, в какой момент обращать внимание на те или иные риски, чтобы они не переросли в серьезные проблемы. Фреймворк начинает проект с устранения наиболее опасных – политических – рисков, затем переходит к рискам в формировании идеи продукта и лишь после этого позволяет менеджеру обратить внимание на куда более привычные, но значительно менее критичные риски вроде перерасхода бюджета или увеличения сроков проекта. Последним уровнем DaShe является концепция:

1) общее понимание проектной деятельности, позволяющее увидеть главные риски в любой ситуации;

2) ее онтология (набор категорий), позволяющая понять, к какой сфере относится возникшая проблема;

3) основные принципы, позволяющие ориентироваться в существующих методах и создавать новые, тем самым повышая личную квалификацию проджект-менеджера.

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

В 1988 году профессор Университета Талсы (США) Поль Левицки (Paul Lewicky) опубликовал результат экспериментов, связанных со способностью людей определять сложные зависимости. Эксперимент заключался в том, что перед испытуемым помещался экран, разделенный на четыре части, и на каждом шаге только в одной из них появлялся крестик (Х). Испытуемый должен был угадать, в каком месте появится следующий крестик. В случаях, когда алгоритм был простым (например, по часовой стрелке или зигзагом), испытуемые его быстро разгадывали и сообщали экспериментатору, где появится крестик. А вот если алгоритм оказывался более сложным («крестик не появляется в одном и том же квадрате, не появившись в двух других»), испытуемые начинали его «чувствовать» (и угадывать чаще), но не могли объяснить, как именно они определяют, где появится крестик!

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

1) формулировать какие-то правила и им следовать;

2) обучаться интуитивно, без возможности сознательно сформулировать, почему надо нажимать именно эту кнопку, – и как раз этот способ и отвечает за творчество.

Основное отличие проектной деятельности от процессной заключается в том, что в проекте критически важным ресурсом являются творческие усилия человека, непонятные ему самому. В проекте мы не можем сказать разработчику: сделай так-то и так-то и отчитайся о выполнении. Мы можем только сказать: ты должен угадать, где появится крестик (какая особенность нового продукта сделает его бестселлером).

Однако невозможность прямых указаний разработчикам – это только половина проблемы. В 1962 году профессор Принстона Сэм Глюксберг продемонстрировал парадоксальную особенность творческого мышления на простейшей «задаче о свечке» (испытуемому выдается свечка, спички и коробка кнопок, требуется прикрепить свечку к стене и зажечь). Для человека, не знающего решения, эта задача требует некоторого творческого усилия: сообразить, что коробка от кнопок является отдельным звеном и ее можно (в отличие от свечки) прикнопить к стене. Так вот, в случаях, когда испытуемым было обещано денежное вознаграждение за решение задачи в отведенный срок, результаты оказывались хуже (меньшее число решивших задачу правильно), чем при бесплатных испытаниях. Традиционная мотивация – «длинным долларом» – тормозит творческое мышление, заставляя человека переключаться в более привычный режим «следовать правилам». Поэтому разработчиков проекта нельзя мотивировать теми же способами, что и в процессной деятельности; тут требуются более тонкие методы (которые и описаны в соответствующем разделе DaShe).

Онтология (набор категорий) DaShe используется для распределения методов по этапам проекта. Проект в DaShe – это сущность, состоящая из следующих компонентов:

1) ресурсы;

2) продукт;

3) проектная деятельность.

Проектная деятельность, в свою очередь, разделяется на разработку и сопровождение; однако в последнее время наблюдается тенденция сразу переходить к сопровождению, выбрасывая на рынок совершенно «сырые» продукты, чтобы как можно раньше получить от потребителей обратную связь. Тем не менее в любом проекте существует этап изготовления MVP (Minimum Viable Product – минимально жизнеспособный продукт), на котором реальных пользователей у него еще нет и применение методов сопровождения не требуется.

Полный жизненный цикл проекта состоит из следующих итерационно повторяющихся этапов:

1) поиск и привлечение ресурсов;

2) создание продукта (бэклога);

3) разработка MVP;

4) «непрерывная интеграция» (сопровождение и развитие продукта).

Нетрудно заметить, что в непрерывную интеграцию всегда входят первые три этапа: реакция на запросы рынка/заказчика точно так же требует привлечения ресурсов, создания новой версии продукта и ее разработки до стадии готового изделия.

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

1) объективность;

2) «принцип одной лодки»: проблемы любого аффилянта – это проблемы проекта в целом;

3) «принцип самолета»: с момента запуска проект непрерывно летит, расходуя ресурсы, даже когда не приближается к результату;

4) все люди разные, поэтому каждый проект уникален, и для каждого нужен свой собственный комплект «дискурс + нарративы»;

5) «недеяние» (созерцательная пассивность), «сад талантов», подстрижка, подкормка, создание условий и т. д. в определенное время.

0.3. В любой непонятной ситуации: самый востребованный метод

Теперь, когда все общие слова сказаны, для завершения знакомства с DaShe вам осталось лишь прочитать описание какого-нибудь метода. А еще лучше – метода, который требуется буквально на каждом шагу и который иногда является единственным способом справиться с возникающими проблемами. Речь идет о таком простом действии, как поиск информации в интернете, – но как раз потому, что это действие выглядит очень простым и давно совершается на автомате, чрезвычайно важно совершать его правильно.

Нет ничего проще, чем найти веб-страницы, содержащие фамилию известного человека или название определенного продукта. Однако в реальных поисковых задачах ключевые слова попросту неизвестны; например, нам нужно понять действия людей, принимающих решение о покупке металлорежущих станков, – что вбивать в строку поиска?!

В таких случаях одного и даже десяти запросов недостаточно, и поиск необходимо вести по определенному алгоритму. В DaShe этот алгоритм называется «Погружение в тему» и представляет собой процесс конкретизации описания предметной области от самого общего (несколько слов) до пригодного к использованию в проекте (детальное описание плюс коллекция веб-страниц). Пригодность результата оценивается по критерию “Five Ws + Two How” – то есть по наличию ответов на семь контрольных вопросов. Благодаря этому результатом погружения в тему оказывается не найденная где-то в Сети случайная веб-страница с информацией, а сформированное в ходе поиска понимание предметной области, которое, как правило, решает исходную проблему.

Нужно заметить, что, в отличие от простого поиска, когда нужная страница находится в течение нескольких минут или нескольких часов, решение сложной поисковой задачи потребует от нескольких дней до нескольких недель.

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

Погружение в тему обеспечивается итерационным уточнением набора ключевых слов до тех пор, пока результаты не дадут ответы на все контрольные вопросы.

1. Формируется первичный (заведомо недостаточный) список ключевых слов («металлорежущие станки» и найденные по словарю синонимы).

2. На полученных в выдаче веб-страницах ищутся:

1) источники информации по теме (сайты, книги, журналы, форумы, новостные агрегаторы и т. д.);

2) новые ключевые слова, более подходящие для целей поиска.

3. Источники информации внимательно прочитываются, ключевая информация помещается в отдельный файл со ссылками на источник. Появившиеся по ходу чтения идеи записываются туда же.

4. Проверяется достаточность понимания темы. Критерий – способность ответить на все семь контрольных вопросов: кто, что, где, когда, как, почему и сколько (Five Ws + Two How). В нашем примере с металлорежущими станками нужно получить перечень типов субъектов, принимающих решение о закупках (кто), количество и типы заключаемых ими сделок (что), места их профессионального и личного общения – форумы, аккаунты в соцсетях (где), бюджетные циклы и сезонность сделок (когда), порядок подготовки и принятия решений (как), мотивы субъектов, принимающих решение о закупках (почему), и, наконец, примерные объемы закупок (сколько).

По контрольным вопросам становится понятно отличие в объеме информации, выдаваемой по первоначальному запросу «закупки металлорежущих станков» и появившейся в результате погружения в тему. Метод применяется для того, чтобы информация была не «проходной», а достаточной для возникновения нетривиальных идей в конкретной области, и тем самым минимизирует риск отсутствия креатива в разработке продукта.

5. Если понимания недостаточно для ответа на все вопросы, шаги повторяются начиная с пункта 1, но уже с новым набором ключевых слов.

Результат: достаточное для возникновения новых идей описание предметной области.

На этом краткое знакомство с DaShe закончено. Дальше начинается сам фреймворк.

– Почему вы сдали крепость?

– На то было много причин. Во-первых, у нас не было пороха…

Желание запустить проект может возникнуть у стейкхолдеров по любому поводу. «Есть свободные деньги, надо инвестировать их в какой-нибудь стартап». «Пора уже переделать корпоративную систему работы с клиентами». «До следующего большого заказа целый год, надо занять чем-то разработчиков, чтобы не разбежались», и т. д., с бесконечным числом вариантов. Но какой бы ни была начальная идея, каждый раз речь идет о чем-то таком, чего в практике стейкхолдеров еще не было и что нельзя создать простым указанием: «С сегодняшнего дня начинайте отгрузку изделия ХХХ». Речь идет о создании не просто нового продукта, но и о создании организации, которая его сделает, – команды проекта.

«Перед тем как ехать, нужно собрать машину». Управление проектом отличается от управления производством не только необходимостью каждый день изобретать что-то новенькое, но и тем, что изобретать это новенькое поначалу просто некому. В случае производства управляемая система – отдел, цех, предприятие – уже существует; известен и производимый ею продукт, и технологии его производства, требуется лишь обеспечивать соблюдение этих технологий. Классический менеджмент можно сравнить с ежедневной поездкой на автомобиле по одному и тому же маршруту: да, некоторые улицы закрывают на ремонт, в дороге встречаются пробки, автомобиль иногда ломается, но в целом и автомобиль, и улицы, и пункт назначения одни и те же. А вот в начале любого проекта никакой управляемой системы не существует; команды проекта еще нет, используемые технологии не выбраны, и даже конечный результат обрисован весьма приблизительно. Проектный менеджмент – это каждый раз сборка нового «автомобиля», наилучшим образом подходящего для одной-единственной поездки, причем сборка эта осуществляется прямо во время движения. Помните анекдот про автомеханика и хирурга, когда последний заводит машину и говорит автомеханику: «Вот теперь – чини!»? Точно так же отличается работа просто менеджера и проджект-менеджера.

Реальная «сборка машины» в DaShe производится на этапе разработки, поскольку только на нем становятся понятны все требования и ограничения, существующие в проекте. Но чтобы такая «сборка» оказалась успешной, для нее нужно подготовить «комплектующие» (ресурсы) и задать «маршрут» (бэклог). Тогда станет более-менее понятно: делать для машины обтекаемый корпус и гнать по шоссе или же оснащать ее большими колесами на автономной подвеске и пробираться по бездорожью. Обратите внимание: точно так же, как разные маршруты требуют разных автомобилей, разные продукты должны создаваться разными командами; успех какой-то команды в проекте «по шоссе» – скорее минус, чем плюс, для проекта «по бездорожью»!