Зачем нужен проектный офис, если компания работает в продуктовом подходе?

Привет! Это Оля Муттер, руководитель проектного офиса в СберМаркет Tech. Сегодня я хочу рассказать о проектном подходе в продуктовой разработке. Нужны ли проджекты, если в компании уже есть продакты? Как построить синергию между проектным офисом и продуктовой командой и какую пользу от этого могут получить все участники процесса, включая бизнес? Кто такие деливери менеджеры как они могут усилить вашу команду?

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

Структура компании в продуктовом подходе и где скрывается подвох

Проджект: кто это такой и какими инструментами владеет

Продакт, проджект, тимлид. Как между ними делится ответственность

Зачем нужен проектный офис

Деливери-менеджер: кто это и чем отличается от продакта?

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

Домены, юниты, команды

Начну с краткого экскурса в нашу структуру. Так вам будет проще понять, как появление проектного офиса может лечь на уже существующую систему.

В СберМаркете более 1300 человек в IT и шесть продуктовых доменов. Каждый из них отвечает за определенное направление. Например, домен RTE (Ready-to-eat или доставка готовой еды) — это все, что связано с путем клиента в отношении оформления заказа из ресторанов, в том числе личный кабинет для ресторана и интеграции. 

Внутри каждого домена выделяются юниты. Продолжая пример с ресторанами, за клиентские сервис отвечает юнит Clients, за интеграции с системами учета в ресторанах  и другими сервисами — Integrations. Юниты делятся на команды. Причём чем больше загрузка юнита, тем больше в нём команд.

Команды у нас кросс-функциональные, то есть ребята могут выполнять совершенно разные задачи: и бэкенд, и мобильную разработку, и тестирование. Команда — обособленная единица. У неё есть бесконечный бэклог задач, есть процессы, по которым она работает: например планирует работу на двухнедельных спринт, до этого проведя грумминг и оценку задач, а в конце спринта — ретроспективу.

В чем скрывается подвох?

Когда команда обособленно выполняет свои задачи, подвоха нет. Продакт приоритизирует бэклог, тимлид распределяет задачи — все работает отлично.

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

Чтобы достичь результата, команды должны работать слаженно. А для этого они должны знать последовательность действий. Даже если подзадачи можно выполнять параллельно, необходимо учесть все риски и зависимости.

Возникает целый список вопросов:

• Кто в ответе за конечный результат?

• Какие итоговые сроки реализации?

• А мы сейчас успеваем или нет?

• А всё ли мы учли?

• Все ли команды согласованы?

• Какие риски?

• А кто работает с рисками?

• Как отслеживать прогресс?

Все эти вопросы можно объединить в один: «А кто ответственный?»

Например, ответственность может лежать на том человеке, кто придумал фичу. Сам придумал — сам и должен сделать все, что входит в понятие проектного управления.

У такого подхода есть ряд недостатков:

• Если таким человеком становился продакт, кросс-функциональная задача мешала его собственному Discovery. 

• Если тимлид — теряется фокус с команды и собственного бэклога.

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

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

Волшебное слово «проджект»

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

Чем занимается проджект?

1. Формирует план работ (роадмап).

2. Контролирует статус реализации плана и наличие отклонений.

3. Координирует участников и единое информирование заинтересованных лиц.

4. Управляет рисками.

5. Отвечает за прозрачность хода проекта и формирование отчетности для стейкхолдеров.

6. Своевременно реагирует на изменения в условиях и требованиях.

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

Если проджект понимает, что определенная команда только в 60% случаев попадает в дедлайны, он заложит больше времени, будет чаще и сильнее контролировать этих ребят.

Чтобы избежать риска неучтенных требований и того, что у команд будут разные контексты, проджект будет вести встречи, фиксировать договоренности сторон.

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

Девять инструментов проджекта

1. One Pager — ключевая информация по проекту.

2. Сформулированная бизнес-цель, ожидаемый результат, критерии готовности (Definition of Done).

3. RACI-матрица, о которой я расскажу ниже.

4. Функциональные требования (ФТ). Их пишет бизнес-аналитик или продакт, но задача проджекта — убедиться, что эти требования зафиксированы и со всеми согласованы.

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

6. Роадмап. В СберМаркете мы рисуем роадмапы с помощью Jira-плагина Structure.

7. RAID-лог. Какие риски могут возникнуть? Какие есть зависимости? Что будем делать, если что-то пойдет не по плану?

