Нужно ли руководителю проекта детально разбираться в процессе разработки?

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

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

И действительно, часто ПМы не погружаются ни во что другое, и фокусируются на тройственном ограничении. За детали отвечает кто-то другой: команда, архитектор, «владелец продукта», и т.д.

Но возникает вопрос - действительно ли в таком случае ПМ влияет на результат проекта? Кто-то может подумать, что руководитель проекта - сервисная должность, которая помогает команде, а команда сама отвечает за результат.

Но мы подвесим сразу несколько вопросов:

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

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

Тимлид	ПМ
Проработка концепции
Формирование технического решения, проектирование архитектуры, определение технологического стека, необходимой инфраструктуры	Участие в аналитической работе (описание PBI, определение критического пути, критериев приемки, реагирование на изменения)
Предварительная оценка	Согласование бюджета проекта и этапов внедрения
Наполнение технического бэклога	Формирование дорожной карты
Проектирование решения
Ревью оценок, декомпозиции, планирование реализации	Донесение продуктового видения до команды, формирование стратегии развития продукта (скомпилировать ТЕ+PO+Команда, подготовить схемы, донести до команды)
Анализ технических рисков	Формирование графика релизов и ожиданий заказчика
Донесение технического видения до команды
Обеспечение интеграции с другими системами
Разработка
Добавлять в спринты задачи из тех. долга	Формирование спринтов и контроль метрик TFS
Обеспечение оптимального способа решения задач и распределения сил команды	Актуализация бэклога (технически: статусы PBI, area, parents)
Определение и контроль критериев завершенности задач (task)	Контроль сроков
Технический и архитектурный надзор (код-ревью, код-стайл)	Контроль и согласование трудозатрат
Поддержка и развитие CI-CD: обеспечение стабильного обновления окружений, автоматизация процессов	Проведение ежедневных митингов
Соблюдение командой разработки оценок	Контроль этапов работ: готовы требования, готовы оценки, готово к приемке
Обеспечение качества
Помощь с настройкой автотестирования	Анализ причин появление багов, системные решения по устранению их причин
Настройка инструментов обеспечения качества и ИБ (юнит тесты, автотесты, сонар, гитликс, триви)	Обеспечение тестирования требований
Внедрение
Анализ логов и статистики по продуктам	Создание плана внедрения, обучение пользователей, решение проблем внедрения
Подготовка и координация сложных релизов	Release Notes
	Коммуникации с саппорт
Фиксация ценности
Ведение тех. документации	Отчет по проекту
Настройка логирования и мониторинга	Сбор обратной связи по фичам от пользователей и PO
	Закрытие контракта
Работа с людьми
Развитие командности (культура команды, формирование ценностей команды. поддержание вовлеченности и удовлетворенности участников)	Привлечение ресурсов в команду
Развитие навыков участников команды (кодревью, 1-1)	Организация процесса On-boarding
Участие в собеседованиях и ежегодной оценке сотрудников	Внешние проявления команды (новости, общение с руководством), обратная связь от руководства
Продуктовая, процессная и техническая стратегия
Техническое развитие продукта (контроль техдолга, наполнение тех. бэколга, культура и подход к разработке, архитектурный надзор)	Развитие процессов (требования, разработка, поставка), ведущие к уменьшению time-to-market, рисков, повышению качества.
	Проведение ретроспектив (график, быть ведущим, составление задач команды)

Дальше у многих ПМов возникает желание развиваться в область управления продуктом: влиять не только на процесс реализации, но и на достигаемые продуктом цели. ТО ЕСТЬ думать об будущем больше, чем о настоящем. Это естественное и позитивное стремление.

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

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

Мысль одним предложением: «Формирование устойчивого производственного процесса позволяет руководителю заниматься задачами развития продукта.»

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

Процессная стратегия состоит из нескольких направлений:

планирование, аналитика и декомпозиция
обеспечение качества
Конвейер производства, доставки, CI/CD
операционная эффективность команды

Это и есть те зоны, которые ПМ должен детально понимать, изучать, знать лучшие практики, уметь диагностировать. Как результат: команда работает продуктивно и равномерно загружена. Давайте нырнем еще глубже, как мы любим 😊

Что нужно уметь или знать	Как позволяет влиять на результат
Понимание архитектуры продукта (приложения, сервисов)	Можно валидировать оценки команды, детально объяснять заказчику декомпозицию, видеть больше рисков. Говорить на одном языке с разработчиками, понимать их трудности и достижения. Обмениваться опытом на тему применения технологий и способов их использования.
Умение настраивать мониторинг и анализировать логи приложения.	Можно за минуты самостоятельно определить работоспособность сценария, число ошибок в продакшене, сделать вывод об использовании или неиспользовании новой фичи. Легко найти общий язык с инженером поддержки. Легко дать обратную связь команде еще до того, как с этим пришли пользователи или владелец продукта. Изучение навыка занимает один день - дальше мониторинг встраивается в процесс команды, контроль занимает минуты. Позволяет уверенно приоритизировать задачи, например, на основе частотности использования сценария или возникновения бага.
Владеть трекером задач на 120% и понимать, как отразить в нем реальное состояние разработки	Детально проследить любое решение/задачу от появления первой буквы кода до работающего приложения в проде. Можно расследовать любую проблему за минуты, определить выполненные шаги реализации, проверки, какие были требования, макеты. Дать ответ заказчику на любой вопрос, избежав мнений и оценочных суждений членов команды. +Бонус: легкое погружение в процесс новых участников команды. +Экстрабонус: ПМ не нужен для ответа на любой вопрос о статусе - все можно посмотреть в трекере задач.
Умение декомпозировать фичу на сценарии, выделить MVP	Эта суперспособность оказывает максимальное влияние на количество рисков, которые могут возникнуть в процессе разработки. Наиважнейшая точка контакта с аналитиками - сделать вместе или вникнуть в существующую нарезку задач. Отсюда идет понимание размера задач, их тестируемости, сложности разработки, вывод об исполнении бюджета фичи. Отсюда же появляется план внедрения, а значит и стратегия управления разработкой.
Понимать пирамиду тестирования, виды тестов, классы эквивалентности в своем продукте.	Часто, понимая тестирование, возникает желание поменять декомпозицию. Фича, которая выглядит легкой в аналитике и разработке, далеко не всегда проста в тестировании. Как раз ПМ видит все части и может влиять на общий результат. Плюс разбор результатов тестирования вместе с тестировщиками помогает давать корректную обратную связь разработчикам, регулировать взаимодействие между ролями, определять зоны ответственности. Для опытных - организация тестирования требований в команде. Это также позволяет отрабатывать риски на ранних стадиях разработки.

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

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