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

Одиннадцать месяцев назад ваша команда провела три встречи, выбирая между разработкой интеграции внутри компании и покупкой. Люди пришли подготовленными. Кто-то сделал таблицу. Обсуждение было действительно хорошим — были подняты вопросы, взвешены компромиссы, было принято решение. Затем все вернулись к работе.

На этой неделе к нам присоединился новый инженерный руководитель, который посмотрел на интеграцию и задал разумный вопрос: "Почему мы просто не построили это сами?" И честный ответ, доступный каждому в комнате, был: никто точно не помнит. Так что вопрос снова открыт. Три встречи снова собираются пройти — с меньшим количеством информации, чем в первый раз, потому что человек, который сделал таблицу, ушел в марте.

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

Что такое Запись Решения — и о чем этот пост

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

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

Одно примечание к объему: значимые решения. Место проведения выездного мероприятия не требует записи. Все, что вы бы не хотели обсуждать снова через шесть месяцев — архитектура, поставщики, цены, политика, требования к найму — требует записи. Полезный тест: если будущий коллега мог бы plausibly спросить "почему это так?", то решение подходит.

Что на самом деле стоят незафиксированные решения

Затраты обыденны, повторяются и в основном невидимы, потому что приходят замаскированными под обычную работу. Улаженные вопросы снова становятся предметом спора — та же дискуссия, разыгранная снова, за исключением того, кто держал контекст. Новые сотрудники наследуют системы, форму которых никто не может объяснить, поэтому они либо переучиваются, ломая вещи, либо направляют каждый вопрос к самому опытному человеку в комнате. И когда результат оказывается неправильным, невозможно сказать, было ли обоснование плохим или везение — что означает, что процесс никогда не улучшается.

Существует также более острый аспект: ответственность. Когда решение существует только в памяти, его история переписывается тем, кто его пересказывает — обычно в свою пользу. Запись делает аргументацию проверяемой, когда это важно, что является основой настоящего аудита решений. Мы написали короткую сопроводительную статью о самих накопительных затратах: стоимость недокументированных решений.

Существующие рамки — и пробел, который они оставляют

Вам не нужно изобретать эту практику; несколько серьезных фреймворков касаются ее. Но стоит обратить внимание на то, что каждый из них на самом деле охватывает, потому что самые популярные решают другую проблему, чем та, о которой идет речь в этом посте.

Обратите внимание на шаблон: три из четырех известных структур назначают роли; только ADR создает запись. Роли и записи — это взаимодополняющие половины — RAPID или DACI говорят вам, кто имеет D; запись сохраняет то, что D решило и почему. Большинство команд, которые чувствуют "у нас есть процесс принятия решений", приняли структуру ролей и полностью пропустили запись. Это тот разрыв, который заполняют семь полей ниже. Одна структура действительно пересекает границу, и ее стоит назвать, потому что это ближайшее к записи, что производит структура ролей: SPADE (Гокул Раджарам, использовавшийся в Google, Facebook и Square) добавляет Альтернативы и Объяснить к ролям, которые назначают другие — два из семи полей ниже, зафиксированных в момент принятия решения, а не после. Она все еще организует по встрече по принятию решения, а не по решению, так что это еще не журнал; но команда, уже использующая SPADE, находится в двух полях от одного. Краткая версия — структура SPADE в пяти буквах, и все четыре структуры ролей находятся рядом в гиде по правам на решения.

Что захватить: Семь полей

Это собственный шаблон Argumentree — не внешний стандарт, а синтез, который мы используем и рекомендуем: дисциплина записи ADR, дополненная двумя вещами, которые нужны общим командным решениям, но которые архитектурные решения получают бесплатно (явный владелец и дата обзора). Используйте его как есть.

Запись, которую вы можете скопировать

На практике семь полей помещаются на полстраницы. Пример с решением, сжатый:

Это весь артефакт. Любой, кто присоединится к команде в следующем году, прочитает его за сорок секунд и узнает, что было решено, что он обошелся, сколько стоил и когда он снова появится. Сравните это с протоколами трех встреч.

Практики, которые помогают закрепить это

Шаблоны не подводят; подводят привычки. Четыре практики отделяют команды, чьи журналы решений живут, от команд, чьи журналы умирают после второй недели:

Распространенные ошибки

Четыре режима отказа объясняют большинство заброшенных журналов решений:

Мы Agile — разве это не просто избыточная документация?

Сильнейшая версия возражения заслуживает правильного изложения: документация имеет реальную стоимость, большинство документов никогда не читается, и команда, которая тратит свои силы на написание о работе вместо того, чтобы ее выполнять, делает себя медленнее без причины. Инсайт Agile — рабочее программное обеспечение важнее обширной документации — был исправлением реальной проблемы.

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

Честное предупреждение: практика терпит неудачу, когда она навязывается как театральный процесс — обязательные поля, в которые никто не верит, записи, сделанные для того, чтобы удовлетворить галочку. Она работает, когда команда ощутила ту боль, которую предотвращает. Если ваша команда еще не потеряла ни одного решения, начните с одной записи в журнале для вашего следующего значительного звонка и позвольте первому моменту "подождите, мы это записали!" продать эту привычку.

Как Argumentree автоматически документирует решения

Все вышеперечисленное работает с вики-страницей. Причина, по которой мы создали Argumentree, заключается в том, что самая сложная область для ручного заполнения — это поле 3 — аргументы — потому что они возникают в процессе обсуждения, и записывать их позже означает подводить итоги по памяти. В Argumentree само обсуждение структурировано: вопрос ясен, варианты и их аргументы "за" и "против" образуют дерево, а рейтинги показывают, какие аргументы действительно повлияли на решение.

Что означает, что запись решения не является документом, который кто-то пишет после встречи — это структура самой встречи, сохраненная. Все семь полей автоматически заполняются: вопрос, варианты, аргументы, решение, обоснование (путь выигравшего аргумента), владелец и дата обзора. Нет этапа транскрипции, нет искажения памяти, и полное обоснование остается доступным для проверки каждым будущим читателем. Посмотрите это от начала до конца в интеллекте встреч. Если вы хотите попробовать формат на реальном решении на этой неделе, вы можете начать бесплатно и задокументировать следующее, пока вы его принимаете.

Решения — это актив, если вы их сохраняете.

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

Начните с меньшего, чем кажется серьезным. Следующее значительное решение: пять минут, семь полей, один доступный для поиска дом, одна дата обзора. Когда новый руководитель инженерного отдела спрашивает: "Почему мы не построили это сами?" — и кто-то отвечает за сорок секунд вместо трех встреч — практика окупится сама собой, навсегда.