Продакт × аналитик: три кейса коллаборации

Кратко

Продакт и аналитик чаще всего сталкиваются в одной задаче на этапе бизнес-аналитики — там, где описывается процесс по ролям, фиксируются проблемы пользователей и формируется требование до того, как в дело вступит системная аналитика. Именно здесь работа чаще всего превращается в хаос: аналитик уходит в решение без согласования, продакт видит результат уже на тестировании, junior тонет в новой предметной области. Эта заметка — decision-log по трём кейсам из практики команды ITSM 365 (Naumen), где каждый кейс заставил перестроить процесс и зафиксировать ответственность сторон.

Где пересекаются продакт и аналитик

В продукте с устоявшимся циклом (Delivery) аналитик заходит в задачу после продуктового анализа — когда уже понятно, что вообще делаем и зачем. Его зона — бизнес-аналитика по конкретному процессу: какие проблемы пользователей привели к задаче, как они работают сейчас, как выглядит полный процесс по ролям. В новый продукт (Discovery) аналитик заходит ещё раньше — ему нужно описать процесс с нуля, собрать роли, этапы, проблемные точки и ограничения.

На обоих дорожках точка максимального пересечения с продактом — это этап бизнес-аналитики. Дальше аналитик передаёт результат системному аналитику или разработчику, и стоимость правок резко возрастает. Если продакт не вмешался на этом этапе — правка приедет на тестировании, и кому-то придётся переделывать.

Три кейса ниже — это три разных способа, как эта точка пересечения может сломаться, и что мы сделали, чтобы она работала.

Кейс 1. Приёмка аналитики: продакт видит решение слишком поздно

Задача. Delivery по флагманскому продукту. Аналитик получает задачу на доработку отдельного процесса — например, какие колонки показывать пользователю в списках. Пока команда была небольшой, действовал принцип «кто делал аналитику, тот и реализовывал» — взгляды на продукт были схожими, ошибок мало.

Когда команда выросла, у каждого аналитика появилось своё «чувство прекрасного» и свой опыт. Распространённый сценарий: аналитик продумал решение → передал задачу дальше → решение попало на тестирование → продакт увидел результат и понял, что он не согласен. Колонки, которые аналитик оставил почти все («важны для пользователя»), продакт сократил — чтобы избежать горизонтального скролла и визуального перегруза, учитывая UX, первое впечатление и маркетинг. Но это стало ясно слишком поздно.

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

Что дало бизнесу.

• Два взгляда на решение до того, как оно стоит денег в разработке.
• Действия аналитика и продакта согласованы — нет внезапных правок на тестировании.
• Продакт в курсе того, как работает его продукт на уровне деталей.
• Аналитик не один на один с задачей — есть точка эскалации спорных решений.

Кто за что отвечает. Аналитик — сроки задачи, оформление результата, сопровождение на этапе системной аналитики и реализации, вопросы и перенаправление к продакту. Продакт — конечный результат в виде продукта и спорные вопросы, которые не может решить аналитик.

Главная мысль кейса: стоимость правки растёт нелинейно по мере движения задачи по пайплайну. Приёмка аналитики — это дешёвый контроль дорогой ошибки.

Кейс 2. Курирование аналитики: продакт как узкое горлышко

Задача. Снова Delivery, но теперь важен масштаб. Продакт флагманского продукта совмещает несколько ролей: тимлид команды аналитиков, куратор, организатор мероприятий. Приёмка всех аналитических задач была сосредоточена на нём одном. Накапливалась очередь, решения приходили сырыми или с большим количеством вопросов, единого шаблона аналитики не было, а сроки аналитических задач начали влиять на сроки релизов.

Как аналитик вмешался. Сделали два шага.

