Всем привет!

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



Интересующимся и желающим пообщаться на эту тему — добро пожаловать под кат.

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

Попадая в такую компанию, поначалу сложно сориентироваться. Но проходит время, и вот ты уже вполне можешь представить себе свой «островок». Как правило, это:

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

Знакомая картина?

Так выглядит типичная и не самая худшая система разработки ПО. Обычно к такому виду приходят департаменты разработки компаний с успешными продуктами лет через 10-15. Успешные продукты приносят деньги, деньги вкладываются в разработку. Разработка растет как на дрожжах, ее линейно масштабируют и приходят к ситуации, когда проектные менеджеры уже не могут держать в голове все зависимости, множество команд начинают тянуть «одеяло» на себя, и, порой, вредят продукту, нежели развивают его. В такой ситуации вполне нормально, когда одна команда стремится к собственному успеху, уже не переживая, что их коллеги испытывают какие-то проблемы, и их общая фича не будет из-за этого доставлена. В порядке вещей разрабатывать тот функционал, который громче всех просят бесконечные стейкхолдеры, а не тот, который нужен пользователям. Не редкость и разработка «в стол». Процесс ведь идет — требования приходят, реализуются, тестируются, поставляются. За ширмой из суеты и шума легко спрятать главное — разработка продукта уже далеко не такая эффективная, как раньше.

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


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

Не похоже на историю выше, верно?

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

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

• Пользователей кастдевил продакт? Теперь ваши владельцы продукта о них не вспоминают, они носятся от одного стейкхолдера к другому, пытаясь понять за какие требования хвататься в первую очередь;
• Была ясная и прозрачная юнит-экономика? Теперь владельцы продукта не считают даже PnL (Profit and Loss), загружая всю команду на пол спринта сторями с сомнительной пользой;
• Были job story, customer journey map и прочие персоны? Теперь в сторе пишут «Как продакт оунер, я хочу, чтобы это было сделано, потому что это нужно департаменту Operation and Maintanence»;
• Было понимание ответственности за результат и сроки? Теперь каждая команда сама за себя, ваши фичи доставят на прод на релиз-другой позже.

Сложность управления разработкой для масштабных продуктов растет по экспоненте. Что же делать?

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


Являются ли они «серебряной пулей»?

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

И могу сказать следующее:

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

Единственно ли верен подобный подход? Давайте посмотрим, что еще можно сделать.



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

Продукт. Продукт должен приносить ценность. Рассмотрите зоопарк ваших систем и компонент с точки зрения ценности. Выделите все потоки ценности (value streams) для конечных клиентов, контрагентов или третьих лиц и разделите карту систем по таким потокам. Каждый владелец продукта должен иметь в управлении полную цепочку систем, имеющих ценность. Дайте ему пару аналитиков, если объем ответственности слишком велик.

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

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

Гипотезы. Никаких больше имплементаций функционала вслепую. У каждого эпика или фичи должны быть ожидания по влиянию на метрики. Реализуя фичи и проверяя их А/B тестами, владельцы продукта должны понимать успешна была гипотеза или нет.

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

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

Далее, в небольшом цикле статей разберу каждую идею более подробно:

• Продукт;
• Метрики;
• Пользователи;
• Гипотезы;
• Координация.