Когда харизмы недостаточно: 6 обязательных hard skills для PM-а

Привет, меня зовут Анна Лаврова, сейчас я — Agile Coach Wemanity Belgium, а в 2018 году работала PM-ом в Дубае, управляла программой проектов, по digital-трансформации компании. Достаточно быстро стало понятно что все 9 проектов мы будем отдавать на аутсорс другим организациям. 

У меня был опыт проектного менеджмента в IT, и казалось, будет легко сотрудничать с РМ-ами на стороне вендоров, ведь мы «говорим на одном языке» .

Я ошиблась: общение получилось сложным, причем РМ-ы спотыкались на одних и тех же вещах. Трудности возникли из-за недостатка конкретных hard скилов. 

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

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

Работа с требованиями

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

Однако РМ-ы, с которыми я общалась, не умели читать требования, то есть, рассматривали их только с одной стороны. От итерации к итерации приходилось добавлять разные описания, чтобы сделать требования более понятными: я рисовала customer journey, показывала user персон и прописывала use кейсы. 

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

Умение смотреть на потребности с разных сторон — это один из важных навыков РМ-а.  

Hard skill 1. Техники формирования требований

Потребности заинтересованных сторон нужно выявить на старте, ведь по ним будут прописаны цели и критерии приемки проекта. Для формирования требований РМ-у понадобится знание основных техник: 

• Анкетирование — самый простой метод. Представители заказчика либо конкретная фокус-группа заполняют анкету. 
• Интервью. Может быть структурированным — один и тот же набор вопросов для всех участников, либо неструктурированным — вопросы основаны на том, какие задачи решает собеседник. На эту тему советую прекрасную книгу о пользовательских интервью: Стивен Гари Бланк «Четыре шага к озарению».  
• Автозапись — РМ получает от заказчика готовые требования. В моем случае, я создавала документы с прописанными требованиями для РМ-ов вендора. Как заказчик, я ожидала, что РМ-ы ознакомятся с документами и только потом мы будем общаться. 
• Gemba Walk — концепция разработана компанией Toyota в рамках технологии бережливого производства. Техника построена на том, чтобы увидеть собственными глазами, как проходят процессы у будущих пользователей продукта. Например, поехать на конкретный склад и посмотреть, как там работают люди. Gemba Walk используют, если нужно создать решение для не-айтишных организаций, например, помочь сети супермаркетов выбирать стратегии скидок. 
• Брейншторм — одна из самых популярных техник по работе с требованиями. Встреча проходит в групповом формате, участники вместе создают или выделяют основные части требований.
• Use Case — как правило их пишут бизнес-аналитики, но когда ВА нет, а требования писать нужно, навык создавать use cases очень пригодится РМ-у. 

Оценка 

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

1. Время: Когда будет готово или какой график контрольных точек (milestones)?  
2. Стоимость: Сколько потребуется денег и за что конкретно? 
3. Качество: Какой порядок работы и что должно произойти, чтобы вы мне это отдали? 

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

Hard skill 2. Техники оценки 

• Покер планирования помогает оценить сложность работы или понять объем задач. 
• Уточнение оценки происходит, когда предварительную документацию по требованиям обновляют и используют в течении жизни проекта. Например, сначала у нас есть 30% уверенности, что сделаем за столько времени и денег. Затем уточняем по конусу неопределенности: чем дальше находимся, тем больше процент уверенности. 
• Сверху вниз (Top Down Estimate) — способ, который еще называют экспертной оценкой. Техника помогает увидеть траты на ранних этапах, когда информация о проекте не полная или ограниченная. Оценка происходит обобщенно и стоимость рассчитывается, в основном, по одному из показателей.
• Оценка по аналогам. В основе метода — идея о том, что проекты похожи, поэтому стоимость можно рассчитать по проектам, которые делал РМ или его коллеги раньше.  

Планирование

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

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

• Что мы делаем?
• Когда сдадим каждую часть работы?
• Сколько нужно времени и денег?
• Что можно сократить?
• Где находимся в конкретный момент времени?

Успешное планирование всегда проходит через определенные этапы. 

Hard skill 3. Базовые этапы планирования

1. Содержание работ. РМ-у нужно анализировать работы как по проекту, так и по продукту. Scope of works продукта говорит о том, что вы создаете. Scope of works проекта — о работах, которые происходят вокруг продукта. 
2. Work Breakdown Structure, WBS или Иерархическая структура работ. Менеджеру важно понимать, какие пакеты выполнить, чтобы закрыть функции или выполнить промежуточные цели проекта. 
3. Estimates (Оценки трудозатрат) и их точность. Умение дать эстимейт — значит, оценить затраты человеческого труда и продолжительность всех активностей в WBS.
4. Расписание (Schedule). Построенную WBS (структуру работ) трансформируют в расписание проекта. Полученный результат анализируют: интуитивно на основе прошлого опыта или, используя сетевую диаграмму и критический путь в качестве инструментов. 
5. Сетевая диаграмма — лучший способ визуализировать последовательность и параллельность каких-то действий. Диаграмму можно создавать даже вручную на физической доске. Критический путь — минимальное количество активностей, которое нельзя распараллелить, чтобы пройти всю схему сетевой диаграммы. 
6. Техники сокращения расписания. Есть разные техники и и подходы, например, увеличение участников в команде или декомпозиция блокирующих задач на более мелкие. 
7. Прогнозирование — такие техники как Burn down/up Chart, Velocity, EVM показывают, где мы будем находиться в каждый конкретный момент времени. Эти подходы не оценивают работу, а обозначают, где находимся сейчас и помогают спрогнозировать развитие событий. 

Отслеживание прогресса 

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

Hard skill 4. Метрики производительности

Есть разные виды метрик для оценки прогресса, но 2 базовых фактора, которые нужно отслеживать всегда, — это движение к целям и результатам. 

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

Формулируют цели проекта с помощью техники Impact Mapping, а затем РМ решает, как отслеживать, движется ли команда по направлению к целям или от них удаляется. 

Результат (Deliverable) — то, что вы отдаете вашему клиенту. Результатом может быть отчет, приложение, обновление, документ, ссылка на InVision. Есть разные варианты Deliverable: процессный, организационный, разработческий, инженерный, —  и все эти варианты РМ должен уметь формировать и отслеживать. 

Риски

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

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

Hard skills 5. Управление рисками

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

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

Сдача проекта

Перед стартом, менеджер должен планировать не только начало, но и сдачу проекта. Однако в роли заказчика, мне приходилось буквально «доставать» из РМ-ов: «А что же произойдет потом?» Ни один PM со стороны вендора, не прописывал в самом начале, как видит завершение и что отдаст заказчику. 

Ответить на вопрос: «А что дальше?» помогает Transition Plan — описание, как и кому вы передадите все, что создавали.  

Hard skill 6. Transition plan

Сформулировать требования к переходу и передаче проекта помогают вопросы: 

• Что нужно сделать для завершения проекта?
• Что и кому вы отдадите?
• Как соберете все знания, полученные в проекте?
• Какие рекомендации понадобятся новому РМ-у при передаче проекта? (например, по случаю вашего отпуска).

Когда РМ сформулировал для себя ответы, можно приступать к составлению Transition Plan:

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

Подводим итоги

Чтобы стать профессионалом, понадобится не только трудолюбие и харизма, но и владение конкретными навыками:

1. Техники формирования требований.
2. Методы оценки проекта.
3. Этапы планирования.
4. Отслеживание производительности.
5. Управление рисками.
6. Планирование перехода и передачи проекта.

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