Где-то уже недели 4 (с тех пор как у меня самого "щёлкнуло") я уделяю 3-5 часов в неделю тренировке подчинённых (и, при случае, более "отдалённых" коллег) пониманию связи ролей, интересов и практик — и удержанию во внимании связанных с этим изменений. Естественно, это подводит их к пересмотру собственных практик и планированию постепенного (и согласованного между разными людьми/командами!) обновления их стека.
Важная практика, которую приходится ставить практически "с нуля" (с очень примитивной, нигде не описанной, ad-hoc системы, наросшей эволюционно без какого-то дизайна для затыкания дырок "в моменте") — управление знаниями (knowledge management). Команда растёт, проекты и задачи всё более разнообразны — и полагаться на дедовские методы ("я просто подсмотрю в коде" и "я найду, у кого спросить" в основном) больше не выходит.
При этом большая часть "традиционных" knowledge management практик очевидно противоречат остальным инженерным Agile-практикам, который мы применяем: "по классике" Agile предполагает, что код (в том числе Infrastructure as a code) — единственное необходимое описание нашего проекта (чтобы избежать церемоний, связанных с согласованием нескольких разных описаний; при этом прожекторный подход — также чересчур громоздок). Один из тезисов в Agile Manifesto вполне прямо звучит как "Working software over comprehensive documentation". Это означает, что в наших текущих практиках любая другая документация (в особенности — архитектурная и пользовательская) появляется только при крайней необходимости, и мгновенно устаревает и рассогласовывается с реалиями активно дорабатываемых описаний кодом.
Практики Agile Knowledge Management (см. например https://pmworldlibrary.net/wp-content/uploads/2016/05/pmwj46-May2016-Paterek-effective-knowledge-management-in-agile-second-edition.pdf и https://www.searchunify.com/blog/agile-knowledge-management-why-how-to-inculcate-it/) предлагают разрешать это противоречие. Кому-то в Agile-команде неизбежно приходится играть роль отвечателя на вопросы — и вот в эту-то роль и добавляется практика документирования всех этих ответов. При этом вместо выбора и насаждения единственно-верной системы для поддержания этой документации (ибо "Individuals and interactions over processes and tools") предполагается оставить за командами гибкость в выборе способа документирования — но ограничить (и, в свою очередь, прошить в общем каталоге) места размещения этой документации, в зависимости от типа (комментарии к коду — только в самом коде, инструкции для пользователей — только в Notion, инфраструктурные диаргаммы — только в DevOps wiki). После этого важно сфокусироваться на культивации практики "research before asking" в ролях-пользоватях документации; для этого предполагается не только собственно тренировать спрашивающих сначала искать информацию, но и снабдить их технологией, которая позволит не задумываться про места размещения (и точную формулировку запросов), предлагая внутренний поисковик по всем источникам разом (тут есть некоторый выбор технологий собственно поиска, но в силу организационной специфики конечное решение купить невозможно, и придётся строить).
Удивительным образом, отвечатели в "моих" командах согласны потерпеть и добавление новых обязанностей-практик в свою деятельность, и неизбежно турбулентный переходный период. А вот со спрашивателями не всё так просто — слишком велики опасения "застрять" между недоработанной технологией, которая не отвечает на вопрос, и отвечателем, который не хочет больше вникать в вопрос, а тупо переадресует обратно к роботу. Пока мне кажется, что для разрешения этого конфликта достаточно будет ввести практику "отвечатель всегда ищет в базе знаний за спрашивателя, раз уж тот пришёл". Если результаты такого поиска правильно "запакетировать" (экстремальный пример здесь — https://www.letmegooglethat.com/; нам, понятно, подойдёт гораздо более мягкий и уважительный вариант), то со временем всё больше и больше вопросов будут приходить сначала во внутренний поисковик, и только потом — к отвечателям.