Журнал решений

Зачем он вообще нужен

Большинство управленческих проблем возникают не из-за плохих решений,
а из-за того, что решения не зафиксированы.

Контекст исчезает.
Альтернативы забываются.
Через месяц спорят не о фактах, а о воспоминаниях и интерпретациях.

Журнал решений — это не инструмент контроля команды.
Это инструмент удержания ясности и собственной позиции в системе.

Что считается решением

Решение — это:

• выбор одного варианта из нескольких;
• который меняет траекторию проекта, команды или ресурсов;
• и имеет цену отката.

Не является решением:

• обсуждение без выбора;
• гипотеза без действия;
• «давайте попробуем» без точки возврата;
• мелкая операционка без последствий.

Если есть цена ошибки — это решение.
Если нет — фиксировать нечего.

Когда решение фиксируется обязательно

Фиксируй решение, если выполняется хотя бы одно:

• влияет на сроки или скоуп;
• затрагивает роли и ответственность;
• перераспределяет ресурсы;
• создаёт долг (технический, управленческий, репутационный);
• ограничивает будущие варианты.

Если сомневаешься — фиксируй.
Лишняя запись дешевле потерянного контекста.

Формат записи (минимальный)

Одна запись — 5–10 минут.
Никаких эссе.

Дата:
Контекст:
Варианты:
Выбранное решение:
Почему:
Риски:
Сигналы проверки:
Дата ревизии:

Как заполнять

Контекст

Коротко. Без истории мира.

Ответь:

• где мы сейчас?
• почему решение возникло?
• что давит (сроки, люди, деньги, ожидания)?

Варианты

Минимум два. Лучше три–пять.

Варианты должны быть реальными,
а не «хороший / плохой».

Выбранное решение

Одна строка. Без оправданий.

Если решение нельзя сформулировать одной строкой —
оно ещё не принято.

Почему

Через простую ROI-логику:

• Impact — что улучшается;
• Cost — чем платим;
• Risk — где можем ошибиться.

Коротко. Пунктами.

Риски

Риски не отменяют решение.
Они делают его честным.

Если риск неприятно писать —
значит он реальный.

Сигналы проверки

Самый важный блок.

По каким ранним сигналам ты поймёшь,
что решение было ошибочным?

Если сигналов нет —
решение невозможно проверить.

Дата ревизии

Обязательно.

Решение без даты ревизии —
это решение навсегда.
Почти всегда ошибка.

Пример записи (анонимно)

Дата: 12.11.2025

Контекст:
Проект в активном лайвопсе. Доход стабильный.
Фаундер настаивает на срочном запуске новой фичи «для роста».
Команда перегружена фиксами и подготовкой апдейта.
Ответственность за сроки и стабильность на мне, власть по приоритетам — неполная.

Варианты:

• A. Взять фичу в текущий спринт, пожертвовав частью фиксов.
• B. Отложить фичу до следующего апдейта, сфокусироваться на стабилизации.
• C. Делать урезанную версию фичи параллельно, не меняя сроков.

Выбранное решение:
Выбран вариант B — фича откладывается, текущий фокус только на стабилизацию.

Почему:

• Impact: снижаем риск просадки метрик и выгорания команды; повышаем предсказуемость релиза.
• Cost: недовольство фаундера, отсутствие быстрого «вау-эффекта».
• Risk: возможная потеря окна роста.

Риски:

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

Сигналы проверки:

• через 10–14 дней критические баги не снижаются → решение недостаточно жёсткое;
• команда самопроизвольно переключается на фичу → фокус не удержан;
• давление сверху усиливается напрямую → потеря управляемости.

Дата ревизии:
Пересмотреть через 3 недели или при изменении приоритетов сверху.

Как использовать журнал

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

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

• писать красиво вместо честно;
• превращать журнал в отчёт;
• фиксировать всё подряд;
• не возвращаться к записям;
• использовать как инструмент давления.

Ключевая мысль

Если решение неприятно перечитывать через месяц —
оно, скорее всего, было настоящим.

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