Потребность в [глубоком] анализе IT-системы которую вы сами проектировали и разрабатывали говорит о том что у вас проблемы… с чем? Глобально проблема в преобразовании организационного знания. Согласно теории Такучи и Нонака (а на кого нам еще опираться), их спиральной модели, явно присутствуют витки преобразования неявного знания в явное. На изображении показано, что происходит. Все начинается с небольшой экономии времени на документации, а заканчивается ситуацией, когда даже создатели системы не могут в ней разобраться без глубокого анализа. Каждый новый виток цикла делает систему менее управляемой и более дорогой в поддержке. Если более формально, то проблема в переходе неявных знаний из голов разработчиков, архитекторов и аналитиков в явное знание в документах и артефактах. Но тут все не так просто, в этом процессе есть минимум три функции: - Функция сохранения знания - Функция передачи знания - Функция использования знания Теперь ближе к конкретике. Три ключевые причины, которые проецируются на эту модель: 1. Архитектурный долг Когда вы писали систему, вы «сэкономили» время на документации. Вы взяли кредит. Сейчас вы не просто работаете, вы платите проценты по этому кредиту. То время, которое вы тратите на анализ – это штраф за то, что решения не были зафиксированы тогда и чем дольше система живет без описания, тем дороже стоит каждое следующее изменение. Это называется «эрозия архитектуры» — реальность уплыла от задумки, и никто не знает, где правда. 2. Культура устной передачи информации Вы общаетесь в чатах, на митингах. Вы обсуждаете сложные решения, киваете и идете писать код. В этот момент происходит сбой. Вы проговорили (социализация), но не записали (экстернализация). Все договоренности живут ровно до тех пор, пока контекст свеж в памяти. Потом это превращается в мифы и легенды. Нет процесса, который заставляет превращать разговор в документ. 3. Героизм Я этот пример приводил на курсах по DevOps как один из видов потерь в бережливом производстве. Если для понимания системы нужен конкретный человек, значит, система неустойчива. Это монополизация знаний, иными словами Bus Factor = 1 4. Бизнес находится в заложниках у памяти сотрудника :) И это, внезапно, не признак незаменимости сотрудника, а признак хрупкости бизнеса. Но героем быть выгодно и приятно :) В качестве конкретных шагов, что можно сделать прямо сразу: 1. Установить налог на знания. Ни одно решение не считается завершенным, пока оно не задокументировано - буквально, например, pull request уходит в реджект. 2. Снизить bus factor - минимум три человека хорошо знают какую-то одну область. Сессии по передачи знаний здесь хорошо работают. Кстати, Event Storming с дальнейшим погружением в архитектуру достаточно не плох в этом. 3. Выделить время на возврат долга и добавить задачи в бэклог. Вычистить устаревшее, обновить схемы, артефакты, документы. Самый простой и сложный пункт одновременно, тут и время надо выделить и дисциплина нужна. Разумеется и причин и средств на порядки больше, и в каждой компании/команде они могут быть «немного» своими, тут книгу написать можно, но в общех чертах постарался сформулировать, чтобы отразить основную мысль.