Иногда в разработке достаточно одной фразы, чтобы проект тихо вышел из чата: «Да-да, всё понятно». С виду это звучит как победа коммуникации, а на деле — как стартовый выстрел для марафона недопонимания, который финиширует в дедлайн с судорогой.
История знакомая многим лидам. Большая фича, сложная архитектура, план на два месяца — и тут отпуск на месяц. Вы собираете пару инженеров, несколько раз проходите по задумке, рисуете диаграммы на доске, обсуждаете детали. В ответ — уверенные кивки: мол, разберёмся, доведём до готовности. Возвращаетесь — и видите «почти готово». Правда, «почти» означает, что реализован один небольшой частный случай, а всё остальное не работает. Дальше — драматичный спринт, вечера, выходные, попытка догнать реальность… и всё равно промах по срокам.
Проблема здесь не в чьей-то лени и не в злой судьбе, а в иллюзии общего понимания. Кажется, что договорились, но у каждого в голове — своя ментальная модель: что именно строим, где границы, какие сценарии обязательны, какие компромиссы допустимы. Разговоры создают ощущение синхронизации, но редко оставляют проверяемый след.
Выход удивительно прозаичен: внутренние RFC (Request for Comments). Это короткий документ, где описано предлагаемое решение и куда команда приносит комментарии. В open-source RFC — привычный жанр, но внутри компаний его часто недооценивают. А зря.
Письменный формат выигрывает у устного по трем причинам. Во‑первых, текст заставляет автора структурировать мысль: пока пишешь, сам видишь дырки, риски и недосказанности. Во‑вторых, хороший RFC сужает пространство интерпретаций: можно приложить диаграммы, примеры, расчёты, описать крайние случаи. В‑третьих, к документу можно вернуться позже — память ненадёжна, а через день детали «кристально ясного» созвона превращаются в туман.
Конечно, возникает сопротивление: «писать — это же медленнее, чем кодить». Здесь помогает трюк: внедрить RFC как таймбокс-эксперимент на месяц. Потом — ретро и честное решение, оставляем ли практику. Чтобы снизить порог, первые пару RFC лучше написать лидеру самому, а команду попросить комментировать, а не «сразу сочинять». Ещё один усилитель — подключить формальных или неформальных лидеров: культурные изменения умирают, если их «проповедуют», но не практикуют.
Шаблон тоже должен быть простым. В шапке: название, владелец, дата, статус (WIP/In Review/Approved/Obsolete), список апруверов и их решение. В теле — две секции: Background (зачем это нужно) и Proposal (что именно делаем). Этого достаточно, чтобы «поняли одинаково» стало не ощущением, а фактом, который можно перечитать.