Пункт действия против решения: почему ваши заметки с собраний фиксируют не то, что нужно

Встреча заканчивается хорошо. Три пункта действий появляются в трекере в течение нескольких минут: "Перенести биллинг на Поставщика A — К., конец спринта." "Устареть старую конечную точку — С., пятница." "Обновить страницу с ценами — М., четверг." Владельцы, сроки, критерии завершения. Учебник.

Шесть месяцев спустя все три задачи давно закрыты — и новый руководитель команды смотрит на Поставщика A, спрашивая, почему он был выбран вместо очевидной альтернативы. Трекер содержит ответ на вопрос, который никто не задает: кто мигрировал биллинг и когда. Вопрос, который задается — почему — никогда не был задачей для выполнения. Это было решение, от которого исходили задачи, и оно не зафиксировано нигде.

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

Элемент действия против решения: фактическая разница

Поставьте два артефакта рядом, и они будут отличаться по всем важным свойствам:

Почему решение является долговым активом

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

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

Что фиксирует реальный протокол решения

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

Затем свяжите вниз: каждый пункт действия, который выполняет решение, ссылается на него. "Миграция биллинга — К., конец спринта (Решение #47)." Один указатель, и инертная история трекера становится навигационной обратно к живому рассуждению — что также является основой используемого аудита решений. SPADE называет ту же самую линию в своих собственных письмах: D производит решение, а пункты действия — это то, что выпадает из E после этого — два артефакта из одного ритуала, что и является тем разделением, за которое выступает этот пост.

Журнал решений — это не список задач.

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

Две системы сосуществуют без конфликтов в тот момент, когда каждая из них хранит свой собственный артефакт: трекер отслеживает работу, журнал фиксирует выборы, а указатели соединяют их. (Версия на уровне документа того же разделения: протоколы заседаний против журнала решений.)

Наши билеты уже содержат контекст

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

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

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

Как Argumentree фиксирует решения — с прикрепленным обоснованием

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

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

Отслеживайте работу. Сохраняйте причину.

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

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