Дмитрий Аркадьевич Ильенков

Не усложняй! Управление проектами по методу P3.express

Дмитрий Ильенков

Дисклеймер

Часть содержания книги основана на руководстве P3.express от OMIMO и использована по лицензии Creative Commons Attribution.

Посвящение

Посвящается нашим учителям и ученикам

Введение

Хаос. Пожалуй, самое короткое слово, которым можно описать управление проектами в большинстве компаний. Конкретики нет, требования и приоритеты постоянно меняются. Непонятно, кто за что отвечает, интересы сторон противоречат друг другу, времени всегда недостаточно, а в самый нужный момент что-нибудь ломается. Знакомо? Да практически каждому, кто хоть раз принимал участие в проекте, где больше одного человека. Именно с хаосом – отсутствием понятной системы, прозрачности и предсказуемости в проектах – чаще всего приходят бороться к нам в онлайн-школу pmclub.

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

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

В этой книге я хочу познакомить вас с минималистичной методологией P3.express и замотивировать двигаться к порядку в проектах.

Почему именно с P3.express?

Кажется, я забыл представиться. Меня зовут Дима Ильенков, и я управляю проектами больше 15 лет. В 2014 году я получил свой первый профессиональный сертификат. Начал преподавать проджект-менеджмент в Финансовом университете, а затем и в Высшей школе экономики. Несколько лет был волонтером Института управления проектами (PMI) и президентом Московского отделения. Меня начали приглашать в компании с просьбой помочь наладить проектное управление.

И я заметил: большинство участников, да и менеджеров проектов – не профессиональные проджекты! Управление проектами не их основная работа. А компании не могут тратить по несколько месяцев на обучение сотрудников. Это значит, что нужен подход, который любой человек может быстро освоить и начать сразу применять в работе.

Существует ли такой подход?

Ответ я получил в 2018 году. На профессиональной конференции в Берлине я познакомился с Фрэнком Терли. А чуть позже Фрэнк и его коллега Надер Рад рассказали мне о своей разработке – P3.express. Эта методология помогает с минимальными усилиями сделать управление проектами более системным и прозрачным, а результаты – предсказуемыми.

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

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

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

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

Книга будет полезна,даже если формально ваша должность не звучит как «проджект-менеджер»,но вырегулярно делаете проекты, участвуете в них и хотите знать, как работать эффективнее без лишних заморочек и терминов. Среди наших учеников есть продакты, директора заводов и владельцы IT-компаний, бизнес-аналитики и тимлиды, HRы, маркетологи и не только.

Предлагаю следовать такому плану:

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

2. Затем структурируем работу над проектом – разделим на понятные этапы и действия, благодаря P3.express.

3. И, наконец, адаптируем систему под особенности вашей проектной среды – ведь каждый проект и компания в чем-то уникальны, правда?

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

Как книга повлияет на вас? Давайте узнаем!

Раздел 1. Знакомство с P3.express

Зачем нужна методология?

Первые проектные методологии разработали в прошлом веке, а до этого как-то обходились без них. Без них отправляли корабли в дальние плавания, без них прорыли Панамский канал (со второй попытки). Пирамиды тоже строили без проектной методологии!

Может, методология для управления проектами и не нужна?

Стартапам не до этого, нужно поднять метрики до следующего раунда инвестиций. Корпорации завалены тоннами регламентов, но кто их читает? Даже компании, в которых есть проектный офис – и не один! – зачастую не применяют методологию за его пределами. В общем, управление проектами по наитию и сейчас остается способом номер один.

Идет ли это на пользу проектам?

Давайте обратимся к одному из самых крупных исследований в области управления проектами – Пульс Профессии 2018. Оно показывает, что в организациях без формализованного управления проектами только 58 % проектов достигают цели, 48 % – укладываются в рамки бюджета и 43 % – завершаются в срок[1].

Это хорошо или плохо? Попробую снизить уровень абстракции.

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

К счастью, стоматологи не лечат зубы по наитию. У них есть протоколы, которым они следуют.

Методология – это своего рода протокол в управлении проектами. Он, как и врачебный, снижает неопределенность, экономит время и повышает качество работы. В итоге у компаний, где формализовано управление проектами, показатели гораздо лучше: 73 % проектов достигают цели, 63 % – укладываются в бюджет,

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

В этой книге я познакомлю вас с практичной методологией P3.express, которую легко изучить и начать применять, не ломая уже существующие процессы. О ней и поговорим в следующей главе.

Что такое P3.express?

Вам когда-нибудь доводилось собирать конструктор Lego или шкаф IKEA?

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

Для использования P3.express вам не потребуется проводить очередную трансформацию компании, менять корпоративные ценности, внедрять новое программное обеспечение, нанимать или увольнять специалистов и привлекать консультантов. В вашем наборе уже достаточно деталей!

P3.express содержит 33 шага, разделенных на 7 этапов. Когда я говорю об этом на конференциях некоторые слушатели от удивления поднимают брови: «33 шага – это просто?!» Но присмотревшись, они убеждаются, что понять эти шаги не сложнее, чем запомнить 33 буквы алфавита.

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

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

Рисунок 1. Схема P3.express

Итак, работа над проектом по P3.express состоит из 7 этапов:

• Запуск проекта (A01-A10);

• Планирование цикла (B01-B05);

• Еженедельные действия (C01-C04);

• Ежедневные действия (D01-D02);

• Закрытие цикла (E01-E03);

• Закрытие проекта (F01-F06);

• После проекта (G01-G03).

Давайте кратко разберем, что происходит на каждом этапе.

Все начинается сЗапуска проекта(A01–A10). Здесь формируется база: команда, цель, первые оценки и планы. Главная задача – убедиться, что есть достаточные основания вообще начать проект. Пропускать эти шаги – все равно что отправляться в поход по горам в шлепках, не построив маршрут и не собрав рюкзак. Не рекомендую.

Если вы приняли решение браться за проект, то переходим к этапуПланирования цикла(B01-B05). Он нужен для подготовки к предстоящему месяцу работы. На нем команда обновляет и уточняет планы.

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

Погружаемся дальше и переходим кЕженедельным действиям(C01-C04) – они нужны, чтобы фиксировать прогресс и отслеживать, где план расходится с реальностью уже на более детальном уровне. Так вы сможете держать руку на пульсе проекта и вовремя замечать отклонения, пока они не превратились в проблемы.

Каждый день члены команды закрывают задачи, а в проекте появляются новые вводные. Именно с этим менеджеру проекта необходимо будет работать наЕжедневных действиях(D01-D02) – принимать выполненную работу и решать возникшие вопросы.

В конце месяца нужно пройтиЗакрытие цикла(E01-E03) – извлечь уроки и собрать обратную связь от команды и других участников проекта.

Тут можно узнать много интересного. Разработчику, оказывается, не нравится, как ставят задачи. Заказчик считает, что из еженедельных отчетов невозможно понять, когда ожидать завершения. А в бухгалтерии ваш проект уже начинают недолюбливать.

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

К шагамЗакрытия проекта(F01-F06) переходят в двух случаях – когда продукт готов или когда принято решение остановить проект досрочно. Это финальная стадия работы, когда важно корректно завершить все процессы и передать результат заказчику.

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

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

Наконец, последний этап –После проекта(G01-G03). Здесь важно оценить, какую пользу принес проект и можно ли получить больше.

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

Напоследок – еще раз обратите внимание на схему процесса.

Нумерация шагов – не сквозная! То есть на каждом этапе отсчет шагов начинается заново. Это классная фишка, которая позволяет легко дорабатывать методологию под особенности компании и добавлять в этапы собственные шаги. Про это еще поговорим в главе «Советы по внедрению».

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

Раздел 2. Принципы

Зачем нужны принципы?

Изначально P3.express прекрасно существовал без принципов. Я не придавал этому особого значения, пока не начал проводить тренинги по методологии. На обучение приходили менеджеры проектов из совершенно разных миров: IT, строительство, электронная коммерция, нефтегазовая отрасль, малый бизнес. Участники сыпали вопросами и кейсами: «Что делать, если у меня внешний заказчик?

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

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

В это время Лера, соавтор книги и моя жена, читала книгу финансиста и миллиардера Рэя Далио «Принципы» и регулярно делилась мыслями из нее. Рэй заметил, что многие ситуации в жизни повторяются и, если каждый раз не придумывать с нуля, как в них поступить, то принимать решения становится быстрее и проще, а качество жизни растет. Сначала Далио сформулировал принципы для себя, а позже – для работы Bridgewater Associates, одной из самых успешных инвестиционных компаний США.

Я задумался и понял, что принципы существуют и применяются в самых разных сферах – например, на них основаны международные стандарты бухгалтерской отчетности. Да что там, знаменитая клятва Гиппократа, – это по сути набор этических принципов!

Пазл сложился. Я написал Фрэнку и Надеру: «Кажется, в руководстве не хватает принципов, на которые опирается методология».

Пару месяцев мы обсуждали эту идею, и еще через какое-то время Надер прислал мне ссылку на новый сайт: NUPP.guide[2].

NUPP расшифровывается как Nearly Universal Principles of Projects – почти универсальные проектные принципы, на которые теперь опирается методология P3.express.

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

1. Выбирай результаты и истину, а не привязанности.

2. Береги и оптимизируй энергию и ресурсы.

3. Всегда будь проактивен.

4. Помни, что прочность цепи определяется по самому слабому звену.

5. Не делай ничего без четкой цели.

6. Используй воспроизводимые элементы.

Недавно наш выпускник Юрий Чернов, руководитель проектного офиса, прислал мне фотографию своего рабочего стола, где на видном месте висит распечатка NUPP.

Рисунок 2. Рабочий стол Юры

«Каждый раз, когда менеджеры проектов приходят с вопросами, – сказал Юра, – мы начинаем проходить по списку принципов. Они становятся отправной точкой в процессе принятия решений».

Кажется, компас работает.

NUP1 – выбирай результаты и истину, а не привязанности

Не ограничивая свою идентичность и взгляды привязанностями, мы можем добиться больше как профессионалы

Руководство NUPP

28 февраля 2018 года авиалайнер вылетел из аэропорта Джакарты. Уже через 11 минут после взлета самолет упал в Яванском море. Все находившиеся на борту – 181 пассажир и 18 членов экипажа – погибли.

Это была первая и крупнейшая катастрофа Boeing 737 MAX 8, но увы не последняя. Годом позже самолет той же модели разбился в Эфиопии и снова с многочисленными жертвами.

Авторы статьи[3], в которой анализируются причины трагических событий, отмечают: к авиакатастрофам во многом привел страх сотрудников Boeing пойти против коллектива и остаться без работы. Инженеры, сомневающиеся в безопасности авиалайнера, не стали публично высказывать свои опасения.

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

Аналогичный случай произошел, когда хирург-гинеколог Игнац Земмельвейс предложил своим коллегам-врачам мыть руки перед осмотром рожениц, чтобы снизить количество смертей от родильной горячки[4]. Многие консервативные коллеги отказались следовать его совету, так как это противоречило взглядам, принятым в медицинском сообществе XIX века, и организовали травлю новатора. Измученный борьбой доктор окончил свои дни в сумасшедшем доме. А сколько девушек погибли из-за грязных рук врачей-консерваторов?

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

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

УВЫ, ВЫБИРАТЬ ИСТИНУ И РЕЗУЛЬТАТ – НЕ ТАК ПРОСТО, КАК МОЖЕТ ПОКАЗАТЬСЯ. ДАЖЕ ЕСЛИ ВЫ ЗНАКОМЫ С ПРИНЦИПАМИ NUPP.

Небольшая исповедь. Я очень любил Keynote, программу для создания презентаций. Она простая и позволяет в два клика делать минималистичные и стильные слайды. К сожалению, Keynote есть не у всех: организаторы конференций, где я выступал, постоянно просили прислать презентацию в привычном формате – PowerPoint или гугл-презентации, а не Keynote или PDF-файл. Я отправлял, но это всегда заканчивалось одинаково: обязательно съезжали шрифт и картинки. Летом 2024 года за пять минут до выступления на IT Summer Fest в Белграде я правил свои слайды, пострадавшие при конвертации. К слову, их было 90. Зато я понял, что, наконец, готов отказаться от привычки и перейти на гугл-презентации.

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

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

NUP2 – береги и оптимизируй энергию и ресурсы

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

Руководство NUPP

Мы с Лерой очень любим длинные пешие прогулки и по городу, и на природе. Ходим быстро, отдыхаем редко. Но заметили, что уже к концу прогулки ноги начинают гудеть. Да и вообще, после 20 000 шагов на следующий день чувствуешь себя не очень хорошо.

Так было, пока мы не пошли гулять

Через несколько месяцев мы прошли участок Ликийской тропы от маяка Гелидония до Адрасана. Путь составил 20 километров по гористой местности, а перепад высоты – 1000 метров. Следуя Жениному совету, мы регулярно отдыхали. Благодаря этому у нас хватило сил на вторую половину тропы, где идти приходилось по каменистому обрыву над морем. Мы не встретили ни одного человека, так что вряд ли нам кто-нибудь помог, если бы возникли проблемы.

Но куда уходят силы в походе всем понятно. А куда же уходит энергия руководителей проектов? Им вроде не нужно разгружать вагоны и искать выход из леса.

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

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

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

Второй враг –перфекционизм[5]. В нашей команде он чаще всего преследовал Леру. Она могла по три часа подряд вычитывать статью перед публикацией, хотя ее можно было поправить позже. Редактировать съехавшую на два пикселя картинку, хотя это никак не повлияло бы на показы поста. Откладывать описание задачи, потому что пока не пришла в голову идеальная формулировка. Потом у нее болели глаза, а список дел за день не уменьшался.

Если вы узнали в Лере себя, воспользуйтесь лайфхаком, который помогает усмирить перфекционизм. Пообщайтесь со своим внутренним отличником и дайте ему новую установку – следуй принципу Парето: 20 % усилий приносят 80 % результата. Выгоднее иметь 80 % результата за 20 % усилий, чем 100 % результата за 100 % усилий. Пока вы будете пытаться сделать идеальный макет или написать идеальное письмо, ваш заказчик потеряет терпение и уйдет к конкуренту. Потому что правильная расстановка запятых его волнует меньше всего.

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

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

ПОДДЕРЖАНИЕ СЕБЯ В ХОРОШЕЙ ФОРМЕ – ЭТО ВАША РАБОЧАЯ ОБЯЗАННОСТЬ, А НЕ БЛАЖЬ.

Каждое пятое ДТП связано с тем, что водитель заснул за рулем[6]. Разве вы хотите быть таким водителем для своей команды?

NUP3 – всегда будь проактивен

МЫ МОЖЕМ ДОБИТЬСЯ ЛУЧШИХ РЕЗУЛЬТАТОВ, ПРОЯВИВ ИНИЦИАТИВУ.

Руководство NUPP

Недавно я узнал историю строительства скоростной железнодорожной ветки HS2, ведущей из Лондона на север Англии. Такие проекты очень редко идут по плану и укладываются в срок. Но этому проекту повезло – его консультировал лично профессор Бент Фливбьорг, автор книги «How big things get done». Бент и команда начали с поиска рисков и обратили внимание на один очень специфичный.

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

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

Вот это проактивный подход!

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

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

ПЛАНИРОВАНИЕ ПРОЕКТА – ЭТО УЖЕ ПРОАКТИВНЫЙ ПОДХОД.

Не стоит забывать и про более мелкие задачки.

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

Например, у нас в pmclub есть повестка для любой встречи – один-на-один, командной, проектной. Как результат, все участники понимают, на что она направлена и активно к ней готовятся.

Кстати, начать читать книгу по проектному управлению вместо того, чтобы самому наступить на все грабли, – это тоже проактивный подход. Вы молодцы!

NUP4 – помни, что прочность цепи определяется по ее самому слабому звену[7]

ПРОЕКТЫ СОСТОЯТ ИЗ РАЗЛИЧНЫХ ДОМЕНОВ, И ВСЕ ОНИ ТРЕБУЮТ ВНИМАНИЯ; У НАС ДОЛЖНА БЫТЬ ЦЕЛОСТНАЯ КАРТИНА ПРОЕКТА.

