Думать надо на входе в поворот, на выходе думать будет поздно
Думать на входе в поворот: мудрость мотоциклистов в проектном управлении.
Метафора: Мотоциклист на входе в поворот выбирает траекторию, скорость, точку торможения. На выходе — уже поздно: инерция, гравитация, физика. То же в проектах: решения на старте определяют всё, а попытки «переосмыслить» в разгаре стоят в 10-100 раз дороже и приводят к проблемам или к провалам.
Мотоциклист → Менеджер проекта
Главный инсайт: Самые дорогие решения — те, которые ты не принял вовремя. В повороте ты не выбираешь — ты только платишь за выбор, сделанный (или не сделанный) раньше.
Практики «думать на входе»
Практика 3C - (Card, conversation, and confirmation (3 C's))
Зачем? Быстро «приземлить» идею в конкретный артефакт, синхронизировать понимание и зафиксировать решение до старта работ.
- Card (карточка) — формулируем что именно делаем в виде короткой карточки/тикета: цель, границы (in/out), критерии приёмки, риски/зависимости, ссылки на контекст.
- Conversation (разговор) — обсуждаем карточку с ключевыми участниками: уточняем ожидания, сценарии, исключения, альтернативы, договариваемся об ответственности.
- Confirmation (подтверждение) — фиксируем итог: решение, кто владелец, какие next steps, что считается «готово». Обновляем карточку/док и используем как единый источник правды.
Результат: меньше «догадок» в исполнении, меньше переоткрытий требований на середине пути.
Практика: Дизайн док - ТЗ (RFC)
Зачем? Принять ключевые решения до реализации и сделать их проверяемыми и зафиксировать в каком то документе.
- Контекст и проблема: что болит, почему сейчас, какие ограничения.
- Цель и не-цель: что обязательно, а что сознательно не делаем.
- Предлагаемое решение: общий подход, компоненты, интерфейсы, данные, миграции.
- Альтернативы: 1–3 варианта и почему выбрали этот (trade-offs).
- Риски и вопросы: что может пойти не так, что нужно проверить/прототипировать.
- План внедрения: этапы, критерии готовности, метрики успеха.
Как работает: документ публикуется → собираются комментарии → проводится короткое RFC-обсуждение → фиксируется итоговое решение (и при необходимости создаётся ADR).
Практика: Дорожная карта
Зачем: видеть «повороты» заранее — последовательность шагов, зависимости и точки принятия решений.
- Цели по времени: ближайшие 1–2 недели (оперативка), 1–2 месяца (тактика), 1–2 квартала (стратегия).
- Вехи и результаты: не «делаем X», а «получаем Y» (outcome-based).
- Зависимости: кто/что блокирует, что нужно заранее согласовать.
- Буферы и риски: где возможны срывы, как мониторим.
- Правила изменения: как попадают новые задачи и что выкидываем/сдвигаем взамен (change control).
Как работает: регулярный пересмотр (например, еженедельно/раз в спринт) + явные решения о приоритетах, чтобы не «тормозить в повороте».
Прочее
В зависимости от проекта могут понадобится какие то более тонкие проработки.
- Требования (Discovery & Requirements Engineering): проработка user stories, критериев приёмки, интеграций, ограничений и зависимостей до kickoff.
- Риски (Shift-Left Risk Management): реестр рисков; риск-сессии/воркшопы (SWOT, Delphi) ещё на инициации.
- Архитектура (ADR): ключевые архитектурные решения фиксируются и согласуются до написания кода.
- Оценка (Planning Poker / Wideband Delphi): командная оценка через обсуждение, без «оценка с потолка» или “оцнека самым умным”.
- Качество (Shift-Left Testing): тестовые сценарии и критерии качества формулируются до/параллельно разработке.
- Согласования (Project Charter + RACI): роли, зоны ответственности, критерии успеха и правила принятия решений — до старта.
- Зависимости (Dependency Mapping): карта межкомандных/межсистемных зависимостей до начала работ.
- Смена требований (Change Control): правила внесения изменений и компромиссы (что сдвигаем/отменяем) определены до первого запроса на change.
Ключевые принципы
1. Раннее «насыщение» проектирования (front-loading)
Максимальная проработка на ранних фазах. Каждая упущенная ключевая мысль на входе = потерянные дни и недели работы на выходе.
2. «Сдвиг влево» (Shift-Left)
Перенос всех «проверочных» активностей на более ранние этапы: тестирование, рецензирование (review), анализ рисков, безопасность. Не «сначала напишем, потом проверим», а «проверяем по ходу».
3. Иерархия irreversible decisions
Сначала принимаем самые дорогие для отката решения (архитектура, технологический стек (stack), контракты, команда), потом менее дорогие.
4. «Сначала спроектируй — потом строй» (Design before build)
BIM в строительстве, каркасы интерфейса (wireframes) в дизайне, техзадание в разработке. Проект без проектирования = мотоциклист без глаз на слепом повороте.
Что будет, если игнорировать
Прямые последствия (деньги и сроки)
- Цена поздних изменений (cost of change) растёт экспоненциально — ошибка в требованиях (requirements) стоит 1×, в коде 10×, в продакшене (prod) 100×
- Каскадные задержки — одна поздняя правка рушит расписание трёх команд (20-25% просрочек именно из-за поздних изменений)
- Переделка (rework) — повторное изготовление уже сделанного: демонтаж модулей, переписывание модулей, новые пермиты
- Поздние архитектурные изменения — 40%+ оверран по бюджету
Организационные последствия
- Потеря доверия — заказчик видит, что сроки плывут, бюджет растёт, обещания не выполняются
- Выгорание команды — постоянные переделки, хаос, «мы вчера это уже делали»
- Суды — в крупных проектах поздние изменения — основная причина арбитражей
Технические последствия
- Технический долг — «быстро сделаем, потом рефакторим» → никогда не рефакторим
- Критические баги в проде — потому что тестирование было «потом»
- Несогласованные интеграции — две команды строили API в разные стороны
Видео
Идея этого поста пришла в голову после просмотра видео Максима Дорофеева. Он как раз рассказывает историю про то как обучался водить мотоцикл и как его тренер дал ему эту идею.