Привет, Хабр! Меня зовут Иван, и я проджект-менеджер (или PM) в продуктовой разработке. Кто не знает, проджект занимается…чем только не занимается: мы одновременно держим под контролем работу команд и общаемся с десятками людей, успеваем делать ещё и свои задачи. Выглядит как хаос, но я знаю как им управлять.
В статье расскажу, на чём нужно сосредоточиться PM, чтобы влиять на результат и заниматься действительно важным и интересным, покажу фрагмент моего списка дел, поделюсь фишками управления несколькими проектами сразу.
Роль проджекта в продуктовой разработке
В iSpring всё начинается с того, что отдел развития продуктов анализирует рынок и формирует видение новой фичи. Затем заказчик фичи презентует идею в формате one-pager. Дальше подключаются продуктовые дизайнеры, а затем команды разработчиков реализуют фичу по ТЗ. У каждой такой команды есть PM, который контролирует сроки и качество проектов. Обычно у PM 2-3 команды и до 10 параллельных проектов.
В каждой команде также есть тимлид, отвечающий за архитектуру и технические детали, а также мотивацию и развитие сотрудников. PM же сосредоточен на управлении проектами и межкомандном взаимодействии.
Тимлид и PM могут подменять друг друга при необходимости, но в целом каждый отвечает за свою область.
Как приоритизировать задачи?
Каждое утро я просматриваю новые письма, сообщения и задачи, которые накопились за вечер, отсеиваю вопросы и выстраиваю их приоритеты с помощью матрицы Эйзенхауэра. Метод позволяет разделить задачи на важные и неважные, срочные и несрочные, и это действительно помогает фокусироваться на главном.
Что можно отнести в каждую категорию:
Важные и срочные — требуют немедленного выполнения, их задержка негативно влияет на проект или процесс.
Важные, но не срочные — ключевые задачи, которые приводят к долгосрочным результатам. Их нужно планировать и выделять для них время заранее.
Неважные, но срочные — задачи, которые нужно выполнить быстро, но они не критичны для вашей роли. Это идеальные кандидаты для делегирования.
Неважные и несрочные — не требуют значительного внимания. Их можно смело отложить или вообще убрать из списка.
Как больше времени уделять несрочным важным задачам?
Часть срочных важных задач всегда будет возникать — это неизбежно. Но многие из них можно переводить в категорию несрочных важных. Тут на помощь приходит особенность мозга: он склонен завышать срочность дел, которые мы удерживаем в голове.
Как я подметил на тренинге по личной эффективности Максима Дорофеева, полезно все кажущиеся срочными вопросы сразу записывать в список дел, чтобы снять их «мнимую срочность». Эта техника действительно помогает мне сосредоточиться на важном, не перегружая себя ложной тревогой о срочности.
Важные задачи проджекта
Как обещал, расскажу, на чём нужно сосредоточиться PM. Для удобства разберу на примере проджект-менеджера в iSpring.
Планирование и контроль прогресса. У нас в продуктовой разработке в iSpring квартальное планирование. PM несёт ответственность за выполнение квартального плана своих команд.
В Q1 2025 над созданием наших продуктов и наполнением их фичами трудились 14 потоков разработки.
Для того, чтобы любой участник процесса создания продукта мог понимать, над чем работают в соседних командах, какие зависимости есть у его проекта, когда освободится разработчик или тестировщик, кто и когда уходит в отпуск и т.п., план разработки должен быть общедоступным и удобным для восприятия.
Над визуализацией плана мы работаем в Miro. Там мы отражаем объёмы разработки и тестирования, контрольные точки, показываем зависимости. Это очень удобный инструмент, делающий планирование и разработку согласованными и прозрачными. Задача PM - поддерживать визуальную версию плана актуальной.
Организация ресурсов. Чтобы команда могла работать, нужны готовые ТЗ, дизайн и другие ресурсы. PM отслеживает статусы внешних задач и координирует получение командой ресурсов. Для этого он может участвовать во внешних планёрках, следить за статусами задач смежных команд, обсуждать сроки с их представителями.
Участие в подготовке ТЗ. PM участвует в обсуждении ТЗ с первых этапов его формирования. Обсуждение будущей фичи начинается в отделе дизайна продуктов. Затем мы плавно вовлекаем в проработку архитекторов и Senior-разработчиков. Они оценивают, как новый модуль встраивается в архитектуру продукта, подсвечивают варианты реализации, указывают на ограничения и риски. Далее продуктовые дизайнеры оформляют ТЗ и дизайн для команды разработки.
По ходу процесса PM не просто фасилитирует встречи, а выступает полноценным участником дискуссии - предлагает идеи, высказывает своё мнение по всем обсуждаемым вопросам. Проджект обеспечивает, чтобы ключевые пользовательские сценарии были учтены при подготовке ТЗ и определении состава MVP.
В качестве бонуса у PM после 100500 проектов формируются знания по огромному контексту, какое мало у кого есть.
Контроль сроков. PM отслеживает прогресс по контрольным точкам, планирует нагрузку, фокусирует команду на целях итерации, помогает команде завершать задачи вовремя.
Один из важных инструментов контроля сроков - планёрки. Мы проводим их ежедневно в смешанном режиме – иногда синхронно, а иногда письменно.
Плюсы и минусы письменных планёрок
Письменные планёрки хороши тем, что:
дисциплинируют команду
систематизируют информацию автора письменного сообщения, дают ему чёткое понимание происходящего
там можно явно тегнуть человека, от которого что-то кому-то требуется, и у него сразу сформируется список дел в рабочем чате
представляют собой лог того, что происходило в команде, как каждый из участников двигался по своим задачам, с какими трудностями сталкивался. Такая информация бывает полезной для ретроспективного анализа работы команды.
Недостатки таких планёрок:
на них сложно отловить сомнения и недопонимания у участников команды
на них сложнее держать команду в общем контексте
Я рекомендую чередовать очные планёрки с письменными и не переходить на письменный формат полностью.
Работа с таск-трекером. В таск-трекере PM может:
контролировать статусы;
собирать отчёты о сделанной работе;
находить задачи, которые задержались, и направлять их в нужное русло.
Здесь важно пробежаться по тегам, сделать выборки, подсветить разработчикам, где забыли перевести на ревью, завести задачу в отдел SRE на подготовку БД для нового сервиса и прочее.
Кроме того, грамотно построенные дашборды в таск-трекере позволяют быстро получить информацию о состоянии дел по любому из проектов в работе. Регулярно пользуюсь дашбордами, когда готовлюсь к планёркам, сверяюсь с контрольными точками и принимаю решения.
На дашборд я помещаю ссылки на нужные ресурсы, графики с количеством задач с разбивкой по статусам, исполнителям, функциональным блокам фичи. Могу отдельно смотреть ситуацию по фронтенду, бекенду, тестированию и т.д.
Планирование состава релизов. В нашей компании мы следуем принципу ритмичной доставки ценности через MVP, разделяя большие фичи на блоки функционала, которые можно выпускать поочередно. Зона ответственности PM - совместно с командой определить, какие задачи из текущего MVP можно выпустить в релиз, а какие отложить в бэклог для дальнейшей работы.
Проверка фичей перед релизом. Выпуская новые модули и улучшения, важно не только придерживаться ТЗ, но и помнить о ценности, которую улучшение несёт для клиентов.
Пример из практики
Когда мы добавляем фильтр в отчёт, мы держим в голове, что этим фильтром клиент решает задачу группировки пользователей по нужному ему признаку для дальнейших действий с ними. Поэтому мы фокусируемся не на фильтре как таковом, а смотрим на весь путь пользователя при решении его задачи.
PM, понимая задачи клиента, которые решает фича, проверяет полноту реализации и формирует бэклог улучшений, которые могут не войти в первую версию.
Релиз-менеджмент. У нас в компании несколько PM и с десяток команд, которые периодически что-то релизят на прод.
Проджект-менеджер каждой из команд решает, в какой релиз взять ту или иную доработку, сделанную в его команде, вносит информацию в общий график, договаривается с другими командами о датах релизов и ресурсах CI/CD инфраструктуры.
В дни, когда релизов несколько, PM совместно с тестировщиками координирует их очерёдность или договаривается об объединении релизов.
Релиз нескольких фичей в один день требует предварительной сборки общего билда для решения конфликтов в коде, либо поочерёдного попадания фичей в мастер-ветку и согласования изменений кода там. Кроме того, в процессе деплоймента такого сборного релиза требуется smoke-тестирование фичей в стейдже тестировщиками каждой из фичей. Дальше углубляться не буду, если тема вызвала интерес - пишите в комментариях 🙂
Взаимодействие со стейкхолдерами. PM ведёт переговоры с заказчиками, устанавливая приоритеты, сроки и объём функционала. Его задача – прийти на такие переговоры подготовленным, заранее проработав внутри команды возможные варианты.
Проверка артефактов фичи. Фичу нужно не только разработать, но и представить пользователю. PM проверяет все материалы перед релизом: обучающие курсы, документацию и маркетинговые материалы, чтобы в них были точно и понятно описаны новые возможности продукта для пользователей.
Решение проблем. PM часто является точкой входа для всех вопросов, так как имеет широкий круг взаимодействий внутри компании. PM маршрутизирует вопросы, поступающие от пользователей, клиентов и команды, помогая оперативно решать возникающие проблемы.
На чём не стоит фокусироваться PM
Модерация технических обсуждений. Задачи, такие как решение споров о хранении данных (таблицы или JSON), или обсуждения конфигов для быстрофиксов — лучше оставить разработчикам, тем более что в нашей компании они опытные и осознанные. Проджекту важно убедиться, что разработчики пришли к согласию, и у всех единое понимание дальнейших шагов.
Декомпозиция ТЗ на задачи для разработки. Проджект может ставить задачи разработчикам, например, на исправление бага, но разбиение ТЗ на конкретные задачи для разработки — это задача техлида или лидов команды.
При этом PM совместно с тимлидом определяет приоритет реализации пользовательских сценариев по фиче.
Организация тимбилдингов и поздравлений. Этими вопросами у нас занимаются тимлиды или инициативные коллеги при содействии HR.
Консультации по общим вопросам. Например, ответы на вопросы из разряда “Как должен работать тот или иной функционал?” в групповых корпоративных чатах. При этом, если меня тегнули в рабочем чате, я обязательно помогу или перенаправлю к нужному специалисту.
Где важно разделить зоны ответственности
Проведение ретроспектив. Раньше проведением ретро занимался только проджект, теперь проводим такие встречи совместно с тимлидом и оба отвечаем за обсуждаемые вопросы.
Планирование итераций. Как и с ретро, раньше этим занимался только проджект. Теперь тимлид помогает оценить задачи с технической стороны, а проджект фокусируется на сроках и влиянии инкремента итерации на продуктовую цель.
Вопросы по команде. Контроль дисциплины, мотивация и запросы доступов — такие задачи может сделать или тимлид, или PM, кто свободен или по договорённости.
Описанный в статье подход позволяет мне сосредоточиться на задачах, которые действительно влияют на результат, завершать проекты вовремя и в рамках бюджета, и получать удовольствие от работы.
Расскажите в комментариях, а как выглядит ваш список важных и неважных задач? 🙂