Руководство NUPP

Разработка ракеты Falcon 1 заняла почти четыре года и обошлась компании SpaceX примерно в сто миллионов долларов. Первый запуск, стоивший свыше семи миллионов, состоялся 26 марта 2006 года. Ракета пролетела меньше минуты и упала, пробив крышу сарая на соседнем острове.

Что же стало причиной катастрофы? Обычная гайка! Алюминиевая B-гайка на входе датчика давления топливного насоса разрушилась из-за межкристаллитной коррозии, что привело к утечке топлива. И при зажигании двигателя вытекшее топливо загорелось[8].

Злополучная гайка стоила пять долларов. Иногда слабое звено

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

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

А иногда слабое звено очень большое. Буквально слон в комнате, которого все пытаются не замечать.

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

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

ЗАДАЧА МЕНЕДЖЕРА ПРОЕКТА – КАЖДЫЙ ДЕНЬ НАХОДИТЬ СЛАБЫЕ ЗВЕНЬЯ В СВОЕМ ПРОЕКТЕ И РАБОТАТЬ С НИМИ, НЕВАЖНО, ГАЙКА ЭТО ИЛИ ВЛАДЕЛЕЦ КОМПАНИИ.

NUP5 – не делай ничего без четкой цели

ВЫ НЕ ДОЛЖНЫ НИЧЕГО ДЕЛАТЬ, ЕСЛИ ЭТО НЕ ИМЕЕТ ЧЕТКОЙ ЦЕЛИ.

Руководство NUPP

1000 часов. Именно столько моя жена училась игре на фортепиано. Ей очень нравился этот инструмент. Родители не сразу, но поддались на уговоры записать дочь в музыкалку.

И вот, мечта сбылась. Теперь дома стояло красивое немецкое пианино, а в новом портфеле лежали нотные тетради. Школа находилась рядом с домом, и Лере даже повезло попасть к отзывчивому преподавателю. Через 7 лет моя будущая супруга получила аттестат об окончании музыкальной школы с одной четверкой.

История успеха? Пожалуй, да.

Есть один нюанс – я никогда не слышал, как Лера играет на фортепиано.

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

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

Для проектов это тоже справедливо.

«Принимайте решения, основываясь на данных!» – наверное вы слышали такой совет. Звучит разумно? Разумно. Я тоже согласился с этим утверждением, и весь 2024 год мы внедряли систему сквозной аналитики в pmclub.

У нас было пять социальных сетей, три сайта, две CRM[9] и почтовые рассылки. Не то чтобы все эти данные были нужны, но раз начал строить систему сквозной аналитики, то иди в своем увлечении до конца. Единственное, что меня беспокоило – это LMS[10]. В мире нет ничего более беспомощного, безответственного и безнравственного, чем аналитика в LMS. И я знал, что довольно скоро мы в это окунемся.

Несколько месяцев мы разбирались с этим зоопарком, решали, что будем считать заявкой и каким данным верить. Собрали формы отчетов для B2B[11] и B2C[12], для блога и для телеграм-канала, для вебинаров и для курсов.

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

Мы были так погружены в процесс, что забыли спросить себя: азачемнам эти данные?

К счастью, в других случаях мы были более сдержанны и рассудительны. «Давайте переедем в новый мессенджер», «давайте перенесем весь сайт на WordPress»[13], «давайте сделаем кастомный дизайн в LMS» – все это примеры идей, от которых мы отказались и не жалеем.

Если сегодня к вам подойдет ваш заказчик или начальник и попросит внести изменения в проект, не спешите говорить «да» или «нет». Подождите оценивать сроки и стоимость. Сначала спросите, зачем эти изменения нужны.

NUP6 – используй воспроизводимые элементы

ЛУЧШИЙ СПОСОБ УПРОСТИТЬ РАБОТУ – ИСПОЛЬЗОВАТЬ ВОСПРОИЗВОДИМЫЕ ЭЛЕМЕНТЫ[14], ЖЕЛАТЕЛЬНО В ПОВТОРЯЮЩИХСЯ ЦИКЛАХ.

Руководство NUPP

Несколько лет назад маме Леры потребовалась операция. Перед началом врач задавал вопросы по стандартному чек-листу и первым делом попросил пациентку подтвердить свое имя. Так выяснилось, что маму привезли в эту палату ошибочно и чуть не сделали совершенно другую операцию.

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

Хирург и профессор Гарварда Атул Гаванде в своей книге «Манифест чек-листа. Как не допускать ошибок в важных делах» приводит множество кейсов, например: внедрение хирургического чек-листа ВОЗ в 8 странах снизило смертность почти вдвое (с 1,5 до 0,8 %) и число осложнений на треть.

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

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

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

Любой руководитель проекта

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

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

• Следуя повторяющимся шагам из P3.express вы упрощаете себе жизнь – не нужно задумываться, когда обновлять планы, составлять отчеты и проводить встречи.

• Здоровая рутина высвободит время на главное – коммуникации, помощь команде и принятие решений.

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

Давайте лучше перейдем к разбору шагов методологии.

Раздел 3. Запуск проекта

– Лер, а давай сделаем курс по публичным выступлениям? Я знаю классного эксперта!

В феврале 2020 года я выступал на Teamlead Conf в Москве, где рассказывал про методологию P3.express. Я был так впечатлен масштабом мероприятия и подготовкой спикеров, что даже не сомневался – всем в IT-сфере нужны навыки публичных выступлений, поэтому надо срочно делать курс по этой теме в нашей онлайн-школе. Видимо, мои глаза горели так сильно, что Лера сразу поддержала идею нового проекта.

Курс получился настоящей конфеткой! На рынке таких не было. Во-первых, курс о смыслах – о том, как донести свои идеи до аудитории, а не о том, как задорно прыгать по сцене и не бояться людей в зале. Во-вторых, он заточен под IT-специалистов – у нас даже есть урок про лайвкодинг[15]. В-третьих, в программе много приятных фишек: выступление можно отработать с автором курса, к видео даны конспекты и задания, а ключевые мысли проиллюстрированы примерами из TED[16] и других классных конференций. Я до сих пор пересматриваю отдельные уроки, когда готовлюсь к важным выступлениям.

Мы сделали качественный продукт, которым гордимся. Но есть один нюанс.

Продажи нового курса открылись в августе 2020 года. Да, вы все правильно поняли. Мы запустили курс в самый разгар пандемии, когда все крупные мероприятия были под запретом и подготовка к выступлениям стала неактуальной. Летом, когда, по нашему опыту, в онлайн-школах наступает низкий сезон. На тему, курсы по которой набирают меньше тысячи ежемесячных запросов в поисковике.

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

Почему так вышло? Можно ли было заранее прикинуть результаты проекта? Да! Можно ли было отказаться от идеи курса в самом начале? Конечно!

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

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

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

В такой ситуации оказался Йорн Утцон, архитектор Сиднейского оперного театра. Из-за давления политиков на подготовку проекта было выделено недостаточно времени. В итоге к началу строительства в 1959 году многие вопросы проектирования оставались нерешенными. Как технически воплотить в жизнь паруса, по которым сегодня здание узнают во всем мире, было непонятно. На поиск решения ушло несколько лет. А в разгар работы, в 1966 году, Утцона и вовсе отстранили от проекта[17]. Он покинул Австралию, и, дожив до 90 лет, так и не увидел свой шедевр, открытый в 1973 году, в законченном виде.

Не поддавайтесь на соблазнительные мысли «по ходу разберусь», «что тут думать, делать надо», «да все просто». Такие мысли – проделки когнитивных искажений. Когда вы идете в магазин со списком покупок, вы тратите меньше времени на выбор продуктов и меньше денег на незапланированные вкусняшки. Даже в таком простом вопросе минимальная подготовка экономит много ресурсов. А сделать проект обычно все-таки сложнее, чем сходить за молоком.

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

– А в чем особенность P3.express? – спросит опытный проджект. – У меня во всех проектах есть подготовительный этап. Как только руководство утверждает новый проект, я составляю планы, потом собираю команду и берусь за работу.

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

А кто принимает это решение и кто выделяет ресурсы на проект, который еще даже не утвержден, я расскажу в следующей главе.

A01 – назначить спонсора проекта

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

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

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

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

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

Параллельно со сбором информации придется проводить тендер и согласовывать формальности. Здесь нужна

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

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

Казалось бы, всего пара шагов – учесть интересы всех топов и расплатиться за услуги – и проект завершен. Но почему-то никто не хочет перечислять оплату по вашей просьбе. А секретарь председателя правления снова отвечает, что его руководитель занят и не успел посмотреть отчет.

ПРИЧИНА, ПО КОТОРОЙ ВЫ МОЖЕТЕ ОКАЗАТЬСЯ В ТУПИКЕ НА ЭТОМ ЭТАПЕ, ПРОСТА – ВЫ ДОСТИГЛИ ПРЕДЕЛОВ СВОИХ ПОЛНОМОЧИЙ.

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

Как менеджер вы не должны и не можете быть в курсе предпочтений членов правления. Доступа к кнопке «Подписать платеж» у вас тоже нет. Для решения этих вопросов нужно подняться на уровень выше. На уровень спонсора.

Спонсор – это руководитель высшего звена, поэтому ему проще договариваться о встрече с председателем правления и оплате счетов. Он хорошо понимает, зачем компании нужен проект, и может влиять на процессы. А еще он знает, чего хотят члены правления, с которыми он на «ты».

Спонсор должен помогать проджекту с решением сложных вопросов, но он не может глубоко погружаться в ежедневные процессы. У большинства топ-менеджеров физически нет времени вникать в детали конкретного проекта. Это и не требуется, потому что спонсору важнее сохранять helicopter view[18] – думать о проекте в контексте всей организации и ее стратегии.

Давайте вернемся к годовому отчету. Знаете ли вы, кто спонсор проекта?

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

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

Скорее всего, вы найдете способ решить все вопросы вовремя, но потратите на это больше усилий и нервов, чем могли бы. А если годовой отчет к совету директоров вдруг окажется не готов, крайним будете именно вы.

Делать проекты без спонсора тяжелее, и исследования это подтверждают: по данным Пульса Профессии[19], одна из четырех опрошенных организаций (26 %) указывает, что недостаточная поддержка спонсора – основная причина провала проектов.

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

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

Спонсор – это роль, а не должность. Ответьте на вопрос: кто из топ-менеджеров больше всего заинтересован в успехе вашего проекта? Это может быть коммерческий или технический директор, главный бухгалтер или любой другой руководитель. Допустим, вы делаете приложение для сотрудников – супер, вам нужен директор по HR. Пообщайтесь с этим человеком и попросите взять на себя роль спонсора. Затем письменно зафиксируйте договоренности – например, в приказе, сообщении в чате или электронном письме.

Важно: спонсор у проекта должен быть только один. Несколько спонсоров – это гарантированный хаос.

Несколько лет назад к нам на обучение по P3.express пришла команда медтех-стартапа. На первом же мастермайнде, когда мы обсуждали роль спонсора, менеджер проекта взял слово и почти прокричал: «Я не понимаю, как мне быть! У нас трое основателей, и у каждого есть свое мнение по проекту. Они приходят ко мне по одному и требуют все переделать…» Чтобы команда не попала в замкнутый круг переделок, основателям было бы достаточно договориться, кто какой проект курирует. Что они и сделали благодаря мастермайнду.

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

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

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

Договоритесь о границах до старта проекта. Например, уточните, в каких случаях решение можете принять вы, а в каких его нужно передать спонсору? Можете ли вы самостоятельно менять поставщиков? О каких изменениях в проекте критично сообщать? В каком формате лучше предоставлять отчеты?

Регулярно общайтесь. Поддерживайте осведомленность спонсора о проекте. Заранее договаривайтесь о встречах для обсуждения актуальности проекта, его статуса и вопросов.

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

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

A02 – назначить менеджера проекта

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

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

Надеюсь, вы стремились к роли проджекта не для того, чтобы стать большим начальником и раздавать указания. Иначе у меня для вас плохие новости. В профессиональных кругах при описании роли руководителя проекта часто используют термин «лидер-слуга». В 1970 году его ввел мыслитель, бизнесмен и консультант Роберт Гринлиф в противовес концепции авторитарного лидерства.

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

Задайте себе эти вопросы, чтобы оценить, правильно ли вы понимаете свою роль:

1) Привлекаете ли вы команду к совместной работе, чтобы вместе принимать решения, оценивать и ставить задачи, управлять рисками?

2) Настраиваете ли вы процессы так, чтобы всем было комфортно взаимодействовать?

3) Помогаете ли вы участникам команды развиваться и расти профессионально?

4) Устраняете ли вы препятствия, которые мешают команде работать лучше и достигать результата?

Ань Дао Фам в своей книге сравнивает проектных менеджеров с клеем, который «сцепляет команды, заполняя пробелы в процессе и коммуникациях везде, где это необходимо»[20]. Чтобы стать таким клеем, потребуется искренний интерес к участникам проекта, желание и умение помочь им прийти к цели. Поэтому я считаю, что софты, как часто называют мягкие навыки, и внутренний настрой для проджекта первичны.

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

МЕНЕДЖЕР ПРОЕКТА – ЭТО НЕ ПОВЫШЕНИЕ, А ДРУГАЯ ВЕТВЬ РАЗВИТИЯ.

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

На своем примере покажу, почему так происходит. Когда-то я был финансовым аналитиком, даже защитил диссертацию по этой специальности. Сейчас предел моих возможностей – это автосумма в Excel. Я утрирую, но не очень сильно. Решите для себя, что для вас приоритетнее – быть крутым техническим специалистом или расти как руководитель.

Кстати, отказываться от роли менеджера тоже нормально. Это отличная идея, особенно в следующих случаях.

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

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

Испытываете сложности со структурированием информации.Заметки по встречам, отчеты, реестры, чек-листы, фоллоу-апы – неизменные спутники работы. Если у вас они вызывают стресс, лучше сменить направление.

Привыкли принимать решения единолично.Есть компании, в которых это качество ценится. Но точно ли вы хотите в них работать?

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

Кстати, как только вас назначили, сразу проверьте, кто спонсор. Если его нет, вернитесь к А01 и воспользуйтесь рекомендациями из этого раздела. На практике шаги методологии могут немного меняться местами или накладываться друг на друга – не переживайте из-за этого, важнее, чтобы они были пройдены.

A03 – назначить ключевых членов команды

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

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

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

А вам бы понравилось, если бы кто-то без вашего участия договорился о том, что завтра вечером вы съедите кастрюлю борща за пять минут? Сомневаюсь. Так и команда зачастую оказывается не готова выполнить то, что от ее имени пообещали менеджеры. Расскажу, что обычно происходит дальше.

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

А дальше выяснилось, что команду изначально не привлекали к оценке. Менеджер рассчитала все сама. В итоге пару недель ушли только на изучение документации, еще три на переписки с поддержкой и согласования. Стоимость тем временем выросла на треть. Пострадали все.

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

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

О ком еще стоит подумать?

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

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

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

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

A04 – описать проект

НА ЭТОМ ШАГЕ ПРОВОДИТЕ РАБОЧИЕ ВСТРЕЧИ, ЧТОБЫ СОБРАТЬ ИНФОРМАЦИЮ И ПОДГОТОВИТЬ РЕЗЮМЕ ПРОЕКТА.

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

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

У этого документа много названий: паспорт проекта, устав, карточка или мандат. Продолжать можно до бесконечности. Но главное – суть.

Резюме проекта – это простые ответы на сложные вопросы:

• Что мы делаем?

• Зачем мы это делаем?

• Сколько у нас есть на это времени и денег?

• Каковы основные требования к проекту и продукту?

• Кто участвует в проекте?

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

РЕЗЮМЕ ПРОЕКТА – ЭТО САМОДОСТАТОЧНЫЙ ДОКУМЕНТ, КОТОРЫЙ ДОЛЖЕН БЫТЬ ПОНЯТЕН БЕЗ ПОЯСНЕНИЙ.

Тогда

Больше того, Резюме не заканчивает свое существование после завершения проекта. Сохраните его в базе знаний – чтобы переиспользовать в дальнейшем. Обратите внимание – это NUP6 «Используй воспроизводимые элементы»!

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

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

