Привет! Меня зовут Маша, я продакт ITSM 365 в Naumen. Более 8 лет я работаю в ИТ: начинала как бизнес‑аналитик, затем стала продуктовым аналитиком, позже — менеджером продукта. Сейчас занимаюсь Discovery — исследую новые области, где наши решения могут принести бизнесу пользу.

Маша Вострикова

менеджер продукта ITSM 365

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

Чем мы занимаемся в ITSM 365

Наш рынок — SMB (small & medium business). Это компании, которые не всегда располагают большими бюджетами, но при этом ожидают современный UX, понятный интерфейс и быстрое внедрение. Плюс ITSM 365 — облачное решение: мы регулярно выпускаем обновления, ориентируемся на рынок и держим продукт в актуальном состоянии.

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

Delivery — развитие существующих продуктов

Это наши продукты‑флагманы:

• ITSM 365.Support — автоматизация внутренней поддержки;

• ITSM 365.Outsource — автоматизация внешней поддержки.

Они давно на рынке, и по ним есть постоянный поток требований и стандартный цикл разработки.

Discovery — создание новых продуктов

Новые продукты, которые мы не так давно выпустили на рынок:

• ITSM 365.HR — автоматизация процесса подбора;

• ITSM 365.Projects — автоматизация процесса ведения проектов.

Как устроены процессы: Delivery и Discovery

Delivery: когда продукт уже существует

1. Наполнение релиза
   Собираем задачи из бэклога, требования, пожелания и гипотезы для проверки от продаж, клиентов, аналитиков.

2. Продуктовая аналитика
   На этом этапе исследуем, что имел в виду автор задачи, чего хотим достичь в результате, что есть похожее у конкурентов и главное — надо ли это реализовывать.

3. Бизнес‑аналитика по задаче
   Тут анализируем, какие конкретные проблемы пользователей привели к этой задаче, как он работает в этой ситуации, описываем полный процесс по ролям.
   На этом этапе мы не погружаемся в реализацию — важно понять, что происходит и зачем.

4. Системная аналитика
   Прорабатываем архитектуру: как встроить фичу в существующее решение и продукт.

5. Разработка фичи

6. Тестирование

7. Выкатка на прод

8. Анонс фичи и сбор ОС

Discovery: когда продукта еще нет

1. Исследование рынка
   Анализируем, в какую сторону нам двигаться, какую нишу мы можем занять.

2. Бизнес-аналитика всего процесса с нуля
   Описываем процесс и его этапы, зависимости, роли и сценарии, проблемные точки на каждом шаге.

3. Системная аналитика
   Строим архитектуру с нуля, учитывая возможные расширения на будущее.

4. Разработка продукта

5. Тестирование 

6. Анонс продукта и маркетинг
   Продакт уточняет позиционирование продукта на основе проведенного исследования и совместно с маркетингом запускает рекламные кампании.

7. Выкатка на прод

8. Продажа

9. Сбор ОС и исправление замечаний

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

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

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

Но команда выросла. У каждого появилось собственное «чувство прекрасного», свой опыт, свои представления об удобстве и логике продукта. В результате появился распространенный сценарий: аналитик продумал решение → передал задачу дальше → решение попало на тестирование → продакт увидел решение и понял, что он не согласен с итогом.

Что мы изменили в нашей работе

Мы ввели этап приемки аналитики:

• аналитик приносит продакту свое решение еще до передачи задач системному аналитику или разработчику;

• продакт смотрит на задачу с точки зрения продукта целиком — маркетинг, UX, продажи, консистентность.

Что это нам дало

• Появилось два взгляда на решение.

• Действия аналитиков и продакта согласованы.

• Продакт оценивает решение в рамках всего продукта, учитывая продажи и маркетинг.

• Продакт в курсе, как работает его продукт.

• Аналитик доволен, что он не один на один с задачей.

Кто за что отвечает

Аналитик:

• Сроки задачи и аналитика

• Оформление результата в понятном виде

• Сопровождение задачи на этапе системной аналитики и реализации

• Вопросы и перенаправление в случае необходимости к продакту

Продакт:

• Конечный результат в виде продукта

• Спорные вопросы, которые не может решить аналитик

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

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

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

Что мы изменили в нашей работе

Шаг 1. Мы создали шаблон постановки задач

Вместе с продактом сформировали шаблон, который стал ориентиром.

Что включили в шаблон:

• Контекст задачи
  Откуда она взялась, какие проблемы есть, что мы знаем о задаче.

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

• Образ результата
  Что именно должно быть описано: процесс и его бизнес-ценность, роли и их действия.

Шаблон стандартизировал работу аналитиков и сделал ожидания прозрачными.

Шаг 2. Ввели роль куратора аналитики

Мы внедрили куратора — старшего специалиста, который помогает аналитику с конкретной бизнес-аналитикой:

• обсуждает контрольные точки;

• отвечает на вопросы;

• проверяет логику решений;

• предупреждает типичные ошибки;

• помогает оформить результат.

Куратор — это поддержка, а не «второй аналитик, который делает все сам». Роль плавающая — ее можно распределять между специалистами.

Что это нам дало

• Шаблон, который описывает образ результата аналитики.

• Продакт получает более качественные и продуманные решения.

• Более быстрое обучение младших сотрудников благодаря роли куратора.

• Аналитика не затягивается.

Кто за что отвечает

Аналитик:

• Сроки задачи и аналитика

• Оформление результата в понятном виде

• Сопровождение задачи на этапе системной аналитики и реализации

• Вопросы и перенаправление в случае необходимости к продакту

Куратор:

• Спорные вопросы, которые не может решить аналитик

• Подсказки, на что важно обратить внимание и какие есть особенности

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

Этот кейс — самый объемный и болезненный, потому что связан с созданием нового HR‑продукта. Мы впервые за долгое время заходили в совершенно новую область. Я как продакт знала об этой сфере немного. А еще никогда раньше этим составом команды мы не делали продукт с нуля.

Ошибка 1. Недооценили сложность предметной области

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

• в реальности много скрытых этапов;

• масса нюансов влияет на сценарии.

Ошибка 2. Подключили junior-аналитика

Мы рассчитывали, что сможем дать весь контекст и параллельно обучать. Но в Discovery у продакта нет такой возможности:

• огромный объем задач;

• высокая неопределенность;

• ошибок слишком много;

• нужна самостоятельность.

Пришлось признать, что в Discovery нужны middle+ аналитики.

Ошибка 3. Не договорились о контрольных точках

Когда подключили middle‑аналитика, возникла другая проблема: аналитик «утонул» в новой области и не возвращался с новостями, а продакт не понимал, в каком состоянии находится задача.

Как мы решили проблему

Мы начали встречаться регулярно и работать над аналитикой в паре.

Продакт приносил:

• контекст области;

• результаты исследования рынка;

• ограничения и риски;

• конкурентов;

• принципы позиционирования будущего продукта.

Аналитик приносил:

• структуру процессов;

• выделение ролей;

• формализацию этапов;

• выявление проблем и узких мест;

• формирование требований.

Как мы структурировали бизнес-аналитику процесса

1. Разбиваем на этапы.

2. Выделяем роли.

3. Описываем каждый этап и участие ролей в них.

4. Выделяем на этапах проблемы, которые мы потом будем закрывать.

5. Определяем, что должно быть на входе в этап и на выходе.

6. Продумываем, какие должны быть оповещения и для кого.

Что мы получили

• Быстро собрали огромный объем аналитики.

• Количество уточняющих вопросов сократилось.

• Архитектор и системный аналитик сразу увидели структуру процессов.

• Middle-аналитик вырос в эксперта.

Кто за что отвечает

Аналитик:

• Сроки задачи и аналитика

• Оформление результата в понятном виде

• Сопровождение задачи на этапе системной аналитики и реализации

• Вопросы и перенаправление в случае необходимости к продакту

Продакт:

• Конечный результат в виде продукта

• Спорные вопросы, которые не может решить аналитик

О чем важно помнить

1. Ответственный за задачу все-таки аналитик.

2. Продакт отвечает за глобальный результат и помогает аналитику в его задаче.

3. Курирование аналитики можно распределять — это не обязанность продакта.

Мы продолжаем развивать подходы к Delivery и Discovery. Каждый из трех кейсов помог нам увидеть ограничения, перестроить работу и сделать процесс более предсказуемым. Надеюсь, наши выводы будут полезны и вашей команде :)