Привет, Хабр! Давайте поговорим о проектном управлении в продуктах Озона.

Меня зовут Андрей, я пришёл в компанию менеджером по продукту полгода назад. И первое, что бросилось мне в глаза, — отсутствие излишней бюрократии, которую ожидаешь встретить в корпорации: формальных планёрок, отчётных встреч, бесконечных служебок и приказов. Ура! Не надо отчитываться по решённым задачам разработчиков, объёму техдолга, собирать статистику спринтов, искать виноватых или самому ходить «на ковёр».

При дальнейшем погружении в работу нашей команды выяснилось, что частично эти процессы всё же есть, но реже, чем я ожидал в начале. Отчеты — перед заказчиками по проектам в работе, а планирование происходит раз в месяц (как и у большинства других команд); ключевой формат планирования — технический комитет, где встречаются заказчики от бизнеса и исполнители от IT.

Такой подход к планированию связан с масштабом — количеством и размером продуктов в Озоне. Здесь нет фундаментального ноу-хау — принцип «Давайте есть слона по кусочкам» для работы с большими проектами работает и в нашем случае. Наша специфика в том, что приходится думать не только о нюансах работы с отдельно взятым слоном, но и об их популяции: учёте, хранении, планировании поставок, селекции и разведении. 


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

Жизненный цикл слона: композиция vs декомпозиция 

В классическом проектном управлении часто можно встретить принцип декомпозиции. 

В стратегическом же планировании и управлении распространена концепция композиции. Разные источники рассказывают об этом в разных терминах: Helicopter View, Бык Пикассо, Пять почему. Объединяет всё это универсальный принцип композиции: выбора, агрегации, отсева и упрощения значимых элементов.


Верхнеуровневые принципы композиции и декомпозиции используются для планирования у нас примерно так:

• в бизнесе: Идея → Коридорные исследования → Декомпозиция → Количественное исследование → Синтез → Анализ → Композиция → Презентация и защита → Проект;
• в IT: Проект → Декомпозиция → Системная и бизнес-аналитика → Спецификация → Задачи → Реализация → Внедрение → Композиция → Ретроспектива → Запуск.

От идеи до запуска мы несколько раз «спускаемся вниз» (разбираем проект до цифр и метрик, задач и подзадач) и «поднимаемся наверх» (для отделения значимого от второстепенного).

Команда по разведению слонов: бизнес и IT 

Давайте теперь более пристально всмотримся в две вертикали Озона — бизнес и IT.

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

IT-вертикаль отвечает за реализацию требований: селекцию подходящих пород слонов и разработку «обвеса» (методы кормления и дрессировки, базовые команды).

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

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

В IT-вертикали — всё как в условном Google: используется доменная архитектура, в которой команды и отделы строятся вокруг функциональных блоков и модулей приложения. Например, может быть отдел, задачей которого является поддержание в актуальном состоянии какого-то одного API или таблицы данных.

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


В такой структуре могут возникать спорные моменты, в частности о границах зон ответственности за проект и продукт. Не достигли целей почему? Было недостаточно компетенций исполнителей или проблема в экспертизе заказчика?

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

Для разработки, контроля и улучшения конвенций существуют комитеты:

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

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

Откуда берутся слоны: генерация продуктовых гипотез

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

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

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

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

1. Генерация идей.
2. Выбор и приоритизация.
3. Коридорное исследование.
4. Разработка гипотезы, оценка влияния на целевую метрику (что надо сделать, чтобы гипотеза подтвердилась). 
5. Оценка вероятности подтверждения гипотезы.
6. Качественное и количественное исследования (если возможно).
7. Разработка бизнес-требований к реализации.
8. Технический и продуктовый UX-дизайн.
9. Построение сиквенс-диаграммы;
10. Декомпозиция до уровня доменных проектов. 
11. Верхнеуровневая оценка сложности реализации и размера проекта.
12. Разработка презентации проекта.
13. Защита проекта перед своим руководителем, получение бюджета на реализацию (счастливый номер пункта — случайность).

Если схему еще упростить, получим классический цикл непрерывных изменений (PDCA)


По итогам аналитики и презентации не все проекты получают зелёный свет — некоторые остаются ждать.

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

Когда проект готов, бизнес-заказчик определяется с исполнителем на стороне IT. Если предлагаемые бизнес-требования могут быть реализованы по-разному (например, виджет можно показать на разных разделах) или продукт находится в стадии роста, то имеет смысл идти в наименее загруженные домены. Принцип примерно такой же, как в стартапе Quick Wins. В нашем случае, как правило, наиболее загруженные те домены (и, соответственно, их техкомы), которые находятся ближе всего к финальному этапу покупки.

Здесь стоит обратиться к психологии пользователя: чем дальше человек прошёл по пути покупки, тем сильнее его готовность эту покупку совершить. Поэтому задача на этих последних шагах пользовательского пути — снять барьеры и возражения, в то время как на начальных этапах — заинтересовать. Таким образом, самые эффективные решения, в разы увеличивающие целевые метрики, находятся ближе к финишу, а самые дешевые в реализации — ближе к началу.

Чем ближе к концу пользовательского пути, тем:

• выше ответственность за стабильность и устойчивость под нагрузками;
• суровее SLA-требования к сервисам;
• больше покрытие тестами;
• больше проверок крайних состояний;
• выше цена техдолга;
• ниже скорость реализации бизнес-фич.

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

Формируем меню из слонов: технические комитеты 

Окей, проекты для слонов у нас есть. Что дальше? 

Распределение ресурсов на производство слонов происходит на техническом комитете или просто техкоме. 

Бизнес-заказчик (менеджер продукта) приносит на техком один свой приоритетный проект. В рамках презентации он даёт прогноз влияния своего проекта на бизнес-показатели и продуктовые метрики. Одна из наиболее важных метрик — Gross Merchandise Volume (GMV), валовая выручка по заказам.

Если продукт не самый прибыльный, то и относительное увеличение GMV на условные 200% может принести заметно меньше выручки, чем увеличение целевой метрики на 5% в другом продукте, который уже приносит значительную прибыль. Поэтому проекты менее прибыльных продуктов по умолчанию могут получить более низкий приоритет. Однако «авторитетные» (в смысле прибыльности) бизнес-заказчики могут уступать приоритет менее прибыльным проектам, которые они считают важными.

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

По итогу техкома проектам выставляются приоритеты; для проектов, попавших в топ по приоритетам — IT-подразделение обязуется провести аналитику и выдать прогноз сроков реализации.

Обзорная экскурсия по местам обитания слонов — продолжается

В этой статье мы рассмотрели, как в Озоне устроена работа с большими проектами-слонами, на первых шагах. 

В формате обзорной экскурсии: 

• заглянули в базовые принципы жизненного цикла проектов — композицию и декомпозицию;
• познакомились с участниками процесса — бизнесом и IT;
• узнали, что происходит в самом начале — на этапе генерации продуктовых гипотез и их верификации на технических комитетах.

Многие моменты могут показаться вам стандартными, и это будет справедливо. Наша задача — не переизобрести велосипеды проектное управление, а использовать лучшие практики, чтобы отвечать на вызовы масштаба — количества и размера проектов в Озоне. 

А как регламентированы процессы разработки у вас?

В следующий раз я расскажу о том, как мы автоматизировали проектное управление (техкомы). Оставайтесь на связи с нашей экскурсионной группой!