Резюме должно занимать до пяти страниц. Мы в pmclub предпочитаем лаконичные одностраничники, и это не случайно – чем короче документ, тем быстрее его можно вдумчиво прочитать и тем легче его корректировать. Ведь Резюме не выбивают в камне на века, и в ходе проекта вам неоднократно придется его обновлять. Только не забывайте согласовывать изменения со спонсором.

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

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

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

Давайте вместе сделаем Резюме этого проекта.

Название проекта.Не используйте сложные аббревиатуры типа АБЫРВАЛГ или БОЧ рВФ 260602 – будет трудно сходу распознать, о чем вообще речь. Давать числовые обозначения вроде «Проект 1249» тоже не вариант – это как «папка 1», «папка 2» на рабочем столе компьютера, не слишком удобно. Лучше выбрать короткое и емкое название, которое будет легко использовать в разговорной речи: «Отчет 2035», «Распил монолита», «Битрикс для продажников».

Наш проект назовем «Конференция Про. дизайн».

Содержание проекта.Тут следует указать, что вы конкретно планируете сделать. Написать: «Проект по повышению узнаваемости», – плохая идея. Звучит абстрактно, ничего не понятно. Гораздо лучше добавить деталей: «Двухдневная офлайн-конференция про дизайн в Москве». Конечно, вы можете лучше. Но мы же только начинаем!

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

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

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

Теперь о выгодах: зачем вы делаете конференцию?

Вариант: «Мы делаем конференцию для повышения популярности школы», – неудачный. Мы действительно делаем мероприятие, чтобы школа стала известнее – но ведь мы почти все делаем для этого: создаем продукты, проводим акции и вебинары. Если у вас появился такой «универсальный» пункт, это повод еще раз задуматься и проверить, точно ли он несет ценность.

А какой вариант будет хорошим?

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

Организуя конференцию, вы рассчитываете повысить узнаваемость и сделать продажи. Супер. Вот как можно сформулировать ожидаемые выгоды:

• увеличение подписчиков сообщества на 1000 участников;

• не менее 100 продаж на сумму не менее 5000000 рублей на участников конференции в течение трех месяцев после проведения;

• не менее 10 публикаций в СМИ.

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

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

Там, где говорят, что сроки «вчера», дедлайны по всем проектам уже давно провалены. И ничего, как-то компания работает. Безграничных денег тоже не бывает. Обычно через пару месяцев оказывается, что деньги не проблема только до определенных границ, и они почему-то постоянно сужаются. Обе формулировки – признаки проблем в культуре компании. Одним проектным управлением такое, к сожалению, не лечится.

ДРУГАЯ КРАЙНОСТЬ – ТОЧНЫЕ ЦИФРЫ.

На этапе создания Резюме они должны настораживать, даже пугать. Откуда они могут взяться? Вы еще не приступали к работе, не делали декомпозицию проекта и не анализировали риски. Вам неоткуда взять точные оценки. Это стоит признать и не пытаться никого, в первую очередь себя, ввести в заблуждение.

Вот хороший пример заполнения этого раздела – он задает некоторые границы, но при этом не создает иллюзию точной оценки: «Бюджет до 1 000 000 рублей. Конференция должна пройти в мае».

Требования.Самое смешное, что может быть в этом пункте (и бывает!): «Выполнить проект в соответствии с требованиями». Это превосходный пример рекурсии, но совершенно бесполезная строчка в Резюме проекта.

Лучше крупными мазками прописать требования к проекту и продукту: «Площадка расположена не дальше 5 минут от метро», «Зал вмещает не менее 300 человек», «В программе участвуют зарубежные эксперты».

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

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

Спонсор проекта – директор по маркетингу Сергей, ник в мессенджере @name;

Менеджер проекта – Алина, ник в мессенджере @name1;

Тимлид – Павел, ник в мессенджере @name2;

Директор по продажам – Кристина, ник в мессенджере @name3.

Также к этому перечню постоянно будут добавляться новые стейкхолдеры – контактные лица со стороны подрядчиков,

Супер, мы сделали первую версию Резюме проекта, оно на рисунке.

Рисунок 3. Первая версия Резюме проекта «Конференция Про. дизайн»

Обратите внимание, оно не идеально. Рабочий вариант обычно проще того, что мы себе воображаем. Возможно, даже проще этого примера.

Восемь лет назад я проснулся с гениальной идеей выпустить бесплатный курс[21], а деньги на его создание собрать через краудфандинг. Я взял в руки телефон и накидал первую версию резюме – посмотрите, что у меня получилось.

Рисунок 4. Та самая версия Резюме, которую я накидал в заметках

Я показал его Лере, объяснил суть проекта, и мы взялись за работу. Краудфандинговая кампания прошла успешно – мы не только собрали всю требуемую сумму, но и набрали первую тысячу учеников. А всего за эти годы курс прошли более 10 000 человек, и для многих из них он стал пропуском в мир управления проектами.

А началось все с простенького резюме на смартфоне.

Бесплатный онлайн-курс Проджект менеджмент 101 от pmclub об основных понятиях проектного менеджмента

https://pmclub.pro/courses/pm-101

A05 – определить ожидаемые результаты

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

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

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

Помните технику из тайм-менеджмента по работе с большими задачами: «слона надо есть по кусочкам»?

ЗДЕСЬ ДЕЙСТВУЕТ ПОХОЖИЙ ПРИНЦИП – РАЗДЕЛИТЕ ПРОЕКТ НА ЧАСТИ.

Так вы превратите общее намерение в набор элементов, которые команда сможет детализировать, обсуждать и контролировать. А значит, проектом будет легче управлять.

По итогу воркшопа у вас должна получиться Карта результатов – визуализация элементов проекта. Первую версию Карты удобно разрабатывать в виде майндмэпа[22]: у него понятная структура, она помогает мыслить творчески и видеть проект целиком.

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

Заявление в ЗАГС – если хотим регистрацию в день свадьбы. Кольца – их всю жизнь носить, это важно. Неплохо бы подумать про медовый месяц или, по крайней мере, выходные. Ничего не забыли? Точно! Нужны фотки. А для удачных фоток – стильные луки, то есть образы. Если хотим собрать друзей, надо подумать про банкет.

Отлично! Теперь перенесем все ключевые элементы на рисунок в виде майндмэпа.

Рисунок 5. Карта результатов проекта «Свадьба» в виде майндмэпа

Обратите внимание, для формулировки результатов мы используем существительные. Это не случайно.

Нам надо будет выполнить много действий, например, для получения «Фотографий»: собрать рекомендации, выбрать фотографа, договориться об условиях. Но на Карте мы обозначаем главное – конечный результат, а не действия, поэтому на ней вы видите только одно слово – «Фотографии».

Что дальше? Часть элементов – Кольца, Заявление, Фотографии – в целом понятны и трогать их не надо. А вот остальные можно продолжить декомпозировать. Например, Образ невесты будет включать в себя: Платье, Туфли, Прическу, Макияж и Маникюр. Теперь гораздо понятнее, что надо будет сделать, чтобы его собрать.

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

Посмотрим, что у нас получилось.

Рисунок 6. Карта результатов проекта «Свадьба» с декомпозицией остальных элементов

КАКОГО-ТО ОДНОГО ПРАВИЛЬНОГО ВАРИАНТА ДЕКОМПОЗИЦИИ НЕ СУЩЕСТВУЕТ. ЭКСПЕРИМЕНТИРУЙТЕ.

Для той же свадьбы можно сделать Карту результатов иначе – посмотрите на рисунок 7. Здесь в качестве основных выделено всего четыре элемента: Регистрация, Фотографии, Банкет, Путешествия. В этой версии Заявление в ЗАГС, Кольца, Образ невесты и жениха входят в компонент Регистрация.

Рисунок 7. Другая версия Карты результатов проекта «Свадьба»

НАСКОЛЬКО ДЕТАЛЬНОЙ НУЖНО ДЕЛАТЬ КАРТУ – ТОЖЕ СМОТРИТЕ ПО СИТУАЦИИ.

Например, нашу карту мы можем оставить как есть. Вроде, все понятно. А можем продолжить спускаться на следующие уровни и раскрыть «Меню»: Напитки, Горячее, Закуски, Десерт.

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

Рисунок 8. Пример Карты результатов для проекта по внедрению CRM

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

А вот ключевые принципы составления Карты результатов:

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

2)Используйте существительные: это помогает держать фокус на результатах, а не на действиях, которые к ним приведут.

3)Не пытайтесь сделать сразу «чистовой» вариант– ничто так не способствует прокрастинации, как перфекционизм.

Не забудьте обновить Резюме проекта, когда в ходе воркшопа по составлению Карты результатов выявили новые факты: например, если потребуется обучить продавцов работе в CRM, это повлияет как минимум на сроки – надо зафиксировать.

Теперь займемся укрощением неопределенности в проекте.

A06 – определить риски и запланировать меры реагирования

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

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

Нассим Талеб – автор серии книг Incerto, посвященных рискам и неопределенности. Самая известная из них – «Черный лебедь», опубликованная в 2007 году. Она была переведена на 30 языков и разошлась по миру тиражом более 3 000 000 экземпляров.

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

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

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

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

Действительно, откуда? О планах разработчика уволиться можно узнать, если регулярно проводить один-на-один[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] проверить:

На что же обращать внимание во время ревью на Запуске? Насколько глубоко нужно погружаться в детали? Стоит ли вникать в технические подробности? В большинстве случаев ничего подобного не требуется: чаще всего проблемы лежат на поверхности.

Поэтому для начала обратите внимание на простые вопросы:

• Вовлечен ли спонсор в ключевые аспекты проекта?

• Избегает ли спонсор погружения в детали?

• Достаточно ли менеджер проекта знаком с P3.express?

• Сформировано ли ядро команды?

• Понятно ли написано резюме?

• Достаточен ли уровень декомпозиции проекта?

• Какие нашли риски?

• Принимали ли ключевые члены команды активное участие в планировании проекта?

АДАПТИРУЙТЕ ЭТОТ СПИСОК ПОД НУЖДЫ СВОЕГО ПРОЕКТА.

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

Однажды я проводил ревью проекта по созданию Интранета и обратил внимание, что идентификацию рисков не проводили.

– А какие там могут быть риски? – спросил меня проджект. – Проект понятный, с подрядчиком уже работали.

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

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

Звучит прекрасно, но есть и подводные камни. Например, с чего вдруг допускать в свою вотчину кого-то еще? У нас в культуре не принято показывать слабость. И уж точно не принято заниматься самодоносительством и признавать свои ошибки до того, как кто-то их заметил.

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

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

Еще несколько идей:

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

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

•вступите в комьюнити pmclub для поиска ревьюерови участия в созвонах для развития нетворка и насмотренности.

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

Сохраните полученную информацию вРеестре «Здоровье проекта». Так в Р3.express называют документ, в котором зафиксированы результаты прошедших ревью и оценок удовлетворенности участников проекта. Устраните недочеты и приступайте к шагу, на котором наконец решится судьба проекта.

A08 – решить «go/no-go»

МЕНЕДЖЕР ПРОЕКТА ОТПРАВЛЯЕТ ПОДГОТОВЛЕННУЮ ПРОЕКТНУЮ ДОКУМЕНТАЦИЮ СПОНСОРУ, А СПОНСОР ПРИНИМАЕТ РЕШЕНИЕ «GO/NO-GO» – СТАРТОВАТЬ ПРОЕКТ ИЛИ ОТМЕНИТЬ ЕГО РЕАЛИЗАЦИЮ.

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

Все получилось как-то само собой. Я работал в найме и участвовал в очередном проекте. У него был вовлеченный спонсор, менеджер и ядро команды. Мы составили планы. Согласование проекта перенесли по не зависящим от нас причинам – а мы решили просто действовать. Мы же не формалисты, на результат работаем.

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

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

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

Главный урок, который я извлек из этой истории – не стоит бежать впереди паровоза. Устные договоренности – это прекрасно, энтузиазм – просто чудесно, но, прежде чем приступать к работе, проектнужно утвердить, соблюдая все формальности.

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

Как происходит защита проекта в этом случае?

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

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

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

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

Если принято решение не запускать проект, проджект должен заархивировать все наработки – они пригодятся в будущем при планировании похожих проектов или возвращении к этому.

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

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

– Окей, Дима. Все классно, мы со всем согласны. Но что делать, если проект уже запустили, а меня просто поставили перед фактом?

Перед таким

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

A09 – провести стартовую встречу проекта

ПОЗАБОТЬТЕСЬ, ЧТОБЫ СТАРТОВОЕ СОБЫТИЕ НЕ ПРЕВРАТИЛОСЬ В «СУХУЮ» И СКУЧНУЮ ВСТРЕЧУ, ГДЕ ОБСУЖДАЮТСЯ ТОЛЬКО ДЕТАЛИ ПРОЕКТА.

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

Если спонсор подтвердил запуск проекта – отлично! Приступайте!

Самое время собрать команду и стейкхолдеров на кик-офф – стартовую встречу. Зачем?

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

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

Главное, помните, что встреча направлена не на планирование. Планированием вы занимались при подготовке Резюме проекта, Карты результатов и поиске рисков. Она нужна для налаживания взаимодействия в команде. Объявите о запуске проекта, сообщите ключевую информацию и помогите участникам познакомиться.

P3.express рекомендует выделить на стартовую встречу целый день и провести его за пределами офиса. Когда бюджет позволяет, можно превратить старт в интересное, запоминающееся событие.

Мой друг, специализирующийся на организации сложных мероприятий, вывез команду одной IT-компании на три дня в Грузию. Первый день был целиком посвящен активностям, не связанным с работой: ребята дегустировали воду[26], разделяли баранов на белых и черных, встречали рассвет на границе с Азербайджаном. И только на второй день они перешли к обсуждению рабочих вопросов.

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

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

Вы тоже можете найти проблему, которая откликается у вашей команды и связаться с НКО или волонтерами, которым вы доверяете.

ВЫДЕЛИТЕ ОДИН ДЕНЬ, И ПРОВЕДИТЕ ЕГО ВМЕСТЕ, ЗАНИМАЯСЬ ДОБРЫМ ДЕЛОМ.

A10 – направить фокусированную коммуникацию

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

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

Вы завершаете этап «Запуск проекта», остался всего один шаг – поделиться новостями с коллегами.

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

Как часто вам приходилось слышать эти фразы: «Мы же с тобой договорились»; «Я же сказал об этом вчера»; «Мы же обсуждали на прошлой встрече»; «В смысле ты не знаешь, что планы поменялись?»

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

• не все присутствовали на встрече;

• кто-то отвлекался;

• кто-то делает вид, что не услышал про неприятную задачу.

ПОСТОЯННЫЕ ПЕРЕПИСКИ НА ПОЧТЕ И В ЧАТАХ ИНОГДА НЕ УЛУЧШАЮТ ПОЛОЖЕНИЕ ДЕЛ, А НАПРОТИВ, УСУГУБЛЯЮТ.

Однажды мы работали в компании, где общение параллельно велось по почте, в Whatsapp, Telegram, Slack, Trello, Bitrix 24. При этом работали все в офисе, и устных договоренностей тоже хватало. Разумеется, никто не понимал, какую информацию считать актуальной – каждый жил в своем мире.

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

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

Рисунок 10. Пример фокусированной коммуникации на старте проекта

У меня была такая нелепая ситуация. Мы разрабатывали стратегию компании и решили, что стоит узнать, как ее видят сотрудники. Выбрали агентство, которое может провести исследование, согласовали все с директором и передали счет на оплату финансистам. Через час к нам забежала разъяренная начальница HR-отдела: оказалось, что за месяц до нас она тоже начала проект по оценке вовлеченности персонала, выбрала подрядчика и уже оплатила счет. Конечно, мы ничего не знали о проектах друг друга.

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

Как сказал наш ученик Илья: «Самая большая ошибка – вначале отправить коммуникацию только на свою команду. Потому что ваша команда и так знает, что вы делаете». Гораздо больше смысла в том, чтобы сделать рассылку на все направление или даже компанию.

Раздел 4. Планирование цикла

