Почему мой заказчик мудак?

Если вы хотя бы раз задавались таким вопросом, потому что проделали работу в стол или в последний момент вам вносят большие правки, то поздравляю, вы скоро поймёте в чём дело!

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

Тема сейчас очень слабо раскрывается и на практике вижу, что 80%+ аналитиков сталкиваются с проблемами в сборе требований.

Это первый пост из серии по созданию дата-продуктов.

Текущая обстановка

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

Самый слабый вариант

— <Лучший работник на свете>, добавь график GMV!
— Хорошо, возьму в спринт.

Здесь аналитик просто берёт и делает то, что ему говорят. Неловкость тут в том, что он даже не знает, а куда добавлять GMV и что это за метрика вообще.

Ну ладно, мы не в детском саду и представим, что такого не бывает (бывает)! Едем дальше.

SMART

Чуть более просвещённые говорят: я абы какую задачу брать не буду!

Пусть она будет поставлена по SMART и будет конкретной, измеримой и достижимой.

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

Постановка задачи в таком случае выглядит так:
— <Лучший работник на свете>, добавь график GMV на дашборд с ключевыми метриками за прошлый месяц там должно получиться <NDA>, данные тебе даст <лучший инженер на свете>, сделай задачу до 1 июля.
— Хорошо, возьму в спринт!

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

Dashboard Canvas

В мире BI и разработки отчётности есть святой грааль, серебренная пуля, которая по мнению аналитиков может решить все проблемы с пониманием задачи. Dashboard Canvas (Канвас) от Ромы Бунина.

Посмотрим на пример заполненного шаблона:

Это реально следующий уровень:

1. Есть информация разных заказчиках и их контексте и задачах.
2. Аналитик сам предлагает визуализации под вопросы.
3. Закладывается правильная мысль: общайтесь с заказчиком и понимайте бизнес.

Какие проблемы остаются:

1. К сожалению, сам инструмент довольно поверхностно раскрывает как можно погрузиться в бизнес и задачу и что считается хорошим погружением.
2. Чаще всего аналитическая функция перекладывается на заказчика. Он говорит, в каких случаях какую информацию потребляет, и это является основой разработки отчёта.
3. Проблема, которая косвенно всплывает почти всегда: при наличии шаблона отключается мозг. Видишь цифры 1, 2, 3, делаешь 1, 2, 3. Думаю именно из-за этого я почти никогда не встречал критики Канваса. Это удобный чёткий шаблон, который работает.

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

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

• Если это ключевая метрика, почему её не было до этого?
• Почему в разрезе сервисов? А другие?
• Почему это GMV? Кто выбрал эту метрику?
• Что заказчик будет делать, если метрика просела?

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

Как реально понять задачу?

Вернёмся к началу. Ох уж эти нелогичные заказчики! Сами не знают чего хотят, постоянно всё меняется, что-то любят добавлять и менять. Ну мудаки! Или нет?

Чаще всего такое поведение заказчика — симптом ваших ошибок.

То, как заказчик видит решение — это его личное видение. И далеко не факт, что он эффективный и вообще правильный. Особенно, если заказчик не аналитик предлагает и говорит то, как делать аналитику.

Единственный майндсет, который может вас привести к успешной карьере и счастливым рабочим будням: я — партнёр, а не исполнитель.

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

Как же это можно сделать?

В бизнес-анализе есть понятная последовательность и иерархия сбора требований:

1. Потребность. Это проблема и база, от которой строятся бизнес-требования. Они описывают почему возникает задача.
2. Бизнес-требования. Это высокоуровневые цели, которые позволят решить потребность. Они описывают как она будет закрываться.
3. Требования заказчиков. Их ожидания, которые описывают реализацию бизнес-требования и потребности. Это самый коварный этап.
4. Требования к решению. Описывается то, что и как конкретно будет сделано на уровне данных и инструмента.
5. Проект внедрения. То, как будет раскатываться наше решение. Где, как
   и кому пишем анонсы, где вешаем плашки и баннеры о новом инструменте
   или вставляем кросс-ссылки на другие инструменты.

