Привет, Хабр! Давайте поговорим о проектном управлении в продуктах Озона.
Меня зовут Андрей, я пришёл в компанию менеджером по продукту полгода назад. И первое, что бросилось мне в глаза, — отсутствие излишней бюрократии, которую ожидаешь встретить в корпорации: формальных планёрок, отчётных встреч, бесконечных служебок и приказов. Ура! Не надо отчитываться по решённым задачам разработчиков, объёму техдолга, собирать статистику спринтов, искать виноватых или самому ходить «на ковёр».
При дальнейшем погружении в работу нашей команды выяснилось, что частично эти процессы всё же есть, но реже, чем я ожидал в начале. Отчеты — перед заказчиками по проектам в работе, а планирование происходит раз в месяц (как и у большинства других команд); ключевой формат планирования — технический комитет, где встречаются заказчики от бизнеса и исполнители от IT.
Такой подход к планированию связан с масштабом — количеством и размером продуктов в Озоне. Здесь нет фундаментального ноу-хау — принцип «Давайте есть слона по кусочкам» для работы с большими проектами работает и в нашем случае. Наша специфика в том, что приходится думать не только о нюансах работы с отдельно взятым слоном, но и об их популяции: учёте, хранении, планировании поставок, селекции и разведении.
Откуда в Озоне появляются слоны, как организованы процесс поставки проектным командам, как организовано верхнеуровневое планирование и отчётность, — расскажу в серии статей. В этот раз — о том, с чего всё начинается.
В классическом проектном управлении часто можно встретить принцип декомпозиции.
В стратегическом же планировании и управлении распространена концепция композиции. Разные источники рассказывают об этом в разных терминах: Helicopter View, Бык Пикассо, Пять почему. Объединяет всё это универсальный принцип композиции: выбора, агрегации, отсева и упрощения значимых элементов.
Верхнеуровневые принципы композиции и декомпозиции используются для планирования у нас примерно так:
От идеи до запуска мы несколько раз «спускаемся вниз» (разбираем проект до цифр и метрик, задач и подзадач) и «поднимаемся наверх» (для отделения значимого от второстепенного).
Давайте теперь более пристально всмотримся в две вертикали Озона — бизнес и IT.
Бизнес отвечает за требования к слонам: габариты, размеры, цели применения, планы по использованию, ожидаемый эффект.
IT-вертикаль отвечает за реализацию требований: селекцию подходящих пород слонов и разработку «обвеса» (методы кормления и дрессировки, базовые команды).
IT-вертикаль стремится избегать ситуаций, когда слоны сначала появились, а потом их нужно кому-нибудь «продать», но выполняет заказ на поставку как полагается — с прогнозом сроков, нужного качества, в рамках оговорённого бюджета.
Внутреннее устройство вертикалей — классическое. В бизнесовой части всё устроено как в офлайновой компании: прибыль, трафик, покупатели, поставщики, логистика и прочее. Структурное деление организовано по направлениям и предметной области экспертизы. Например, может быть отдел, занимающийся одной категорией товаров, со всей вытекающей внутренней иерархией.
В IT-вертикали — всё как в условном Google: используется доменная архитектура, в которой команды и отделы строятся вокруг функциональных блоков и модулей приложения. Например, может быть отдел, задачей которого является поддержание в актуальном состоянии какого-то одного API или таблицы данных.
Если представить взаимодействие вертикалей как экспертизу и компетенцию, то мы получим классическую матричную структуру управления.
В такой структуре могут возникать спорные моменты, в частности о границах зон ответственности за проект и продукт. Не достигли целей почему? Было недостаточно компетенций исполнителей или проблема в экспертизе заказчика?
Поэтому для определения границ зон ответственности у нас есть конвенции,в которых прописаны основные бизнес-процессы и положения, принятые в компании.
Для разработки, контроля и улучшения конвенций существуют комитеты:
Кто-то может сказать, что конвенции и комитеты — это слишком суровые атрибуты процессов, что у нас всё слишком регламентировано: «свод законов и правил, которые нельзя нарушать». Но по факту именно это позволяет снизить уровень энтропии, определять границы проектов и степень их готовности, а также набор обязательных требований.
Давайте посмотрим, откуда же берутся слоны?
Прежде чем сделать заказ слонов, надо сходить в несколько походов: узнать, какие слоны лучше переносят тот или иной климат, какие — хороши в борьбе с варварами, а какие — с организованной конницей.
Для этого каждое подразделение занимается генерацией и проверкой гипотез: проводит полевые исследования и интервью, изучает рынок.
Процесс проведения предварительных исследований и аналитики выглядит примерно так:
Если схему еще упростить, получим классический цикл непрерывных изменений (PDCA)
По итогам аналитики и презентации не все проекты получают зелёный свет — некоторые остаются ждать.
В каждом из пунктов выше есть свои нюансы, но основа основ — финансовая выгода. Главное требование к слону — чтобы приносил деньги или помогал существенно их экономить.
Когда проект готов, бизнес-заказчик определяется с исполнителем на стороне IT. Если предлагаемые бизнес-требования могут быть реализованы по-разному (например, виджет можно показать на разных разделах) или продукт находится в стадии роста, то имеет смысл идти в наименее загруженные домены. Принцип примерно такой же, как в стартапе Quick Wins. В нашем случае, как правило, наиболее загруженные те домены (и, соответственно, их техкомы), которые находятся ближе всего к финальному этапу покупки.
Здесь стоит обратиться к психологии пользователя: чем дальше человек прошёл по пути покупки, тем сильнее его готовность эту покупку совершить. Поэтому задача на этих последних шагах пользовательского пути — снять барьеры и возражения, в то время как на начальных этапах — заинтересовать. Таким образом, самые эффективные решения, в разы увеличивающие целевые метрики, находятся ближе к финишу, а самые дешевые в реализации — ближе к началу.
Чем ближе к концу пользовательского пути, тем:
Чем ближе пользователь к покупке, тем выше требования к техническим компетенциям команды, отвечающей за тот или иной этап, тем большую зону ответственности ей выделяют, тем больше очередь из заказчиков.
Окей, проекты для слонов у нас есть. Что дальше?
Распределение ресурсов на производство слонов происходит на техническом комитете или просто техкоме.
Бизнес-заказчик (менеджер продукта) приносит на техком один свой приоритетный проект. В рамках презентации он даёт прогноз влияния своего проекта на бизнес-показатели и продуктовые метрики. Одна из наиболее важных метрик — Gross Merchandise Volume (GMV), валовая выручка по заказам.
Если продукт не самый прибыльный, то и относительное увеличение GMV на условные 200% может принести заметно меньше выручки, чем увеличение целевой метрики на 5% в другом продукте, который уже приносит значительную прибыль. Поэтому проекты менее прибыльных продуктов по умолчанию могут получить более низкий приоритет. Однако «авторитетные» (в смысле прибыльности) бизнес-заказчики могут уступать приоритет менее прибыльным проектам, которые они считают важными.
В техкомах есть элемент конкуренции за ресурсы, но суть не только в этом. Большое внимание уделяется получению здоровой конструктивной критики и обсуждению возможностей для роста продукта и был всесторонний челлендж.
По итогу техкома проектам выставляются приоритеты; для проектов, попавших в топ по приоритетам — IT-подразделение обязуется провести аналитику и выдать прогноз сроков реализации.
В этой статье мы рассмотрели, как в Озоне устроена работа с большими проектами-слонами, на первых шагах.
В формате обзорной экскурсии:
Многие моменты могут показаться вам стандартными, и это будет справедливо. Наша задача — не переизобрестивелосипеды проектное управление, а использовать лучшие практики, чтобы отвечать на вызовы масштаба — количества и размера проектов в Озоне.
А как регламентированы процессы разработки у вас?
В следующий раз я расскажу о том, как мы автоматизировали проектное управление (техкомы). Оставайтесь на связи с нашей экскурсионной группой!
Меня зовут Андрей, я пришёл в компанию менеджером по продукту полгода назад. И первое, что бросилось мне в глаза, — отсутствие излишней бюрократии, которую ожидаешь встретить в корпорации: формальных планёрок, отчётных встреч, бесконечных служебок и приказов. Ура! Не надо отчитываться по решённым задачам разработчиков, объёму техдолга, собирать статистику спринтов, искать виноватых или самому ходить «на ковёр».
При дальнейшем погружении в работу нашей команды выяснилось, что частично эти процессы всё же есть, но реже, чем я ожидал в начале. Отчеты — перед заказчиками по проектам в работе, а планирование происходит раз в месяц (как и у большинства других команд); ключевой формат планирования — технический комитет, где встречаются заказчики от бизнеса и исполнители от IT.
Такой подход к планированию связан с масштабом — количеством и размером продуктов в Озоне. Здесь нет фундаментального ноу-хау — принцип «Давайте есть слона по кусочкам» для работы с большими проектами работает и в нашем случае. Наша специфика в том, что приходится думать не только о нюансах работы с отдельно взятым слоном, но и об их популяции: учёте, хранении, планировании поставок, селекции и разведении.
Откуда в Озоне появляются слоны, как организованы процесс поставки проектным командам, как организовано верхнеуровневое планирование и отчётность, — расскажу в серии статей. В этот раз — о том, с чего всё начинается.
Жизненный цикл слона: композиция vs декомпозиция
В классическом проектном управлении часто можно встретить принцип декомпозиции.
В стратегическом же планировании и управлении распространена концепция композиции. Разные источники рассказывают об этом в разных терминах: Helicopter View, Бык Пикассо, Пять почему. Объединяет всё это универсальный принцип композиции: выбора, агрегации, отсева и упрощения значимых элементов.
Верхнеуровневые принципы композиции и декомпозиции используются для планирования у нас примерно так:
- в бизнесе: Идея → Коридорные исследования → Декомпозиция → Количественное исследование → Синтез → Анализ → Композиция → Презентация и защита → Проект;
- в IT: Проект → Декомпозиция → Системная и бизнес-аналитика → Спецификация → Задачи → Реализация → Внедрение → Композиция → Ретроспектива → Запуск.
От идеи до запуска мы несколько раз «спускаемся вниз» (разбираем проект до цифр и метрик, задач и подзадач) и «поднимаемся наверх» (для отделения значимого от второстепенного).
Команда по разведению слонов: бизнес и IT
Давайте теперь более пристально всмотримся в две вертикали Озона — бизнес и IT.
Бизнес отвечает за требования к слонам: габариты, размеры, цели применения, планы по использованию, ожидаемый эффект.
IT-вертикаль отвечает за реализацию требований: селекцию подходящих пород слонов и разработку «обвеса» (методы кормления и дрессировки, базовые команды).
IT-вертикаль стремится избегать ситуаций, когда слоны сначала появились, а потом их нужно кому-нибудь «продать», но выполняет заказ на поставку как полагается — с прогнозом сроков, нужного качества, в рамках оговорённого бюджета.
Внутреннее устройство вертикалей — классическое. В бизнесовой части всё устроено как в офлайновой компании: прибыль, трафик, покупатели, поставщики, логистика и прочее. Структурное деление организовано по направлениям и предметной области экспертизы. Например, может быть отдел, занимающийся одной категорией товаров, со всей вытекающей внутренней иерархией.
В IT-вертикали — всё как в условном Google: используется доменная архитектура, в которой команды и отделы строятся вокруг функциональных блоков и модулей приложения. Например, может быть отдел, задачей которого является поддержание в актуальном состоянии какого-то одного API или таблицы данных.
Если представить взаимодействие вертикалей как экспертизу и компетенцию, то мы получим классическую матричную структуру управления.
В такой структуре могут возникать спорные моменты, в частности о границах зон ответственности за проект и продукт. Не достигли целей почему? Было недостаточно компетенций исполнителей или проблема в экспертизе заказчика?
Поэтому для определения границ зон ответственности у нас есть конвенции,в которых прописаны основные бизнес-процессы и положения, принятые в компании.
Для разработки, контроля и улучшения конвенций существуют комитеты:
- архитектурный комитет — отвечает за глобальные изменения в архитектуре приложений;
- проектный комитет — управляет процессами разработки и внедрения, определяет требования к проекту и спецификации;
- комитеты по центрам компетенций — разрабатывают манифест и технические требования к компетенциям линейных сотрудников.
- технические комитеты — место встречи бизнеса и IT для обсуждения и приоритизации проектов.
Кто-то может сказать, что конвенции и комитеты — это слишком суровые атрибуты процессов, что у нас всё слишком регламентировано: «свод законов и правил, которые нельзя нарушать». Но по факту именно это позволяет снизить уровень энтропии, определять границы проектов и степень их готовности, а также набор обязательных требований.
Откуда берутся слоны: генерация продуктовых гипотез
Давайте посмотрим, откуда же берутся слоны?
Прежде чем сделать заказ слонов, надо сходить в несколько походов: узнать, какие слоны лучше переносят тот или иной климат, какие — хороши в борьбе с варварами, а какие — с организованной конницей.
Для этого каждое подразделение занимается генерацией и проверкой гипотез: проводит полевые исследования и интервью, изучает рынок.
Процесс проведения предварительных исследований и аналитики выглядит примерно так:
- Генерация идей.
- Выбор и приоритизация.
- Коридорное исследование.
- Разработка гипотезы, оценка влияния на целевую метрику (что надо сделать, чтобы гипотеза подтвердилась).
- Оценка вероятности подтверждения гипотезы.
- Качественное и количественное исследования (если возможно).
- Разработка бизнес-требований к реализации.
- Технический и продуктовый UX-дизайн.
- Построение сиквенс-диаграммы;
- Декомпозиция до уровня доменных проектов.
- Верхнеуровневая оценка сложности реализации и размера проекта.
- Разработка презентации проекта.
- Защита проекта перед своим руководителем, получение бюджета на реализацию (счастливый номер пункта — случайность).
Если схему еще упростить, получим классический цикл непрерывных изменений (PDCA)
По итогам аналитики и презентации не все проекты получают зелёный свет — некоторые остаются ждать.
В каждом из пунктов выше есть свои нюансы, но основа основ — финансовая выгода. Главное требование к слону — чтобы приносил деньги или помогал существенно их экономить.
Когда проект готов, бизнес-заказчик определяется с исполнителем на стороне IT. Если предлагаемые бизнес-требования могут быть реализованы по-разному (например, виджет можно показать на разных разделах) или продукт находится в стадии роста, то имеет смысл идти в наименее загруженные домены. Принцип примерно такой же, как в стартапе Quick Wins. В нашем случае, как правило, наиболее загруженные те домены (и, соответственно, их техкомы), которые находятся ближе всего к финальному этапу покупки.
Здесь стоит обратиться к психологии пользователя: чем дальше человек прошёл по пути покупки, тем сильнее его готовность эту покупку совершить. Поэтому задача на этих последних шагах пользовательского пути — снять барьеры и возражения, в то время как на начальных этапах — заинтересовать. Таким образом, самые эффективные решения, в разы увеличивающие целевые метрики, находятся ближе к финишу, а самые дешевые в реализации — ближе к началу.
Чем ближе к концу пользовательского пути, тем:
- выше ответственность за стабильность и устойчивость под нагрузками;
- суровее SLA-требования к сервисам;
- больше покрытие тестами;
- больше проверок крайних состояний;
- выше цена техдолга;
- ниже скорость реализации бизнес-фич.
Чем ближе пользователь к покупке, тем выше требования к техническим компетенциям команды, отвечающей за тот или иной этап, тем большую зону ответственности ей выделяют, тем больше очередь из заказчиков.
Формируем меню из слонов: технические комитеты
Окей, проекты для слонов у нас есть. Что дальше?
Распределение ресурсов на производство слонов происходит на техническом комитете или просто техкоме.
Бизнес-заказчик (менеджер продукта) приносит на техком один свой приоритетный проект. В рамках презентации он даёт прогноз влияния своего проекта на бизнес-показатели и продуктовые метрики. Одна из наиболее важных метрик — Gross Merchandise Volume (GMV), валовая выручка по заказам.
Если продукт не самый прибыльный, то и относительное увеличение GMV на условные 200% может принести заметно меньше выручки, чем увеличение целевой метрики на 5% в другом продукте, который уже приносит значительную прибыль. Поэтому проекты менее прибыльных продуктов по умолчанию могут получить более низкий приоритет. Однако «авторитетные» (в смысле прибыльности) бизнес-заказчики могут уступать приоритет менее прибыльным проектам, которые они считают важными.
В техкомах есть элемент конкуренции за ресурсы, но суть не только в этом. Большое внимание уделяется получению здоровой конструктивной критики и обсуждению возможностей для роста продукта и был всесторонний челлендж.
По итогу техкома проектам выставляются приоритеты; для проектов, попавших в топ по приоритетам — IT-подразделение обязуется провести аналитику и выдать прогноз сроков реализации.
Обзорная экскурсия по местам обитания слонов — продолжается
В этой статье мы рассмотрели, как в Озоне устроена работа с большими проектами-слонами, на первых шагах.
В формате обзорной экскурсии:
- заглянули в базовые принципы жизненного цикла проектов — композицию и декомпозицию;
- познакомились с участниками процесса — бизнесом и IT;
- узнали, что происходит в самом начале — на этапе генерации продуктовых гипотез и их верификации на технических комитетах.
Многие моменты могут показаться вам стандартными, и это будет справедливо. Наша задача — не переизобрести
А как регламентированы процессы разработки у вас?
В следующий раз я расскажу о том, как мы автоматизировали проектное управление (техкомы). Оставайтесь на связи с нашей экскурсионной группой!