Шаг 1 — шаблон постановки задач. Вместе с продактом сформировали шаблон, который стал ориентиром для всех аналитиков. В шаблон вошли: контекст задачи (откуда взялась, какие проблемы, что знаем), ход работы (что изучить, каких конкурентов проанализировать, какие ограничения учесть, с кем взаимодействовать, как оформить результат) и образ результата (что именно должно быть описано — процесс, его бизнес-ценность, роли и их действия). Шаблон сделал ожидания прозрачными и убрал «а что ты имел в виду» на приёмке.

Шаг 2 — роль куратора аналитики. Внедрили старшего специалиста, который помогает аналитику с конкретной бизнес-аналитикой: обсуждает контрольные точки, отвечает на вопросы, проверяет логику решений, предупреждает типовые ошибки, помогает оформить результат. Куратор — это поддержка, а не «второй аналитик, который делает всё сам». Роль плавающая, её можно распределять между специалистами.

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

Что дало бизнесу.

• Шаблон, который описывает образ результата аналитики — ожидания сторон перестали расходиться.
• Продакт получает более качественные и продуманные решения, очередь на приёмку перестала быть узким горлышком.
• Более быстрое обучение младших сотрудников — куратор передаёт контекст, а не оставляет junior тонуть.
• Аналитика не затягивается, сроки релизов перестали зависеть от одного человека.

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

Главная мысль кейса: концентрация приёмки на одном человеке — это архитектурная уязвимость процесса. Шаблон и куратор разгружают продакта без потери качества.

Кейс 3. Создание нового продукта: почему понимания ценности недостаточно

Задача. Самый объёмный и болезненный кейс — создание нового HR-продукта с нуля (Discovery). Команда впервые за долгое время заходила в совершенно новую область. Продакт знала об этой сфере немного, и этим составом команды продукт с нуля раньше не делали.

Как аналитик вмешался — и где проиграл. Сначала сделали три ошибки подряд.

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

Ошибка 2 — подключили junior-аналитика. Рассчитывали дать весь контекст и параллельно обучать. В Discovery у продакта нет такой возможности: огромный объём задач, высокая неопределённость, ошибок слишком много, нужна самостоятельность. Пришлось признать, что в Discovery нужны middle+ аналитики.

Ошибка 3 — не договорились о контрольных точках. Когда подключили middle-аналитика, он «утонул» в новой области и не возвращался с новостями. Продакт не понимал, в каком состоянии находится задача.

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

Структурировали бизнес-аналитику процесса так: разбили на этапы → выделили роли → описали каждый этап и участие ролей → выделили проблемы, которые потом будем закрывать → определили, что должно быть на входе в этап и на выходе → продумали оповещения и для кого.

Что дало бизнесу.

• Быстро собрали огромный объём аналитики — тот, который раньше тонул в уточняющих вопросах.
• Количество уточняющих вопросов сократилось — контекст перестал теряться.
• Архитектор и системный аналитик сразу увидели структуру процессов — им не приходилось собирать требования по кускам.
• Middle-аналитик вырос в эксперта по предметной области.

Кто за что отвечает. Аналитик — сроки, оформление, сопровождение, вопросы и перенаправление. Продакт — конечный результат и спорные вопросы.

Главная мысль кейса: в Discovery ценность продукта понятна продакту, но без структурной бизнес-аналитики она не превращается в требование. Junior в этом месте не справляется, а middle без контрольных точек теряется.

Паттерны успешной коллаборации

По трём кейсам складывается несколько паттернов, которые стоит фиксировать как рабочие правила.

Приёмка до передачи. Аналитик показывает решение продакту до того, как оно ушло в системную аналитику или разработку. Это не согласование каждой колонки — это проверка, что решение не противоречит продукту целиком. Стоимость такой проверки — час продакта; стоимость правки на тестировании — дни команды.

Шаблон как контракт ожиданий. Шаблон постановки задачи делает явным то, что иначе выясняется на приёмке: какой контекст нужен, что изучить, как выглядит готовый результат. Без шаблона каждый аналитик делает «как понял», а продакт каждый раз перенаправляет. С шаблоном ожидания сторон сходятся до начала работы.

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