Понять потребность

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

Потребность похожа на айсберг:

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

На картинке выше я привёл пример типичного айсберга:

1. К нам приходят с задачей (запросом) — это надводная часть.
2. Уточняем и задаём вопросы. Это вскрывает первые проблемы и симптомы,
   в контексте дашбордов это чаще всего про прозрачность.
3. Дальше нас ждут невысказанные потребности и страхи, что-то не нравится
   в текущих процессах.
4. Пытаясь понять что не нравится в процессах, мы так или иначе упираемся
   в цели бизнеса.

Именно в решении целей бизнеса и кроется истинная ценность вашей деятельности. Разберём на примере с дашбордом.

1. Вершина

Продакт ставит задачу (по SMART, хехехе):

«Нужен дашборд, который показывает DAU (Daily Active Users), MAU (Monthly Active Users) и Stickiness (DAU/MAU) за последние 90 дней.

С разбивкой по планам подписки (Free, Pro, Enterprise). И чтобы были графики и тренды.

Сделать нужно до конца следующей недели.»

2. Погружаемся под воду

Задача на этом этапе — выявить симптомы реальных потребностей и понять причины предложенных решений.
Поэтому аналитик (А) ставит встречу и общается с продактом (П):

• А: Чем поможет бизнесу этот дашборд?
• П: Мы сделали платную подписку, ключевая метрика растёт, но руководство спрашивает, насколько глубокая вовлечённость у пользователей
• А: А, получается именно для этого нам нужна разбивка по планам?
• П: Да, хочется понимать какая доля переходит из бесплатных в платные и какая откатывается
• А: Как связаны вообще 3 уровня подписки описанные?
• П: По умолчанию все пользователи на бесплатном тарифе, мы их всячески пытаемся конвертировать в Про. А вот энтерпрайс вообще отдельная история и скорее про B2B, там отдельное направвление и пока на нём нет фокуса...
• А: Почему вам нужны именно эти метрики?
• П: MAU — наша ключевая метрика. Но чтобы понять вовлечённость пользователей хочется понять как они пользуются продуктом ежедневно, поэтому DAU

Видим следующие факты:

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

Возможно, проблема не в отслеживании *AU, а в прозрачности работы новых продуктов.

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

Погружение нацелено на расширение картины и выявлении проблем.

Наш диалог продолжается, цепляемся за факты из прошлого этапа.

• А: Получается, что-то беспокоит руководство в текущей ситуации?
• П: Есть ощущение, что многие пробуют раз и пропадают. Хотим понять масштаб проблемы «недогруженных» платящих пользователей
• А: Откуда такие опасения?
• П: До этого пробовали запуск, и сталкивались с тем, что новые платные юзеры не используют продукт интенсивно после первых 2 недель.
  По опросам топ-2 причины: не находят ценности и сталкиваются
  с барьерами в онбординге.

Уже видим:

1. Опасения про вовлечённость не ощущения, а конкретный неуспешный опыт.
2. Несмотря на провал в прошлом, бизнес пытается ещё раз.

4. Пытаемся понять бизнес

Последние уточнения нас выводят на реальные потребности бизнеса.

• А: Получается, что прошлый запуск провалился? Почему решили повторить?
• П: Конкурент это сделал и его акции выросли на 30%, по нашим оценкам рынок огромный, сейчас мы будем вливать огромные деньги в маркетинг этой подписки

Здесь понимаем:

1. Это большой и важный проект, на котором весь бизнес ставит ставку.
2. Будет тратиться большое количество денег.

Итого. Выявили потребность

Прекрасно видно, как наша потребность из «Отслеживать DAU, MAU, Sticky в разрезе планов подписки» превратилась в проблему:

«Как не наступить на грабли c низкой вовлечённостью платных клиентов в новом важном направлении бизнеса с платными подписками?».

Это точно потребность, а не замаскированные требования:

