Pull to refresh
СберМаркет
Кодим будущее доставки товаров

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

Reading time 8 min
Views 6.8K

Привет! Это Оля Муттер, руководитель проектного офиса в СберМаркет 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 (оповещается после исполнения).

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

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

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

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

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

В проектном офисе мы:

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

  • Минимизируем риски. Мы выявляем, анализируем и управляем рисками, обеспечивая стабильность и надежность проектов.

  • Сокращаем время доставки ценности в продукт. Наша цель — сократить время от идеи до выхода продукта на рынок, что способствует увеличению скорости и удовлетворенности клиентов.

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

Я как руководитель офиса распределяю проекты в зависимости от нагрузки менеджеров и их компетенций.

Кроме того, у нас есть обязательное еженедельное мероприятие для брейншторма и обратной связи. Оно состоит из трех блоков:

  1. В первом блоке мы обсуждаем новости компании.

  2. Во втором — проверяем, четко ли идем по стратегии проектного офиса. 

  3. Третий блок я называю открытым микрофоном: там можно свободно поделиться проблемами и получить мнение коллег.

Кстати, вам может быть интересна моя статья о методике технических ретроспектив. На 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-менеджеров.

Tags:
Hubs:
+10
Comments 7
Comments Comments 7

Articles

Information

Website
sbermarket.ru
Registered
Founded
Employees
1,001–5,000 employees
Location
Россия
Representative
SberMarket Tech