Escaping the Build Trap, глава 9: Как организовать команды

Главная мысль: организуйте команды вокруг целей и потоков ценности (value streams), а не вокруг технических компонентов. Иначе команды создают работу ради работы.

Три способа организации

Компании обычно строят команды так:

Способ	Плюс	Проблема
Технические компоненты	Каждая часть системы покрыта	Команда делает работу, даже когда компонент уже стабилен
Фичи	Есть владелец у каждой части продукта	Мышление через output: ищем, что ещё добавить в «свой кусок»
Value streams и цели	Работа связана с ценностью для клиента	Нужно много координации

Проблема команд по компонентам

• В Marquetly команды стояли над каждым компонентом. Так посоветовал Agile-коуч, чтобы было «покрытие».
• Product owner команды login API сказала: она не может работать по-новому, ей нужно держать бэклог полным, иначе разработчикам нечего делать.
• У API не было серьёзных проблем. Он уже стабильно работал.
• Она считала, что команда владеет этим API навсегда. Поэтому она придумывала задачи.

Похожая проблема с командами по фичам:

• Это полезно в самом начале, когда продуктовой организации ещё нет.
• Со временем это ведёт к output-мышлению.
• Если сравнить работу таких команд со стратегией, многое не стоило делать.
• Стабильную фичу нужно мониторить и переходить к важной работе.

Команды вокруг целей: TransferWise

• TransferWise — компания из Лондона. Делает дешёвые денежные переводы в другие страны.
• Около 12 продуктовых команд. Каждая строится вокруг стратегической цели.
• Примеры: команда по retention, команда по новым валютам, команда по привлечению пользователей.
• Каждая команда владеет целью. Её успех оценивают по outcome.
• Команда может менять любые продукты, если это нужно для цели.

Что это даёт:

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

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

Value streams

Value stream — все действия, которые нужны, чтобы доставить ценность клиенту. От поиска проблемы и целей до поставки продукта или сервиса.

Как организоваться вокруг value stream:

1. Начните с клиента. Какую ценность он получает?
2. Идите назад. Через какие точки контакта с компанией он проходит?
3. Как упростить этот путь и давать больше ценности быстрее?

Важно, что такое продукт:

• Люди думают, что продукт — это приложение, фича или интерфейс.
• Но продукт — это средство доставки ценности (см. обмен ценностью в главе 1).
• Пример: у страховой компании продукт — страховка авто. Мобильное приложение для управления полисом — только часть этого value stream.
• У приложения может быть свой PM. Но он должен быть в подразделении страхования авто. Тогда стратегия и её выполнение остаются рядом.

Уровни управления:

• При росте нужно больше уровней. Но не перебарщивайте.
• Меньше слоёв и больше охвата у PM — проще поддерживать стратегию.

Кейс: продуктовая команда Marquetly

Было:

• 20 команд по компонентам. PM целый день писали user stories.
• Большинство из 20 PM по сути были associate PM, новые в роли.
• Один senior — Карен, VP of product — учила всех.
• Над платформой для преподавателей работали четыре PM. Никто не отвечал за общее видение.

Рекомендации автора:

• Перестроиться вокруг value streams.
• Сначала нанять опытного CPO. Карен — сильный VP, но портфель продуктов и общение с советом директоров ей пока не по силам.
• Карен оставить на опыте преподавателей. Найти ещё одного VP для опыта студентов.
• Нанять больше senior-людей.

Итог:

• Новая структура — первая версия. Её планировали менять, когда новый CPO уточнит видение.
• Без видения продукта нельзя построить структуру: value streams не видны.
• Людей в новой схеме меньше 20. Когда делили продукт по ценности, а не по компонентам, 20 областей просто не нашлось.

Маленькая команда как преимущество: Pandora

• Pandora — музыкальный сервис по подписке.
• Выросла до 70 млн пользователей в месяц с 40 инженерами.
• Секрет — жёсткая приоритизация работы каждый квартал.
• Это заложило основу для оценки в $7 млрд.

Вывод главы:

• PM нужен охват, чтобы влиять на целую цель, измеряемую через outcome.
• Без ясной стратегии с несколькими целями команды распыляются. Много команд оптимизируют части, но не целое.
• Как построить такую стратегию — тема следующей части книги.

Ключевые термины

Термин	Значение
value stream	Все шаги, которые нужны, чтобы доставить ценность клиенту
coverage	Желание, чтобы у каждой части продукта был владелец
component team	Команда, которая владеет техническим компонентом, например API
goal-oriented team	Команда, которая владеет целью и оценивается по outcome
retention	Удержание клиентов, пример цели для команды

Что это значит на практике

• Data-команды часто строят по компонентам: «команда Kafka», «команда хранилища», «команда BI». Риск тот же: работа ради работы над стабильной системой.
• Попробуйте организовать работу с данными вокруг value stream или цели: например, данные для retention от событий до дашборда.
• Стабильный пайплайн не требует постоянных доработок. Поставьте мониторинг и тесты в dbt и займитесь задачами под стратегию.
• Если знание о пайплайне только у одного инженера, это риск. Документация, ревью и общий код снижают его.
• Перед тем как просить новых людей, проверьте: может, задач по ценности меньше, чем кажется? Как у Marquetly и Pandora.
• Свяжите витрины с продуктами в смысле ценности. Метрики приложения — часть метрик всего продукта, а не отдельный мир.

Вопросы для самопроверки

1. Почему команда по стабильному компоненту начинает создавать лишнюю работу?
2. Что такое value stream и как организовать команду вокруг него?
3. Что дала TransferWise организация вокруг целей и какой у неё минус?
4. Почему в новой структуре Marquetly оказалось меньше 20 PM?

Предыдущая: 8. Карьера продакт-менеджера. Следующая: 10. Что такое стратегия.