Давным-давно работал я в компании, занимавшейся заказной разработкой. Будем откровенны, для заказной разработки один из важных моментов — разделение ответственности и быстрое решение конфликтов. Потому что никому не хочется разбираться с множеством исправлений за свой счёт. Плюсом к этому в компании не хватало внутренних коммуникаций: договорённости фиксировались плохо, а словам верить было не принято.
И созрел план — наладить коммуникацию через написание архитектурной документации, фиксировать в ней договорённости, возникающие между разными ветвями разработки и менеджментом. Разработали шаблоны, чтобы было проще фиксировать мысли. Обучили разработчиков новому и встроили практики в рабочий процесс. На мой сегодняшний вкус — возможно чрезмерно жёстко, по принципу "нет архитектурного описания — нет задачи", но это работало.

Ну… Как работало… )

Первые полгода-год меня поносили всеми немыслимыми словами и менеджеры, и разработчики. Добавил работы на пустом месте.
А потом люди начали понимать плюсы, особенно когда проект зарелизили и полезли баги в production. Когда благодаря зафиксированным знаниям разработчикам удавалось быстро влезать в незнакомые сервисы, а менеджеры сами могли диагностировать проблемы с помощью Postman и хорошего описания API.


Некоторые изменения очень трудно продать, невозможно забыть и очень непросто оценить. Но таков путь.