Добро пожаловать в хаос
Вы только что заняли позицию Head of Product. Поздравляю — и добро пожаловать в хаос. На этом этапе сложно понять, с чего начать: стратегия, команда, стейкхолдеры, процессы. Эта статья — попытка дать структуру первым шагам и помочь превратить хаос в порядок.
Я работаю с B2B/B2G-продуктами, поэтому многое из описанного будет актуально в первую очередь для этих сегментов. Но многие принципы универсальны и применимы в любой продуктовой среде.
Когда в компании появляется запрос на найм Head of Product, это обычно означает, что назрела необходимость в тюнинге процессов и команды. Типичный набор вопросов от стейкхолдеров в таких ситуациях:
Я не понимаю, насколько эффективно работает команда.
Как формируется бэклог? Почему мы делаем именно это?
К моменту релиза фичей становится меньше или они выглядят иначе.
Продукт развивается медленно. Может, пора в OKR?
Если вы слышите подобные сигналы — пора разбираться в процессах. И да, стратегия немного подождёт. Начинать стоит с тактики.
В зоне внимания — два ключевых процесса:
Управление требованиями — как идеи, проблемы и ожидания превращаются в функции продукта и задачи для команды.
Управление релизами — как результаты доходят до пользователя.
Когда эти процессы не выстроены, они съедают 85–90% времени команды. Стратегия? Не, не слышали.
Под «процессом» я понимаю последовательность действий, роли и артефакты. Центр внимания — именно артефакты, которыми обмениваются участники. Это ключевой результат деятельности каждого члена команды.
Ниже — мой подход к диагностике и формированию плана изменений.
Этап 1. Диагностика внешнего контура
Цель: понять, как устроен контекст вокруг продукта, кто влияет на него и какие артефакты циркулируют между функциями.
Методы: интервью, анализ коммуникаций, работа с документами.
Вопросы для анализа:
Структура компании:
Какие отделы и команды есть?
Кто кому подчиняется?
Как устроены взаимодействия?
Стейкхолдеры продукта:
Кто участвует в создании и развитии?
Руководители, бизнес-заказчики, продажи, поддержка, внедрение, аналитики, разработка, маркетинг и др.
Работа с артефактами:
Какие документы и материалы создаются и потребляются?
Есть ли доступ к roadmap? Как происходит информирование о релизах?
Подробные блоки для уточнения:
Продажи:
Как устроена воронка?
Какие материалы и демо используются?
В какой момент нужен продакт?
Проводится ли win/loss анализ?
Как передаются инсайты от клиентов?
Маркетинг:
Как представлен продукт?
Кто формирует ценностные предложения?
Как измеряется воронка вовлечения?
Как собирается и обрабатывается обратная связь?
Поддержка / внедрение / консалтинг:
Как обучаются пользователи?
Как баги и фидбэк возвращаются в продукт?
Как происходит информирование о релизах?
Релиз:
Как устроен выпуск?
Какие метрики используются (лид-тайм, объём инкремента и др.)?
Как управляются риски?
Как устроено кросс-функциональное взаимодействие?
Итог: карта заинтересованных сторон, список слепых зон и пробелов в коммуникации.
Этап 2. Диагностика продуктовой команды
Цель: понять реальные процессы, зоны ответственности и точки принятия решений.
Методы: интервью, time-tracking, анализ артефактов.
Упражнение: базовый time-tracking
В течение 1–2 недель каждый продакт записывает задачи, которые занимают больше 10 минут. Это даёт командное "прозрение" — куда уходит время на самом деле.
Вопросы для команды:
Процессы и ритм:
Какие регулярные встречи? Цель каждой?
Какие артефакты используются?
Как принимаются решения — что делаем, а что нет?
Артефакты:
Что такое "хорошо оформленная задача"?
Как наполняется и приоритизируется backlog?
Есть ли roadmap? На какой период?
Роли:
Кто отвечает за приоритизацию?
Как задачи попадают в релиз?
Кто проверяет результат?
Какие зоны ответственности "висят в воздухе"?
Проблемные зоны:
Где теряется информация?
Какие договорённости забываются?
Что вызывает фрустрации?
Итог: честная картина процессов, список "живых" и мёртвых артефактов, зоны напряжения.
Визуализация проблемных зон
Далее я строю визуальную схему процесса управления требованиями в текущем виде (as-is):
Жизненный цикл требования:
Initiation — входящий запрос или потребность.
Discovery — формализация идеи или гипотезы.
Research & Design — пользовательский сценарий, дизайн.
Ready-to-Go — финализация требований.
Development — реализация.
Test — проверка.
Launch — выпуск и коммуникация.
Learn — сбор обратной связи и оценка.
На схеме отмечаются "красные зоны": узкие места, разрывы, зоны с неясной ответственностью. Проблемам присваиваются приоритеты по влиянию и сложности устранения.
Иногда использую инструмент "дерево текущей реальности" (TOC) — чтобы выявить корневые причины.
RACI-матрица (пример)
Артефакт | PM | BA | UX | Dev | QA | Stakeholder |
|---|---|---|---|---|---|---|
Запрос (требование) | A | R | C | |||
Продуктовый бэклог | R | A | I | |||
Гипотеза с приоритетом | R | C | A | |||
Результаты экспериментов | R | C | C | I | ||
User Story с приоритетом | R | A | C | C | I | |
Бэклог релиза | R | A | I | |||
UX-ресерч | C | C | A | I | ||
UI-макеты | C | A | I | |||
Бизнес-требования | C | A | I | |||
Системные требования | A | C | C | C | I | |
Декомпозированные задачи | R | A | I | |||
Тест-кейсы | A | I | ||||
Метрики влияния на цели | A | R | C | C | ||
Метрики успеха внедрения | A | R | C | |||
Разработанная фича | A | C | I | |||
Release Notes | R | C | C | I | ||
Документация | A | C | C | I | ||
Релиз на рынок | A | R | C | R | C | I |
Выводы по релизу | A | R | C | C | C | I |
Реализованный запрос | A | R | C | C | I | |
План действий | A | R | C | C | I |
Расшифровка аббревиатуры RACI:
R (responsible) — исполнитель задач. Тот, кто самостоятельно выполняет все работы в рамках задачи.
A (accountable) — ответственный за всю задачу. Участник с этой ролью несёт ответственность за то, чтобы задачу завершили в срок, но не обязательно выполняет её сам.
C (consult) — эксперт, который консультирует команду по вопросам, находящимся в его компетенции.
I (informed) — участник проекта, который должен быть в курсе выполнения задачи. Результат задачи или всего проекта влияет на дальнейшую деятельность I-участников.
Финал
Осталось отрисовать схему процессов управления требованием и релиза в формате "как есть". На схеме обозначить красные зоны, которые выявлены на предыдущих стадиях. Все ли необходимые артефакты существуют? Как организован обмен? Есть ли лишние или неучтённые зоны?
Диагностика выполнена. Следующий этап — проектирование изменений.
Но об этом — в следующей статье. Буду рада содержательным комментариям и обмену опытом.