Регулярные контрольные точки в Discovery. В новой предметной области аналитик не может работать автономно неделями — он теряет контекст. Регулярные парные сессии с продактом (контекст рынка + структура процесса) — единственный способ удержать направление. Без них аналитик либо тонет, либо уходит не туда.

Разделение ответственности по ролям, а не по задачам. Во всех трёх кейсах ответственность зафиксирована так: аналитик отвечает за задачу (сроки, оформление, сопровождение), продакт — за продукт (глобальный результат, спорные решения). Куратор — за поддержку аналитика. Это снимает размытие «кто за что отвечает», которое и было причиной хаоса.

Где аналитик обычно проигрывает

Разберём типичные провалы, которые видно по всем трём кейсам.

Аналитик уходит в решение без проверки ценности. В кейсе 1 аналитик решает «колонки важны — оставлю все», не учитывая UX и маркетинг. Это не ошибка аналитика — это отсутствие точки сверки с продактом. Без приёмки аналитик оптимизирует локально, а не в рамках продукта.

Junior в Discovery — это не экономия, а потеря времени. В кейсе 2 и кейсе 3 видно одно и то же: в условиях неопределённости junior требует постоянного контекста, который продакт не успевает давать. В итоге страдают и junior, и продукт. Middle+ в Discovery — это не каприз, а ограничение предметной области.

Молчание аналитика в новой области. В кейсе 3 middle-аналитик «утонул» и не возвращался с новостями. Это не проблема коммуникации — это проблема отсутствия контрольных точек. Без явных чекпойнтов аналитик в новой области будет молчать до тех пор, пока не станет поздно.

Концентрация приёмки на одном человеке. В кейсе 2 продакт стал узким горлышком, потому что вся приёмка шла через него. Это архитектурная проблема процесса, а не проблема продакта. Шаблон и куратор решают её структурно.

Как ставить рабочие отношения с продактом

Из трёх кейсов вытаскивается практический рецепт — что зафиксировать с продактом в первый день работы над задачей.

Согласуйте образ результата до начала. Что именно аналитик должен принести: процесс по ролям, схему этапов, описание проблем и узких мест, требования. Без этого «готовая аналитика» для аналитика и для продакта — разные документы.

Договоритесь о точках сверки. Одна приёмка в конце — мало. В Delivery — приёмка до передачи в системную аналитику. В Discovery — регулярные парные сессии. Точки сверки — это не микроменеджмент, это страховка от ухода не туда.

Зафиксируйте, какие вопросы решает аналитик сам, а какие эскалируются. Не каждый выбор колонки — это решение продакта. Типовые решения аналитик принимает сам, спорные — эскалирует куратору или продакту. Граница должна быть явной, иначе аналитик либо парализован, либо берёт на себя чужие решения.

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

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

Выводы

• Приёмка аналитики — обязательный этап. Аналитик показывает решение продакту до передачи в системную аналитику. Стоимость часа продакта на приёмке — ничтожна по сравнению со стоимостью правки на тестировании.
• Шаблон постановки задачи — контракт ожиданий. Без шаблона каждый аналитик делает «как понял»; с шаблоном — ожидания сторон сходятся до начала работы. Контекст, ход работы, образ результата — три обязательных блока.
• Куратор разгружает продакта без потери качества. Роль плавающая, её распределяют между старшими специалистами. До продакта доходят только спорные решения, реально влияющие на продукт.
• В Discovery нужен middle+, не junior. Высокая неопределённость и большой объём задач требуют самостоятельности. Junior в этих условиях — потеря времени и для аналитика, и для продукта.
• Контрольные точки в новой области — не опция, а необходимость. Регулярные парные сессии с продактом — единственный способ удержать направление и не дать аналитику «утонуть» в предметной области.
• Ответственность зафиксирована по ролям, а не по задачам. Аналитик отвечает за задачу, продакт — за продукт, куратор — за поддержку. Размытие ответственности — причина хаоса в коллаборации.