На этапе «Запуск проекта» вы много времени уделили подготовке. Так зачем снова, когда проект только-только одобрен, возвращаться к планированию? Почему нельзя просто начать работать?

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

Так и в любом проекте: не все детали можно или нужно просчитывать с самого начала. Когда вы составляли первые планы, вы даже не могли сказать, будет ли он в итоге запущен. Сейчас ситуация изменилась: вы точно знаете, что проект одобрили. Кроме того, уже могли появиться новые вводные.

После этапа «Запуск проекта» начинается работа в циклах. Цикл – отрезок времени, продолжительностью один месяц. Шаги в циклах повторяются, так вы не только задаете ритм своей работе, но и снижаете когнитивную нагрузку: к примеру, не приходится каждый раз придумывать, когда и какие рабочие встречи проводить, кому сообщать о статусе. Это чем-то напоминает тренировки в спортзале: чем регулярнее занимаешься, тем меньше сопротивления и результат более стабильный.

ПРИ ПЛАНИРОВАНИИ ЦИКЛА ОСНОВНОЕ ВНИМАНИЕ НУЖНО УДЕЛИТЬ ПРОАКТИВНОСТИ: УТОЧНИТЬ ПЛАНЫ НА БЛИЖАЙШИЙ МЕСЯЦ И ПРОВЕРИТЬ ИХ НА АКТУАЛЬНОСТЬ.

Также на этом этапе вы можете обновить планы на весь проект – например, скорректировать прогнозы по срокам или Карту результатов, просто эта часть планов останется менее детализированной.

Если вернуться к поездке в Мостар, то «менее детализированный план» – это когда вы решили посетить ресторан местной кухни, но еще не выбрали, какой именно и какого числа вы это сделаете.

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

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

B01 – обновить и детализировать планы

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

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

Лера очень любит, когда все предусмотрено заранее. Она всегда составляет чек-лист для сбора вещей в поездку, требует от меня резюме на любой проект, а если к вечеру пятницы мы не решили, чем займемся в выходные, то у нее начинается паника. Я в свою очередь отношусь к планам спокойно: главное, чтобы никто не требовал от меня их записывать и соблюдать.

Оба подхода имеют свои недостатки. У Леры портится настроение, если что-то вдруг поменялось. А я каждый раз переплачиваю за билеты и отели, бронируя их накануне вылета.

Но какой из подходов предпочтительнее, когда речь идет о планировании в проекте? Как показывает наш опыт, нужен третий вариант, более гибкий. В мире, где каждый день все переворачивается с ног на голову, упорные попытки следовать плану могут привести в тупик, а не к цели. В то же время недостаток планирования быстро приведет к хаосу. Оптимальная стратегия – всегда иметь план и быть готовым к изменениям. Это учитывается в P3.express: планирование происходит поэтапно, а работа с обновлениями – каждый день.

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

Давайте временно побудем такой командой. Вы разрабатываете онлайн-курс, и первоначальный вариант Карты результатов проекта приведен на рисунке 11. Она состоит из следующих элементов: Программа, Спикеры, Лендинг, Контент, Продвижение.

Рисунок 11. Карта результатов проекта по разработке онлайн-курса, основные компоненты

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

Рисунок 12. Карта результатов проекта по разработке онлайн-курса с декомпозицией элемента Контент

Получилось несколько пунктов: Видео, Конспекты уроков, Полезные ссылки, Тесты после уроков, Задания на проверку, Тесты к модулям, Финальный тест. Как понять, за что браться в первую очередь? Можно ориентироваться назависимости между элементами, а можно наприоритеты.

Для начала рассмотрим вариант сприоритетами. Мы в pmclub чаще всего используем метод приоритизации MoSCoW. Давайте используем его на составляющих элемента Контент и разделим их на несколько типов:

M (Must) – те задачи, без которых обойтись нельзя. В нашем случае это будет Видео – основа урока, вокруг которой все строится;

S (Should) – то, что делаем во вторую очередь. Задания на проверку. С ними урок уже выполняет свои основные задачи, поэтому к ним можно приступить после Видео;

C (Could) – можем делать, можем не делать. Конспекты и Полезные ссылки. Классное дополнение к урокам, но без них учиться тоже можно, поэтому приоритет ниже;

W (Would) – сделаем, только если выполним все предыдущие пункты и станет совсем скучно. Тесты к модулям и Финальный тест. Хорошие пункты, но пока не понятно содержание уроков, их делать бесполезно. Отложим.

Рисунок 13. Элементы результата Контент приоритизированы по методу MoSCoW

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

Рисунок 14. Пример рабочей доски в софте Weeek с тэгами приоритетов на карточках

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

От цикла к циклу приоритеты могут меняться. Например, в первом цикле «Конспекты уроков» могут быть Should (так как записать видео в этом цикле важнее), а в третьем уже Must (потому что из оставшихся ожидаемых результатов этот будет самым важным).

Второй подход учитываетзависимости между элементамипроекта.

Помните пример с CRM из шага А05, где мы составляли Карту результатов? Там были такие элементы: Настройка решения, Сравнение решений, Обучение.

Пока вы не выберете систему, не получится ее настроить. А без понимания того, как CRM работает, будет проблематично провести обучение. Это и есть пример зависимости – когда не получится начать или завершить какой-либо элемент проекта, не начав

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

Рисунок 15. Пример упрощенной диаграммы Ганта

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

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

Рисунок 16. Карточка результата Видео с описанием

Не забудьте назначитьответственногоза карточку – члена команды, который будет следить за ее обновлением. Допустим, это Надя. Обратите внимание: это не значит, что она будет выполнять все задачи. Запись и монтаж видео по-прежнему делают другие люди. Но Надя, помимо выполнения своей работы, также будет проверять актуальность информации в описании.

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

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

Проверьте и остальные материалы проекта: Резюме, Карту результатов, и внесите правки, если информация устарела. Например, к проекту присоединился консультант – нужно добавить его в список стейкхолдеров.

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

B02 – провести ежемесячное ревью

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

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

Цель этого шага – замедлиться и проверить то, как вы управляете проектом. Для этого, как и на A07, нужно привлечь другого проджекта и обсудить с ним вашу работу в завершенном цикле и подготовку к следующему.

Некоторые стесняются отвлекать коллег от работы. А зачем им это надо? – спрашивают они. Не смущайтесь, ваш визави получит от процесса ревью еще больше пользы: консультируя другие проекты мы быстро качаем насмотренность.

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

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

Используйте эту возможность, чтобы обсудить вопросы, которые по-настоящему вас беспокоят. Старайтесь узнать новое, а не пытаться изо всех сил доказать, что с вашим проектом все хорошо.

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

Вот несколько примеров вопросов для обсуждения:

• Детализирован ли план на предстоящий месяц?

• Обновлен ли верхнеуровневый план?

• Знает ли команда о своих задачах?

• Как оценивается прогресс проекта?

• Что с информированием стейкхолдеров?

• По каким причинам возникают отклонения в проекте и как можно с ними работать?

• Актуальна ли информация в таск-трекере?

• Фиксируете ли вы извлеченные уроки по мере работы?

• Что можно улучшить в работе?

• Достаточно ли команда вовлечена в работу с рисками?

• Проводится ли оценка удовлетворенности команды и заказчика?

• Нужно ли пересматривать подход к оценке удовлетворенности?

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

Полученные комментарии и идеи зафиксируйте в реестре «Здоровье проекта». Как именно он будет выглядеть, не принципиально, кому-то удобно оформлять заметки в таблицах как на рисунке 17. Главное собирать их в одном месте.

Рисунок 17. Заметки по результатам ежемесячного ревью

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

ПРОЕКТ – ЭТО НЕ ТО МЕСТО, ГДЕ СТОИТ ВЕСТИ ДОКУМЕНТАЦИЮ «ЧИСТО ДЛЯ СЕБЯ»: ЕЙ ДОЛЖНО БЫТЬ УДОБНО ПОЛЬЗОВАТЬСЯ ЛЮБОМУ ЧЕЛОВЕКУ.

Думаю, правильнее всего относиться к шагам ревью именно как к взаимному обучению и обмену опытом. Согласно исследованиям, 75 % сотрудников предпочитают учиться вместе с другими людьми, а 19 % особенно любят обучение с равными по статусу коллегами[27]. Потому что это хорошо работает. P3.express по сути побуждает осознанно использовать этот подход, чтобы улучшать свои навыки проектного управления.

Убедившись, что вы ничего не пропустили, переходите к следующему шагу.

B03 – решить «go/no-go»

НА ЭТОМ ШАГЕ СПОНСОР ДОЛЖЕН ПРИНЯТЬ НОВОЕ РЕШЕНИЕ GO/NO-GO НА ОСНОВЕ УТОЧНЕННЫХ ПЛАНОВ. ОН МОЖЕТ ПРИНЯТЬ РЕШЕНИЕ ЕДИНОЛИЧНО ИЛИ СОГЛАСОВАТЬ ЕГО С ДРУГИМИ, НАПРИМЕР, С КОМАНДОЙ УПРАВЛЕНИЯ ПОРТФЕЛЕМ ПРОЕКТОВ.

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

Вам когда-нибудь приходилось разбирать гардероб?

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

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

Почему так сложно избавляться от ненужных вещей? А главное, почему они накапливаются?

Ответ на этот вопрос дал экономист и психолог Ричард Талер, основоположник поведенческой экономики. Именно он ввел термин «ловушка невозвратных потерь» (англ. «sunk cost fallacy») – это когнитивное искажение, при котором люди продолжают тратить время, деньги или усилия на убыточный проект только потому, что в него уже были вложены большие ресурсы.

Примечательно, что второе название этого искажения –эффект Конкорда[28]. «Конкорд» – сверхзвуковой самолет, совместный проект Франции и Великобритании. Строительство прототипов авиалайнера началось

Можно ли было избежать этого провала? Да. Уже в самом начале стало понятно, что из-за сильного шума самолет можно будет использовать только для трансконтинентальных полетов, а высокий расход топлива сделает их нерентабельными. Почему решили продолжать проект?

Правильно, потому что в него уже вложены ресурсы.

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

Чтобы этого избежать, в P3.express есть повторяющийся шаг «Go/No-Go», на котором нужно заново ответить себе на вопрос: выполняет ли проект поставленные задачи или вы работаете «просто потому что уже начали»?

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

Решение о продолжении или закрытии проекта принимает спонсор, это его ответственность. Ответственность менеджера – подготовить все материалы, которые помогут спонсору проанализировать ситуацию, и не заметать проблемы под ковер.

Лайфхак от нашего ученика – чтобы не пропускать этот шаг, просто поставьте себе и спонсору повторяющуюся встречу в календарь. Это еще одно практическое применение принципа NUP 6 – «Используй воспроизводимые элементы».

B04 – провести стартовую встречу цикла

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

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

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

Но есть загвоздка – количество коммуникаций (особенно встреч) порой становится таким большим, что жалобы из серии «мне некогда делать свою работу» уже давно не кажутся преувеличением. Самое печальное, что потраченное на совещания время часто не приносит желаемых результатов. Работники умственного труда сетуют, что встречи неэффективны в 72 % случаев[30]. Читая это, я представляю, что сел в поезд, который 7 из 10 часов пути стоит, и прихожу в ужас.

Интересно, что и совсем отказаться от встреч тоже нельзя. Особенно, если члены вашей команды работают из разных городов[31]: полное отсутствие созвонов приводит к снижению вовлеченности и продуктивности[32].

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

У ВСТРЕЧ ЕСТЬ И ДРУГОЙ ПРИЯТНЫЙ БОНУС – ОНИ ПОМОГАЮТ УЧАСТНИКАМ ПРОЖИВАТЬ СОВМЕСТНЫЙ ОПЫТ.

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

Еще на встречах можнообнаружить «мелочи», которые не вскрылись бы в иных обстоятельствах: недопонимания, идеи и мысли по проекту, для озвучивания которых не было подходящего момента. Вдруг бизнес-аналитику Владимиру не нравится, когда вы называете его Вовой. Без личного контакта можете и не узнать.

Вернемся к B04 – на нем нужно организовать стартовую встречу цикла. Она будет не такой грандиозной, как на «Запуске проекта», но и к ней нужно немного подготовиться. У этой встречи две цели: сплотить команду и донести информацию о планах на предстоящий месяц.

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

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

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

B05 – направить фокусированную коммуникацию

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

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

Как и на других шагах с фокусированной коммуникацией, здесь вам нужно отправить сообщение.

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

Цель данного шага может быть не сразу понятна, особенно если вы сделали хорошие заметки по встрече на B04. Вы делаете фоллоу-апы, правда? Чем тогда отличается от них фокусированная коммуникация?

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

Я к тому, что совмещать эти две сущности не стоит, если у вас нет на это веских причин – например, над проектом работает только одна небольшая команда. Лучше потратьте минутку и составьте сообщение, которое будет адаптировано под текущую цель.

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

Большинство участников не занимаются проектом 100 % своего времени. Дайте им возможность быстро посмотреть и вспомнить, что происходит, не продираясь через технические подробности. Избегайте специфической терминологии и погружения в детали из разряда: мы добавим lazy loading для длинных таблиц, увеличим скорость загрузки страницы на 5 секунд, уберем возможность фильтровать таблицу по цене.

Рисунок 18. Пример фокусированной коммуникации на старте цикла

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

Раздел 5. Еженедельные действия

Однажды, еще до знакомства с P3.express, я участвовал в проекте в качестве спонсора. Мы делали сайт: содержанием занималась наша команда, а технической стороной – подрядчик. Сайт был старый и с запутанной структурой, контента накопилось очень много и позиции в поиске терять не хотелось.

Раз в неделю мы созванивались с подрядчиком. Я периодически подключался ко встречам из любопытства – команда отлично справлялась и без меня.

Каждая встреча длилась минут 20–30 максимум, при этом половина этого времени уходила на любезности типа «как мы рады с вами работать», «потрясающе выглядишь сегодня», «блестящая идея», а затем мы проходились по доске в Trello. Задачи смотрели справа налево – сначала сделанные, потом в работе, и в конце те, к которым еще не приступили. Если все было в порядке – шли дальше. Если возникали вопросы – ничего не пытались решить на месте. Вместо этого просто отмечали в комментариях участника команды, который должен был потом разобраться.

Расходились все в приподнятом настроении. После встречи наш проджект писал короткое сообщение со статусом проекта.

Сами не зная этого, мы фактически проходили еженедельные шаги по методологии P3.express:

C01 – Оценить и зафиксировать прогресс;

C02 – Реагировать на отклонения;

C03 – Провести еженедельную встречу;

C04 – Направить фокусированную коммуникацию.

Что это давало?

Во-первых, мы сразу видели, когда появлялись какие-то проблемы. Задачка зависла – почему?

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

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

Сайт сделали в срок, и все остались довольны. До сих пор не понимаю, почему такие еженедельные встречи еще не стали стандартом.

C01 – оценить и зафиксировать прогресс

СРАВНИТЕ ПРОГРЕСС ПРОЕКТА С ЕГО ЦЕЛЯМИ И ПОДГОТОВЬТЕ РЕАЛИСТИЧНЫЕ ПРОГНОЗЫ ПО ЦЕЛЕВЫМ ПОКАЗАТЕЛЯМ (НАПРИМЕР, ПО СРОКАМ И СТОИМОСТИ). СОСТАВЬТЕ ОДИН ИЛИ НЕСКОЛЬКО ОТЧЕТОВ С АКЦЕНТОМ НА ПРОГНОЗЫ.

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

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

Если команда работает в едином пространстве, таск-трекере, то это не составит труда. При условии, что все вовремя и качественно обновляют информацию, конечно.

Я понимаю, когда решаешь исправно вести таск-трекер, первые пару дней или неделю все классно: добавляешь карточки, двигаешь их между колонками, разные тэги красиво подсвечиваются. Потом карточек становится слишком много, а заходить на рабочую доску – слишком страшно. Колонки «В очереди» и «В работе» стремительно растут, а «Готово» пустует больше, чем хотелось бы.

Привыкать качественно вести доску задач – и так занятие мучительное, чем-то напоминает попытку бросить курить. А тут еще и хорошо видно, как много работы не сделано и как много карточек не обновлено. Не ободряет.

