🔍 Архитектурное ревью после релиза: как разобраться в причинах, а не осудить выбор

Архитектурное ревью обычно задумывают как независимую экспертизу до реализации: проверить решения, снизить технические ошибки, сверить с ТЗ и отрезать лишнюю логику.

Классические домены: бизнес-архитектура, прикладная, данные, интеграции, техническая часть. Плюс к ним нефункциональные требования: безопасность, производительность, надёжность, наблюдаемость, сопровождаемость.

С недавнего времени у нас появилась практика проводить ревью после реализации. Что-то обобщённое между PIR (ITIL-овцы кивнут) – про извлечение уроков, и архитектурным комплаенсом – про технический долг, с перевесом в комплаенс.

Зачем после? Чтобы выяснить наличие технического долга и извлечь уроки. Когда разработчик берёт задачу из проекта, он ограничен временем. Если где-то видится блокер, он может действовать по своему опыту. И это не «плохой разработчик», это человек в конкретных условиях.

Самое важное: как донести до докладчика цель встречи. Это не суд. Цель – разобраться в причинах выбора конкретных реализаций, а не осудить его, если он пошёл вразрез с принятыми практиками. Когда это получается, разговор становится откровенным. И тогда мы видим проблему не в человеке, а в инструментах и среде: — где-то документации не хватает; — где-то накладываются ограничения платформы; — где-то требуется консультация от вендора.

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

Вывод: PIR ценен не отчётом о найденных нарушениях, а тем, что после него меняются условия работы. Если разбор заканчивается списком «кто виноват», то это просто формальность. Если после него появляются недостающие артефакты, меняется среда или подключается вендор, то это значит, что встреча сработала.

Кто проводил PIR или архитектурный комплаенс: как удавалось сделать разговор откровенным, а не защитным? 🤔

#разработка #архитектура #технический_долг #боль_разработки #самозванец