8. Отчеты стейкхолдерам.

9. План по тестированию и внедрению. Что и когда мы тестируем, кто делает интеграционное тестирование, включает Feature Flags, запускает AB-тест?

Как встроить проджекта в оргструктуру

У нас проджект чаще всего входит в конкретный домен. Он отвечает за управление кросс-функциональным проектом, если:

• именно его домен владеет фичой;

• проект имеет высокий приоритет именно для его домена;

• в его домене находятся большинство команд, вовлеченных в реализацию проекта.

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

Как делится ответственность между продактом, тимлидом и проджектом?

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

Тимлид управляет командой: проводит декомпозицию и оценку качества, отвечает за пипл-менеджмент.

Проджект — это о прозрачности хода работ, координации участников, едином подходе ко всем.

Если продакт мыслит продуктом, а тимлид — командой, то проджект мыслит проектом и задачами, которые нужно выполнить в рамках этого проекта.

Чтобы не путаться в зонах ответственности, мы используем RACI-матрицу.

• R = Responsible (исполняющий).

• A = Accountable (ответственный).

• С = Consult before doing (консультирует перед исполнением).

• I = Inform after doing (оповещается после исполнения).

Такую матрицу следует иметь каждой команде, чтобы все понимали, от кого и насколько они зависимы. Однако от команды к команде эта таблица может отличаться: иногда роль проджекта по тем или иным причинам выполняет всё-таки тимлид или продакт и эти зависимости мы предпочитаем закреплять и визуализировтаь для всех членов команды.

Зачем нужен проектный офис

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

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

Кое-кто еще: деливери-менеджеры

Я упомянула, что проектный офис работает на максимизацию поставки ценности. Как понять, что у нас это действительно получается?

Для этого есть деливери-менеджеры — эксперты в лучших практиках и методологиях. Не путайте с Service Delivery Manager из канбана, в нашем случае речь идет о специалисте, который не специализируется на определенной методологии, а смотрит на процессы максимально широко.

Подходы команд к планированию, рефлексии, декомпозиции могут устаревать. Нужно отслеживать насколько они актуальны и правильно ли с ними работают сотрудники. А ещё, насколько они подходят для эффективной и гибкой работы конкретной компании.

Чем занимается деливери-менеджер?

1. Выявляет неудовлетворенность, проблемы и блокировки в процессах.

2. Определяет узкие места в потоке ценности. Почему на этапе перед разработкой накапливается слишком много задач? Что с этим можно сделать?

3. Строит и анализирует метрики.

4. Разрабатывает стратегию и план по улучшению процессов.

5. Организует взаимодействие между отделами, командами, бизнес-линиями. В случае проджект-менеджера синхронизация идет по задачам проекта, в случае деливери-менеджера — по процессу.

6. Масштабирует практики.

7. Повышает зрелость команд.

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

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

Инструменты деливери-менеджера

1. Lead Time. Медианное время выполнения проектов во всех кросс-функциональных командах — с момента начала Discovery до раскатки на всех клиентов.

2. Контрметрики Throughput (количество поставленных проектов) и Value (суммарная бизнесовая ценность поставленных проектов).

3. Анализ цепочки поставок. Он дает информацию обо всех основных проблемах и о том, как они влияют на Lead Time.

4. Скорость работы и прочие метрики.

Естественно, деливери-менеджер проводит мероприятия с командой: обзоры поставок, синки по стратегии, оценки уровня зрелости.

Разница между проджектами и деливери-менеджерами?

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

Project Manager	Delivery Manager
Снижает риски нарушения сроков по проектам Владеет экспертизой проектного управления, снижает нагрузку с продактов и тимлидов.	Выявляет блокеры на всем процессе доставки ценности. Внедряет системные улучшения и обучает команды.

Итоги

С момента создания проектного офиса, то есть с февраля 2023 года, СберМаркет вырос по количеству проджектов в два раза. Это означает, что у компании есть потребность в таких сотрудниках. Lead Time — снизился, а команды стали попадать в сроки на 40% чаще. Безусловно, это заслуга не только проджектов, а и системной настройки процессов, но создание проектного офиса было одним из важных шагов в этом направлении. Отличный результат, из-за которого я и рекомендую проектный подход другим продуктовым командам 🙂 

Tech-команда СберМаркета ведет соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и на  YouTube. А также слушай подкаст «Для tech и этих» от наших it-менеджеров.