Май 15

Как PM не нафакапить на новом проекте

Статья написана в соавторстве с Мэри Ротарь, Co-Founder IAMPM.

Привет, я Павел Устинов, сейчас работаю PMO в Solar Digital. Из 15 лет работы в IT-сфере последние 7 руковожу проектами. За это время уже научился видеть обстоятельства, которые с большой вероятностью завалят как минимум дедлайн, а то и поставят под вопрос целесообразность дальнейшего сотрудничества с заказчиком.

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

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

Какой проект считать успешным

В проджект-менеджменте успех управления проектом подразумевает, что все ограничения — Cost, Scope, Time, Quality — выполнены в оговоренных объемах и сроках. Работа считается завершенной, если сделана:

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

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

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

Успех управления проектом vs успех продукта

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

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

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

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

Почему проекты проваливаются

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

Вот минутка суровых реалий проектного менеджера: только 34% IT-проектов выполняется в срок, с запланированным бюджетом и объемом работ. Продукт запустили — и заказчик доволен результатом.

Остальные 66% проектов частично неуспешны или провальны: 51% проходят с отклонениями от первоначальных условий, а оставшиеся 15% вообще бросают.

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

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

Плохое знамение на проекте

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

Самые распространенные симптомы беды на проекте:

1. Непонятные либо нестабильные требования. Если разработчики не поняли задачу — в итоге получится не то, что ожидает заказчик. А когда требования постоянно меняются, снижается мотивация сотрудников: зачем стараться, ведь завтра дадут новые «вводные».

Как-то на одном из Fixed Price проектов заказчик вдруг решил бесконтрольно подвезти много изменений и дополнений. Заодно добавил в проект дизайнера и разработчика. Дизайнер оказался очень старательный и сделал много новых прекрасных макетов. Так объем работы вырос и пришлось долго переделывать то, что теперь стало неактуально.

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

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

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

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

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

3. Жесткие сроки, в которые невозможно уложиться. Часто Junior PM’ы стараются проявить себя перед заказчиком, соглашаясь на заведомо нереальные даты выполнения работ, потому что считают, что скорость выполнения равно профессионализм.

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

Здесь мой опыт рисует две картины.

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

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

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

Факторы, снижающие эффективность команды

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

Когда РМ неправильно выстраивает внутрикомандные процессы — быть беде. Вот самые распространенные ошибки в управлении:

В компании нет культуры обработки конфликтов, в том числе и с заказчиками. Здесь велика вероятность, что сотрудничество экстренно прекратится. Если конфликты обрабатываются неправильно, команда не доверяет РМ-у: люди боятся наказаний, поэтому вовремя не сообщают об ошибках. В таком случае у менеджера не остается времени на спасение ситуации.
Личная ответственность или безответственность в команде. Когда сотрудники переживают о работе, им важно, чтобы пользователям нравился конечный продукт. Если же личной ответственности нет, а деньги платят даже за некачественный результат, то проект рискует не дожить до завершения.
Отсутствие оценок. Отрицательные и положительные оценки, порицание и похвала помогают людям понять, что они делают хорошо, а что — не очень. Важное правило: хвалить лучше при свидетелях, а ругать — один на один.
Отсутствие иерархии и нарушение субординации приводит к беспорядку в коммуникациях. Если директор компании ставит задания разработчикам, минуя PМ’а, или заказчик требует, чтобы менеджер принимал решения, на которые тот не уполномочен, — это нарушение субординации. Тогда всем трудно фокусироваться на достижении результата.

Распространенная ошибка в построении внутрикомандных процессов — это классический кейс «Бегаем по личкам». В команде есть спринты/планы по нагрузке, но заказчик или босс пишет разработчикам в личку «мелкие улучшения», или easy tweaks. И потом удивляется, почему за три дня работы по спринту/плану ничего не сделано.

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

5 стереотипов о работе PM’a, которыми руководствуются джуны

Начиная проект, менеджер осознает собственную роль в процессе: что нужно делать, а что — нет, какие ожидания заказчиков и команды от менеджера и чего он сам ждет от сотрудников. Однако иногда убеждения РМ’а не совпадают с действительностью и мешают наладить нормальный рабочий процесс. Топ-5 заблуждений в начале карьеры PM’а:

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

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

документацию неплохо пишут QA и DevOps, а регистрировать change requests могут дизайнеры и все те же QA;
провести демо может Junior React Developer, QA или BA, на худой конец, Lead Developer.

2. Сотрудники умеют «читать мысли», а все объяснения понятны с первого раза. Часть информации при передаче теряется, но РМ этого не замечает: главное написать в чате или поставить задачу в Jira. Когда так происходит постоянно, нужно налаживать «обратную связь», проверять, как исполнители поняли задачу.

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

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

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

Удобнее всего «насыпать информации на радиатор»:

на планировании задач, когда вся команда подробно оценивает и докапывается до сути;
на kick-out сессиях в начале спринта или итерации;
в процессе рутинных UI Review, когда дизайнеры смотрят, что получается с UI у разработчиков.

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

