Почему Wiki, чаты и ADR не решают проблему
Эти инструменты не фиксируют решения. Они имитируют фиксацию.
Эти инструменты не фиксируют решения. Они имитируют фиксацию.
Разница принципиальная.
Проблема не в использовании. Проблема в архитектуре
Если инструмент по своей модели не способен представить решение как объект, никакая дисциплина это не исправит.
Можно:
- писать аккуратнее;
- договариваться строже;
- вводить правила и шаблоны;
Но нельзя:
- извлечь объект из инструмента, который его не поддерживает.
Это не вопрос культуры. Это вопрос несоответствия модели.
Чаты: поток вместо сущности
Чат - это линейный поток сообщений.
Он:
- не различает обсуждение и решение;
- не фиксирует границы;
- не имеет состояния;
- не знает, что из написанного является итогом.
Решение в чате:
- не выделимо;
- не проверяемо;
- не воспроизводимо;
- не сопоставимо с другим решением.
Сообщение «договорились» не создаёт объект. Оно растворяется в потоке.
Чат фиксирует разговор. Разговор - не решение.
Wiki: текст без жизненного цикла
Wiki - это хранилище документов.
Документ:
- описывает;
- поясняет;
- аккумулирует знания.
Но решение - не знание. Решение - состояние системы.
Wiki:
- не знает, когда решение принято;
- не знает, актуально ли оно;
- не умеет фиксировать пересмотр как смену состояния;
- не различает историю и действительность.
В итоге:
- старые решения выглядят актуальными;
- новые противоречат старым без фиксации конфликта;
- пересмотр маскируется под «обновление страницы».
Wiki хранит текст. Текст - не объект решения.
Task-трекеры: процесс вместо причины
Таск-трекер фиксирует работу.
Он отвечает на вопрос:
«Что нужно сделать и в каком статусе».
Решение отвечает на другой:
«Почему это вообще нужно делать».
Когда решение зашивают в задачу:
- причина подменяется активностью;
- решение исчезает после закрытия;
- последствия остаются без источника.
Task-трекер управляет исполнением. Он не управляет причинами.
ADR: правильная идея, частная реализация
ADR - первый инструмент, который приблизился к правильной модели.
Он признаёт:
- решение как отдельную сущность;
- необходимость контекста;
- наличие альтернатив и последствий.
Но:
ADR:
- не встроен в коммуникацию;
- не покрывает все типы решений;
- не поддерживает конфликты как сущность;
- не имеет универсального жизненного цикла;
- живёт в репозитории, а не в системе управления решениями.
ADR фиксирует архитектурные решения. Все остальные остаются вне модели.
Это не ошибка ADR. Это ограничение области применения.
Почему это не вопрос дисциплины
Попытка «исправить» инструменты дисциплиной выглядит так:
- «давайте писать аккуратнее»;
- «давайте всегда обновлять Wiki»;
- «давайте помнить, что это решение»;
- «давайте договоримся не забывать».
Это означает одно: инструмент не выполняет свою функцию.
Если система требует постоянного человеческого контроля, чтобы не потерять смысл, она структурно несостоятельна.
Общая причина провала
Все эти инструменты:
- работают с текстом;
- управляют процессом;
- хранят информацию;
Но ни один из них не управляет решениями как объектами.
У них нет:
- идентичности решения;
- статуса;
- жизненного цикла;
- конфликта как сущности;
- проверяемости во времени.
Они не ломаются. Они делают не то.
Итог
Wiki, чаты, таск-трекеры и даже ADR не решают проблему фиксации решений, потому что они не спроектированы для этого.
Это не вопрос выбора инструмента. Это вопрос отсутствия подходящего класса систем.
Если инструмент не умеет представить решение как объект:
- его нельзя проверить;
- его нельзя пересмотреть;
- его нельзя конфликтовать;
- его нельзя восстановить.
Такой инструмент не фиксирует решения.
Он лишь создаёт иллюзию, что они где-то есть.