Не усложняй! Управление проектами по методу P3.express - Дмитрий Аркадьевич Ильенков Страница 11

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

Но так ли это на самом деле?

Я слышал о самых разных «черных лебедях»: внезапно уволился разработчик, обанкротился подрядчик, изменился курс валюты. Рассказывая о перипетиях судьбы, собеседники обычно вздыхают: «Откуда мы могли об этом знать заранее?»

Действительно, откуда? О планах разработчика уволиться можно узнать, если регулярно проводить один-на-один[23], риск банкротства подрядчика проще предвидеть, если служба безопасности тщательно проверяет контрагентов, а курс валют постоянно двигается в обе стороны, и это тоже не секрет.

Такие примеры подтверждают не обилие черных лебедей, а то, что мы часто уделяем недостаточно внимания управлению рисками. Многие команды не занимаются этим совсем. А бывают и анекдотичные случаи: одна консалтинговая компания приступает к выявлению рисков после подписания договора. Другими словами, сначала они берутся за проект, а потом смотрят, что может пойти не так. Затейливо!

Методология P3.express предлагает заняться выявлением рисков и планированием мер реагирования сразу после составления Карты результатов, то есть до принятия окончательного решения о запуске проекта.

Во-первых, это позволит не брать на себя необоснованные риски. Не стоит приниматься за проект, заказчик которого находится на грани банкротства, предъявляет нереалистичные требования, агрессивен в общении, в десятый раз меняет условия сотрудничества.

Во-вторых, понимание рисков поможет скорректировать план действий и оценки. Помните, как Бент Фливбьорг в главе про NUP3 – «Всегда будь проактивен» – нанял археологов при строительстве железной дороги еще до того, как нашли первый римский камушек? По сути, профессор нашел потенциальную проблему заранее и придумал, что с ней делать.

Риск – это всегда вероятностное событие. Оно может произойти, а может не произойти. Например, фронтендер неудачно поужинал, и не может выйти на работу. И хотя вы не можете на 100 % предотвратить данный риск, в ваших силах продумать заранее, как поступить в таком случае:

• убедиться, что вся команда может работать из дома;

• собрать команду таким образом, чтобы его могли подменить;

• держать на низком старте пару фрилансеров;

• использовать все перечисленные варианты.

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

Однажды этот шаг изменил историю pmclub. Мы рассматривали возможность проведения курса в вебинарном формате. В списке рисков возник пункт: «Из-за проблем с интернетом, связь может прерваться, что не позволит качественно провести вебинар и подготовить запись для пропустивших».

Мы обсудили меры реагирования и решили отказаться от первоначального плана. В итоге мы пришли к формату урока, в котором работаем и сейчас: профессиональное видео + конспект + подборка дополнительных материалов + задание на проработку. Такой подход позволяет не только гарантировать качество, но и постоянно развивать продукт. А началось все с одного выявленного риска.

Это нормально. По итогам шага A06 вы тоже можете изменить проект или вовсе отказаться от него.

Если присмотритесь к формулировке риска из нашего кейса, то заметите, что предложение составлено по следующей схеме «причина-следствие-влияние»:

• причина – проблемы с интернетом;

• следствие – у спикера могут возникать перебои в соединении;

• влияние – некачественные материалы на выходе.

Такая структура упрощает работу с риском. Гораздо легче придумать те же меры реагирования, когда понимаешь, почему может возникнуть проблема и как она повлияет на проект. Если при описании использовать слишком общие слова, из серии «есть риск, что мы сделаем некачественный продукт», то будет совершенно непонятно, в какую сторону вообще стоит думать над решением.

По методологии P3.express риски и проблемы фиксируют в Реестре последующих действий. Его базовый вариант вы видите на рисунке.

Рисунок 9. Пример Реестра последующих действий в табличном виде

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

Выявить потенциальные угрозы даже для совсем новых проектов не так сложно, как кажется. Для этого:

• изучите корпоративную базу знаний или архивы проектов – в них вы найдете описание тех проблем, которые в вашей компании уже случались;

• пообщайтесь с коллегами, в том числе из профессиональных сообществ и других компаний – так вы узнаете еще больше;

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

• используйте ИИ-инструменты – только проконсультируйтесь со службой безопасности своей компании и узнайте, есть ли у вас какие-то ограничения по применению искусственного интеллекта.

ПОСЛЕ ПРЕДВАРИТЕЛЬНОЙ РАБОТЫ ОРГАНИЗУЙТЕ ВОРКШОП, ЧТОБЫ ОБСУДИТЬ, КАКИЕ РИСКИ ЕЩЕ НЕ ЗАФИКСИРОВАНЫ, НАЗНАЧИТЬ ОТВЕТСТВЕННЫХ И РАЗРАБОТАТЬ МЕРЫ РЕАГИРОВАНИЯ.

А затем проверим, хорошо ли все потрудились.

A07 – провести ревью запуска проекта

ПРИШЛО ВРЕМЯ ПОПРОСИТЬ ДРУГОГО МЕНЕДЖЕРА ПРОЕКТОВ ВАШЕЙ ОРГАНИЗАЦИИ ПОМОЧЬ ВАМ, ПРОАНАЛИЗИРОВАВ ВАШИ ДЕЙСТВИЯ ПО УПРАВЛЕНИЮ ПРОЕКТОМ.

Руководство P3.express

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

Это пример peer-review – когда одни ученые оценивают работы других, проверяя перед публикацией материал на качество, достоверность и соответствие стандартам. Впервые этот подход применили в журнале «Philosophical Transactions» в 1665 году. За несколько сотен лет появились разные типы ревью – одностороннее и двустороннее слепое, парное и тройное, до публикации и после[24].

В мире разработки популярна похожая практика – код-ревью, когда один разработчик пишет код, а другой его проверяет. Сложно сказать, почему ревью не вошли в рутину руководителей проектов раньше, но P3.express устраняет это досадное недоразумение.

На шаге A07 проджект идет к другому с просьбой сделать ревью. Это нужно, чтобы перед принятием решения «Go/No-Go»[25] проверить: