Привет! Меня зовут Диана Анфёрова, я лид аналитиков и системный аналитик в Контур.Толке. 

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

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

Я оцениваю работу не только по качеству постановки, но и по качеству работы с задачей. Смотрю: удалось ли разобраться в проблеме, выбрать оправданное решение, синхронизировать команду и получить результат для бизнеса.

В статье делюсь своими критериями качества работы аналитика и на реальных задачах показываю, как проносить не только постановки, но и результаты. И быть ценнее для компании.

4 критерия, что аналитик поработал хорошо

1. Раскопал суть проблемы. Аналитику важно понять, какая есть проблема, кому мешает, почему она важна и какую ценность даст её решение. 

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

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

3. Синхронизировал команду по цели и способу реализации. 

💼 Стейкхолдеры знают, какую ценность получат пользователи и когда можно ожидать результат.

🤓 Руководитель разработки видит объём работ, ограничения, варианты реализации — и может спланировать работу команды. 

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

🤝 Тестировщики не тратят время на то, чтобы раскопать, как решение должно работать: у них есть постановка и понятные критерии, на которые можно опереться.

4. Помог получить бизнес-результат. 

Всё перечисленное должно в итоге привести к эффекту, ради которого запускали работу.

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

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

Контекст: что такое Толк и с чего начинались доски 

⚫ Контур.Толк — российская платформа для рабочих коммуникаций. В одном пространстве пользователи проводят видеовстречи, вебинары и трансляции, общаются в чатах, управляют переговорными комнатами и работают с интерактивными досками.

🔵 Виртуальные доски — это бесконечный холст, на котором участники встречи работают вместе: собирают идеи на стикерах, рисуют схемы, голосуют, фиксируют договорённости.

Когда я пришла в команду Толка, виртуальных досок в продукте ещё не было. И почти сразу мне досталась задача добавить в сервис такую фичу. 

На рынке уже были решения вроде Miro, но наша задача не сводилась к тому, чтобы повторить их набор инструментов. Толк задумывался как единое рабочее пространство: участники должны были иметь возможность обсудить вопрос на встрече, зафиксировать результат и продолжить работу, не переключаясь между сервисами.

Так что ↓

Я начала не с выбора решения, а с исследования проблемы. На этом этапе мне нужно было ответить на два вопроса:

❓Какую пользовательскую проблему мы решаем? Какая у нас бизнес-мотивация?

❓Насколько эта проблема значима: у каких пользователей она возникает, в каких сценариях, как часто и насколько мешает им достигать цели?

Пока на эти вопросы нет ответов, обсуждать состав будущей функциональности рано.

Данные о пользователях можно собирать из разных источников, и я обычно заглядываю во все.

Собираем данные и определяем реальные проблемы пользователей

Проходимся по всем источникам данных.

Интервью дают возможность услышать реальных пользователей. В нашей истории всё проходило в несколько этапов. 

Сначала продакт исследовал рынок. 

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

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

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

Дальше были встречи. Я участвовала в интервью, уточняла сценарии, если казалось, что где-то внутри спряталась та самая корневая проблема. Помогала исследователю отвечать на вопросы респондентов по продукту.

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

Это позволяло отделить запрос на конкретную функцию от потребности, которую пользователь пытался закрыть, и понять, что стоит исследовать или прорабатывать дальше. 

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

Пользователи чаще приносят решение: «сделайте кнопку», «добавьте инструмент». Моя работа — вернуться на шаг назад, восстановить сценарий и понять, какую потребность пользователь пытается закрыть.

Продуктовые метрики позволяют оценить масштаб проблемы.

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

Реальные кейсы использования могут помочь понять, как часто пользователи «обходят» проблемы. Например, в данных по виртуальным доскам мы увидели, что пользователи часто применяют карандаш и ластик в одной сессии. 

Посмотрели на реальные сценарии и предположили, что часть пользователей обводит или подчёркивает объект, чтобы временно обратить на него внимание участников встречи, а затем стирает отметку. То есть использует карандаш как указку.

Так появилась идея лазерной указки — отдельного инструмента, который позволяет спикеру выделить нужную область доски, не добавляя на неё лишние объекты.

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

Обобщаем данные и формируем состав MVP

После интервью и погружения во все источники мы обобщили наблюдения и выделили проблемы, которые должна была закрыть первая версия досок:

— Идеи, которые озвучивались на встрече, теряются. Особенно если никто не записывал встречу. 

— Без визуализации участники могут по-разному понимать предмет обсуждения.

— Вовлечь всех в обсуждение сложно, часть людей просто молчит.

— Встреча заканчивается без артефактов и следующих шагов.

— Компания платит за два сервиса сразу — платформу для встреч и внешнюю доску, — а люди переключаются между ними посреди разговора.

Все эти проблемы и легли в основу MVP.

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

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

Так что перед проработкой решения нужно было ответить на вопросы:

❓ Когда пользователь может открыть доску: до встречи, во время неё или после.

❓ Как реализовать сквозную аутентификацию между досками и Толком, чтобы участнику не приходилось входить в доску отдельно.

❓ Как связать между собой доску, комнату и встречу. 

❓ Как доска отображается в интерфейсе Толка и какие действия с ней доступны администратору.

Прорабатываем постановку так, чтобы у команды было как можно меньше вопросов

После согласования MVP я стала собирать ту самую постановку. 

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

Эту часть я прорабатывала вместе с разработчиком и дизайнером. Собирала ограничения, проверяла текущее поведение системы, фиксировала пограничные случаи и помогала выбрать правила, которые не придётся пересматривать после каждой следующей доработки.

После релиза следим за метриками и находим новые идеи доработок

Конечно, после релиза ничего не заканчивается. Мы смотрим, как люди на самом деле пользуются тем, что мы сделали, и ищем места для улучшений.

Проверяю эффект после релиза. Я собираю и поддерживаю дашборды по доскам: смотрю, как ведёт себя аудитория, что меняется после каждого релиза. 

Если изменение затрагивает существующий сценарий или есть риск ухудшить ключевую метрику, мы с продактом запускаем A/B-тест. Он помогает сравнить варианты решения, оценить их влияние на целевую метрику и убедиться, что новая механика не ухудшает важные показатели.

Запрашиваем обратную связь через встроенные вопросы. Спрашиваем не «Что вы думаете о продукте?» в общем, а задаём вопрос в момент, когда человек сталкивается с затруднением или прерывает сценарий.

Например, так мы нашли потребность пользователей импортировать доски из ещё одного сервиса.

И встроили фичу. Так что сейчас в Толк можно интегрировать доски из сервисов Miro и Holst ↓

Что в итоге: доски начинались как задача внутри Контур.Толка, а потом выросли в самостоятельное продуктовое направление

Сейчас доски продаются как модификатор к Толку — усиливают ценность продукта как единой платформы для рабочих коммуникаций: встреча, совместная работа и её результат остаются в одном сервисе.

⭐ С момента запуска показатель MAU у досок вырос более чем в 13 раз.

⭐ А каждая значимая новая функция сейчас даёт прирост месячной аудитории примерно на 5%. 

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

6 шагов, которые помогают аналитику влиять на бизнес-результат 

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

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

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

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

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

Считайте технические ограничения частью решения. В сложной функциональности нельзя сначала придумать «что сделать», а затем передать разработчикам вопрос «как это реализовать». 

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

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

Системные аналитики, а как вы понимаете, что хорошо поработали?