> ## Content Index
> Fetch the complete content index at: https://think-visualize.ru/llms.txt
> Use this file to discover other available public pages before exploring further.

# Почему мой заказчик мудак?
- URL: https://think-visualize.ru/principles-of-good-data-product-requirements/
- Published: 2025-09-07T17:28:00.000Z
- Updated: 2025-09-27T20:36:15.000Z
- Author: Сергей 
- Tags: Работа с бизнесом, Дата-продукты, #series-masterskaya

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

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

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

Это первый пост из [серии по созданию дата-продуктов](https://think-visualize.ru/principles-of-good-data-product-intro).

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

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

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

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

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

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

### SMART

![](https://img1.teletype.in/files/0a/2f/0a2f24ed-b585-428a-8fe7-717e993c9383.png)

То, по каким критериям оценивается «хорошая» задача

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

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

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

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

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

### Dashboard Canvas

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

![](https://img4.teletype.in/files/35/bb/35bb3ed4-ac49-45a3-8ef5-a5b44e9a54d0.png)

https://miro.com/app/board/o9J\_kpOMVFA=/

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

![](https://img1.teletype.in/files/8b/36/8b36592d-5de7-450e-bd74-3c0fce4f20a2.png)

https://miro.com/app/board/o9J\_kpOMVFA=/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

![](https://img1.teletype.in/files/c0/bf/c0bf0be0-d3fe-43e9-aa8a-ec7b72c61450.png)

Этапы понимания задачи и сбора требований

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

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

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

![](https://img3.teletype.in/files/ac/95/ac95db36-095c-4b45-ac82-3879d1b18d11.png)

Пример типичного айсберга потребностей

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

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

Так что топ-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. Будет тратиться большое количество денег.

---

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

![](https://img4.teletype.in/files/31/27/31271128-11c4-49f8-a2fa-353d8673cc49.png)

Ключевые параметры потребности

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

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

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

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

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

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

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

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

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

1. Нужны метрики по окупаемости и расходам
2. Есть две ключевые точки контроля: новые и новые платные.  
    
Под каждую точку нужен разный инструмент. И это нормально, когда разные задачи решаются разными инструментами.  
    
Мы делаем не дашборды, а [дата-продукты](https://think-visualize.ru/principles-of-good-data-product-intro).
3. Понятно, что основные цели это не MAU, DAU и Sticky, а Retention платных, MAU и Sticky платных и доля платящих. То есть мы изменили фокус внимания.

---

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

![](https://img2.teletype.in/files/dc/e4/dce43162-40f7-4da0-bb6a-9a60262a25c4.png)

Ключевые параметры бизнес-требований

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

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

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

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

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

![](https://img1.teletype.in/files/c5/0e/c50eb3b7-03e0-4970-88ae-35ff9fe2761f.png)

Все заказчики разные

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

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

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

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

![](https://img1.teletype.in/files/04/ad/04ad88d6-ead2-4ace-9b5d-d69a242844bb.png)

Мир без понимания потребности и бизнес-процесса

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

Согласны? Пробовали? Ругались когда-нибудь с заказчиками? Подписаны на телеграм? [https://t.me/think\_visualize](https://t.me/think%5Fvisualize?ref=think-visualize.ru)