Но когда речь идет о работе в команде, без ведения задач никуда. Все соблазны сделать побыстрее и что-то пропустить – описание задачи, критерии приемки, ответственного – приводят к тому, что задачу приходится делать по два раза или намного дольше. Это как сходить на рабочую встречу и не сделать заметки. Через день вы уже забудете, что там было, и, когда возникнет необходимость, информацию надо будет узнавать и искать заново. Помните: правильные процессы обходятся дешевле.

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

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

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

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

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

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

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

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

C02 – реагировать на отклонения

ЕСЛИ ПОСЛЕ ОЦЕНКИ ПРОГРЕССА C01 ВЫ ОБНАРУЖИЛИ ОТКЛОНЕНИЯ ОТ ЦЕЛЕЙ, ВЫ ДОЛЖНЫ УСТРАНИТЬ ИХ, ЧТОБЫ ВЕРНУТЬ РАБОТУ ПО ПРОЕКТУ В НОРМАЛЬНОЕ РУСЛО.

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

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

Устроили мозговой штурм, но снова безрезультатно. Единственным, кто не высказался, был молодой организационный психолог, недавно пришедший в компанию. Когда к нему обратились, он спросил: «А почему они жалуются? Лифт ждать пару минут». Оказалось, что время ни при чем. Людям просто скучно. Тогда в холле установили зеркала, чтобы скрасить ожидание. Решение сработало – жалобы прекратились. Кстати, зеркало в вашем лифте стоит в тех же целях.

Я считаю, что эта история – хорошая иллюстрация проблемы XY: вместо того чтобы решать настоящую проблему Y – скуку пассажиров, компания пыталась решить проблему X – ускорить лифт.

К чему я это рассказываю?

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

Большой ошибкой будет в этот момент собрать команду и сказать: «Мы отстаем от графика на 15 дней! Давайте работать быстрее, чтобы наверстать!» Бесполезно. Я знаю, о чем говорю: всегда так делаю и ни разу это не сработало.

ВМЕСТО ТОГО, ЧТОБЫ РЕШАТЬ ПРОБЛЕМУ В ЛОБ, ПОСТАРАЙТЕСЬ НАЙТИ ПЕРВОПРИЧИНЫ И УСТРАНИТЬ ИХ.

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

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

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

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

C03 – провести еженедельную встречу

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

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

Абду сосредоточенно смотрит в ноутбук, заканчивая сообщение. Диляра пытается отогнать сон и тянется к чашке с кофе. Даша и Ваня застыли со стеклянными глазами, а Вадим рассказывает о своих планах на предстоящую неделю. Вы, менеджер проекта, с беспокойством оглядываете аудиторию и вздыхаете, отмечая, что рекомендации P3.express никуда не годятся.

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

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

ПОМОГИТЕ ЧЛЕНАМ КОМАНДЫ НАЛАДИТЬ КОНТАКТ В ЭТОМ МЕСТЕ – ПРОГОВОРИТЬ МЕЖДУ СОБОЙ, КОГДА И КАК БУДЕТ ПРОИСХОДИТЬ ПЕРЕДАЧА РАБОТЫ ОТ ОДНОГО СОТРУДНИКА ДРУГОМУ.

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

При этом постарайтесь не растягивать обсуждение, по крайней мере формальную часть. Этого легко добиться, если проводить его стоя в планке. Шучу, конечно, про планку – а вот стоя попробуйте: это может оказаться действительно удобно.

В какой день проводить еженедельную встречу? Универсального ответа нет. Лично мне нравится, когда к вечеру пятницы уже понятно, с чего надо будет продолжить работу в понедельник. Плюс пятничную встречу по желанию команды удобно завершать неформальной частью.

Убедились, что конфликтов нет и все понимают свои задачи? Можно двигаться дальше.

C04 – направить фокусированную коммуникацию

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

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

– Какой проект? Не слышал о таком. – директор положил трубку и выразительно посмотрел на Антона.

Антон руководил проектом по замене информационных систем в финансовом холдинге. Однажды директор вызвал его в кабинет и поинтересовался, как идут дела в филиалах.

Услышав, что те вовлечены в проект, директор позвонил в Самару. Естественно, по закону подлости, коллега, снявший трубку, о проекте не слышал.

Антон задумался – вроде бы, он все делал правильно. И все же дела в проекте шли плохо. То есть не так чтобы очень плохо, можно было бы даже сказать – хорошо, но с каждым днем все хуже и хуже[33]. Почему так?

Взглянув на проект со стороны, Антон и команда поняли: многие в компании не воспринимали проект всерьез или забыли про него. Поэтому каждая оплата по счету, каждое согласование, каждая задача затягивались.

Вот тогда Антон, участник самого первого в России тренинга по P3.express, и вспомнил про фокусированные коммуникации.

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

КОММУНИКАЦИЯ, СТАВШАЯ РИТУАЛОМ, ПРИВЕЛА К РОСТУ ВОВЛЕЧЕННОСТИ В ПРОЕКТ.

Ребятам начали предлагать помощь: кто-то хотел помочь

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

Рисунок 19. Пример еженедельной фокусированной коммуникации

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

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

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

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

Раздел 6. Ежедневные действия

Чем занимается менеджер проекта? Однажды я задал[34] этот вопрос в канале pmclub и получил такой ответ от подписчика Алексея Терехова: «Основная цель во всех случаях: двигать проект вперед. В зависимости от компании, в это вкладывается разный объем ответственности и возможностей». Очень метко сказано, согласен на все сто.

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

– Каждый день я жарил котлеты, кормил ребят и укладывал спать.

– Серьезно? – поперхнулся я.

– Конечно. Задача проджекта – каждый день приближать проект к цели. Если для этого надо жарить котлеты, я это делаю.

Илья очень сильный менеджер проекта, и у него стоит поучиться каждому.

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

Не отменяя их важности, P3.express предлагает каждый день фокусироваться на двух шагах:

D01 – Управлять рисками, проблемами и запросами на изменения;

D02 – Принять результаты работы.

D01 – управлять рисками, проблемами и запросами на изменения

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

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

Вы играли в детстве в тетрис?

Квадраты, зиг-заги, т-образные фигуры летят сверху вниз. Постепенно они ускоряются и летят все быстрее. Игрок может поворачивать их и перемещать влево или вправо. Если квадратики легли в ряд, он исчезает. Если зазеваться, фигуры встанут как попало, и игровое поле будет заполняться все больше и больше. Когда новым блокам будет некуда падать, игра окончена – вы проиграли.

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

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

В первую очередь обращайте внимание на все обновления. Заказчик хочет добавить фичу, работы на час – может, согласиться? Не стоит, это запрос на изменение, его нужно обработать. Дизайнерка просит дать отгул в следующем месяце – хм, нужно проверить, не создаст ли это проблему? Не пытайтесь решать все вопросы на ходу. И не держите их в голове, лучше оставьте в ней достаточно пространства для принятия решений.

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

В A06 на примере риска я объяснил, как заполнять Реестр последующих действий в формате таблицы. Это идеальный вариант для фанатов таблиц и тех, кто привык полностью вести в них проект. Если ваша команда работает в таск-трекере, то, возможно, более удобное решение – использовать для Реестра доску. По аналогии с доской задач.

И создать ее можно в том же самом рабочем пространстве. На рисунке показано, как это реализовано в сервисе Kaiten[35]. Сверху располагается доска с Картой результатов, а ниже доска с Реестром последующих действий.

Рисунок 20. Вид рабочей доски с Картой результатов и Реестром последующих действий в шаблоне от Kaiten

В этом случае для работы с Реестром последующих действий команде не придется заходить в сторонние вкладки, будет проще обновлять информацию, добавлять ответственных и отслеживать изменения. Кроме того, можно ставить напоминания и прикреплять дополнительные материалы.

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

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

Не пытайтесь сразу сделать карточку идеальной – красоту навести потом успеете. Лучше сфокусируйтесь на сути: опишите ситуацию и назначьте ответственного – того, кто будет за этой карточкой следить.

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

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

Поэтому вместе опишите правила работы с ним и своевременно обновляйте информацию.

D02 – принять результаты работы

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

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

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

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

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

Классический пример проекта, где была допущена эта ошибка – строительство международного аэропорта Денвер. Команда не протестировала инновационную систему обработки багажа в реальных условиях. Это привело к многочисленным проблемам: тележек и буксировщиков оказалось недостаточно, возникали заторы, которые приводили к повреждению и потере багажа[36]. В итоге проект завершился с опозданием на 16 месяцев и превышением бюджета на два миллиарда долларов. А спустя 10 лет от непротестированной вовремя системы отказались полностью.

ЧТОБЫ НЕ ВСТРЕЧАТЬ ДЕДЛАЙН С ПУСТЫМИ РУКАМИ И НЕ ПОПАДАТЬ В УЧЕБНИКИ КАК ПРИМЕР ЭПИЧНОГО ПРОВАЛА, КАЖДЫЙ РАЗ, КОГДА У ВАС В ПРОЕКТЕ ЧТО-ТО ГОТОВО, ПРОВЕРЯЙТЕ РЕЗУЛЬТАТ.

Идеально, если вы можете утвердить его у спонсора или заказчика как можно быстрее. Это просто, когда вы все на связи. Но если нет, обговорите, каким образом вы можете регулярно показывать и письменно согласовывать промежуточные результаты.

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

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

На шаге B01 – «Обновить и детализировать планы» задайте вопрос команде:а как мы убедимся, что задача выполнена? И добавьте к описанию чек-лист, по которому можно будет проверить готовность.

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

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

Если вовремя отмечать выполненные этапы, то, заглянув в карточку, всегда можно узнать, что происходит с задачей, никого не беспокоя вопросами. А если все-таки нужно будет что-то уточнить – то вы знаете, к кому можно обратиться.

Рисунок 22. Пример карточки результата с описанием критериев приемки и этапов работы

Есть еще один веский довод не затягивать с приемкой. Мультизадачность часто встречается и в вакансиях, и в резюме, но, по данным исследований, хорошо с ней справляются только 2 % людей[37], а остальные здорово теряют в продуктивности.

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

Ну и наконец: как же приятно видеть в таск-трекере статусы «Готово». Не так ли? Тоже хороший повод сначала закончить текущую задачу, прежде чем взять следующую.

Раздел 7. Закрытие цикла

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

Уже в 2004 году Великобритания выиграла на Олимпиаде две медали, в 2008 – восемь, а в 2012 установила девять мировых рекордов и семь олимпийских. А человек, изменивший ход истории велогонок, тренер Дэвид Джон Брейлсфорд, в 2014 году был произведен в рыцари ее Величества и получил к своему имени приставку сэр. В чем же был его секрет?

Процитирую:

«Весь принцип основан на идее, что, если разбить на составляющие все, что можно придумать в отношении езды на велосипеде, а затем улучшить каждую из них на 1 %, то в совокупности получится значительное улучшение»[38].

К делу отнеслись серьезно и совершенствовали буквально все: от велосипедных сидений до способа мытья рук. Даже установили, на каких подушках должны спать спортсмены. Звучит скучно, но эта методичная работа вывела команду-аутсайдера на вершину.

Мне очень нравится эта концепция, получившая название «накопление минимальных улучшений» – она применима и в управлении проектами.

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

Чтобы накапливать улучшения и не совершать одни и те же ошибки снова и снова, P3.express предусматривает этап «Закрытие цикла». Он состоит из трех шагов, которые позволяют сделать паузу для анализа проделанной работы и подумать, что стоит изменить в следующем цикле. Этап включает в себя сбор обратной связи от стейкхолдеров, извлечение уроков и коммуникацию результатов, достигнутых в цикле.

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

E01 – оценить удовлетворенность стейкхолдеров

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

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

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

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

Казалось бы, вы как менеджер и так глубоко погружены в проект и постоянно на связи с командой и другими стейкхолдерами. Если возникнут недопонимания, то вы непременно их заметите, – или вам о них сообщат. Правда?

Но в реальности одни члены команды не любят жаловаться, другие не дают обратную связь, когда не спрашивают, а третьи не задумываются, что это может быть важно или даже не осознают, что им есть, чем поделиться. В итоге люди начинают грустить, а потом увольняются с мыслями «как же надоел этот хаос!», «мое мнение никого не интересует», «я вообще не понимаю, над чем работаю…».

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

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

Не менее важно собирать фидбэк не только от команды, но и от других стейкхолдеров проекта. Это поможет узнать о проблемах, пока они в зародыше.

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

Как именно запрашивать обратную связь? P3.express рекомендует направлять опросники, которые можно пройти анонимно. Так людям гораздо легче делиться своими опасениями и проблемами и сложнее якориться[39] на мнение других коллег. Для проведения опросов можно использовать онлайн-формы.

Примеры вопросов для оценки удовлетворенности команды:

• Комфортно ли вам общаться с участниками проекта?

• Цели проекта, на ваш взгляд, реалистичны?

• У вас есть целостная картина проекта? Вы понимаете свою роль в нем?

• Процесс управления проектом делает вашу работу более комфортной?

• Менеджер проекта вас достаточно поддерживает?

• У вас есть предложения по совершенствованию системы управления проектом?

• К вашему мнению прислушиваются?

• В целом, вы довольны работой в проекте?

• Вам комфортно работать в вашей команде?

• Как вы считаете, нуждается ли команда в тимбилдинге?

Для ответа предложите поставить оценку от 1 до 5 или выбрать что-то из списка: «совсем нет», «скорее нет», «50/50», «скорее да», «точно да». Не забудьте в конце опросника оставить место для свободного комментария, чтобы можно было добавить пояснения.

Рисунок 23. Пример опроса в онлайн-формах

Примеры вопросов для оценки удовлетворенности других стейкхолдеров проекта, например, заказчика, подрядчиков, поставщиков:

• Вам комфортно с нами коммуницировать?

• Процесс управления проектом для вас понятен и прозрачен?

• У вас всегда есть четкое понимание того, что мы делаем?

• У вас есть четкое понимание наших планов?

• У вас есть предложения по тому, как улучшить процесс управления проектом?

• В целом, хотели бы вы продолжить работу с нами в рамках других проектов?

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

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

ПОПРОБУЙТЕ В СИНХРОННОМ РЕЖИМЕ – ВЫДЕЛИТЕ ПЯТЬ МИНУТ НА ЗАПОЛНЕНИЕ ОПРОСНИКА НА ВСТРЕЧЕ ИЛИ СОЗВОНЕ И ЗАТЕМ ОБСУДИТЕ РЕЗУЛЬТАТЫ.

Есть и другие варианты: попросите прислать в чат стикер или цифру от 1 до 5, проведите созвоны один-на-один. Не бойтесь креативить: поштормите с командой или коллегами, чтобы пополнить копилку идей для оценки удовлетворенности.

Например, подписчица pmclub и руководитель проектов Ирина адаптировала этот инструмент таким образом: в конец еженедельных отчетов добавила форму с вопросами по ощущениям от проекта – что нравится, что оставить, что улучшить и что убрать. Команда знает правила: Ирина направляет отчет в понедельник и до среды можно оставить обратную связь. Затем она лично разбирает ответы и приоритизирует те, которые требуют действия.

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

E02 – извлечь уроки и запланировать улучшения

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

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

Перед тем, как писать про этот шаг, я решил посмотреть комментарии, которые к нему оставляют слушатели нашего курса по P3.express[40].

Там есть небольшой вопрос для рефлексии: умеет ли ваша команда проводитьретроспективу– встречу по анализу проделанной работы и извлечению уроков? Я ожидал, что почти 100 % ответов будут положительными. Мне казалось, что это такая популярная практика, что буквально все ее используют.

Но, пролистав пару десятков ответов, я заметил, что «нет» тоже встречается довольно часто.

Тогда я решил посмотреть все ответы, которых было больше 300. Выяснилось, что 40 % комментаторов ответили отрицательно! Дополнительно они отмечали, что либо никогда не проводили ретро, либо в компании не принята такая практика.

Еще часть извлекают урокипослезавершения проекта. Хорошие новости, но как это поможет уже закрытому проекту? Никак. По факту такая ретроспектива – это post-mortem[41].

