Роль Project Manager (далее, PM).
Для того, чтобы продемонстрировать насколько важна роль PM мы расскажем об одном проекте, который позволил обрести очень важные выводы, касающиеся этой роли.
Пример (WO)
В прошлом году у нас появился новый проект в области Fintech. Легаси:
Система заказчика обрабатывала до 80 млн платежей в сутки. Возникла потребность обрабатывать до 1.5 млн операций в сутки.
Мы встретились с потенциальным заказчиком и задали важный вопрос с нашей стороны: кто будет руководить проектом?
Заказчик предложил, что их Product Owner может легко выполнять функции PM.
Проект стартанул очень бодро: каждый месяц мы проводили ДЕМО перед учредителями Заказчика. В конце каждого демо РО делал прогноз по дальнейшим срокам.
Неожиданно для всех к концу 4-го месяца выяснилось, что Акционеры ожидали готовность проекта через 2-3 недели, а по версии РО еще оставалось работы на 3-4 мес.
Разобравшись в причинах, выяснилось, что узкое место — недостаток детального управления проектом, т.к. РO был перегружен: он одновременно был РО, BA и РМ.
В итоге, мы вывели на проект выделенного РМ.
Следующий месяц было очень жарко во взаимодействии с заказчиком. При этом, все справились с возникшим конфликтом.
РМ составил подробный план на 2.5 мес, и в этот срок команда уложилась.
В итоге, мы до сих пор очень тесно взаимодействуем с данным заказчиком, принимая участие в других его проектах.
На данном примере мы можем убедиться, что роль PM исключительно важна.
PM должен обладать достаточным временным и другими ресурсами, иначе проект будет сталкиваться с серьезными рисками роста издержек и временных затрат
Роль PM относится к “Локомотивным Ролям”, т.е. отвечает за движение проекта в правильном направлении.
С точки зрения частоты контроля:
- Заказчик следить за проектом раз в две-недели/месяц.
- РО — минимум два раза в неделю.
- РМ — каждый день.
PM решает задачу оперативного управления и прогноза состояния проекта.
В этом плане — он как пилот самолета. Нужно долететь до пункта назначения за определенное время и с ограниченным запасом топлива. В частности, это означает, что именно роль РМ — решать “блокирующие”, кризисные ситуации на проекте.
Возможно ли распределять ответственность PM между другими ролями?
На небольших проектах совмещение роли РМ возможно. Но совмещать ее нужно с “локомотивными ролями”.
- Например с РО.
- Совместимость с “Экспертными ролями” возможна в точечных ситуациях, когда у вас есть проверенный “человек-оркестр”.
С какими ролями взаимодействует PM? И Как он обеспечивает реализацию проекта на повседневной основе?
PM, по сути, является связующим звеном между РО и командой.
Все начинается с того, что в диалоге с PO, BA и Архитектором производится верхнеуровневое планирование, оценка сроков, понимание архитектуры и технологического стека разработки.
Таким образом первая функция PM — это:
Планирование и прогнозирование сроков и бюджета проекта.
Следующим шагом PM должен собрать команду под задачи проекта (аналитиков, разработчиков, девОпсов, тестировщиков и тд). И, по мере необходимости, гибко, менять ее состав.
Таким образом, вторая функция PМ:
Комплектация проекта командой с соответствующими компетенциями.
Третья задача PM:
Обеспечить команду разработки необходимым инструментарием
У всех участников команды должен был доступ в тасктрекер, хранилище проектной информации, канал коммуникации (мы предпочитаем Jira, Confluence и Slack, соответственно), а разработчикам нужен доступ репозиторий (Gitlab, bitbucket или github)
На этом завершается подготовительный этап работ.
Как только мы запустили процессы работ, PM’у важно сразу выстроить коммуникации таким образом, чтобы процесс разработки не был темной лошадкой для заказчика.
Критически важна прозрачность процессов.
Для этого PM вместе с Тим — Лидом в тасктрекере формирует структуру задач, следит, чтобы разработчики в должной мере производили разбивку на подзадачи (то есть делали декомпозицию), поддерживали актуальность статуса задач и фиксировали потраченное время.
Регулярность коммуникаций. (обязательным атрибутом являются регулярные коммуникации).
Важен Ежедневный командный созвон (так называемый daily scrum meeting) и регулярные встречи для командного планирования. Важно, чтобы в планировании участвовал PO, так как это позволяет синхронизировать ожидания и при необходимости скорректировать направление разработки.
Соблюдение процессов всеми участниками позволяет PM’у управлять задачами с точки зрения последовательности и взаимозависимости.
Вышесказанное можно обобщить в функциях Управление задачами проекта (4) и Управление командой проекта (5)
Финальная функция РМ-а:
Демонстрация результатов и актуальных планов РО и Заказчику.
Мы понимаем, бизнес-заказчики “любят глазами”, поэтому PM организует регулярное ДЕМО – раз в несколько недель, на котором заказчик может “пощупать, покликать” результат и дать обратную связь.
Какие компетенции нужны человеку для того, чтобы стать хорошим PM?
Во главе угла стоят личностные компетенции:
- Позитивное отношение к людям.
- Коммуникативные компетенции,
- Эмоциональный интеллект.
Также, PM должен обладать достаточной чуткостью и наблюдательностью, чтобы поддерживать благоприятный эмоциональный фон в команде.
- Целеустремленность.
- Умение находить нестандартные решения
Подводя итог хотелось бы привести еще одну метафору:
PM — как дирижер в оркестре, где ноты — это план проекта, а оркестр это проектная команда.
PM — это роль, которая ценна не только тем, что она реализует в проекте, но теми ресурсами, которыми она обладает за его пределами
PS.
Хотелось бы добавить, что личностные компетенции PM повышают эффективность именно в сочетании с сильным тылом разработчиков разнообразного стека и профессионального опыта. В нашем случае таковой есть.
И если в проекте потребуется точечная экспертная консультация вне основного стека команды, PM может ее обеспечить без дополнительных финансовых затрат со стороны заказчика.