НАМ ПИШУТ
Продолжаем серию постов, которые присылали в рамках розыгрыша на обучение. Сегодня соавтор канала — Сергей @sergejs_andrejevs 👇
Записки из горевшего дома — Decision Log против бананов
Возможно, это старая байка, а возможно, и реальный эксперимент:
Знакомо? Такие "бананы" стоят дороже, чем кажется: они порождают лишние встречи, замедляют поставку, и делают любые изменения опасными, потому что никто не помнит зачем так сделано:
• все пул/мерж-реквесты должен смотреть тимлид. Но старый хардкорный тимлид сменился на управленца, который жмёт кнопку неглядя,
• четыре года были еженедельные встречи на тему оптимизации издержек, но в последние полгода на них почти нет новостей и изредка рассказывает от силы кто-то один, т.к. остальные уже сняли низковисящие плоды и оптимизировать дальше слишком дорого, поэтому все фокусируются на бизнес-функционале.
Возможно, и у вас есть бананы, которые нельзя трогать из-за традиции, контекст решения которых умер давным давно? Причём он мог быть вообще временным решением, ведь, как мы знаем, "нет ничего более постоянного, чем временное".
Как тимлид, вы это видите по симптомам:
• люди вокруг спорят о прошлом ("кто это решил?"), а не о будущем ("что выгоднее сейчас?"),
• решения "передаются устно" и зависят от носителей памяти,
• новичкам проще подчиниться, чем понять, и традиция закрепляется.
Давайте поговорим о том, как этого избежать, и один из способов — Decision Log.
Decision Log — это единый список важных решений, каждое из которых записано в формате "коротко, честно, проверяемо":
• контекст (какие ограничения и зачем это вообще обсуждали),
• решение (что выбрали),
• последствия (чем платим),
• владелец (кто отвечает),
• точка пересмотра (когда можно/нужно переоценить).
Например:
В качестве критерия, когда делать запись, используйте порог важности: логируйте только то, стоимость спора о чём будет дороже. Либо что будет дорого откатывать.
Обязателен владелец: без него решение превращается в "само случилось".
Append-only: не переписывайте прошлое — добавляйте новое решение, которое заменяет старое (как в ADR, https://adr.github.io/, где ADR — для архитектуры и кода, а Decision Log — для людей и привычек).
Один источник истины: один лог, а не “в чате было”.
Но не превращайте DL в лог встречи: пишите кратко и по существу. Позже вы или ваш коллега будет это всё читать. Да, в эру ИИ, это может сделать железяка, но даже здесь контекст имеет свою стоимость.
Как ввести?
Сделайте первую запись DL-001 "о новом ритуале создания Decision Logs". Каждое важное решение в конце встречи получает DL-номер и владельца. Владелец в течение суток заносит запись и кидает ссылку в чат.
Для любителей метрик можно ввести: сколько споров за месяц/четверть вы закрыли ссылкой на Decision Log.
Decision Log не отменяет традиции, а делает их ОБЪЯСНИМЫМИ. Следовательно — пересматриваемыми. Тогда команда перестаёт охранять бананы “потому что так принято” и начинает охранять то, что действительно важно: смысл, риск и результат.
Работа часто становится для нас вторым домом. В этом доме мы не только закрываем задачи, но и проживаем большие части жизни: строим, спорим, ошибаемся, радуемся победам, переживаем провалы и пожары. И если что-то действительно стоит сохранить из этого дома, то не слепые ритуалы, а смысл решений, опыт и контекст. Всё это и остаётся в записках из горевшего дома.
Продолжаем серию постов, которые присылали в рамках розыгрыша на обучение. Сегодня соавтор канала — Сергей @sergejs_andrejevs 👇
Записки из горевшего дома — Decision Log против бананов
Возможно, это старая байка, а возможно, и реальный эксперимент:
В клетку повесили бананы и обрызгивали всех обезьян ледяной водой, когда кто-то пытался залезть к ним.
Обезьяны усвоили урок и стали избивать любого, кто пытался достать банан, чтобы избежать душа.
Затем холодную воду отключили и начали заменять обезьян одну за другой. Новички, не знавшие про воду, всё равно получали побои от остальных, если шли к банану.
В конце концов, в клетке остались обезьяны, которые никогда не видели ледяной воды, но жестоко препятствовали попыткам достать банан, потому что "здесь так принято".
Знакомо? Такие "бананы" стоят дороже, чем кажется: они порождают лишние встречи, замедляют поставку, и делают любые изменения опасными, потому что никто не помнит зачем так сделано:
• все пул/мерж-реквесты должен смотреть тимлид. Но старый хардкорный тимлид сменился на управленца, который жмёт кнопку неглядя,
• четыре года были еженедельные встречи на тему оптимизации издержек, но в последние полгода на них почти нет новостей и изредка рассказывает от силы кто-то один, т.к. остальные уже сняли низковисящие плоды и оптимизировать дальше слишком дорого, поэтому все фокусируются на бизнес-функционале.
Возможно, и у вас есть бананы, которые нельзя трогать из-за традиции, контекст решения которых умер давным давно? Причём он мог быть вообще временным решением, ведь, как мы знаем, "нет ничего более постоянного, чем временное".
Как тимлид, вы это видите по симптомам:
• люди вокруг спорят о прошлом ("кто это решил?"), а не о будущем ("что выгоднее сейчас?"),
• решения "передаются устно" и зависят от носителей памяти,
• новичкам проще подчиниться, чем понять, и традиция закрепляется.
Давайте поговорим о том, как этого избежать, и один из способов — Decision Log.
Decision Log — это единый список важных решений, каждое из которых записано в формате "коротко, честно, проверяемо":
• контекст (какие ограничения и зачем это вообще обсуждали),
• решение (что выбрали),
• последствия (чем платим),
• владелец (кто отвечает),
• точка пересмотра (когда можно/нужно переоценить).
Например:
[DL-xxx] Название
Статус: принято/пересматривается/отменено/заменено DL-yyy
Контекст:
Решение:
Альтернативы [опционально]:
Почему не они [опционально]:
Последствия (trade-offs):
Точка пересмотра:
Ссылки:
В качестве критерия, когда делать запись, используйте порог важности: логируйте только то, стоимость спора о чём будет дороже. Либо что будет дорого откатывать.
Обязателен владелец: без него решение превращается в "само случилось".
Append-only: не переписывайте прошлое — добавляйте новое решение, которое заменяет старое (как в ADR, https://adr.github.io/, где ADR — для архитектуры и кода, а Decision Log — для людей и привычек).
Один источник истины: один лог, а не “в чате было”.
Но не превращайте DL в лог встречи: пишите кратко и по существу. Позже вы или ваш коллега будет это всё читать. Да, в эру ИИ, это может сделать железяка, но даже здесь контекст имеет свою стоимость.
Как ввести?
Сделайте первую запись DL-001 "о новом ритуале создания Decision Logs". Каждое важное решение в конце встречи получает DL-номер и владельца. Владелец в течение суток заносит запись и кидает ссылку в чат.
Для любителей метрик можно ввести: сколько споров за месяц/четверть вы закрыли ссылкой на Decision Log.
Decision Log не отменяет традиции, а делает их ОБЪЯСНИМЫМИ. Следовательно — пересматриваемыми. Тогда команда перестаёт охранять бананы “потому что так принято” и начинает охранять то, что действительно важно: смысл, риск и результат.
Работа часто становится для нас вторым домом. В этом доме мы не только закрываем задачи, но и проживаем большие части жизни: строим, спорим, ошибаемся, радуемся победам, переживаем провалы и пожары. И если что-то действительно стоит сохранить из этого дома, то не слепые ритуалы, а смысл решений, опыт и контекст. Всё это и остаётся в записках из горевшего дома.