Более практичный вариант – провести извлечение уроков на «Закрытии цикла». Часть работы уже проделана, а значит, есть, что проанализировать. А в следующем цикле вы сможете внедрить улучшения. Выдумывать и вспоминать ничего не надо, у вас уже есть с чего начать.

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

Кстати, уроки – это не всегда про неудачу. Если у вас что-то отлично сработало – это тоже урок: так можно и нужно делать. Например, вы зафиксировали в календаре регулярную встречу с заказчиком, и он стал быстрее давать обратную связь и дружелюбнее общаться. Почему бы не использовать эту идею в других проектах?

Как зафиксировать полезные выводы? Можно на соответствующей карточке поставить тэг «Извлеченный урок», создать на доске отдельный столбец с уроками – как на рисунке столбец «Занесен в Базу знаний», или вынести такие элементы на отдельный лист, если вы ведете реестр в таблицах.

Рисунок 24. Пример отражения извлеченного урока на доске с Реестром последующих действий в таск-трекере Weeek

Уточните у команды, есть ли еще уроки, которые не были зафиксированы. Их тоже нужно занести вРеестр последующих действий.

Дальше откройтеРеестр «Здоровье проекта»и посмотрите результаты оценки удовлетворенности. Упс, больше половины команды не уверены, что к ним кто-то прислушивается. Кажется, на инициативу рассчитывать не приходится. Отличный повод обсудить ситуацию и подумать, следует ли что-то изменить.

Рисунок

Также темы для обсуждения и планирования улучшений могут подкинуть результаты опроса заказчика или других стейкхолдеров. Как в случае Дениса из предыдущей главы.

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

А еще люди охотнее поддерживают те решения, которые они сами же и предложили.

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

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

Я предлагаю для поиска решения использовать вариант метода Дельфи[42].

1. Соберите команду, онлайн или офлайн.

2. Объясните цель и технику проведения встречи.

3. Обозначьте проблему так, чтобы с ее формулировкой были согласны все участники.

4. Попросите анонимно записать все варианты решения проблемы (один стикер – одно решение).

5. Соберите стикеры, объедините похожие идеи и составьте общий список идей.

6. Уточните, нужно ли что-то дополнить.

7. Попросите команду проголосовать за лучшие решения.

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

9. Результаты занесите в Реестр последующих действий.

Рисунок 26. Пример голосования с точками на флипчарте

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

E03 – направить фокусированную коммуникацию

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

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

Вот и снова ваш, надеюсь, уже любимый шаг – направить фокусированную коммуникацию. Разработчики P3.express не зря уделяют ей такое внимание: каждый пятый проект терпит провал из-за проблем с коммуникациями[43].

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

Лена выстроила работу по P3.express и разбила проект на четыре цикла, а фокусированная коммуникация помогла ей наладить взаимодействие с командой. В конце каждого месяца Лена находила слова благодарности для каждого участника и делилась результатами проекта, которые уже удалось получить.

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

Рисунок 27. Пример коммуникации на завершении цикла

Все коммуникации были четкими, с фокусом на цель конкретного этапа и признание вклада команды. Это сильно повлияло на мотивацию: команда была полностью готова к старту, а девочки в контенте были максимально заряжены на результат. Лена подготовила шаблон ТЗ, чек-листы для написания и верстки, а процессы работы с текстами и публикации выстроила параллельно.

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

Рисунок 28. Пример коммуникации на завершении цикла

Я хочу передать вам совет от Лены:

«ГОВОРИТЕ В МИРЕ ЧЕЛОВЕКА».

Это значит, сообщайте о том, что важно конкретно этому человеку и теми словами, которые ему понятны.

А вот еще пара советов, которые помогут написать коммуникацию так, чтобы ее прочитали и поняли:

Фокусируйтесь на достижениях, а не на проделанном объеме работы. Если, конечно, не хотите, чтобы, как пел классик, «мерилом работы считали усталость»[44].

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

Пишите лаконично. Если члены вашей команды захотят почитать роман, они могут сходить в книжный. Соревноваться с Толстым и Достоевским в жанре фокусированной коммуникации не стоит.

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

Раздел 8. Закрытие проекта

Мне хотелось бы написать, что теперь, когда вы перешли кЗакрытию проекта, пора выдохнуть и порадоваться успехам. Но расслабляться еще рано. Как минимум, вам предстоит ответственный шаг – передатьрезультаты проекта.

Если вы следовали всем рекомендациям из книги, тоЗакрытиедолжно пройти более менее плавно. В противном случае будет сложнее. Начнут вскрываться все нюансы разом: окажется, что не все задачи действительно готовы, объявится стейкхолдер с новыми требованиями, пользователи будут жаловаться, что ничего не понятно. А вы окажетесь в неловкой ситуации – вы же говорили, что все почти сделано.

После запуска системы расчетов оплаты труда Phoenix в 2016 году десятки тысяч сотрудников федерального правительства Канады столкнулись с ошибками начисления зарплаты[45]. Часть сотрудников не получили денег вообще, часть получили больше или меньше нужной суммы. Вскоре стало понятно, что система неработоспособна, но вернуться к старой было уже невозможно. Спустя десять лет Phoenix продолжает работать некорректно, а проблемы с выплатами копятся и не решаются годами.

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

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

Даже если ваш продукт получился совершенным, все равно уделите внимание шагамЗакрытия. Вы вложили все силы в проект не для того, чтобы на последних шагах оступиться и скомпрометировать результаты проделанной работы. Мой друг Антон Околелов так случайно отправил заказчику готовый интернет-магазин, в котором описание товаров было заполнено шуточным текстом из серии: «Маркс и Энгельс пошли погулять…»[46]. Было неловко.

Также шагиЗакрытия– это отличная возможность подвести итоги со всеми стейкхолдерами и договориться о дальнейших планах.

К концу этапа как раз будет время выдохнуть и от души отпраздновать успехи. Давайте поговорим, как дожить до этого момента.

F01 – передать продукт

Когда проект завершен, мы должны утвердить продукт у

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

Прежде всего морально подготовьтесь к этому шагу. Сделайте глубокий вдооооох и выыыыдох. А теперь погнали.

Обычно F01 – самый сложный и нервный шаг на Закрытии проекта. Я только рад, если для вас это не так. Скажем, вы провели классное мероприятие – это и был ваш «продукт», и теперь вам остается написать пару писем, чтобы рассчитаться с подрядчиками. Идеально!

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

Хорошая идея – разработать для себя чек-лист, по которому будете подводить итоги работы. Это поможет не упустить самое важное.

Перед подготовкой такого чек-листа проверьте, что:

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

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

•есть план реагированияна случай, если что-то фатально пойдет не так;

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

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

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

•есть список документации и доступов, которые понадобится передать;

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

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

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

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

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

Своей команде я говорю:

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

Почему важно ориентироваться на долгосрочные отношения?

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

В 2011 году стартап Tiny Speck выпустил игру Glitch, но она не нашла свою аудиторию, провалилась и была закрыта в 2012-м. Как только у команды появилась идея для пивота, инвесторы Tiny Speck, которые только-только потеряли немалые деньги, были готовы вложиться в новый проект. Сегодня компания создателей Glitch известна всему миру как разработчик корпоративного мессенджера Slack.

НЕ УПУСКАЙТЕ ШАНС ЗАРАБОТАТЬ ХОРОШУЮ РЕПУТАЦИЮ И ЗАВЕСТИ НАДЕЖНЫХ ПАРТНЕРОВ.

F02 – оценить удовлетворенность стейкхолдеров

ОТПРАВЬТЕ ВНУТРЕННИМ ИЛИ ВНЕШНИМ СТЕЙКХОЛДЕРАМ ФИНАЛЬНЫЙ АНОНИМНЫЙ ОПРОСНИК УДОВЛЕТВОРЕННОСТИ И ЗАФИКСИРУЙТЕ РЕЗУЛЬТАТЫ В РЕЕСТРЕ «ЗДОРОВЬЕ ПРОЕКТА». В ОТЛИЧИЕ ОТ ЕЖЕМЕСЯЧНОГО ОПРОСНИКА ЭТА ИТОГОВАЯ ОЦЕНКА КАСАЕТСЯ ВСЕГО ПРОЕКТА В ЦЕЛОМ.

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

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

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

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

Что вы можете получить? Например, проработать недопонимания с заказчиком, если они возникли во время передачи продукта. Договориться об отзыве, благодарственном письме, которое команда сможет добавить в свое портфолио, или сразу о следующих проектах. Выявить свои точки роста, подумать, куда бы вы хотели двигаться дальше. Помочь команде выпустить пар, осознать свой вклад в общее дело, понять потребности в обучении. Закончить сотрудничество в доброжелательной атмосфере.

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

Вопросы для команды:

• Как вы оцениваете свои личные результаты?

• Чему вы научились за время проекта?

• Возникла ли у вас потребность в обучении?

• Комфортным ли для вас было взаимодействие с участниками проекта?

• Что было для вас самым сложным в проекте?

• Что больше всего бесило?

• Что вам понравилось в работе над проектом?

• Что бы вы хотели порекомендовать менеджеру проекта?

Вопросы для заказчика, подрядчиков, поставщиков:

• Насколько вы довольны взаимодействием с нами?

• Готовы ли вы нас рекомендовать?

• Как мы можем стать лучше?

• Какой совет вы хотели бы дать менеджеру проекта?

Вопросы для спонсора:

• Как вы оцениваете результаты работы команды?

• Что хотелось бы сделать по-другому в следующем проекте?

• Что вы хотели бы порекомендовать менеджеру проекта?

Вопросы для менеджера проекта:

• Какие чувства у вас возникают, когда вы думаете о проекте?

• За что вы можете себя похвалить?

• Что бы вы сделали иначе, если бы вернулись в прошлое и начали проект заново?

• Хотели бы вы прокачать какие-то навыки?

Наш коллега и ученик Дмитрий Ирешев, руководя проектным офисом, дополнительно адаптировал для этого шага индекс NPS (англ. Net Promoter Score), чтобы

1.«Предлагаем оценить удовлетворенность результатами и ходом ведения проекта по шкале от 1 до 10.

2.Из количества промоутеров (те, кто поставили 9-10) вычитаем количество критиков (кто поставил от 1 до 6).

3.Делим на общее количество участников опроса.

4.Умножаем на 100 %[47]».

Таким образом получается значение в диапазоне от -100 % до 100 %. Чем оно выше, тем лучше.

После сбора ответов проверьте, можно ли из них извлечь уроки. Если да, сформулируйте выводы и занесите в Реестр последующих действий. Поставьте себе задачи, появившиеся благодаря F02 – например, отправить отделу обучения заявку на курс по фасилитации. А сами результаты сохраните в Реестре «Здоровье проекта». С ним вы продолжите работу на следующем шаге.

F03 – сделать ревью этапа закрытия

ПОПРОСИТЕ МЕНЕДЖЕРА ИЛИ ЭКСПЕРТА ПО ПРОЕКТНОМУ УПРАВЛЕНИЮ В ВАШЕЙ ОРГАНИЗАЦИИ ПРОАНАЛИЗИРОВАТЬ ВАШУ ПРОЕКТНУЮ ДЕЯТЕЛЬНОСТЬ СО СТОРОНЫ И ДОБАВЬТЕ РЕЗУЛЬТАТЫ ЭТОЙ ОЦЕНКИ В РЕЕСТР «ЗДОРОВЬЕ ПРОЕКТА».

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

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

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

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

Вот примеры тем, которые стоит обсудить с ним в ходе этого ревью:

• Вы утвердили и передали продукт? Перенесли все на ресурсы заказчика, получили документальное подтверждение приемки результатов?

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

• Понятно ли, как использовать продукт? Заказчик и пользователь – часто разные люди. Убедитесь, что последние понимают, как работает продукт.

• Если остались дополнительные работы, четко ли они перечислены и утверждены? Вы могли договориться, что какие-то задачи будут решены за рамками проекта. Убедитесь, что все стороны понимают, как это будет происходить.

• Вы провели финальную оценку удовлетворенности стейкхолдеров? Если вы последовательно проходили шаги, то наверняка сделали это, но лучше себя проверить и вернуться, если пропустили этот момент.

• Готовы ли документы проекта к архивации? Идеально, если вам удавалось всегда поддерживать документы в актуальном состоянии, но лучше проверить, так ли это.

СТАРАЙТЕСЬ ПРОХОДИТЬ КАЖДОЕ РЕВЬЮ С НОВЫМ МЕНЕДЖЕРОМ. ЭТО СНИЗИТ ЭФФЕКТ ЗАМЫЛЕННОСТИ И ПРИВНЕСЕТ В ВАШ ПРОЕКТ ДОПОЛНИТЕЛЬНУЮ ЭКСПЕРТНОСТЬ.

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

Во-первых, привлекайте менеджеров из других департаментов. Даже если вы работаете в единственном проектном офисе в вашей компании, это не значит, что больше никто из коллег не делает проекты.

Во-вторых, ищите на рынке. Обратите внимание на профессиональные сообщества и на сайты с менторами, например Эйч, Solvery и Getmentor. Зачастую опытные проджекты консультируют других бесплатно. Я и сам как-то провел более пятидесяти менторских сессий просто из интереса.

Вы тоже можете так сделать – зарегистрироваться на одной из платформ и начать помогать другим своей экспертностью. Быстро прокачаете и насмотренность, и нетворк. Рекомендую!

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

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

F04 – заархивировать проектную документацию

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

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

Мой знакомый Борис работал проджектом – отвечал за организацию конференции на 4000 человек.

Несколько лет все шло как по маслу: топовые спикеры, восторженные отзывы в социальных сетях, хорошая прибыль. Сама работа тоже как-то устаканилась, и вклад Бори перестали замечать.

Он заскучал, приуныл и решил сменить работу. Руководство не пыталось его удержать: «и так все нормально работает, нового проджекта наймем, проблем не будет». С передачей дел заморачиваться никто не стал.

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

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

Почему? Есть несколько причин: в компании нет общепринятых инструментов для организации и хранения информации – все разбросано по доскам, почтам, мессенджерам и хранилищам. Уволившемуся сотруднику моментально блокируют доступы и у него не остается шансов систематизировать свои наработки, а поделиться знаниями ему и не с кем – замену еще не нашли, остальным не до того. Я не сгущаю краски, я не раз был свидетелем и даже участником подобных историй.

С компаниями понятно, а в чем ваша заинтересованность в сохранении архивов? На эту тему классно высказался ученик pmclub Александр Огарев: «Если остались заметки, актуальные версии документов, чек-листы, то следующий проект (похожий по масштабу и задачам) идет быстрее: есть с чем свериться, что-то переиспользовать, проще избежать прежних ошибок. Это особенно важно, когда команда частично меняется или часть экспертности теряется из-за паузы между проектами».

НЕ ТЕРЯЙТЕ СВОЙ ОПЫТ – СОХРАНЯЙТЕ И ПЕРЕИСПОЛЬЗУЙТЕ ЕГО.

Для этого аккуратно архивируйте каждый проект: дополните и соберите все материалы в одном месте.

Вот что стоит учесть:

1.Убедитесь, что архив находится в безопасном месте и доступен только для чтения, а система резервного копирования настроена корректно – чтобысо временем не обнаружить, что ваши данные пропали.

2.Проверьте, чтобы названия файлов имели смысл. Названия типа «Папка 1», «Версия 2» – не предел мечтаний: завтра вы не вспомните, что там внутри.

3.Сохраняйте материалы в формате, который будет доступен для чтения, даже если компания поменяет софт.

4.Еще раз убедитесь, что содержание файлов понятно людям, не имеющим отношения к проекту. Архивом могут воспользоваться и через год, и через два. Кто из команды к тому времени продолжит

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

Если на все вопросы вы ответили утвердительно – вашей компании с вами очень повезло. Надеюсь, и вам с ней тоже.

F05 – отметить окончание проекта!

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

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

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

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

Но то, что мы не привыкли отмечать, не значит, что нам не нужно признание и празднование. Очень нужно, просто, закопавшись в рутине, мы перестали чувствовать эту потребность.

