Открыть содержание

Шаблоны

Decision log

Шаблон decision log: контекст, варианты, решение, аргументы, владелец, дата пересмотра и последствия.

Decision log сохраняет не только итог, но и контекст, в котором он был рационален. Записывайте решения с высокой ценой повторного обсуждения или важными допущениями; указывайте рассмотренные варианты, владельца и сигнал пересмотра, чтобы журнал не стал кладбищем заметок.

Что такое decision log и зачем он нужен

Определение

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

Пример применения

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

Кому это надо

Тот, кто решает продуктовые задачи — продакт, аналитик, архитектор, тимлид. Decision log зарекомендовал себя при работе с распределёнными и быстрорастущими командами. Один log на продукт — и поток вопросов “почему мы это сделали” становится короче.

Авторитетная ссылка: Atlassian: Decision log template

Структура хорошего decision log

Обязательные элементы

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

  • Дата
  • Автор
  • Описание решения
  • Контекст
  • Альтернативы
  • Причины выбора
  • Риски и ограничения
  • Согласовано с

Краткий шаблон для быстрого старта

ДатаРешениеКонтекстАльтернативыПричина выбораОтветственныйСогласовано с
2024-06-10Cloud StorageСистема XLocal StorageБезопасность, масштабируемостьИвановПетренко

Избегай абстрактных формулировок. Филипп Станев из Thoughtworks подчёркивает: лог должен читаться как бизнес-документ, не как заметка на коленке.

Пример из жизни

Запущен новый платёжный шлюз. Лог фиксирует:

  • выбрали Stripe из трех альтернатив;
  • основная причина — время интеграции и поддержка локальных карт;
  • согласовали с CTO и Head of Payments.

Как вести: чек-лист по эффективному использованию

Как часто обновлять

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

Кто отвечает

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

Где хранить

Подойдет любой доступный инструмент: Google Docs, Confluence, Notion, корпоративный wiki. Главное — одинаковое оформление и полный доступ для команды.

Антипаттерны

  1. Не ведёшь лог регулярно — теряется смысл.
  2. Задним числом фальсифицируешь логи — команда не верит записям.
  3. Путаешь решения со статусами задач — log не для task-трекинга.

Готовые формы и примеры

Универсальный шаблон (скопируй для своей команды)

Дата:
Решение:
Контекст:
Альтернативы:
Причина выбора:
Риски и ограничения:
Ответственный:
Согласовано:

Сокращённый шаблон для Slack/Telegram

[Дата] [Решение] — [Причина и альтернатива] (Ответственный, согласовано)

Пример: 2024-06-01: Перешли на новую аналитику. Прежняя не видит когорты, сравнивали с Amplitude. Ответственный: Мария, согласовано с Петром.

Полезные ссылки

FAQ

Какие решения вносить в decision log?

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

Сколько времени занимает ведение decision log?

2–5 минут на запись одного решения. Зависит от сложности и зрелости процессов в команде.

Можно ли использовать шаблон для небольшого стартапа?

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

Когда пересматривать старые записи?

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

В каком инструменте лучше вести?

Там, где команде удобно: Notion, Confluence, Google Docs, корпоративный wiki.

Кто несет ответственность за актуальность?

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