Как выяснить требования у нетехнического заказчика?

Выявление требований у нетехнического заказчика

Основной принцип: слушание и переформулирование

Нетехнический заказчик часто не знает, что такое pipeline, ETL или хранилище данных. Ваша задача — перевести его бизнес-проблемы в технические требования.

Шаг 1: Поймите бизнес-проблему

Вопросы, которые нужно задать:

1. Почему вы пришли с этой проблемой?

   • Заказчик: «Наша аналитика работает медленно»
   • Data Engineer: «Сколько эта медленность вас стоит? Часы ожидания результата значит потерянные решения?»

2. Какой результат вы хотите получить?

   • Заказчик: «Хотим видеть данные по продажам»
   • Data Engineer: «Вы хотите видеть: sales by region/product/time? Нужны детали каждого заказа или только сводки?»

3. Кто будет использовать решение?

   • Менеджер (нужны красивые dashboards)
   • Аналитик (нужен SQL доступ)
   • Руководитель (нужны только KPI)
   • Каждому требуется свой интерфейс

Шаг 2: Выясните масштабы

Примеры опасных предположений:

ЗАКАЗЧИК: «Нам нужна база данных для аналитики»

ВАРИАНТ A: 10 GB, 100 пользователей, обновление раз в день
  Обычная PostgreSQL, $50/месяц

ВАРИАНТ B: 10 TB, 1000 пользователей, real-time обновление каждую минуту
  Snowflake + real-time pipeline, $50k/месяц

Вопросы на масштабирование:

1. Сколько данных вы создаете в день?
   - Ответ: "Много" -> Спросите: 1 GB? 100 GB? 1 TB?
   - Требуется понимание масштаба

2. Как часто нужны свежие данные?
   - Ежедневный отчет в 09:00?
   - Каждый час?
   - Каждую минуту (real-time)?
   - Разные сценарии равно разные технологии

3. На какой период нужно хранить данные?
   - Последние 30 дней?
   - 5 лет? (стоимость хранилища меняется на порядок)

Шаг 3: Переведите в метрики

Создайте матрицу требований:

Требование: Данные обновляются 1x в день
Решение: Batch ETL (airflow)

Требование: Нужны в 09:00 утра
Решение: Schedule: 08:30

Требование: SLA: макс 2 часа ожидания
Решение: Timeout: 2h

Требование: 100 пользователей
Решение: Snowflake (не Spark)

Требование: 50 GB новых данных в день
Решение: примерно 1.5 TB в месяц

Требование: Хранить 1 год
Решение: примерно 18 TB storage

Требование: Видеть region, product, KPI
Решение: 15 основных метрик

Шаг 4: Конкретные вопросы по данным

Источники данных:

- Откуда берутся данные?
  * CRM (Salesforce)?
  * ERP (SAP)?
  * Веб-сайт или приложение (логи, события)?
  * Файлы от партнеров (CSV, FTP)?
  * API?

- Какова частота поступления?
  * Один раз в конце месяца?
  * Каждый час?
  * В реальном времени (потоковые)?

- Есть ли проблемы с данными?
  * Дубликаты?
  * Пропущенные значения?
  * Задержки в доставке?

Измерения и метрики:

# Вместо: "Нам нужна аналитика"
# Спросите конкретно:

# Бизнес-вопрос: "Какой регион приносит больше дохода?"
# Техническое решение:
#   - Таблица: Sales (customer_id, region, amount, date)
#   - Метрика: SUM(amount) по region
#   - Гранулярность: ежедневно
#   - Фильтры: по дате, по типу продукта

# Бизнес-вопрос: "Почему продажи упали в прошлом месяце?"
# Техническое решение:
#   - Таблица: Daily_Sales (date, region, product, amount, units_sold)
#   - Сравнение: месяц-к-месяцу, неделя-к-неделе
#   - Детализация: может быть ограничение в 1 продукте, 1 регионе

Шаг 5: Документируйте на их языке

Запрещено писать:

Нужна ELT pipeline с incremental loading на хранилище,
используя streaming debezium и processing фреймворк Kafka

Пишите:

Каждый день в 06:00 мы берем новые заказы из CRM,
и в 09:00 они появляются в dashboard для менеджеров.

Это означает: в 06:00 система запускает скрипт (1 час обработки),
результаты загружаются в аналитическое приложение,
менеджеры видят свежие данные в 09:00.

Если что-то сломается, мы получим алерт и сможем исправить.

Шаг 6: Валидация через примеры

Покажите mock-up результаты:

ЗАКАЗЧИК: "Нужна аналитика по продажам"

ВЫ ПОКАЗЫВАЕТЕ ТАБЛИЦУ:
Region | Units | Revenue
North  | 1500  | 450000
South  | 2100  | 630000
East   | 890   | 267000
West   | 1200  | 360000

ВОПРОС: "Это то, что вам нужно? Правильные цифры? Чего не хватает?"

ОТВЕТ: "Да, хорошо, но добавьте еще % изменения от прошлого месяца
и группировку по типу продукта"

ВЫ ПЕРЕСЧИТЫВАЕТЕ И ПОКАЗЫВАЕТЕ С ДОПОЛНИТЕЛЬНЫМИ КОЛОНКАМИ:
Region | Product | Units | Revenue | vs Last Month
North  | Premium | 600   | 240000  | +15%
North  | Basic   | 900   | 210000  | -5%
South  | Premium | 1100  | 440000  | +22%

ЭТО И ЕСТЬ ТРЕБОВАНИЯ!

Шаг 7: Согласуйте границы ответственности

Важный диалог:

ВЫ: "Кто отвечает за качество данных в CRM?"
ЗАКАЗЧИК: "Отдел продаж"
ВЫ: "Если есть дубликаты клиентов в CRM, мы их очищаем,
но это требует правила: первый заказ всегда верный?"
ЗАКАЗЧИК: "Да, но проверяй с отделом продаж"

РЕЗУЛЬТАТ:
- Data Engineer отвечает за pipeline (берет, трансформирует)
- Sales Team отвечает за качество входных данных
- Аналитик использует выходные данные

Чеклист для интервью с заказчиком

• Бизнес-проблема: четкое определение, почему это нужно
• Пользователи: кто будет пользоваться, их роль
• Масштабы: объемы данных, частота обновления
• Источники: где берутся данные
• Метрики: конкретные цифры и KPI, которые нужны
• SLA: сроки готовности данных
• Примеры: mock-up таблицы с ожидаемыми результатами
• Бюджет: на что они готовы потратить
• Сроки: когда нужно запустить

Вывод

Выявление требований у нетехнического заказчика — это навык перевода. Вы берете их бизнес-язык (проблемы, цели, процессы) и переводите в технические параметры (объемы, частоты, SLA). Результат — четкий контракт, который понимают обе стороны.