'/%3e%3cpath%20d='M83.8172%20112C100.688%20112%20111.886%2098.2694%20112%2083.8882H44.0245C25.8409%2083.8882%2016.001%2094.3169%2016.001%20112H83.8172Z'%20fill='url(%23paint1_linear_101_577)'/%3e%3cpath%20d='M44.1725%2044.1138H16.0008C15.9465%2051.0963%2018.504%2058.2306%2024.2977%2064.0225L44.1706%2083.8881L52.8986%2075.3569L61.7636%2066.7019C63.2767%2065.2244%2063.2786%2062.7888%2061.7636%2061.3094L44.1725%2044.1138Z'%20fill='%233A5FFF'/%3e%3cpath%20d='M83.8248%2083.8862H111.996C112.051%2076.9037%20109.493%2069.7693%20103.7%2063.9774L83.8267%2044.1118L75.0986%2052.6431L66.2337%2061.2981C64.7206%2062.7756%2064.7187%2065.2112%2066.2337%2066.6906L83.8248%2083.8862Z'%20fill='%233A5FFF'/%3e%3cdefs%3e%3clinearGradient%20id='paint0_linear_101_577'%20x1='16.001'%20y1='30.055'%20x2='111.998'%20y2='30.055'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2370ADFE'/%3e%3cstop%20offset='0.62'%20stop-color='%233A5FFF'/%3e%3c/linearGradient%3e%3clinearGradient%20id='paint1_linear_101_577'%20x1='111.998'%20y1='97.9451'%20x2='16.001'%20y2='97.9451'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2370ADFE'/%3e%3cstop%20offset='0.62'%20stop-color='%233A5FFF'/%3e%3c/linearGradient%3e%3c/defs%3e%3c/svg%3e)
Что такое продуктовый подход
Команда, работающая по Scrum или Kanban, выпускает быстро и предсказуемо. Список того, что выпускать, при этом обычно приходит извне: от заказчика, от руководства, из головы основателя. Ошибка в этом списке стоит дороже любой ошибки в процессе — можно безупречно построить то, чем никто не пользуется.
Продуктовый подход добавляет к разработке второй поток работы: открытие. В нём выясняют, какая задача у пользователя не решена, придумывают варианты и проверяют их дёшево, до того как писать код.
Оба потока идут одновременно и в одной команде. Пока разработка занимается проверенным, открытие готовит следующее: интервью, прототипы, эксперименты. Разделение на «сначала всё исследуем, потом всё построим» возвращает водопад под другим названием.
Основной инструмент открытия — разговор с людьми, которые уже сталкиваются с задачей. Тут есть техника: спрашивают о прошлом поведении, а не о будущих намерениях. «Как вы решали это в последний раз» даёт факты, «стали бы вы пользоваться» — вежливость.
Проверка формулируется как гипотеза с числом. «Мы думаем, что напоминание за день до срока снизит долю просрочек с двадцати процентов до двенадцати; проверим на трёх сотнях задач за две недели». Такую формулировку можно опровергнуть, и в этом её ценность.
Приоритеты в продуктовом бэклоге считают по нескольким осям: охват, влияние, уверенность, трудоёмкость. Способы счёта дают общий язык для сравнения, а окончательное решение всё равно принимает человек, отвечающий за продукт.
- Команда влияет на состав продукта, а не только на способ его сделать
- Есть возможность поговорить с пользователями и посмотреть, как они работают
- Собираются данные о поведении: воронки, удержание, частота использования
- Руководство готово слышать «проверили и отказались» как результат
- Содержание зафиксировано договором и меняться не может
- Доступа к пользователям нет и не будет: работаете через посредника
- Единственный критерий — уложиться в срок с заранее известным списком
- Отрицательный результат проверки считается провалом команды
Что появляется в работе
Документов мало и все короткие. Их задача — не дать команде забыть, что именно проверяли и почему решили так.
Карта задач пользователя
Что человек пытается сделать, какими путями решает это сегодня и где ему больно. Строится по интервью и наблюдениям.
Список гипотез
Каждая с ожидаемым результатом в числах, способом проверки и стоимостью этой проверки. Упорядочен по соотношению риска и цены.
Журнал проверок
Что проверяли, каким способом, что получилось и какое решение приняли. Через полгода отвечает на вопрос, почему отказались от идеи, которую снова предлагают.
Продуктовый бэклог
Упорядоченный список того, что делаем дальше, с оценкой по согласованным осям. Один на продукт, с одним владельцем приоритетов.
| СОБЫТИЕ | ЧАСТОТА И ДЛИТЕЛЬНОСТЬ | УЧАСТНИКИ | ЧЕМ ЗАКАНЧИВАЕТСЯ |
|---|---|---|---|
| Разговор с пользователем | 30–45 мин, 3–5 в неделю | владелец продукта и участник команды | факты о прошлом поведении |
| Разбор находок | 1 ч еженедельно | команда открытия | обновлённая карта задач и новые гипотезы |
| Обзор проверок | 1 ч раз в две недели | команда и заинтересованные стороны | решения: строим, дорабатываем, отказываемся |
| Пересмотр приоритетов | 1–2 ч ежемесячно | владелец продукта и команда | порядок бэклога на ближайший период |
С чего начать
Начинают с разговоров, а не с фреймворка приоритизации. Считать по формуле нечего, пока неизвестно, какие задачи у пользователей вообще есть.
- 1Поговорите с пятью пользователямиСпрашивайте о том, как они решали задачу в последний раз. Пяти разговоров хватает, чтобы увидеть повторяющиеся сюжеты; после десяти новое появляется редко.первые две недели
- 2Соберите карту задачЧто человек пытается сделать, чем пользуется сейчас, где теряет время. Карта на один лист, обновляется после каждой серии разговоров.первый месяц
- 3Сформулируйте три гипотезы с числамиОжидаемый результат, способ проверки, стоимость проверки. Гипотеза без числа проверке не поддаётся и превращается в мнение.первый месяц
- 4Проверьте самую дешёвуюПрототип, ручная имитация функции, письмо с предложением, страница с описанием. Разработка на этом шаге чаще всего избыточна.второй месяц
- 5Договоритесь, как считаете результатМетрика и порог до начала проверки. Иначе после эксперимента всегда найдётся объяснение, почему цифры на самом деле хорошие.второй месяц
- 6Заведите ритмРазговоры еженедельно, обзор проверок раз в две недели, пересмотр приоритетов раз в месяц. Открытие живёт расписанием.постоянно
Что считать
Где обычно ломается
Спрашивают о будущем
Минимальный продукт превращают в урезанный
Метрику выбирают после эксперимента
Открытие делают отдельным этапом
Формулу приоритизации считают решением
Отказ считают провалом
Темы про продукт
Как вести продукт в Shtab
Заведите отдельный список под гипотезы со своими статусами — «сформулирована», «проверяем», «решение принято». Тогда видно, сколько проверок идёт одновременно и что с ними стало.
- 01Отдельный список гипотез с собственными статусами показывает поток проверок целиком.
- 02Пользовательские поля хранят ожидаемый результат, метрику и порог — то, что нельзя менять после старта.
- 03Оценка по осям приоритизации живёт полями карточки, и бэклог сортируется по ним без выгрузок.
- 04Журнал проверок удобно держать страницей: решения и причины остаются в истории.
- 05Цели связывают проверенные гипотезы с квартальным результатом продукта.
- 06Заметки после разговоров с пользователями складываются в тот же проект и находятся поиском.
Частые вопросы
Предметом. Scrum отвечает на вопрос, как команда организует работу: цикл, роли, события. Продуктовый подход отвечает на вопрос, что именно попадёт в этот цикл, и добавляет к разработке второй поток — открытие. Они не заменяют друг друга: команда обычно работает по Scrum или Kanban и параллельно ведёт открытие.