Как документировать аналитические задачи

Почему документация важна

Анализ в голове аналитика — не анализ. Документация — это то, где живёт знание.

Без документации:

• Через месяц вы сами забудете выводы.
• Другие аналитики будут повторять вашу работу.
• Стейкхолдеры не будут использовать инсайты.
• Знание уходит вместе с вами при смене работы.

С документацией:

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

Сеньоры тратят 30–40% времени на писанину, а не на код.

Типы аналитических документов

1. Мемо / отчёты. Подробный анализ с находками и рекомендациями.

2. Рунбуки. Операционные инструкции (как запустить A/B-тест, как выкатить дашборд).

3. Ресёрч-документы. Более длинные стратегические анализы с несколькими гипотезами.

4. Документация экспериментов. A/B-тесты — пре-регистрация, запуск, разбор.

5. Документация дашбордов. Что дашборд показывает и как интерпретировать.

6. Словари данных. Определения таблиц, колонок, метрик.

Разные форматы под разные цели.

Универсальная структура мемо

Классическая структура хорошего аналитического мемо:

1. TL;DR.

3–5 буллетов с ключевыми находками. Если читатель прочтёт только это — получит основной месседж.

2. Исследовательский вопрос.

На что пытались ответить?

3. Контекст.

Почему этот анализ важен? Бизнес-контекст.

4. Методология.

Как подошли? Источники данных, фильтры, сегменты.

5. Находки.

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

6. Ограничения.

Чего не знаем? Оговорки, проблемы качества данных, альтернативные интерпретации.

7. Рекомендации.

Что делать на основе находок?

8. Следующие шаги.

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

9. Приложение.

Технические детали, SQL, подробные графики.

Пример мемо: анализ retention

# Глубокий разбор retention: Q1 2026

## TL;DR
- Day-30 retention упал с 28% до 24% за последние 3 месяца.
- Падение связано с новым онбордингом (flow B, запущен 15 января).
- Drop-off на шаге 3 онбординга вырос с 15% до 28%.
- Рекомендуется откатить на предыдущий flow или хотфикс шага 3.

## Исследовательский вопрос
«Что вызвало падение Day-30 retention в Q1 2026?»

## Контекст
Бизнес-цель — 30% Day-30 retention к концу Q2.
Retention — ключевой рычаг роста. Даже 1 п.п. изменений = $500k годовой выручки.

## Методология
- Данные: таблица user_events, 2025-10-01 до 2026-03-31.
- Когорты: ежемесячные когорты регистрации.
- Day-N retention: пользователь активен на день N после регистрации.
- Активен = минимум 1 событие (логин, покупка, просмотр).

## Находки

### Находка 1: общий retention падает
[график: Day-30 retention по месячным когортам]
С 28% (окт–дек 2025) до 24% (янв–март 2026).

### Находка 2: проблема в новом онбординге
Разбор A/B flow A vs flow B (запущен 15 января):
- Flow A: 28% Day-30 retention
- Flow B: 22% Day-30 retention
- Значимо, p < 0.001

### Находка 3: drop-off на шаге 3
В flow B шаг 3 требует верификации телефона.
- Flow A, завершение шага 3: 85%
- Flow B, завершение шага 3: 72%

## Ограничения
- Кросс-платформенные эффекты не изолированы.
- Длинный retention (Day-60, Day-90) ещё собирается.
- Возможен selection bias у ранних пользователей flow B.

## Рекомендации
1. **Немедленно**: откатить flow B к flow A. Ожидаемое восстановление: +4 п.п. retention.
2. **Краткосрочно**: переделать шаг с верификацией телефона или сделать опциональным.
3. **Долгосрочно**: A/B-тестировать варианты онбординга с фокусом на шаг 3.

## Следующие шаги
- Откат: план — @engineer_lead, ETA 2026-04-20.
- Новые варианты онбординга: @pm_name, ETA 2026-05-30.
- Дополнительный анализ: Day-60 retention, когда данные будут готовы.

## Приложение
[SQL-запросы, подробные графики, разбивки по сегментам]

~700 слов основного контента + приложение. Читается за 5 минут.

Документация экспериментов

A/B-тесты особенно важны для документирования.

До эксперимента:

# Эксперимент: [название]

## Гипотеза
Если мы [изменение], то [метрика] будет [направление], потому что [причина].

## Первичная метрика
[метрика, определение]

## Вторичные метрики
[список с определениями]

## Guardrail-метрики
[метрики, которые не должны просесть]

## Ожидаемый размер эффекта
[прогнозный % лифта]

## Размер выборки
[рассчитан по MDE, мощности, базовой метрике]

## Длительность
[дни, с учётом возможных novelty-эффектов]

## План раскатки
[этапы, % трафика, критерии]

Пре-регистрация защищает от p-хакинга и подгонки выводов.

После эксперимента:

## Результаты
- [первичная метрика]: фактический лифт [значение], p=[p-value], CI
- [guardrail-метрики]: статус
- Сегменты: [разбивка]

## Решение
[Запустить / подержать / итерировать] по критериям, определённым до эксперимента.

## Уроки
[инсайты, неожиданные находки, дополнительные вопросы]

Один документ → весь жизненный цикл эксперимента.

Стиль

Начинайте с вывода. Пирамидальный принцип. Читатель знает ответ уже из первого абзаца.

Конкретика. «Churn вырос на 5%» > «Churn существенно изменился».

