Привет! Это Оля Муттер, руководитель проектного офиса в СберМаркет Tech. Сегодня я хочу рассказать о проектном подходе в продуктовой разработке. Нужны ли проджекты, если в компании уже есть продакты? Как построить синергию между проектным офисом и продуктовой командой и какую пользу от этого могут получить все участники процесса, включая бизнес? Кто такие деливери менеджеры как они могут усилить вашу команду?
Моя статья будет полезной для всех участников продуктовой разработки: продактов, тимлидов, руководителей IT. Проджекты и деливери-менеджеры тоже могут узнать что-то новое.
Структура компании в продуктовом подходе и где скрывается подвох
Проджект: кто это такой и какими инструментами владеет
Продакт, проджект, тимлид. Как между ними делится ответственность
Деливери-менеджер: кто это и чем отличается от продакта?
Домены, юниты, команды
Начну с краткого экскурса в нашу структуру. Так вам будет проще понять, как появление проектного офиса может лечь на уже существующую систему.
В СберМаркете более 1300 человек в IT и шесть продуктовых доменов. Каждый из них отвечает за определенное направление. Например, домен RTE (Ready-to-eat или доставка готовой еды) — это все, что связано с путем клиента в отношении оформления заказа из ресторанов, в том числе личный кабинет для ресторана и интеграции.
Внутри каждого домена выделяются юниты. Продолжая пример с ресторанами, за клиентские сервис отвечает юнит Clients, за интеграции с системами учета в ресторанах и другими сервисами — Integrations. Юниты делятся на команды. Причём чем больше загрузка юнита, тем больше в нём команд.
Команды у нас кросс-функциональные, то есть ребята могут выполнять совершенно разные задачи: и бэкенд, и мобильную разработку, и тестирование. Команда — обособленная единица. У неё есть бесконечный бэклог задач, есть процессы, по которым она работает: например планирует работу на двухнедельных спринт, до этого проведя грумминг и оценку задач, а в конце спринта — ретроспективу.
В чем скрывается подвох?
Когда команда обособленно выполняет свои задачи, подвоха нет. Продакт приоритизирует бэклог, тимлид распределяет задачи — все работает отлично.
Проблемы возникают, когда есть кросс-функциональная задача, которую должны выполнить сразу несколько команд, причем не из одного юнита и даже не из одного домена.
Чтобы достичь результата, команды должны работать слаженно. А для этого они должны знать последовательность действий. Даже если подзадачи можно выполнять параллельно, необходимо учесть все риски и зависимости.
Возникает целый список вопросов:
Кто в ответе за конечный результат?
Какие итоговые сроки реализации?
А мы сейчас успеваем или нет?
А всё ли мы учли?
Все ли команды согласованы?
Какие риски?
А кто работает с рисками?
Как отслеживать прогресс?
Все эти вопросы можно объединить в один: «А кто ответственный?»
Например, ответственность может лежать на том человеке, кто придумал фичу. Сам придумал — сам и должен сделать все, что входит в понятие проектного управления.
У такого подхода есть ряд недостатков:
Если таким человеком становился продакт, кросс-функциональная задача мешала его собственному Discovery.
Если тимлид — теряется фокус с команды и собственного бэклога.
Оверкоммуникация или отсутствие коммуникации, микроменеджмент, большое количество блокировок, неучтенные требования в роадмапе, никакой прозрачности в ходе проекта. Я могу продолжить, но вы уже поняли. А самое главное — никто не отвечает за итог.
При этом минимум 30% проектов внутри СберМаркета — кросс-функциональные. От их реализации действительно зависит самочувствие бизнеса. Поэтому мы решили сделать по-другому.
Волшебное слово «проджект»
Мы осознали критическую важность стандартизированного подхода и ввели роль проджект-менеджера.
Чем занимается проджект?
Формирует план работ (роадмап).
Контролирует статус реализации плана и наличие отклонений.
Координирует участников и единое информирование заинтересованных лиц.
Управляет рисками.
Отвечает за прозрачность хода проекта и формирование отчетности для стейкхолдеров.
Своевременно реагирует на изменения в условиях и требованиях.
Проджект — это внешняя сила, которая может выявить проблемы с планированием. Например, если он увидит, что команда берет в спринт больше задач, чем может себе позволить исторически, то предложит что-то сделать с теми задачами, которые выходят за рамки капасити, максимальной емкости.
Если проджект понимает, что определенная команда только в 60% случаев попадает в дедлайны, он заложит больше времени, будет чаще и сильнее контролировать этих ребят.
Чтобы избежать риска неучтенных требований и того, что у команд будут разные контексты, проджект будет вести встречи, фиксировать договоренности сторон.
Хороший проджект имеет стратегию на случай, если какой-то из рисков не получится амортизировать. Если мобильное приложение не будет готово вовремя, если возникнут баги на тестировании, неучтенные требования, новые условия.
Девять инструментов проджекта
One Pager — ключевая информация по проекту.
Сформулированная бизнес-цель, ожидаемый результат, критерии готовности (Definition of Done).
RACI-матрица, о которой я расскажу ниже.
Функциональные требования (ФТ). Их пишет бизнес-аналитик или продакт, но задача проджекта — убедиться, что эти требования зафиксированы и со всеми согласованы.
План по коммуникациям. Включает в себя список регулярных встреч и лист эскалации на случай возникновения проблем: к кому идти, в какой чат писать.
Роадмап. В СберМаркете мы рисуем роадмапы с помощью Jira-плагина Structure.
RAID-лог. Какие риски могут возникнуть? Какие есть зависимости? Что будем делать, если что-то пойдет не по плану?
Отчеты стейкхолдерам.
План по тестированию и внедрению. Что и когда мы тестируем, кто делает интеграционное тестирование, включает Feature Flags, запускает AB-тест?
Как встроить проджекта в оргструктуру
У нас проджект чаще всего входит в конкретный домен. Он отвечает за управление кросс-функциональным проектом, если:
именно его домен владеет фичой;
проект имеет высокий приоритет именно для его домена;
в его домене находятся большинство команд, вовлеченных в реализацию проекта.
Иногда проджект может быть закреплен и за конкретным юнитом. В этом случае он больше погружается в задачи команд. Находясь в юните, он также может отвечать за кросс-функциональный проект на всю компанию, просто команды его юнита будут знать, что могут обратиться к нему за помощью.
Как делится ответственность между продактом, тимлидом и проджектом?
Продакт определяет, что мы делаем, какой эффект ожидаем, какую пользу несем клиенту. Он выдает идеи, тестирует гипотезы и прорабатывает продукт.
Тимлид управляет командой: проводит декомпозицию и оценку качества, отвечает за пипл-менеджмент.
Проджект — это о прозрачности хода работ, координации участников, едином подходе ко всем.
Если продакт мыслит продуктом, а тимлид — командой, то проджект мыслит проектом и задачами, которые нужно выполнить в рамках этого проекта.
Чтобы не путаться в зонах ответственности, мы используем RACI-матрицу.
R = Responsible (исполняющий).
A = Accountable (ответственный).
С = Consult before doing (консультирует перед исполнением).
I = Inform after doing (оповещается после исполнения).
Такую матрицу следует иметь каждой команде, чтобы все понимали, от кого и насколько они зависимы. Однако от команды к команде эта таблица может отличаться: иногда роль проджекта по тем или иным причинам выполняет всё-таки тимлид или продакт и эти зависимости мы предпочитаем закреплять и визуализировтаь для всех членов команды.
Зачем нужен проектный офис
У проджектов СберМаркета есть руководители в доменах. Чаще всего это технические менеджеры. Они дают сроки выполнения проекта, определяют оптимальную стоимость с точки зрения ресурсов.
Проектный офис позволяет работать в рамках единой стратегии достижения результатов, делиться лучшими практиками. Мы работаем на максимизацию поставки ценности, GMV, при заданном уровне затрат IT.
В проектном офисе мы:
Организуем проекты и управляем ими. Мы управляем созданием и выполнением планов проектов, обеспечивем их успешную доставку в срок и в рамках бюджета.
Минимизируем риски. Мы выявляем, анализируем и управляем рисками, обеспечивая стабильность и надежность проектов.
Сокращаем время доставки ценности в продукт. Наша цель — сократить время от идеи до выхода продукта на рынок, что способствует увеличению скорости и удовлетворенности клиентов.
Улучшаем процессы. Мы являемся основными держателями практик по процессу разработки, постоянно оптимизируем бизнес-процессы, обеспечивая гибкость и эффективность масштабирования бизнеса.
Я как руководитель офиса распределяю проекты в зависимости от нагрузки менеджеров и их компетенций.
Кроме того, у нас есть обязательное еженедельное мероприятие для брейншторма и обратной связи. Оно состоит из трех блоков:
В первом блоке мы обсуждаем новости компании.
Во втором — проверяем, четко ли идем по стратегии проектного офиса.
Третий блок я называю открытым микрофоном: там можно свободно поделиться проблемами и получить мнение коллег.
Кстати, вам может быть интересна моя статья о методике технических ретроспектив. На TechRetro специалисты одного направления из разных команд совместно ищут решения инженерных проблем.
Кое-кто еще: деливери-менеджеры
Я упомянула, что проектный офис работает на максимизацию поставки ценности. Как понять, что у нас это действительно получается?
Для этого есть деливери-менеджеры — эксперты в лучших практиках и методологиях. Не путайте с Service Delivery Manager из канбана, в нашем случае речь идет о специалисте, который не специализируется на определенной методологии, а смотрит на процессы максимально широко.
Подходы команд к планированию, рефлексии, декомпозиции могут устаревать. Нужно отслеживать насколько они актуальны и правильно ли с ними работают сотрудники. А ещё, насколько они подходят для эффективной и гибкой работы конкретной компании.
Чем занимается деливери-менеджер?
Выявляет неудовлетворенность, проблемы и блокировки в процессах.
Определяет узкие места в потоке ценности. Почему на этапе перед разработкой накапливается слишком много задач? Что с этим можно сделать?
Строит и анализирует метрики.
Разрабатывает стратегию и план по улучшению процессов.
Организует взаимодействие между отделами, командами, бизнес-линиями. В случае проджект-менеджера синхронизация идет по задачам проекта, в случае деливери-менеджера — по процессу.
Масштабирует практики.
Повышает зрелость команд.
Деливери-менеджер приходит в юнит или команду, разбирает неудовлетворенности, настраивает процессы, а потом масштабирует знания на весь домен. Фокус такого менеджера — системное улучшение, выявление закономерностей и анализ предпосылок.
У нас деливери-менеджеры появились из скрам-мастеров, которые уже были в компании на момент разработки проектного офиса.
Инструменты деливери-менеджера
Lead Time. Медианное время выполнения проектов во всех кросс-функциональных командах — с момента начала Discovery до раскатки на всех клиентов.
Контрметрики Throughput (количество поставленных проектов) и Value (суммарная бизнесовая ценность поставленных проектов).
Анализ цепочки поставок. Он дает информацию обо всех основных проблемах и о том, как они влияют на Lead Time.
Скорость работы и прочие метрики.
Естественно, деливери-менеджер проводит мероприятия с командой: обзоры поставок, синки по стратегии, оценки уровня зрелости.
Разница между проджектами и деливери-менеджерами?
Проджекты дают экспертизу проектного управления, а деливери-менеджеры работают над системой в целом. При этом проджекты и деливери-менеджеры — одна команда. Их совместная работа заметно улучшает бизнесовые показатели.
Project Manager | Delivery Manager |
Снижает риски нарушения сроков по проектам Владеет экспертизой проектного управления, снижает нагрузку с продактов и тимлидов. | Выявляет блокеры на всем процессе доставки ценности. Внедряет системные улучшения и обучает команды. |
Итоги
С момента создания проектного офиса, то есть с февраля 2023 года, СберМаркет вырос по количеству проджектов в два раза. Это означает, что у компании есть потребность в таких сотрудниках. Lead Time — снизился, а команды стали попадать в сроки на 40% чаще. Безусловно, это заслуга не только проджектов, а и системной настройки процессов, но создание проектного офиса было одним из важных шагов в этом направлении. Отличный результат, из-за которого я и рекомендую проектный подход другим продуктовым командам :)
Tech-команда СберМаркета ведет соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и на YouTube. А также слушай подкаст «Для tech и этих» от наших it-менеджеров.