4. PM — самый умный в команде. Менеджер, который «зазвездился» и не принимает чужой помощи или советов, сужает видение проекта исключительно до собственной точки зрения.

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

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

Желательно, чтобы кодом владело более одного человека. Для меня хорошим решением стало распределение знаний между командой и ведение документации. К примеру, на проекте SPA-приложения, где классически задействован один бэкенд и один фронтенд, каждый из них будет владеть 100% кода своей части приложения. Для подстраховки у меня еще будет крутиться Full Stack в полную или частичную занятость, плюс разработана минимальная документация. В этом случае даже если кто-то из специалистов уйдет, его будет не очень сложно заменить.

Как принимать новый проект

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

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

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

Когда стало ясно, от кого пришел заказ, то второе, что надо понять, — статус проекта, на каком этапе все находится сейчас:

Pre-sale фаза — статус предпродажного цикла. Сейлз-менеджер продает непосредственно услуги компании, делает продажи, а проджект-менеджер обеспечивает производство. Вместе с менеджером по продажам РМ формирует scope, сметы и так далее. Нужно выписать все необходимые активности, посчитать — и запускать проект в работу.
После заключения договора. На этом этапе уже все выписано и посчитано, осталось принять новый проект и сделать его как можно лучше.
На этапе формирования требований. Бывает так, что клиенты начали писать требования по продукту, поняли, что сложно, нужен бизнес-аналитик и менеджер, потому что проект явно не такой, как казалось сначала — и в таком виде отдали все в работу. Здесь нужно засесть за сбор и формирование требований. Помните, проработать весь материал надо на одинаковом уровне детализации. Ваша задача — найти ответы на все «нипанятна» и решить все «приколы» проекта на самом старте.
«Как повезет», Или этап «черного ящика». Разработчики уже два месяца пилят код, жизнь бьет ключом, все чем-то заняты, QA отсутствует — а надо уже определяться с работами. И руководство говорит РМ’у: «Иди посмотри, там новый проект, разберись».

Здесь надо начинать с базовых вопросов: что происходит и кто все эти люди? Что это за проект? Где план или хотя бы ТЗ? Как мы работаем и отслеживаем прогресс? Какие полномочия есть у менеджера? (увольнять сотрудников, нанимать новых, влиять на уровень зарплаты). Вторым шагом будет полная и детальная ревизия проекта. Ну а дальше составьте бэклог и поедайте его небольшими порциями в любых количествах.

Когда стало понятно, от кого пришел проект и на каком этапе он находится, проведите предварительное планирование, чтобы найти ответы на ряд вопросов:

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

Ответы и требования стоит зафиксировать в виде описаний, диаграмм, схем, технических заданий, user story map.

Как не провалить существующий проект

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

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

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

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

Что делать, если все-таки «нафакапили»

Говорят, что от ошибок никто не застрахован и не ошибается только тот, кто ничего не делает. Однако в работе проджект-менеджера такая стратегия не подойдет: для РМ’а ничего не делать — уже будет ошибкой, но это не точно.

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

Как-то был просто катастрофический случай. Клиенту предоставили смету с двумя опечатками: механически неправильно посчитали часы. Так как поле с сумой по формату переделалось в дату и вместо xxx xxx красовалось оригинальное 5 мая 70 какого-то года, это не было выявлено аж до самого митинга с заказчиком. Эта механическая ошибка привела к неподписанию актов на одной встрече, а дальше запустила серию проблем, из-за которых потом закрыли проект.

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

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

Как действовать РМ’у, если произошла тотальная проблема, ошибка, жесткий конфликт:

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

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

Факторы успеха

Кроме объективных причин для неудач, есть факторы, ведущие проект к успеху:

Вовлеченность заказчика. Чем больше степень вовлеченности заказчика в работу над продуктом, тем прозрачнее обсуждение проблем и легче их решать. Можно приводить сколько угодно метафор, когда люди действуют на благо общих целей, но это не выразит и части радости, когда заказчик вовлечен в работу и видит ее как есть в правильном свете.
Люди из топа моих лучших заказчиков в основном обладают двумя важными свойствами:
1. В технических проектах они хорошо погружены в матчасть.
2. В проектах, связанных с другими проектами заказчика, они предоставляют эффективную и своевременную поддержку.
Поддержка высшего руководства, в том числе и в переговорном процессе. Работа идет легче, потому что есть дополнительные люди, которые следят за ходом событий, ускоряется решение внутренних и внешних проблем.
Помощь опытного руководителя во главе проекта или Junior РМ в связке с ментором. Опыт специалиста помогает предвидеть ошибки до того, как они возникли. Если есть, с кем обсудить проект — обсуди. Как правило, старшие руководители лучше ориентируются в том, как принято поступать в тех или иных ситуациях.

Кроме того, старшие товарищи помогут проработать риски и составы проектов в компании.

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

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

Итог

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

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