Фреймворк управления и анализа проектов DaShe
Фреймворк управления и анализа проектов DaShe
Сергей Игоревич Щеглов
Петр Давыденков
Сергей Щеглов и Петр Давыденков предложили 77 методов, которые помогут расправиться с трудностями в проектном менеджменте. Менеджер – не супермен, невозможно уметь решать все проблемы без исключения. Но книга поможет не совершать критических ошибок и по максимуму использовать открывающиеся возможности.
В формате PDF A4 сохранен издательский макет книги.
Сергей Щеглов, Петр Давыденков
Фреймворк управления и анализа проектов DaShe
© Щеглов С. И., наследники, 2023
© Давыденков П. И., 2023
© Издание, оформление. ООО Группа Компаний «РИПОЛ классик», 2024
Памяти Сергея Игоревича Щеглова
(1965–2021)
Проект – это временное предприятие, направленное на создание уникального продукта, услуги или результата.
Project Management Body of Knowledge, PMBoK
0. Почему 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) Метод «Погружение в тему»
Погружение в тему обеспечивается итерационным уточнением набора ключевых слов до тех пор, пока результаты не дадут ответы на все контрольные вопросы.
1. Формируется первичный (заведомо недостаточный) список ключевых слов («металлорежущие станки» и найденные по словарю синонимы).
2. На полученных в выдаче веб-страницах ищутся:
1) источники информации по теме (сайты, книги, журналы, форумы, новостные агрегаторы и т. д.);
2) новые ключевые слова, более подходящие для целей поиска.
3. Источники информации внимательно прочитываются, ключевая информация помещается в отдельный файл со ссылками на источник. Появившиеся по ходу чтения идеи записываются туда же.
4. Проверяется достаточность понимания темы. Критерий – способность ответить на все семь контрольных вопросов: кто, что, где, когда, как, почему и сколько (Five Ws + Two How). В нашем примере с металлорежущими станками нужно получить перечень типов субъектов, принимающих решение о закупках (кто), количество и типы заключаемых ими сделок (что), места их профессионального и личного общения – форумы, аккаунты в соцсетях (где), бюджетные циклы и сезонность сделок (когда), порядок подготовки и принятия решений (как), мотивы субъектов, принимающих решение о закупках (почему), и, наконец, примерные объемы закупок (сколько).
По контрольным вопросам становится понятно отличие в объеме информации, выдаваемой по первоначальному запросу «закупки металлорежущих станков» и появившейся в результате погружения в тему. Метод применяется для того, чтобы информация была не «проходной», а достаточной для возникновения нетривиальных идей в конкретной области, и тем самым минимизирует риск отсутствия креатива в разработке продукта.
5. Если понимания недостаточно для ответа на все вопросы, шаги повторяются начиная с пункта 1, но уже с новым набором ключевых слов.
Результат: достаточное для возникновения новых идей описание предметной области.
На этом краткое знакомство с DaShe закончено. Дальше начинается сам фреймворк.
1. Ресурсы
– Почему вы сдали крепость?
– На то было много причин. Во-первых, у нас не было пороха…
Один из вариантов бородатого анекдота
Желание запустить проект может возникнуть у стейкхолдеров по любому поводу. «Есть свободные деньги, надо инвестировать их в какой-нибудь стартап». «Пора уже переделать корпоративную систему работы с клиентами». «До следующего большого заказа целый год, надо занять чем-то разработчиков, чтобы не разбежались», и т. д., с бесконечным числом вариантов. Но какой бы ни была начальная идея, каждый раз речь идет о чем-то таком, чего в практике стейкхолдеров еще не было и что нельзя создать простым указанием: «С сегодняшнего дня начинайте отгрузку изделия ХХХ». Речь идет о создании не просто нового продукта, но и о создании организации, которая его сделает, – команды проекта.
«Перед тем как ехать, нужно собрать машину». Управление проектом отличается от управления производством не только необходимостью каждый день изобретать что-то новенькое, но и тем, что изобретать это новенькое поначалу просто некому. В случае производства управляемая система – отдел, цех, предприятие – уже существует; известен и производимый ею продукт, и технологии его производства, требуется лишь обеспечивать соблюдение этих технологий. Классический менеджмент можно сравнить с ежедневной поездкой на автомобиле по одному и тому же маршруту: да, некоторые улицы закрывают на ремонт, в дороге встречаются пробки, автомобиль иногда ломается, но в целом и автомобиль, и улицы, и пункт назначения одни и те же. А вот в начале любого проекта никакой управляемой системы не существует; команды проекта еще нет, используемые технологии не выбраны, и даже конечный результат обрисован весьма приблизительно. Проектный менеджмент – это каждый раз сборка нового «автомобиля», наилучшим образом подходящего для одной-единственной поездки, причем сборка эта осуществляется прямо во время движения. Помните анекдот про автомеханика и хирурга, когда последний заводит машину и говорит автомеханику: «Вот теперь – чини!»? Точно так же отличается работа просто менеджера и проджект-менеджера.
Реальная «сборка машины» в DaShe производится на этапе разработки, поскольку только на нем становятся понятны все требования и ограничения, существующие в проекте. Но чтобы такая «сборка» оказалась успешной, для нее нужно подготовить «комплектующие» (ресурсы) и задать «маршрут» (бэклог). Тогда станет более-менее понятно: делать для машины обтекаемый корпус и гнать по шоссе или же оснащать ее большими колесами на автономной подвеске и пробираться по бездорожью. Обратите внимание: точно так же, как разные маршруты требуют разных автомобилей, разные продукты должны создаваться разными командами; успех какой-то команды в проекте «по шоссе» – скорее минус, чем плюс, для проекта «по бездорожью»!
Даже из этой простой метафоры становится очевидно, что ресурсов на начало разработки должно быть как можно больше (неизвестно ведь, по какой дороге потребуется ехать), а конечная цель должна быть определена как можно точнее. Но определение конечной цели (продукта в терминах DaShe) – тоже часть разработки (и довольно объемная, см. раздел 2), требующая существенных ресурсов. Поэтому начинать проект нужно с задачи, для решения которой достаточно уже имеющегося ресурса: рабочего времени проджект-менеджера (далее – ПМ). Начинать нужно с анализа ресурсов, завершающегося составлением организационно-ресурсной схемы проекта.
1.1. Проект: власть, люди, инфраструктура
Ресурсом в понимании DaShe является любой компонент проектной деятельности, влияющий на успешность проекта. Самым очевидным типом ресурсов является инфраструктура: помещения, оборудование, информационные технологии, электричество, тепло, расходные материалы, производственные технологии, сырье, комплектующие и все прочее, что чаще всего фигурирует в расходных строках бюджета. Отсутствие или недостаток какого-то инфраструктурного ресурса хорошо заметны (нет электричества – какая работа?), поэтому на них выделяются достаточные средства.
С момента выхода «Человеческого фактора» (Peopleware, 1987) Демарко и Листера хорошо известно, что проекты редко терпят неудачу из-за недостатка материальных ресурсов (денег или времени); куда чаще в качестве причины провала упоминается политика. Неуемная активность одного из стейкхолдеров, интересующаяся дизайном племянница другого, ревнивая жена тимлида (специалиста, который руководит командой разработчиков) – подобные «мелочи жизни» на деле влияют на проект куда сильнее, чем периодически заканчивающаяся бумага в принтере. А если в проекте продолжается застарелый конфликт между стейкхолдерами или ведущий разработчик вдруг ссорится с представителем заказчика – политика начинает проявляться в полную силу и способна поставить проект под угрозу закрытия.
За словом «политика» скрывается тип ресурсов, которому редко уделяется должное внимание. Проектом занимаются люди, связанные между собой определенной сетью полномочий и коммуникаций, которая и делает их командой проекта. В эту команду входят не только непосредственные исполнители, но и стейкхолдеры, и потенциальные заказчики, и сотрудники смежных отделов, и даже, на первый взгляд, посторонние лица, чьи родственники или знакомые как-то связаны с проектом. Чтобы возникающие по ходу любого проекта творческие задачи были успешно решены, разработчики должны обладать нужной квалификацией, быть мотивированными и в любой момент точно знать, что делать. Но разработчики, стейкхолдеры и другие аффилянты (те, которые контролируют ресурсы) проекта – живые люди, у которых, помимо профессиональной квалификации, есть свои интересы и особенности. Поэтому в работе команды неизбежно возникают сбои – начиная с конфликтов между участниками и заканчивая внезапными изменениями требований в интересах одного из стейкхолдеров.
Классический пример из упомянутого «Человеческого фактора» – требование работать в open space и в любой момент быть готовым отчитаться о текущем задании. Такой де-мотивирующий регламент постоянно возникает в проектах в угоду «священной корове» процессного менеджмента – тотальному контролю над работниками. Стейкхолдер, настоявший на таком регламенте, может прекрасно понимать его несовместимость с творческой деятельностью; но если в его KPI (Key Performance Indicator – ключевой показатель эффективности) прописана регулярная отчетность о ходе проекта – он будет обеспечивать именно ее, а не хорошие условия для разработчиков. Вопреки ожиданиям («взрослые же люди, сами должны разобраться»), человеческие ресурсы требуют куда более тщательного подбора и «настройки», чем инфраструктурные. Помещения, оборудование и программы не обижаются друг на друга и не преследуют собственных целей; а вот каждый человек в команде проекта обязательно будет этим заниматься. Надеяться на то, что «интересы дела» возьмут верх над эмоциями, может только очень неопытный и наивный ПМ; на деле он должен заранее предусмотреть возможные проблемы и сформировать команду таким образом, чтобы минимизировать последствия этих проблем.
Однако это еще не самое сложное. Настоящая политика начинается тогда, когда ход или результаты проекта могут повлиять на власть – то есть на распределение должностей, полномочий или на сферу влияния высокопоставленных лиц. Успех любого проекта улучшает карьерные перспективы инициатора и тем самым ухудшает позиции конкурентов. В случае если эти конкуренты сознательно играют «за себя», а не «за компанию» (то есть составляют «властную группировку»), они объективно заинтересованы в срыве проекта. Например, если проект продвигает А, его конкурент Б может рассматривать то, что предлагает и делает А, как способ получить пример его некомпетентности. В этом случае Б может использовать свое влияние в компании для лоббирования неудачных решений (разумеется, так, чтобы ответственность за них лежала на ПМ или была распределена между всеми стейкхолдерами) и тем самым вести дело к срыву проекта.
Рассмотрим классическую схему аппаратной интриги против ПМ и дружественных ему стейкхолдеров.
1. За счет властного ресурса блокируется возможность решить задачу Х официальным путем (пример: не дадим доступ к системе привлеченному разработчику).
2. На ПМ оказывается давление: «Когда задача Х будет выполнена?»
3. Если ПМ решает проблему обходным путем (пример: разрешает разработчику работать под чужим аккаунтом), этот факт документируется и представляется всем стейкхолдерам как свидетельство нелояльности.
Чтобы не попасть в подобную ловушку (а попасть в нее – значит поставить под удар не только себя, но и весь проект), требуется осознавать «аппаратный» смысл возникающих ситуаций – то есть понимать распределение властных ресурсов в компании.
Основная сложность в анализе властных ресурсов заключается в том, что аппаратные интриги, как правило, осуществляются не одиночками, а группировками из нескольких человек, один из которых («сюзерен») обеспечивает административное «прикрытие», а другие («вассалы») осуществляют непосредственные действия, которые со стороны выглядят как обычные лень, глупость или некомпетентность. В этом случае анализ личных симпатий и интересов человека не поможет предсказать, что он вдруг начнет вставлять палки в колеса; требуется еще знать, на кого он на самом деле работает. Разумеется, узнать это получается далеко не всегда, но если существует возможность хоть немного снизить соответствующие риски, ею обязательно нужно воспользоваться.
Поскольку по степени влияния на проект властные и человеческие ресурсы намного превосходят инфраструктурные, подготовка проекта начинается именно с них.
1.1.1. Властные и человеческие ресурсы
Властные и человеческие ресурсы всегда связаны с конкретными людьми. Даже властный ресурс, принадлежащий группировке, все равно соприкасается с проектом через какого-то конкретного человека и может быть пущен в ход только с его подачи. Человеческие ресурсы, такие как компетентность, коммуникабельность или квалификация, тем более принадлежат конкретному специалисту и только ему. Поэтому для работы с властными и человеческими ресурсами используются одни и те же методы: составление списка аффилянтов, сбор сведений о каждом из них, составление психологических портретов, определение вытекающих из них ограничений и требований. Подробно эти методы описаны в пунктах 1.2 и 1.3, но перед тем, как переходить к ним, следует зафиксировать общие принципы работы с человеческими и властными ресурсами.
Во-первых, властные и человеческие ресурсы можно описывать и классифицировать. Вопреки распространенным мнениям о том, что «чужая душа потемки» и что «все люди разные», разнообразие человеческих реакций не слишком велико, и они могут быть с приемлемой точностью предсказаны заранее. Для этого нужно всего лишь не самоустраняться от решения соответствующей задачи и узнать о человеке как можно больше, составить на основе полученных знаний индивидуальный психологический портрет. Дальнейшее тривиально: если Петя любит выпить, а Вася – завязавший алкоголик, то как сложатся их рабочие отношения? Если Коля лютый антисемит, а Иосиф – мальчик из хорошей семьи? Если Гоша фанатичный бабник, а Маша ненавидит служебные романы? Наконец, если Иван Иванович поставлен стейкхолдером присматривать за проектом изнутри, а Сеня демонстративно унижает всех, кто слабее его профессионально? Никакой магии, не правда ли?
Во-вторых, властные и человеческие ресурсы бывают не только негативными (как в приведенных выше примерах), но и позитивными. Там, где один человек может создать проблемы (начиная с мелких, вроде неполадок корпоративной сети перед релизом, и заканчивая крупными, вроде открытия уголовного дела за нарушение режима секретности), другой человек с соответствующим ресурсом может эти проблемы решить (распорядившись властью начальника, «включить сеть» или организовать звонок в прокуратуру откуда следует). Власть, когда она работает на проект, а не против, – мощнейший позитивный ресурс. Именно власть позволяет стейкхолдерам наделять ПМ различными полномочиями, именно использование власти («под мою ответственность») позволяет быстрее всего решать текущие проблемы. Поддержка действий ПМ со стороны стейкхолдеров, обладающих наибольшей властью, – критически важное условие успеха проекта. Вопрос лишь в том, как мотивировать
Конец ознакомительного фрагмента.
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию (https://www.litres.ru/pages/biblio_book/?art=71247583?lfrom=390579938) на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
Сергей Игоревич Щеглов
Петр Давыденков
Сергей Щеглов и Петр Давыденков предложили 77 методов, которые помогут расправиться с трудностями в проектном менеджменте. Менеджер – не супермен, невозможно уметь решать все проблемы без исключения. Но книга поможет не совершать критических ошибок и по максимуму использовать открывающиеся возможности.
В формате PDF A4 сохранен издательский макет книги.
Сергей Щеглов, Петр Давыденков
Фреймворк управления и анализа проектов DaShe
© Щеглов С. И., наследники, 2023
© Давыденков П. И., 2023
© Издание, оформление. ООО Группа Компаний «РИПОЛ классик», 2024
Памяти Сергея Игоревича Щеглова
(1965–2021)
Проект – это временное предприятие, направленное на создание уникального продукта, услуги или результата.
Project Management Body of Knowledge, PMBoK
0. Почему 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) Метод «Погружение в тему»
Погружение в тему обеспечивается итерационным уточнением набора ключевых слов до тех пор, пока результаты не дадут ответы на все контрольные вопросы.
1. Формируется первичный (заведомо недостаточный) список ключевых слов («металлорежущие станки» и найденные по словарю синонимы).
2. На полученных в выдаче веб-страницах ищутся:
1) источники информации по теме (сайты, книги, журналы, форумы, новостные агрегаторы и т. д.);
2) новые ключевые слова, более подходящие для целей поиска.
3. Источники информации внимательно прочитываются, ключевая информация помещается в отдельный файл со ссылками на источник. Появившиеся по ходу чтения идеи записываются туда же.
4. Проверяется достаточность понимания темы. Критерий – способность ответить на все семь контрольных вопросов: кто, что, где, когда, как, почему и сколько (Five Ws + Two How). В нашем примере с металлорежущими станками нужно получить перечень типов субъектов, принимающих решение о закупках (кто), количество и типы заключаемых ими сделок (что), места их профессионального и личного общения – форумы, аккаунты в соцсетях (где), бюджетные циклы и сезонность сделок (когда), порядок подготовки и принятия решений (как), мотивы субъектов, принимающих решение о закупках (почему), и, наконец, примерные объемы закупок (сколько).
По контрольным вопросам становится понятно отличие в объеме информации, выдаваемой по первоначальному запросу «закупки металлорежущих станков» и появившейся в результате погружения в тему. Метод применяется для того, чтобы информация была не «проходной», а достаточной для возникновения нетривиальных идей в конкретной области, и тем самым минимизирует риск отсутствия креатива в разработке продукта.
5. Если понимания недостаточно для ответа на все вопросы, шаги повторяются начиная с пункта 1, но уже с новым набором ключевых слов.
Результат: достаточное для возникновения новых идей описание предметной области.
На этом краткое знакомство с DaShe закончено. Дальше начинается сам фреймворк.
1. Ресурсы
– Почему вы сдали крепость?
– На то было много причин. Во-первых, у нас не было пороха…
Один из вариантов бородатого анекдота
Желание запустить проект может возникнуть у стейкхолдеров по любому поводу. «Есть свободные деньги, надо инвестировать их в какой-нибудь стартап». «Пора уже переделать корпоративную систему работы с клиентами». «До следующего большого заказа целый год, надо занять чем-то разработчиков, чтобы не разбежались», и т. д., с бесконечным числом вариантов. Но какой бы ни была начальная идея, каждый раз речь идет о чем-то таком, чего в практике стейкхолдеров еще не было и что нельзя создать простым указанием: «С сегодняшнего дня начинайте отгрузку изделия ХХХ». Речь идет о создании не просто нового продукта, но и о создании организации, которая его сделает, – команды проекта.
«Перед тем как ехать, нужно собрать машину». Управление проектом отличается от управления производством не только необходимостью каждый день изобретать что-то новенькое, но и тем, что изобретать это новенькое поначалу просто некому. В случае производства управляемая система – отдел, цех, предприятие – уже существует; известен и производимый ею продукт, и технологии его производства, требуется лишь обеспечивать соблюдение этих технологий. Классический менеджмент можно сравнить с ежедневной поездкой на автомобиле по одному и тому же маршруту: да, некоторые улицы закрывают на ремонт, в дороге встречаются пробки, автомобиль иногда ломается, но в целом и автомобиль, и улицы, и пункт назначения одни и те же. А вот в начале любого проекта никакой управляемой системы не существует; команды проекта еще нет, используемые технологии не выбраны, и даже конечный результат обрисован весьма приблизительно. Проектный менеджмент – это каждый раз сборка нового «автомобиля», наилучшим образом подходящего для одной-единственной поездки, причем сборка эта осуществляется прямо во время движения. Помните анекдот про автомеханика и хирурга, когда последний заводит машину и говорит автомеханику: «Вот теперь – чини!»? Точно так же отличается работа просто менеджера и проджект-менеджера.
Реальная «сборка машины» в DaShe производится на этапе разработки, поскольку только на нем становятся понятны все требования и ограничения, существующие в проекте. Но чтобы такая «сборка» оказалась успешной, для нее нужно подготовить «комплектующие» (ресурсы) и задать «маршрут» (бэклог). Тогда станет более-менее понятно: делать для машины обтекаемый корпус и гнать по шоссе или же оснащать ее большими колесами на автономной подвеске и пробираться по бездорожью. Обратите внимание: точно так же, как разные маршруты требуют разных автомобилей, разные продукты должны создаваться разными командами; успех какой-то команды в проекте «по шоссе» – скорее минус, чем плюс, для проекта «по бездорожью»!
Даже из этой простой метафоры становится очевидно, что ресурсов на начало разработки должно быть как можно больше (неизвестно ведь, по какой дороге потребуется ехать), а конечная цель должна быть определена как можно точнее. Но определение конечной цели (продукта в терминах DaShe) – тоже часть разработки (и довольно объемная, см. раздел 2), требующая существенных ресурсов. Поэтому начинать проект нужно с задачи, для решения которой достаточно уже имеющегося ресурса: рабочего времени проджект-менеджера (далее – ПМ). Начинать нужно с анализа ресурсов, завершающегося составлением организационно-ресурсной схемы проекта.
1.1. Проект: власть, люди, инфраструктура
Ресурсом в понимании DaShe является любой компонент проектной деятельности, влияющий на успешность проекта. Самым очевидным типом ресурсов является инфраструктура: помещения, оборудование, информационные технологии, электричество, тепло, расходные материалы, производственные технологии, сырье, комплектующие и все прочее, что чаще всего фигурирует в расходных строках бюджета. Отсутствие или недостаток какого-то инфраструктурного ресурса хорошо заметны (нет электричества – какая работа?), поэтому на них выделяются достаточные средства.
С момента выхода «Человеческого фактора» (Peopleware, 1987) Демарко и Листера хорошо известно, что проекты редко терпят неудачу из-за недостатка материальных ресурсов (денег или времени); куда чаще в качестве причины провала упоминается политика. Неуемная активность одного из стейкхолдеров, интересующаяся дизайном племянница другого, ревнивая жена тимлида (специалиста, который руководит командой разработчиков) – подобные «мелочи жизни» на деле влияют на проект куда сильнее, чем периодически заканчивающаяся бумага в принтере. А если в проекте продолжается застарелый конфликт между стейкхолдерами или ведущий разработчик вдруг ссорится с представителем заказчика – политика начинает проявляться в полную силу и способна поставить проект под угрозу закрытия.
За словом «политика» скрывается тип ресурсов, которому редко уделяется должное внимание. Проектом занимаются люди, связанные между собой определенной сетью полномочий и коммуникаций, которая и делает их командой проекта. В эту команду входят не только непосредственные исполнители, но и стейкхолдеры, и потенциальные заказчики, и сотрудники смежных отделов, и даже, на первый взгляд, посторонние лица, чьи родственники или знакомые как-то связаны с проектом. Чтобы возникающие по ходу любого проекта творческие задачи были успешно решены, разработчики должны обладать нужной квалификацией, быть мотивированными и в любой момент точно знать, что делать. Но разработчики, стейкхолдеры и другие аффилянты (те, которые контролируют ресурсы) проекта – живые люди, у которых, помимо профессиональной квалификации, есть свои интересы и особенности. Поэтому в работе команды неизбежно возникают сбои – начиная с конфликтов между участниками и заканчивая внезапными изменениями требований в интересах одного из стейкхолдеров.
Классический пример из упомянутого «Человеческого фактора» – требование работать в open space и в любой момент быть готовым отчитаться о текущем задании. Такой де-мотивирующий регламент постоянно возникает в проектах в угоду «священной корове» процессного менеджмента – тотальному контролю над работниками. Стейкхолдер, настоявший на таком регламенте, может прекрасно понимать его несовместимость с творческой деятельностью; но если в его KPI (Key Performance Indicator – ключевой показатель эффективности) прописана регулярная отчетность о ходе проекта – он будет обеспечивать именно ее, а не хорошие условия для разработчиков. Вопреки ожиданиям («взрослые же люди, сами должны разобраться»), человеческие ресурсы требуют куда более тщательного подбора и «настройки», чем инфраструктурные. Помещения, оборудование и программы не обижаются друг на друга и не преследуют собственных целей; а вот каждый человек в команде проекта обязательно будет этим заниматься. Надеяться на то, что «интересы дела» возьмут верх над эмоциями, может только очень неопытный и наивный ПМ; на деле он должен заранее предусмотреть возможные проблемы и сформировать команду таким образом, чтобы минимизировать последствия этих проблем.
Однако это еще не самое сложное. Настоящая политика начинается тогда, когда ход или результаты проекта могут повлиять на власть – то есть на распределение должностей, полномочий или на сферу влияния высокопоставленных лиц. Успех любого проекта улучшает карьерные перспективы инициатора и тем самым ухудшает позиции конкурентов. В случае если эти конкуренты сознательно играют «за себя», а не «за компанию» (то есть составляют «властную группировку»), они объективно заинтересованы в срыве проекта. Например, если проект продвигает А, его конкурент Б может рассматривать то, что предлагает и делает А, как способ получить пример его некомпетентности. В этом случае Б может использовать свое влияние в компании для лоббирования неудачных решений (разумеется, так, чтобы ответственность за них лежала на ПМ или была распределена между всеми стейкхолдерами) и тем самым вести дело к срыву проекта.
Рассмотрим классическую схему аппаратной интриги против ПМ и дружественных ему стейкхолдеров.
1. За счет властного ресурса блокируется возможность решить задачу Х официальным путем (пример: не дадим доступ к системе привлеченному разработчику).
2. На ПМ оказывается давление: «Когда задача Х будет выполнена?»
3. Если ПМ решает проблему обходным путем (пример: разрешает разработчику работать под чужим аккаунтом), этот факт документируется и представляется всем стейкхолдерам как свидетельство нелояльности.
Чтобы не попасть в подобную ловушку (а попасть в нее – значит поставить под удар не только себя, но и весь проект), требуется осознавать «аппаратный» смысл возникающих ситуаций – то есть понимать распределение властных ресурсов в компании.
Основная сложность в анализе властных ресурсов заключается в том, что аппаратные интриги, как правило, осуществляются не одиночками, а группировками из нескольких человек, один из которых («сюзерен») обеспечивает административное «прикрытие», а другие («вассалы») осуществляют непосредственные действия, которые со стороны выглядят как обычные лень, глупость или некомпетентность. В этом случае анализ личных симпатий и интересов человека не поможет предсказать, что он вдруг начнет вставлять палки в колеса; требуется еще знать, на кого он на самом деле работает. Разумеется, узнать это получается далеко не всегда, но если существует возможность хоть немного снизить соответствующие риски, ею обязательно нужно воспользоваться.
Поскольку по степени влияния на проект властные и человеческие ресурсы намного превосходят инфраструктурные, подготовка проекта начинается именно с них.
1.1.1. Властные и человеческие ресурсы
Властные и человеческие ресурсы всегда связаны с конкретными людьми. Даже властный ресурс, принадлежащий группировке, все равно соприкасается с проектом через какого-то конкретного человека и может быть пущен в ход только с его подачи. Человеческие ресурсы, такие как компетентность, коммуникабельность или квалификация, тем более принадлежат конкретному специалисту и только ему. Поэтому для работы с властными и человеческими ресурсами используются одни и те же методы: составление списка аффилянтов, сбор сведений о каждом из них, составление психологических портретов, определение вытекающих из них ограничений и требований. Подробно эти методы описаны в пунктах 1.2 и 1.3, но перед тем, как переходить к ним, следует зафиксировать общие принципы работы с человеческими и властными ресурсами.
Во-первых, властные и человеческие ресурсы можно описывать и классифицировать. Вопреки распространенным мнениям о том, что «чужая душа потемки» и что «все люди разные», разнообразие человеческих реакций не слишком велико, и они могут быть с приемлемой точностью предсказаны заранее. Для этого нужно всего лишь не самоустраняться от решения соответствующей задачи и узнать о человеке как можно больше, составить на основе полученных знаний индивидуальный психологический портрет. Дальнейшее тривиально: если Петя любит выпить, а Вася – завязавший алкоголик, то как сложатся их рабочие отношения? Если Коля лютый антисемит, а Иосиф – мальчик из хорошей семьи? Если Гоша фанатичный бабник, а Маша ненавидит служебные романы? Наконец, если Иван Иванович поставлен стейкхолдером присматривать за проектом изнутри, а Сеня демонстративно унижает всех, кто слабее его профессионально? Никакой магии, не правда ли?
Во-вторых, властные и человеческие ресурсы бывают не только негативными (как в приведенных выше примерах), но и позитивными. Там, где один человек может создать проблемы (начиная с мелких, вроде неполадок корпоративной сети перед релизом, и заканчивая крупными, вроде открытия уголовного дела за нарушение режима секретности), другой человек с соответствующим ресурсом может эти проблемы решить (распорядившись властью начальника, «включить сеть» или организовать звонок в прокуратуру откуда следует). Власть, когда она работает на проект, а не против, – мощнейший позитивный ресурс. Именно власть позволяет стейкхолдерам наделять ПМ различными полномочиями, именно использование власти («под мою ответственность») позволяет быстрее всего решать текущие проблемы. Поддержка действий ПМ со стороны стейкхолдеров, обладающих наибольшей властью, – критически важное условие успеха проекта. Вопрос лишь в том, как мотивировать
Конец ознакомительного фрагмента.
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию (https://www.litres.ru/pages/biblio_book/?art=71247583?lfrom=390579938) на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
Сергей Щеглов и Петр Давыденков
Тип: электронная книга
Жанр: Коучинг
Язык: на русском языке
Издательство: РИПОЛ Классик
Дата публикации: 24.10.2024
Отзывы: Пока нет Добавить отзыв
О книге: Сергей Щеглов и Петр Давыденков предложили 77 методов, которые помогут расправиться с трудностями в проектном менеджменте. Менеджер – не супермен, невозможно уметь решать все проблемы без исключения. Но книга поможет не совершать критических ошибок и по максимуму использовать открывающиеся возможности.