Без жаргона. Используйте бизнес-терминологию, где возможно.

Активный залог. «Я измерил X» > «X было измерено».

Короткие абзацы. Максимум 3–4 предложения. Легко сканировать.

Визуализация. Графики вместо длинных описаний. Один график = 200 слов.

Заголовки важны. Читатель скроллит по заголовкам. Делайте их информативными: «Retention на мобилке упал на 20%» > «Анализ retention».

Инструменты

Notion. Гибко, удобно для совместной работы. Хорош для живых документов.

Confluence. Корпоративный стандарт. Тяжеловат, но структурирован.

Google Docs. Самый простой. Хорошая коллаборация. Поиск может быть слабым.

GitLab / GitHub wiki. Хорош для технических команд.

Собственные инструменты. Некоторые компании строят свои (например, Dropbox Paper, Slite).

Ноутбуки. Jupyter, Hex, Deepnote — анализ + документация в одном. Хорошо для технической аудитории.

Выбор зависит от организации. Выберите один и держитесь его.

Версионирование

Документы меняются:

• Приходят новые данные.
• Уточняется методология.
• Появляются комментарии от ревьюеров.

Подходы к версионированию:

1. Пометки с датой. «Апдейт 2026-04-15: новые данные изменили вывод».

2. На базе git. Пишете доки в markdown, отслеживаете в репо.

3. Возможности инструментов. История Notion, ревизии Google Docs.

4. Отдельные версии. «Анализ v1», «Анализ v2 после ревью».

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

Ревью коллегами

Анализы заслуживают ревью.

Чеклист ревьюера:

• Чётко ли сформулирован исследовательский вопрос?
• Методология корректна?
• Выводы следуют из данных?
• Ограничения проговорены?
• Рекомендации actionable?
• SQL/код корректен (точечная проверка)?

Часто 1-на-1 ревью до широкой рассылки.

Польза: ловит ошибки, улучшает текст, строит знание команды.

Документация — базовый навык аналитика. В тренажёре Карьерник есть практические задачи по аналитике, case interviews и навыкам сеньор-уровня.

Словари данных

Специализированный тип документа для определений.

Для каждой метрики:

## MRR (Monthly Recurring Revenue)

**Определение:** сумма месячных стоимостей всех активных подписок.

**SQL:**
```sql
SELECT SUM(monthly_amount)
FROM subscriptions
WHERE status = 'active' AND period = 'monthly';

Годовое представление: MRR × 12.

Включает:

• Активные месячные подписки
• Годовые подписки пропорционально (annual / 12)

Исключает:

• Разовые комиссии
• Плату за подключение
• Подписки, отменённые в текущем месяце

Владелец: команда аналитики

Обновлено: 2026-04-01

Дашборды, где используется: [ссылки]

Единый источник правды для метрики. Дашборды, запросы, мемо — все ссылаются сюда.

## Рунбуки

Операционные доки. «Как запустить еженедельное обновление дашборда retention».

**Хороший рунбук:**

- Назначение (что делает, зачем).
- Предусловия (доступы, инструменты).
- Пошаговая инструкция со скриншотами.
- Решение типичных проблем.
- Контакт, если застряли.

Написан так, что новичок может выполнить без вашей помощи.

Часы, вложенные в хороший рунбук, экономят недели путаницы.

## Долгосрочное управление знаниями

Отдельные доки — не всё. Нужна организация.

**Принципы структуры:**

**1. Центральный хаб.** Лендинг, откуда доступно всё.

**2. Иерархии.** По команде, по теме, по типу документа.

**3. Теги.** Кросс-срезы (тема, команда, дата).

**4. Поиск.** Должен работать хорошо.

**5. Архивация старого.** Устаревшее явно помечено.

**6. Ревью.** Раз в квартал чистка.

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

## Типичные ошибки

**Писать для себя, а не для читателя.** Слишком много деталей на вопросы, которые не спросят.

**Нет TL;DR.** Читатель должен скроллить и выдёргивать. Сделайте так, чтобы его работа была в 10 раз меньше.

**Игнорировать ограничения.** Делать вид, что анализ пуленепробиваемый. Честное признание — строит доверие, а не разрушает.

**Рекомендации без приоритетов.** 10 рекомендаций → паралич. Ранжируйте.

**Нет повторной проверки.** Сдали документ и забыли. Вернитесь через 2–4 недели — применили ли рекомендации?

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

## Читайте также

- [Data storytelling](/blog/data-storytelling-dlya-analitika)
- [Работа со стейкхолдерами](/blog/stakeholder-management-analitik)
- [Первые месяцы на работе](/blog/pervyj-mesyac-na-novoj-rabote-analitik)
- [Карьерный путь аналитика](/blog/kariernyj-put-analitika-dannyh)

## FAQ

### Сколько времени тратить на документирование?

Примерно пропорционально времени на анализ. Быстрый ad-hoc (1 час) — короткий ответ в слаке. Недельный анализ — формальный мемо.

### Notion или Google Docs?

Зависит от компании. Notion — богаче по фичам, Google Docs — проще. Выбирайте, чем уже пользуется команда.

### Навыки письма — врождённые?

Нет. Навык, который развивается практикой и чтением хороших примеров. Начните читать качественные аналитические мемо (Stratechery, Lenny's Newsletter).

### Документация — скучно. Можно забить?

Забить = убить карьеру. Сеньоров узнают по текстам. Мидлы и джуны без текста там и останутся.