Я предлагаю вам стать тем, кто поможет каждому оценить проделанную работу, присвоить себе новое достижение и почувствовать гордость за команду. Как пишет Скотт Беркун в книге «Сделано»:

«СОЗДАВАТЬ КАЧЕСТВЕННЫЕ ПРОДУКТЫ, КОТОРЫМИ БУДУТ ПОЛЬЗОВАТЬСЯ ДРУГИЕ ЛЮДИ, – СЛОЖНЕЙШАЯ ЗАДАЧА. ЕЕ ЗАВЕРШЕНИЕ ДОСТОЙНО ОСОБОГО ПРАЗДНИКА. ВЕСЕЛИТЕСЬ ПО ПОЛНОЙ ПРОГРАММЕ!»

Классно, если вы можете заложить бюджет на это празднование или договориться о его выделении, например, с HR-отделом.

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

Самым простым вариантом, которым можно отметить завершение проекта, со мной поделился основатель студии «Штрихпунктир» Стас Спасеных. Он с командой проводит сессию «Скажи спасибо»: участники проекта текстом, устно или как-то еще благодарят друг друга за совместную работу. Это просто, мило и всегда приятно.

А если проект завершен досрочно? И вообще повод для закрытия так себе: резко поменялась стратегия, клиент недоволен, гипотеза не сработала, новые ограничения ввели. Всем грустно, команда демотивирована, отмечать нечего. Что тогда? Пропускать шаг? Нет!

ПРАЗДНОВАТЬ ПРОВАЛЫ. ПОТОМУ ЧТО БЕЗ НИХ НЕ БЫВАЕТ УСПЕХОВ.

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

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

Не пропускайте шаг F05, даже если не уверены на 100 %, что вот теперь-то все завершено и вас точно больше не потревожат с вопросами по этому проекту. Дела всегда догоняют и затягивают, поэтому не заморачивайтесь с точностью, отмечайте, пока свежи впечатления и эмоции.

F06 – направить фокусированную коммуникацию

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

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

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

Для вдохновения прочитайте письмо, которое вы отправляли на шаге A10 при «Запуске проекта». Сейчас самое время кратко написать о том, как с тех пор трансформировалось видение проекта, с какими сложностями вы столкнулись, какие выгоды уже были достигнуты и чего ожидать дальше. Не забудьте поблагодарить команду и всех, кто оказывал вам поддержку на протяжении проекта. Такое публичное «спасибо» вдохновит на дальнейшую работу и добавит мотивации коллегам на других проектах.

Рисунок 29. Пример коммуникации на завершении проекта

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

Как мы с вами обсуждали на шагах A08 и B03 «Go/No-Go», отказ от проектов – это признак зрелой культуры, а не катастрофа.

В 2019 году Apple отказалась от выпуска устройства для зарядки AirPower, хотя его выход анонсировали еще в 2017 году. «После долгих усилий мы пришли к выводу, что AirPower не сможет соответствовать нашим высоким стандартам, и приняли решение прекратить проект», – сообщил старший вице-президент по разработке аппаратного обеспечения Дэн Риччио[48]. Это был первый случай, когда компания отказалась от выпуска уже анонсированного устройства.

Думаю, всем было тяжело прощаться с проектом, но это жизнь.

ЧТОБЫ ЧЕГО-ТО ДОБИТЬСЯ, НУЖНО НЕ БОЯТЬСЯ СОВЕРШАТЬ И ПРИЗНАВАТЬ ОШИБКИ.

А фокусированная коммуникация – хороший инструмент, чтобы донести эту мысль до всех сотрудников и поддержать их в работе над смелыми идеями.

Раздел 9. После проекта

В 2023 году мы с Лерой гуляли по миру после апокалипсиса. Одичавший японский сад, обветшавшая русская избушка, заросший пруд с лилиями, полузаброшенная оранжерея, футуристичная башня на горизонте – и ни одного человека вокруг. Это «Анталия Экспо» – парк, оставшийся после проведения в 2016 году всемирной ботанической выставки. Мероприятие посетили участники из 50 стран, а башню отметили как «Лучшее культурное здание в мире» на церемонии награждения World’s Best Structures Awards 2017[49].

Увы, это то, что часто

Такие истории – печальный пример неумения работать с выгодами.

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

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

Но вот незадача – кто будет работать с выгодами, если команда уже расформирована? Менеджер проекта в заказной разработке, например, обычно не отвечает ни за судьбу продукта, ни за дополнительные продажи клиенту.

Ответ: управлением выгодами после завершения проекта должен заниматься тот, кто изначально был в нем заинтересован. То есть спонсор. Для этого каждые 3–6 месяцев после закрытия проекта спонсору нужно проходить шаги:

G01 – Оценить выгоды;

G02 – Сгенерировать новые идеи;

G03 – Направить фокусированную коммуникацию.

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

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

G01 – оценить полученные выгоды

СПОНСОР (ИЛИ КТО-ТО ОТ ЕГО ЛИЦА) ДОЛЖЕН ПОТРАТИТЬ НЕСКОЛЬКО ЧАСОВ В КАЖДОМ ПОСТПРОЕКТНОМ ЦИКЛЕ, ИЗМЕРЯЯ ВЫГОДЫ, ПОЛУЧЕННЫЕ ОТ ПРОЕКТА.

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

По статистике, только 52 % организаций отслеживают достижение выгод[51].

Перефразирую: почти половина компаний понятия не имеют, какую пользу приносят им завершенные проекты. Ну если только прикидывают на глазок.

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

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

Доля Coca-Cola на рынке США снижалась уже 15 лет. Пора было что-то менять. Весной 1985 года компания анонсировала изменение легендарной секретной формулы напитка. Слепые тесты, в которых приняли участие более 200 000 человек показывали однозначный результат: большинство предпочитали вкус «новой колы». Бинго! Было решено перейти на выпуск напитка с новым составом. Результат в каком-то смысле превзошел все ожидания.

Coca-Cola стала получать по 1500 звонков в день на горячую линию для потребителей – по сравнению с 400 ранее. Люди принялись создавать запасы газировки, а по всей стране стали возникать протестные группы с целью возвращения старого вкуса. Затем число звонков с жалобами достигло 8000 в день, продажи начали падать, Pepsi воспользовалась случаем и запустила рекламу, утверждающую, что Coca-Cola изменила формулу, потому что потребители предпочитают Pepsi. Актер Билл Косби, который долгое время был рекламным лицом компании, расторг сотрудничество, посчитав что продвижение «новой колы» сильно навредило его репутации. Через 79 дней после начала продаж компания сдалась и возобновила выпуск «классической колы». Теперь в бизнес-школах по всему миру этот кейс изучают как пример маркетингового провала.

Но я хочу отметить, что, ко всему прочему, это еще и пример возникновениянегативных последствий(англ. disbenefits) от реализации проекта. Да, проекты приносят не только то, ради чего их запускают. Именно поэтому надо отслеживать выгоды – уточнять, чем же в итоге все закончилось. Классно, если у вашей компании есть миллионы преданных потребителей, которые сообщают о проблемах сразу. А что, если нет? Заметить неладное будет сложнее.

АНАЛИЗИРОВАТЬ НУЖНО НЕ ТОЛЬКО НЕГАТИВНЫЕ ПОСЛЕДСТВИЯ, НО И ПОЗИТИВНЫЕ.

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

«Мы поставили перед собой цель изменить динамику рынка сахарной колы в Соединенных Штатах, и нам это удалось – пусть и не так, как мы планировали», – сказал председатель правления и главный исполнительный директор Coca-Cola Роберто Гисуэта в 1995 году на мероприятии в честь 10-летнего юбилея «новой колы»[52]. Видите, они еще и отпраздновали свой провал!

Начните с оценки выгод, которые вы прописали вРезюме проекта, а затем взгляните на ситуацию шире и подумайте, принес ли проект еще какие-либо выгоды. Зачем? Чтобы извлечь больше пользы! Этим и займемся на следующем шаге.

G02 – сгенерировать новые идеи

ПОСЛЕ ОЦЕНКИ ПОЛУЧЕННЫХ ВЫГОД (G01) СПОНСОР ДОЛЖЕН ПРОВЕРИТЬ, ЕСТЬ ЛИ ВОЗМОЖНОСТИ ИХ МАКСИМИЗИРОВАТЬ. РЕЗУЛЬТАТОМ МОГУТ СТАТЬ НЕБОЛЬШИЕ ЗАДАЧИ ДЛЯ ОПЕРАЦИОННЫХ КОМАНД ИЛИ БОЛЬШИЕ ИЗМЕНЕНИЯ, КОТОРЫЕ В БУДУЩЕМ МОГУТ СТАТЬ НОВЫМИ ПРОЕКТАМИ.

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

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

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

Давайте посмотрим, что лично вы можете сделать, прочитав эту книгу.

Итак, у вас появились новые знания, что само по себе выгода и приятное достижение – вы молодец! Есть идеи, как максимизировать пользу от чтения?

Накидаю варианты:

1. Применить P3.express на ближайшем проекте.

2. Провести лекцию о методологии или мастер-класс в своей компании. Коллеги получат новые знания, а вы потренируетесь выступать.

3. Сделать доклад на конференции,

4. Провести вебинар с pmclub. Почти как конференция, но не надо выходить из дома. И аудитория теплая.

5. Опубликовать статью про P3.express, например, на Habr, vc.ru или в блоге pmclub. Тоже экспертный пиар, и вы всегда сможете поделиться ссылкой, если вас попросят рассказать о вашем опыте.

6. Пройти сертификацию P3.express Practitioner. Международный сертификат еще никому не помешал, а после чтения книги подготовиться проще.

И это точно еще не полный перечень возможностей! А теперь сравните варианты: закрыть книгу и забыть – или реализовать одну, а может и несколько идей из списка. Чувствуете разницу?

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

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

ВАМ – ЛАЙКИ, ЛУЧИ ПОДДЕРЖКИ И БЛАГОДАРНОСТИ ОТ АУДИТОРИИ, ПОДПИСЧИКАМ – ПОЛЕЗНЫЙ КОНТЕНТ В ЛЕНТУ, А МНЕ – ЗАРЯД ПОЗИТИВА НА ГОД ВПЕРЕД.

G03 – направить фокусированную коммуникацию

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

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

Вы уже знаете, что такое выгоды и что такое фокусированная коммуникация. Сложите одно с другим – и получите шаг G03. Это последний шаг в P3.express, и он очень логичный.

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

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

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

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

G03 не отнимет много времени, особенно если брать пример с основателя «Додо Пицца» Федора Овчинникова. В своей фокусированной коммуникации после завершения проекта он написал всего одно предложение: «Первая партнерская кофейня Дринкит в Самаре вышла в прибыль в первый месяц работы!»[53] Коротко и понятно.

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

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

Рисунок 30. Пример отправки отзыва в чат с командой

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

Раздел 10. Советы по внедрению

Прочитав эту книгу, вы изучили, как говорит наш ученик Илья Бураев, «ванильную версию P3.express» – ту, которая описана в руководстве. Это база, без понимания которой невозможно эффективно внедрить и использовать методологию.

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

НЕ БОЙТЕСЬ И НЕ ЖДИТЕ ИДЕАЛЬНОГО МОМЕНТА ДЛЯ ИЗМЕНЕНИЙ. ИДЕАЛЬНЫЙ МОМЕНТ СОЗДАЕТЕ ВЫ САМИ.

Начните с пилота

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

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

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

Процессы ломаются, инфраструктура не выдерживает. Люди, главная ценность любой компании, в шоке: «не дай Бог вам жить в эпоху перемен»[54]. Некоторые руководители рассуждают так: «Ну да, кто-то уйдет. Зато останутся те, кому с нами точно по пути». Циничная логика, но не вполне верная: останутся в первую очередь те, кому сложнее найти работу. А самые востребованные спецы быстро разойдутся. Частенько уходят сразу целыми командами.

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

В общем, я сам не люблю рубить шашкой с плеча, и вам тоже не рекомендую.

Начните с малого. Запустите пилот.

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

ОЧЕНЬ ТРУДНЫЕ ПРОЕКТЫ НЕ БЕРИТЕ. ЭТО КАК ВПЕРВЫЕ В ЖИЗНИ ВЫЙТИ НА ПРОБЕЖКУ И СРАЗУ ПОПЫТАТЬСЯ ВЗЯТЬ ДЕСЯТКУ.

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

А теперь самое важное – окружите себя заряженной командой! Когда люди верят в то, что делают, им все по плечу.

Сделайте изменения заметными

Можно внедрить метод, никому об этом не сказав. Больше того, можно внедрить P3.express, не рассказывая об этом команде. Серьезно.

Один проджект поступил так: сначала он предложил описать проект – всем понравилось. Потом вместе с командой сделал Карту результатов – тоже зашло. Дальше идентифицировали риски. Никому ничего не объясняя, он прошел все шаги «Запуска проекта» и предложил дальше работать в циклах продолжительностью один месяц. Ближе к концу проекта Сергей все же сказал команде, что они работают по P3.express.

Так делать можно. Но зачем? Зачем совершать хорошие поступки вопреки? Лишая себя поддержки команды и топ-менеджмента. Лишая себя кейса в резюме, выступления на конференции, запросов на консультации.

А вот еще один неожиданный аргумент от Евгения Комиссарова из Спортмастера:

«Надо учиться не тому, как вести проекты, а тому, как в них участвовать. Фокус обучения должен быть не на проджектах, а на команде, воспитании культуры участия в коллективной работе.

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

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

Чтобы сформировать такую зрелую культуру, сделайте свой проект по внедрению методологии заметным.

1. Заручитесь поддержкой спонсора – это поможет и проекту и, вполне вероятно, лично вам. Когда будут решать, кого повышать, и кому давать премию.

2. Расскажите команде, что происходит и проведите небольшое обучение – люди гораздо лучше делают то, что понимают и поддерживают.

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

4. Проведите митап в компании. Не обязательно ждать завершения проекта – просто расскажите, что уже успели сделать. Поверьте, это не менее интересно!

5. Пригласите внешнего эксперта – другого практика, уже внедрившего методологию у себя. Часто к внешним экспертам прислушиваются быстрее.

6. Выступите сами на внешних площадках! Это здорово замотивирует вашу команду, и поможет принять новый метод на уровне компании.

Помните, как старуха Шапокляк в мультфильме говорила: «Хорошими делами прославиться нельзя!» Старуха Шапокляк – отрицательный герой, да и мы уже выросли. Забудьте про этот совет!

Если вы взяли на себя труд и смелость привнести в вашу компанию новый метод P3.express, делайте это открыто и максимально громко!

Опирайтесь на принципы

Надер Рад так объяснил необходимость принципов в книге PMBOK® Guide 7th ed. Underneath the Surface[56]: «принципы помогают нам избегать превращения методологии в карго-культ».

Вкратце напомню историю. Долгое время некоторые племена Папуа-Новой Гвинеи жили обособленно. Когда во время второй мировой войны на острове появились американские военные базы, они заметили нечто интересное. Большие железные птицы приземлялись в специальных местах и привозили карго – ценные грузы. Секрет успеха приезжих был разгадан! Теперь его необходимо только повторить. Под руководством вождей и колдунов, островитяне расчищали в джунглях землю для посадки железных птиц, строили вышки, надевали наушники из половинок кокоса и ждали.

Птицы, к сожалению, так и не прилетели. Это явление получило название «карго-культ».

Люди в белых воротничках частенько повторяют ошибку жителей Папуа-Новой Гвинеи. Пытаясь достичь перемен, они совершают действия, смысл которых им не ясен. Если не понимать, зачем нужны те или иные шаги, отчеты превратятся в бессмысленные таблицы, фокусированные коммуникации – в отписки, а встречи будут только высасывать жизнь из участников, а не приносить результаты.

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

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

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

Действуйте постепенно

P3.express – минималистичный метод, и за счет этого он более универсален. Если вы не запускаете ракету на Марс, скорее всего он подойдет вам без сильной адаптации. Так говорит не только теория, но и практика многих компаний, уже внедривших P3.express в работу.

«Но это практика других компаний! У меня это не сработает. Мы – уникальны» – по крайней мере так я частенько слышу. Это нормальная реакция – все мы уникальны. Как предположительно сказала антрополог Маргарет Мид[57]: «…так же, как и все остальные».