1. Содержит проблему
2. Есть открытый вопрос
3. Нельзя взять потребность и сразу сделать из неё готовый инструмент.

Выявить бизнес-требования

Так как из потребности не получится инструмента, нам нужно конвертировать это в решение на языке бизнеса.

Для понимания бизнес-требований очень важен контекст заказчиков
и пользователей дашборда. Поэтому продолжаем наш диалог аналитика и заказчика.

• А: Сейчас как-то отслеживается, как окупаются затраты?
• П: Ой, кстати, нет, но я думал это отдельной задачкой занести, чтобы в другом дашборде сделали, но руководству это супер-важно, у нас нет второго шанса
• А: Какие основные цели и промежуточные точки у проекта с платными подписками?
• П: Важно, чтобы доля платных была от 25% аудитории, иначе мы будем генерировать убытки, плюс важно, чтобы платные оставались такими хотя бы 3 месяца, иначе их конвертация в платных для нас бесполезна
• А: Хорошо. Допустим, мы видим, что доля платных не растёт, то что делать?
• П: Тогда идём в маркетинг и проверяем, как работают кампании и разбираемся, почему цифры ниже ожидаемого
• А: Если платные отваливаются, то что делаем?
• П: Мы уже проверили, и очень хорошо работают триггерные email-кампании с обучением или предложим персональный онбординг

Понимаем, что:

1. Нужны метрики по окупаемости и расходам
2. Есть две ключевые точки контроля: новые и новые платные.
   
   Под каждую точку нужен разный инструмент. И это нормально, когда разные задачи решаются разными инструментами.
   
   Мы делаем не дашборды, а дата-продукты.
3. Понятно, что основные цели это не MAU, DAU и Sticky, а Retention платных, MAU и Sticky платных и доля платящих. То есть мы изменили фокус внимания.

Итого. Собрали бизнес-требования

Здесь меняется вектор вопросов с проблем, на вопросы о решениях
и процессах.

1. Поняли, что может решить проблему и какие есть точки контроля.
2. Увидели дополнительный контекст в процессе заказчиков, который позволяет понять, что делают с данными и какие решения на них принимают.
3. Формируем не просто задачу, а проект

Получить требования заказчиков

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

Этот этап на самом деле хитрый и не всегда самый простой.

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

Это не потому что заказчики плохие. Так происходит из-за того, что:

1. У разных заказчиков разные цели и разный взгляд на процессы.
2. Они могут находится в своих локальных контекстах.
3. Не знают о каких-то возможностях инструмента.
4. Зачастую не аналитики и это не их сильная сторона.

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

Это мир бесконечных хотелок заказчиков, которые никак не связаны друг
с другом.

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

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

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

Требования к решению

Всё, что мы выяснили на предыдущих этапах выливается в решение. Это ваше понимание задачи.

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

• Набор метрик, их методология расчёта
• Срезы
• Источники
• Глубина данных
• Свежесть данных
• Частота обновления, ожидаемое время подготовки
• Доступы и их ограничения

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

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

Проект внедрения

Этап последней мили — вы описываете и выясняете, как и кому презентовать решение.

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

• Нужна ли демо-группа? Из кого будет состоять?
• Кому нужно рассказать? Какие есть площадки для этого?
• Где написать анонсы?
• Нужно ли где-то внедрить плашки и баннеры с анонсами?
• Нужно ли поддержать в кросс-ссылках новый инструмент?
• Нужно ли делать воркшопы / обучение?

Это позволит вашему дашборду (дата-продукту) увидеть свет и донести пользу, которая закладывалась в него.

Подведём итоги

На первый взгляд может показаться, что это всё так сложно и долго, зачем? Но после пары попыток станет понятно, что по-другому просто нельзя. Иначе это практически гарантия того, что ваша работа будет с низким КПД.

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

Согласны? Пробовали? Ругались когда-нибудь с заказчиками? Подписаны на телеграм? https://t.me/think_visualize