Реестр процессных решений
опубликовано: ⏰ 8Реестр процессных решений (Process Decision Record, PDR) – это документированная практика фиксации решений об изменении, введении или отмене процессов в команде. Если ADR отвечает на вопрос, какую архитектуру выбрать, то PDR – как команда будет работать.
Одна из самых частых проблем на проектах – это процессы, которые просто “исторически сложились”, либо вообще никак не сложились. Например:
- Мы делаем ревью кода по таким правилам, потому что так принято неизвестно кем и когда.
- Собираем ретроспективы, потому что так требует методология.
- Проводим демо с непонятными целями и последующими шагами, потому что так делали раньше.
- Релизы и поставка приложения выполняется одним человеком и шаги этого процесса не формализованы или недостаточно формализованы.
У кого-то в голове есть понимание, зачем всё это нужно и какую проблему решает. А бывает так, что процессов по факту нет и всё живёт на ручном управлении без какой-то формализованной логики. Но как только этот кто-то уходит с проекта, процессы остаются без владельца и вообще без понимания, как это всё поддерживать и зачем всё это существует.
По итогу команда тратит ресурсы на процессную активность, у которой непонятна цена, нет критериев пересмотра и не ясно, решает ли она ту проблему, ради которой её изначально завели. Чтобы сгладить такие ситуации, можно использовать PDR.
Цели использования PDR
PDR фиксируют решения, касающиеся процессов работы команды: церемоний, рабочих процессов, политик, метрик качества (quality gates), правил взаимодействия. Они не заменяют архитектурные решения, но дополняют их. Даже идеальная архитектура не спасёт, если команда не понимает, как с ней работать.
Основные цели:
- Отслеживаемость решений и логики за ними.
- Прозрачность – новые участники команды понимают, зачем существует тот или иной процесс.
- Сохранение знаний – не повторять ошибки, которые уже были сделаны.
- Возможность конструктивного оспаривания процесса до его внедрения.
- Оценка стоимости процессной активности (время, ресурсы, задержка).
- Измеримость – возможность оценить, принесло ли изменение ожидаемый эффект.
- Возможность пересмотра и отмены процессов при смене контекста.
- Выявление рисков и негативных факторов до того, как они стали проблемой.
- Ускорение адаптации новичков.
Область применения
PDR покрывает изменения в том, как команда организует свою работу:
- Agile-церемонии (если работа организована по подобным методологиям): ежедневные созвоны, ретроспективы, планирование и прочее.
- Технические практики, такие как ревью кода, парное программирование, оценка критериев завершённости (definition of done).
- Существующий процесс меняется или адаптируется под новую реальность (удалёнка, смена команды, рост проекта).
- Введение или отмена систем для трекера задач, нотификаций, коммуникации.
- Определение ролей и зон ответственности, кто что делает и как передаёт результаты.
- Определение практик коммуникации: внутренние и внешние.
- Корректировка контекста вокруг процесса – команда выросла втрое, проект перешёл в поддержку, сменился заказчик.
- Есть обоснованное подозрение, что процесс перестал решать ту проблему, для которой создавался.
Важно не путать PDR с ADR. ADR фиксирует решения об устройстве системы – выбор технологий, паттернов, подходов к организации кода. PDR фиксирует решения об устройстве рабочего процесса – как команда общается, как принимает решения, как оценивает качество.
Один и тот же проект может содержать и ADR и PDR. Например, ADR может зафиксировать решение использовать PostgreSQL, а PDR – решение об обязательном ревью кода перед слиянием в основную ветку.
Помимо PDR и ADR существует ещё одна вариация – Product Decision Record, которая фиксирует решения о поведении продукта и его функциональных границах. Например: “AI-сгенерированные сообщения должны оставаться в черновиках до проверки человеком”. Но это не часть этой статьи.
Структура PDR
Карточка PDR должна быть короткой, максимум 1–2 страницы. Чем сложнее процесс, тем важнее уложиться в конкретику, а не размытые формулировки вроде “мы считаем, что это поможет”.
Минимальный набор полей:
- Идентификатор – уникальный номер (например, PDR-001).
- Название – лаконичное, покрывающее суть процесса.
- Дата – когда решение заведено.
- Дата пересмотра – когда вернуться к процессу и оценить его актуальность.
- Авторы – кто инициировал.
- Статус – proposed, accepted, rejected, superseded.
- Контекст – текущая ситуация, проблема или возможность, которую решает процесс.
- Решение – что именно вводится или меняется.
- Стоимость процесса – время команды, задержка, финансовые затраты. Опционально, но крайне желательно.
- Рассмотренные альтернативы – другие варианты, их плюсы и минусы. Даже отклонённые варианты полезны.
- Обоснование – почему выбран именно этот вариант.
- Риски и негативные факторы – что может пойти не так и чего стоит ожидать.
- Ожидаемое влияние – последствия для команды, стейкхолдеров, качества продукта.
- Индикаторы успеха или провала – как измерить, сработало ли решение (метрики, наблюдения, фидбэк с ретро).
- Дальнейшие шаги – какие последующие действия запланированы, когда пересмотр.
Ниже – практический шаблон в формате Markdown, адаптированный из MADR с акцентом на процессные решения.
---
status: "{proposed | accepted | rejected | deprecated | superseded by PDR-XXX}"
date: {YYYY-MM-DD}
author: {кто принял решение}
stakeholders: {кто задействован в процессе}
review-date: {YYYY-MM-DD -- следующая дата пересмотра}
---
# {Краткое название процесса}
## Контекст и решаемая проблема
{Опишите ситуацию, которая потребовала введения процесса. Какую задачу он закрывает? Что было до него? Почему просто оставить как было недостаточно?}
## Решение
{Чётко сформулируйте, что вводится или меняется.}
## Стоимость процесса
{В чём выражается цена процесса? Время команды в часах или человеко-днях, задержка по Time to Market. Финансовые затраты на инструменты или инфраструктуру.}
## Рассмотренные альтернативы
* {Альтернатива 1} -- {плюсы}, {минусы}
* {Альтернатива 2} -- {плюсы}, {минусы}
* ...
## Обоснование
{Почему выбран именно этот вариант. Какие критерии повлияли на решение.}
## Риски и негативные факторы
* {Риск 1 и его возможное следствие}
* {Риск 2}
* ...
## Критерии пересмотра
{По каким признакам стоит вернуться к этому решению? Например: "Если команда вырастет более чем до Y человек"; "Если время на процесс превысит Z часов в спринт".}
## Ожидаемое влияние
* {Влияние на команду}
* {Влияние на качество}
* {Влияние на сроки}
* ...
## Индикаторы успеха или провала
* {Количественный: сколько времени экономит процесс, сколько ошибок ловит и т.д.}
* {Качественный: фидбэк команды, субъективные наблюдения}
* ...
## Дальнейшие шаги
* {Что делать после внедрения и когда пересматривать}
## Ссылки
{Ссылки на обсуждения, тикеты, заметки с воркшопов.}Жизненный цикл PDR
У PDR есть определённый жизненный цикл:
- Создание – любой участник команды может инициировать PDR. Идеально, если это происходит до внедрения изменения, а не постфактум.
- Обсуждение – PDR выносится на рассмотрение команды. Цель – выявить возражения, уточнения, пропущенные аспекты.
- Опубликование – принятое решение размещается в общем репозитории. Все участники и стейкхолдеры должны иметь к нему доступ.
- Мониторинг – команда отслеживает индикаторы успеха. Если решение работает, то процесс остаётся. Если нет, то PDR обновляется или заменяется новым.
- Архивация – отклонённые PDR не удаляются. Они хранятся как историческая запись, чтобы не анализировать одно и то же снова.
Инструменты
PDR, как и ADR, это обычные текстовые файлы в Markdown. Те же инструменты подходят:
Формат одинаковый, разница только в содержании.
Хранить PDR можно в отдельной директории (docs/pdr/), рядом с docs/adr/. Или в общем реестре решений, добавив поле type: process для различения. В небольших проектах хватит и одной папки docs/decisions/.
Ограничения и подводные камни
PDR полезны, но не универсальны. Пара моментов, которые стоит держать в голове:
- Требуется время на написание, это время, отнятое у разработки. Но в долгосрочной перспективе экономия на повторном обсуждении тех же вопросов перекрывает затраты.
- Самый вероятный риск, это излишняя бюрократия. PDR не должны превратиться в административную рутину или стать барьером для изменений. Не каждое решение требует полноценной карточки.
- PDR фиксирует решение, но не гарантирует, что оно правильное. Здравый смысл всё ещё нужен.
- Если реестр будет доступен за пределами команды, стоит учитывать, что некоторые процессные решения могут быть чувствительными к публикации на команду.
Заключение
Реестр процессных решений делает прозрачным то, что обычно живёт в головах, зачем введён тот или иной процесс, сколько он стоит и когда его пора пересмотреть. Без PDR процессы никак не отслеживаются. Однажды заведённая активность никогда не отменяется, даже когда она перестала решать ту проблему, для которой создавалась.
PDR не статичны. Их нужно регулярно пересматривать, не реже той даты, которая указана в карточке. И именно индикаторы успеха и провала, а не настроение должны диктовать, когда процесс меняется, улучшается или убирается.