СТРЕМЛЕНИЕ ВИДЕТЬ СВОЮ УНИКАЛЬНОСТЬ, UNIQUENESS BIAS – ЭТО КОГНИТИВНОЕ ИСКАЖЕНИЕ.

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

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

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

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

Например, команда из онлайн-гипермаркета ВсеИнструменты.ру добавила в этап Запуска проекта шаг – «Подготовлено пространство в Confluence», а количество этапов проекта сократила до пяти вместо семи[58].

Заведите

* * *

Когда решите масштабировать методологию, то вспомните мой последний совет: не будьте сапожниками без сапог! Внедряйте P3.express с помощью P3.express.

Дополнительные материалы к книге

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

Отсканируйте QR-код, пройдите регистрацию и наслаждайтесь.

https://p3express.ru/book-materials

Заключение

Однажды Надер, мой друг и ключевой разработчик P3.express, сказал: «Дмитрий, управление проектами – это не про конференции, сертификации и карьерный рост.

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

И знаете что? Это не преувеличение. Наши ученики работают в фармацевтике и здравоохранении. А еще они создают банковские приложения, автономные автомобили и строят заводы. Результатами их проектов пользуются миллионы людей.

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

Напишите мне на[email protected]– я буду рад узнать вас, вашу историю знакомства с книгой и применения P3.express.

Успехов и до встречи!

Глоссарий

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

Бэклог(backlog) – список задач проекта.

Диаграмма Ганта– способ визуализации расписания проекта на основе зависимостей.

Извлеченный урок– полезный вывод, который пригодится в будущих проектах.

Карта результатов(Deliverables Map): представляет собой декомпозицию продукта на составные элементы (результаты).

Кик-офф(kick-off) – стартовая встреча участников проекта.

Майндмэп(mind map, интеллект-карта, ментальная карта) – способ визуализации идей, мыслей, концепции или бизнес-процесса.

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

Менеджер проектов– тот, кто управляет проектом, в частности: общается с заказчиком, передает требования команде, управляет ресурсами (сотрудники, сроки, финансы и так далее).

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

Методология– набор методов и инструментов для управления проектами.

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

Приоритизация– расставление приоритетов по задачам.

Ревью– процесс, когда один проджект оценивает проект другого.

Ревьюер– коллега, который проводит ревью вашего проекта.

Реестр последующих действий(Follow-Up Register) – доска с карточками или таблица всех рисков, проблем, запросов на изменения, планов по улучшению и извлеченных уроков.

Реестр «Здоровье проекта»(Health Register) – документ, в который заносятся результаты ревью и оценок удовлетворенности заинтересованных сторон.

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

Ретро(ретроспектива) – встреча, на которой команда обсуждает прошедший рабочий цикл, делает выводы и делится инсайтами.

Решение «Go/No-Go»– решение продолжать или остановить проект.

Содержание– объем работ, который надо выполнить для достижения целей проекта.

Спонсор проекта– лицо, предоставляющее ресурсы и поддержку для проекта, программы или портфеля и ответственное за успех.

Стейкхолдер(stakeholder) – заинтересованная сторона в проекте (это может быть руководство, инвесторы, менеджеры и прочие).

Тимлид(team lead) – руководитель команды.

Фокусированная коммуникация– сообщение для команды и других стейкхолдеров, направленное на определенном этапе проекта.

Цикл– промежуток времени, на который разделяется работа в проекте, между Запуском проекта и Закрытием проекта.

Agile Manifesto– Agile-манифест разработки программного обеспечения, опубликованный на сайте agilemanifesto.org.

Creative Commons Attribution– лицензия, которая позволяет копировать, распространять и изменять материал в любых целях, в том числе коммерческих, при условии соответствующего указания авторства.

DACI(Driver, Approver, Contributors, Informed) – матрица, которая устанавливает ответственность за принятие решения в команде.

Kaiten– российский сервис для совместной работы команд.

micro.P3.express– разновидность методологии управления проектами P3.express, адаптированная для микропроектов с командой от 1 до 7 человек.

MoSCoW– метод приоритизации задач.

NUPP(Nearly Universal Principles of Projects) – почти универсальные принципы управления проектами, на которых базируется методология P3.express.

OMIMO(Open Minimalist Modules) – открытые минималистичные модули. Семейство модулей для построения проектной экосистемы. P3.express является одним из модулей.

P3.express– минималистичная методология управления проектами, состоящая из 33 шагов.

P3.express Practitioner– сертификация по методологии P3.express.

RACI(Responsible, Accountable, Consulted, Informed) – матрица для распределения ответственности в команде.

Weeek– российское программное обеспечение для управления проектами.

Благодарности

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

Мария Огаркова – спасибо, что с самого начала поверила в нас и книгу.

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

Анастасия Трубникова – спасибо за все наши переписки по ночам на праздниках!

Елена Кутузова – спасибо за литературную редактуру.

Надер Рад, Фрэнк Терли – спасибо за наши долгие разговоры о жизни и управлении проектами. Александр Паттин – твоя поддержка бесценна!

Спасибо всем, кто участвует в развитии P3.express и проектной экосистемы OMIMO: тренерам, волонтерам и практикам по всему миру.

Спасибо нашим психотерапевтам – без вас бы этой книги не случилось. Марьянна Константинова, я тебе обязан очень многим.

Варвара Топоркова – спасибо, что наша творческая ячейка еще функционирует.

Евгений Ипполитов – спасибо, что не вышел из чата после пятнадцатого разговора о книге.

Психиатру Сергею Колчеву – спасибо, что присмотрел за нами.

Родителям – спасибо, что верили в нас и поддерживали все эти годы.

Мама, я часто вспоминал, как ты писала свою книгу!

Моему брату Владимиру – ты отличный пример.

Сестре Ксении – за то, что на тебя можно рассчитывать в любой ситуации.

Хочу сказать спасибо всем подписчикам и ученикам pmclub, а также сообществу выпускников: ребята, наши ламповые созвоны просто супер!

Спасибо всем, кто делился с нами своим опытом, это ваши истории

Спасибо всем, кто помог выбрать название и обложку для книги!

Марина Перескокова, Алексей Пименов, Александра Клименко, Николай Жаринов, Алекс Шляхова – спасибо вам за рекомендации по написанию и изданию книги.

Всем нашим друзьям – мы по вам скучали!

Отдельное спасибо команде pmclub, особенно:

Насте Фоменко – за потрясающие иллюстрации и оформление.

Елене Власовой – за то, что лучше всех заботишься об учениках.

Об авторах

Мы, Дима и Лера Ильенковы, основатели pmclub.pro – онлайн-школы для менеджеров проектов и продуктов и телеграм-канала @pmclub. У нас проходят обучение более 30 000 учеников и более 300 компаний сотрудничают с нами: Авито, ОЗОН, Спортмастер, Т-Банк, ВсеИнструменты.ру и другие классные ребята.

Дмитрий Ильенков:

• более 15 лет опыта управления проектами в электроэнергетике, e-commerce и образовании;

• к.э.н., приглашенный преподаватель НИУ ВШЭ (2018–2021);

• экс-президент Московского отделения Института управления проектами (PMI);

• сертифицированный менеджер проектов (PMP, PRINCE2, P3.express Practitioner);

• аккредитованный тренер P3.express и micro.P3.express;

• рецензент популярных проектных руководств (PMBOK7 и PMBOK8, Standard for EVM, Standard for Scheduling).

Валерия Ильенкова:

• сертифированный менеджер проектов (P3.express Practitioner, CAPM, ПМ Стандарт);

• аккредитованный тренер P3.express и micro.P3.express;

• приглашенный преподаватель курса «Управление коммуникационными проектами» в бакалавриате НИУ ВШЭ на направлении «Реклама и связи с общественностью», 2018/2019 и 2019/2020, курс признан лучшим по критерию «Новизна полученных знаний»;

• автор учебника «Управление проектами» для 9–11 классов от детской бизнес-школы KinderMBA.

Примечания

PMI, Pulse of the Profession 2018 (2018).

Сейчас принципы переведены на 20+ языков, и все это сделали волонтеры. Вы тоже можете перевести NUPP на свой родной язык, если его еще нет в списке: https://nupp.guide/translation/

Englehardt E., Werhane P. H, Newton L. H Leadership, Engineering and Ethical Clashes at Boeing. Sci Eng Ethics. 2021 Feb 15;27(1):12. doi: 10.1007/s11948-021-00285-x. PMID: 33587209.

Моргошия Т. Ш. Профессор Земмельвейс – «спаситель матерей» (к 200-летию со дня рождения И. Земмельвейса) (1818–1865). Акушерство и гинекология. 2018; 10: 152-4, https://dx.doi.org/10.18565/aig.2018.10.152-154

Что я думаю о перфекционизме, можно прочитать в этой статье: https://habr.com/ru/articles/460275/

Нет, я не преувеличиваю. Пожалуйста, не садитесь за руль, если не выспались!

Tefft, B. C. (2024). Drowsy Driving in Fatal Crashes, United States, 2017–2021 (Research Brief). Washington, D.C.: AAA Foundation for Traffic Safety.

Эта фраза настолько знакома каждому, что звучит, как пословица. Я нашел первоисточник – опубликованные в 1785 году «Опыты об интеллектуальных способностях человека» (Essays on the Intellectual Powers of Man) Томаса Рида, основателя Шотландской школы здравого смысла.

Если быть точнее, то ракета упала в океан, а ее груз – на крышу пустующего склада. Brian Berger, Falcon 1 Failure Traced to a Busted Nut, https://www.space.com/2643-falcon-1-failure-traced-busted-nut.html

CRM – это система для автоматизации бизнеса, которая собирает всю историю общения с клиентами в единую базу, помогает менеджерам вести сделки без ошибок и предоставляет руководителю наглядную аналитику по продажам.

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

B2B – бизнес-модель, по которой компания продает товар или услугу другим компаниям, от английского «business to business».

B2C – бизнес-модель, по которой компания продает товар или услугу физическому лицу, от английского «business to client».

WordPress – популярный конструктор сайтов.

Воспроизводимые элементы – это готовые решения, которые можно легко переиспользовать в новых проектах и задачах.

Лайвкодинг (или «live coding») – практика программирования в реальном времени, то есть на глазах других людей, в данном случае слушателей доклада на конференции.

TED – это серия конференций, где эксперты делятся короткими и вдохновляющими лекциями на самые разные темы.

Архитектура-скульптура (Йорн Утцон) / Е. К. Иванова, 3. К. Покровская // Архитектура Запада: Книга 1. Мастера и течения. – Москва: Стройиздат, 1972. – С. 103–114.

Дословно, взгляд с вертолета. Умение увидеть ситуацию целиком.

PMI, Pulse of the Profession 2018 (2018).

Фам А. Д.«Клей. Стань незаменимым в любом проекте». – СПб.: Питер, 2024. – 288 с.

Проджект менеджмент 101: https://pmclub.pro/courses/pm-101

Майндмэп –англ. «mind map», по-русски еще можно сказать интеллект-карта.

Личная встреча руководителя с сотрудником.

Если интересно, здесь можно прочитать подробнее про разные типы peer-review в науке: https://www.benthamscience.com/blog/2023/08/five-types-of-peer-review/

Начинать или не начинать проект.

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

Degreed, How the Workforce Learns 2023 report, https://www.hrmorning.com/wp-content/uploads/2023/08/Degreed_How-the-Workforce-Learns-2023_Digital-1.pdf

Definition of Concorde fallacy from the Cambridge Business English Dictionary © Cambridge University Press, https://dictionary.cambridge.org/us/dictionary/english/concorde-fallacy

Concorde, https://en.wikipedia.org/wiki/Concorde

Atlassian, Workplace Woes: Meetings Edition, https://www.atlassian.com/blog/workplace-woes-meetings

Laker, B., Pereira, V., Budhwar, P. and Malik, A. (2022) The surprising impact of meeting-free days. MIT Sloan Management Review. ISSN 1532–9194, https://sloanreview.mit.edu/article/the-surprising-impact-of-meeting-free-days/

Romney, A. C., Allen, J. A., & Heydarifard, Z. (2025). Meeting load paradox: Balancing the benefits and burdens of work meetings.

Отсылка к книге Владимира Войновича «Жизнь и необычайные приключения солдата Ивана Чонкина. Лицо неприкосновенное».

Пост с опросом: https://t.me/pmclub/711

Kaiten – российская платформа для управления проектами и задачами.

Denver Airport Baggage Handling System, https://sebokwiki.org/wiki/Denver_Airport_Baggage_Handling_System

Konnikova, M. (2014, May 7). Multitask masters. The New Yorker, https://www.newyorker.com/science/maria-konnikova/multitask-masters

Slater, M. (2012, August 8). Olympics cycling: Marginal gains underpin Team GB dominance. BBC Sport, https://www.bbc.com/sport/olympics/19174302

Эффект якоря (Anchoring effect) – когнитивное искажение. Мы склонны уделять много внимания первой информации, которую получили, и слишком опираться на нее (якориться) при принятии решений.

Управление проектами с методологией P3.express, https://pmclub.pro/courses/p3express-onlajn

Post-mortem – от латинского «после смерти», анализ произошедшего события с целью извлечения уроков. Латинское название тонко намекает, что проект уже завершен и менять что-то уже слишком поздно.

Метод Дельфи – это структурированный опрос экспертов в несколько раундов, где мнения постепенно сближаются. Иронично, что этот рациональный метод отсылает к оракулу, дававшему туманные и мистические предсказания.

The Essential Role of Communications. PMI (2013).

Строчка из песни группы «Наутилус Помпилиус» «Скованные одной цепью».

Jack Diao, Burnt by Phoenix: Canada’s Costly Lesson in Public Financial Management, https://jpia.princeton.edu/news/burnt-by-phoenix-canadas-costly-lesson-public-financial-management

Факапы на галерах, выпуск #4 «Исповедь программиста». https://vkvideo.ru/video-85927362_456239310

Гайд СберМаркета: как построить проектный офис с нуля, https://vc.ru/office/817087-gaid-sbermarketa-kak-postroit-proektnyi-ofis-s-nulya

Hern, A. (2019, March 29). Apple abandons AirPower wireless charging product. BBC News, https://www.bbc.com/news/technology-47756055

ENR Global Best Projects 2017, https://www.enr.com/articles/43030-best-cultural–antalya-expo-2016-tower

1976 Summer Olympics, https://en.wikipedia.org/wiki/1976_Summer_Olympics

Strengthening Benefits Awareness in the C-Suite. The Economist Intelligence Unit (2016).

New Coke: The Most Memorable Marketing Blunder Ever? https://www.coca-colacompany.com/about-us/history/new-coke-the-most-memorable-marketing-blunder-ever

Федор Овчинников, Первая кофейня «Дринкит» в Самаре вышла в плюс, https://sila-uma.ru/stories/drinkit#2021-06-14-pervaya-kofeynya-drinkit-v-samare-vyshla-v-plyus

Выражение «Не дай Бог вам жить в эпоху перемен» часто приписывают Конфуцию, но это не точно.

Как 20 проджектов «Спортмастера» прошли обучение в pmclub, https://pmclub.pro/articles/20-prodzhektov-sportmastera-obuchilis-i-vnedrili-p3express/

Книга доступна бесплатно на английском языке: https://pmbok.guide/

Это отсылка к цитате, традиционно приписываемой американскому антропологу Маргарет Мид: «Always remember that you are absolutely unique. Just like everyone else», – Всегда помни, что ты уникален. Также, как и все остальные.

Управление стало прозрачным и системным: как «ВсеИнструменты.ру» внедрила P3.express, https://pmclub.pro/articles/vnedrenie-p3express-kejs-vseinstrumentyru/

Гайд СберМаркета: как построить проектный офис с нуля, https://pmclub.pro/articles/gajd-sbermarketa-kak-postroit-proektnyj-ofis-s-nulya/

Уйти из Notion и экосистемы Google без вреда для проектов: опыт Express 42, https://pmclub.pro/articles/kak-vizualizirovat-p3express-dlya-komandy-opyt-kompanii-express-42/

Спасибо за чтение

Вернуться к книге