За годы работы в разнообразных командах я много раз видел одну и ту же ситуацию.Компания растёт, продукт усложняется, и в какой-то момент возникает естественное желание разбить всё на отдельные продуктовые команды. Каждая отвечает за свой кусок функционала, свою часть пользовательского пути, свою метрику, свой backlog. На бумаге это выглядит правильно: меньше зависимостей, больше автономии, быстрее принятие решений.Но у такого подхода есть побочный эффект, о котором обычно говорят слишком поздно.Знание о продукте начинает фрагментироваться.Одна команда знает, почему была изменена логика онбординга. Другая помнит, какие ограничения есть у биллинга. Третья когда-то проводила исследование, из которого следовало, что пользователи вообще не понимают текущую модель прав доступа. Где-то это лежит в презентации. Где-то в Notion. Где-то в Confluence. Где-то в почте. Чаще всего — в голове конкретного человека.Пока этот человек рядом, система вроде бы работает. Можно написать ему в Slack, позвать на встречу, спросить: «А почему мы тогда сделали именно так?» Он вспомнит, расскажет, иногда даже найдёт старую ссылку. Но стоит человеку уйти, сменить роль или просто перестать быть доступным, как часть продуктовой памяти исчезает вместе с ним.И это не исключение. Это нормальное состояние большинства организаций.Однажды в большой корпорации у нас сменился Product Owner. На первой встрече с новым PO я спросил, что ему передал предыдущий. Ответ был примерно такой: «Мы встретились, он рассказал мне, что к чему». Читать далее