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

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

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

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

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

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

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

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

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

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

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

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

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

Так было, пока мы не пошли гулять с нашим другом – опытным походником. За его спиной и плато Путорана, и остров Шикотан, и одиночные походы, и сплавы по таежным рекам. Женя сказал просто: «Вы ребята, молодцы, но каждые 45 минут нужно останавливаться и 15 минут отдыхать. Так вы сможете идти практически бесконечно».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Больше того, Резюме не заканчивает свое существование после завершения проекта. Сохраните его в базе знаний – чтобы переиспользовать в дальнейшем. Обратите внимание – это 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но какой из подходов предпочтительнее, когда речь идет о планировании в проекте? Как показывает наш опыт, нужен третий вариант, более гибкий. В мире, где каждый день все переворачивается с ног на голову, упорные попытки следовать плану могут привести в тупик, а не к цели. В то же время недостаток планирования быстро приведет к хаосу. Оптимальная стратегия – всегда иметь план и быть готовым к изменениям. Это учитывается в 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 у вас должны быть: детальные планы на ближайший месяц, верхнеуровневые планы для всей оставшейся части проекта и обновленные документы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ребятам начали предлагать помощь: кто-то хотел помочь руками, кто-то начал помогать методологически и предлагать конкретные решения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 25. Диаграмма с результатом опроса

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Своей команде я говорю:

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

Почему важно ориентироваться на долгосрочные отношения?

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

В 2011 году стартап Tiny Speck выпустил игру Glitch, но она не нашла свою аудиторию, провалилась и была закрыта в 2012-м. Как только у команды появилась идея для пивота, инвесторы Tiny Speck, которые только-только потеряли немалые деньги, были готовы вложиться в новый проект. Сегодня компания создателей Glitch известна всему миру как разработчик корпоративного мессенджера Slack.

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

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

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

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

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

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

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

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

Вот примеры тем, которые стоит обсудить с ним в ходе этого ревью:

• Вы утвердили и передали продукт? Перенесли все на ресурсы заказчика, получили документальное подтверждение приемки результатов?

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

• Понятно ли, как использовать продукт? Заказчик и пользователь – часто разные люди. Убедитесь, что последние понимают, как работает продукт.

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

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

• Готовы ли документы проекта к архивации? Идеально, если вам удавалось всегда поддерживать документы в актуальном состоянии, но лучше проверить, так ли это.

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

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

Во-вторых, ищите на рынке. Обратите внимание на профессиональные сообщества и на сайты с менторами, например Эйч, Solvery и Getmentor. Зачастую опытные проджекты консультируют других бесплатно. Я и сам как-то провел более пятидесяти менторских сессий просто из интереса.

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

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

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

Мой знакомый Борис работал проджектом – отвечал за организацию конференции на 4000 человек.

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

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

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

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

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

С компаниями понятно, а в чем ваша заинтересованность в сохранении архивов? На эту тему классно высказался ученик pmclub Александр Огарев: «Если остались заметки, актуальные версии документов, чек-листы, то следующий проект (похожий по масштабу и задачам) идет быстрее: есть с чем свериться, что-то переиспользовать, проще избежать прежних ошибок. Это особенно важно, когда команда частично меняется или часть экспертности теряется из-за паузы между проектами».

Для этого аккуратно архивируйте каждый проект: дополните и соберите все материалы в одном месте.

Вот что стоит учесть:

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

2. Проверьте, чтобы названия файлов имели смысл. Названия типа «Папка 1», «Версия 2» – не предел мечтаний: завтра вы не вспомните, что там внутри.

3. Сохраняйте материалы в формате, который будет доступен для чтения, даже если компания поменяет софт.

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

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

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

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

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

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

Я предлагаю вам стать тем, кто поможет каждому оценить проделанную работу, присвоить себе новое достижение и почувствовать гордость за команду. Как пишет Скотт Беркун в книге «Сделано»:

Классно, если вы можете заложить бюджет на это празднование или договориться о его выделении, например, с HR-отделом.

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

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

А если проект завершен досрочно? И вообще повод для закрытия так себе: резко поменялась стратегия, клиент недоволен, гипотеза не сработала, новые ограничения ввели. Всем грустно, команда демотивирована, отмечать нечего. Что тогда? Пропускать шаг? Нет!

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

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

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

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

Рисунок 29. Пример коммуникации на завершении проекта

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

Как мы с вами обсуждали на шагах A08 и B03 «Go/No-Go», отказ от проектов – это признак зрелой культуры, а не катастрофа.

В 2019 году Apple отказалась от выпуска устройства для зарядки AirPower, хотя его выход анонсировали еще в 2017 году. «После долгих усилий мы пришли к выводу, что AirPower не сможет соответствовать нашим высоким стандартам, и приняли решение прекратить проект», – сообщил старший вице-президент по разработке аппаратного обеспечения Дэн Риччио[48]. Это был первый случай, когда компания отказалась от выпуска уже анонсированного устройства.

Думаю, всем было тяжело прощаться с проектом, но это жизнь.

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

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

По статистике, только 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]. Видите, они еще и отпраздновали свой провал!

Начните с оценки выгод, которые вы прописали в Резюме проекта, а затем взгляните на ситуацию шире и подумайте, принес ли проект еще какие-либо выгоды. Зачем? Чтобы извлечь больше пользы! Этим и займемся на следующем шаге.

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

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

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

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

Накидаю варианты:

1. Применить P3.express на ближайшем проекте.

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

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

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

5. Опубликовать статью про P3.express, например, на Habr, vc.ru или в блоге pmclub. Тоже экспертный пиар, и вы всегда сможете поделиться ссылкой, если вас попросят рассказать о вашем опыте.

6. Пройти сертификацию P3.express Practitioner. Международный сертификат еще никому не помешал, а после чтения книги подготовиться проще.

И это точно еще не полный перечень возможностей! А теперь сравните варианты: закрыть книгу и забыть – или реализовать одну, а может и несколько идей из списка. Чувствуете разницу?

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

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

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

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

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

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

G03 не отнимет много времени, особенно если брать пример с основателя «Додо Пицца» Федора Овчинникова. В своей фокусированной коммуникации после завершения проекта он написал всего одно предложение: «Первая партнерская кофейня Дринкит в Самаре вышла в прибыль в первый месяц работы!»[53] Коротко и понятно.

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

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

Рисунок 30. Пример отправки отзыва в чат с командой

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