Владение доменами после реорганизации — назначайте модули по бизнес‑областям

Что идёт не так после первой реорганизации

Первая реорганизация редко ломает код в первый же день. Она ломает память.

Когда пятеро человек строят продукт, все знают, где прячутся сложные правила. После разделения команд, смены менеджеров и сдвига приоритетов эта общая память угасает. Скоро никто не может с уверенностью сказать, кто отвечает за трудные места: исключения в биллинге, восстановление аккаунтов, лимиты возвратов, контрактная логика, правила доступа.

Именно тогда владение начинает иметь значение. Если владение следует за людьми, а не за бизнес‑областями, правила перемещаются случайно. Инженер, который понимал биллинг, уходит в другую команду, часть логики остаётся в одном сервисе, другую часть копируют в второй сервис — и теперь две части продукта принимают разные решения по одному и тому же клиенту.

Признаки легко заметить:

• Одна и та же логика встречается в двух‑трёх местах.
• Небольшие изменения превращаются в длинные потоки в Slack и цепочки встреч.
• Команды ждут одобрения, потому что никто не чувствует себя уверенно, чтобы принять решение.
• Ошибки возвращаются снова и снова, потому что исправление не дошло до другой копии.

Стартапы это чувствуют быстро, потому что ранние команды растут вокруг скорости, а не чистых границ. Это работает какое‑то время. Потом первая смена структуры выявляет слабые места. Команда checkout владеет частью логики ценообразования, платформа — другой частью, а в поддержке есть единственный человек, который знает, почему для старых аккаунтов есть исключение.

Главная проблема не в грязном коде. Она в медленных решениях. Когда владение размытое, любое изменение превращается в переговоры. Споры ведут о том, кто должен просматривать, кто тестировать и кто принимает риск в случае ошибки. Работа тормозится, даже если изменение кода крошечное.

Более удачная модель владения привязывает модули к реальным бизнес‑областям, а не к тем, кто их первым написал. Это даёт правилам стабильный дом, даже если штат меняется, команды сливаются или уходит старший инженер. Без этого организационная схема продолжит двигаться, и ваша основная логика пойдёт вместе с ней.

Что значит владение по бизнес‑области

Владение по бизнес‑области просто: каждый модуль принадлежит той части компании, правила которой он обеспечивает.

Биллинг принадлежит биллингу. Доступ к аккаунту — домену identity and permissions. Правила заказов — ordering. Многие делают наоборот: привязывают код к названию сквада, менеджеру или короткому проекту, а потом удивляются, почему через три месяца владение становится размытым.

Чёткий владелец поддерживает модуль в корректном состоянии, делает его безопасным для изменений и понятным. Этот владелец отвечает на вопросы о правилах, ревьюит изменения, которые влияют на эти правила, и решает, когда изменение требует осторожности. Другие команды по‑прежнему могут вносить вклад. Просто они не становятся владельцами по умолчанию, потому что коснулись кода в прошлом месяце.

Это важно, потому что линии отчётности меняются быстрее, чем бизнес‑правила. Стартап может перейти от продуктовых подов к функциональным командам, объединить группы после сокращений или снова разделить команду при наборе людей. Компания по‑прежнему просыпается с теми же правилами ценообразования, возвратов, доступа и жизненного цикла клиента.

Большинство продуктов имеют несколько бизнес‑областей, которые переживают реорганизации гораздо лучше, чем имена команд. Биллинг и платежи обычно остаются. Онбординг клиентов остаётся. Права и доступ остаются. Отчётность и соответствие остаются. Команда с названием «Growth squad» может исчезнуть за квартал. Биллинг — нет.

Такое разделение убирает ежедневную путаницу. Новый инженер увидит, кто владеет логикой возвратов, не спрашивая трёх менеджеров. Если кто‑то уходит, компания по‑прежнему знает, откуда должно прийти одобрение на рискованное изменение.

Один простой тест многое покажет: если вы перенесёте людей между командами завтра, останется ли у модуля ясный дом? Если да — модель работает. Если нет — модуль, вероятно, принадлежит бизнес‑области, которую никто чётко не назвал.

Сопоставьте модули с реальными бизнес‑правилами

Начните с простого списка бизнес‑областей, а не структуры папок.

Большинство кодовых баз растут случайно. В одной папке API, в другой — джобы, в третьей — общие хелперы, в четвёртой — то, что вывезли быстрее всего. Эта карта показывает, как люди кодили. Она не показывает, какие правила продукт должен защищать.

Запишите области, которые бизнес всё равно узнает после смены команд. Для многих продуктов это означает биллинг и возвраты, утверждения и права, доступ к аккаунту и идентификацию, заказы, подписки или фулфилмент.

Затем посмотрите на каждый модуль и задайте один прямой вопрос: какое правило защищает этот модуль?

Биллинг‑модуль может считать налоги, блокировать дублирующиеся списания или решать, когда возможен возврат. Модуль доступа к аккаунту может выполнять сброс пароля, ограничивать сессии или проверять роли. Если вы не можете назвать правило — модуль, вероятно, не на своём месте или делает слишком много задач.

Группируйте код вокруг действий, которые людей волнуют каждый день. Биллинг — это не только счета. Это проверки, которые не дают снять неправильную сумму. Утверждения — это не только кнопки в UI. Это кто может утверждать, когда истекает срок утверждения и что происходит после отказа. Доступ к аккаунту — это не только экраны входа. Это блокировки, правила приглашений и смены прав.

Смешанные модули наносят наибольший вред после реорганизации. Один «user service» часто скрывает правила доступа, контакты для биллинга, историю аудита и потоки утверждений в одном месте. Это выглядит аккуратно, пока одна команда не отвечает за identity, а другая — за финансы. Тогда обе команды начинают править один модуль, и никто не владеет набором правил полностью.

Разделяйте смешанные модули, когда они обслуживают разные области. Общий код держите маленьким и скучным. Форматирование дат, логирование и низкоуровневые хелперы БД могут оставаться общими. Правила времени возврата и проверки административных ролей — не должны.

Ещё один полезный тест: если одна область завтра изменила политику, сможет ли один владелец обновить код без правки модуля другой области? Если нет — граница всё ещё следует за орг‑структурой, а не за бизнесом.

Установите чёткие линии владения

Хорошее владение начинается с простого правила: у каждой бизнес‑доменной области есть один чёткий владелец.

Этот владелец может быть командой, но один человек всё равно должен иметь последнее слово. Если у никого нет окончательного решения, правила быстро расплываются. Продукт‑менеджер может задать правила скидок, инженер их реализует, поддержка заметит крайние случаи. Тем не менее нужен один домен‑владелец, который решает, каково правило, когда оно меняется и кто подписывает изменения.

У общих инструментов другая модель. SDK для платежей, event bus, дизайн‑система или внутренняя админка должны иметь владельца сервиса, а не владельца политики. Эта команда держит инструмент стабильным и удобным, но не должна решать политику возвратов, логику цен или лимиты аккаунтов для компании.

Держите права принятия решений рядом с командой, которая живёт с правилом каждый день. Команда биллинга должна утверждать правила биллинга. Команда риск‑анализа — правила антифрода. Платформенная команда может поддерживать инструмент для обработки запросов, но она не должна решать, кто получает возврат.

Это разделение особенно важно при смене людей. Если одна команда сокращается или переходит в другую область, правило всё равно имеет дом. Другая команда сможет позже взять сервис на себя, но бизнес‑логика не будет плавать в вакууме.

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

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

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

Эта граница может казаться строгой. Но она экономит споры в будущем.

Как сделать изменения шаг за шагом

Не перерисовывайте карту продукта за одну встречу. Начните с области, которая сейчас вызывает наибольшую путаницу. Обычно это место, где баги перекатываются между командами, ревью зависают или два человека дают разные ответы на один и тот же вопрос.

Простая таблица работает лучше, чем большая диаграмма. Дайте каждой строке четыре поля: бизнес‑область, модули, владелец и резервный владелец. Если таблица превращается в стену деталей, люди перестанут её использовать, и старая путаница вернётся.

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

Затем назначьте одного владельца, который решает, как должны работать правила, и одного резервного, который может быстро подменить. Это — владение решением, а не обещание, что один человек напишет весь код.

Переведите только эту доменную область на новую модель и оставьте остальное в покое, пока первая перестановка не устаканится. Такой небольшой шаг даёт людям время привыкнуть. Он также показывает, подходят ли ваши границы, прежде чем распространять модель на весь продукт.

Для каждой области напишите три коротких рабочих правила: как происходят передачи ответственности, кто ведёт инциденты и кто утверждает изменения бизнес‑правил. Держите эти правила достаточно короткими, чтобы новый инженер прочитал их за две минуты.

Небольшой пример делает это конкретным. Допустим, скидки в чекауте живут в веб‑приложении, сервисе биллинга и инструменте поддержки. Передайте всю домен‑область скидок одному владельцу, даже если три инженера работают в разных модулях. Это сокращает обычную петлю, когда фронтенд, бэкенд и поддержка каждый думает, что кто‑то другой владеет правилом.

Когда это работает, оно кажется почти скучным. Люди знают, кто решает, кто подменяет и где живёт правило.

Пересмотрите таблицу после следующей смены персонала. Реорганизации сами по себе не ломают системы. Ломают их не владения правил.

Простой пример из реального продукта

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

Доступ к аккаунту должен оставаться в домене identity. Эта команда владеет правилами входа, сброса пароля, MFA, контролем сессий, восстановлением аккаунта и тем, кто может менять почту на заблокированном аккаунте. Платформа может строить сервис входа, админские экраны и логи аудита. Identity всё равно решает, какие проверки нужно пройти, чтобы вернуть доступ.

Биллинг устроен иначе. Финансы должны владеть правилами оплаты, даже если платформа поддерживает код платежей. Финансы решают, когда требовать оплату, сколько попыток повторить списание после ошибки, когда применять кредиты и когда возврат полон, частичен или отклонён. Если продукт ошибочно списал клиента дважды, финансы владеют правилом его исправления. Платформа владеет инструментом, который выполняет это правило.

Поддержка может помогать в рамках чётких границ. Поддержка может выслать счёт, объяснить смену плана и открыть запрос на возврат. Поддержка может следовать утверждённым шагам восстановления аккаунта от identity. Но поддержка должна эскалировать спорные списания, исключения по возвратам и любые просьбы обойти проверки входа. И не должна обещать возврат, который финансы не одобрили.

Теперь представьте обычный тикет: «Не могу войти, и мне сняли деньги после отмены». На самом деле это два домена. Identity решает доступ. Финансы решают, стоит ли возвращать списание. Поддержка полезна, когда правильно маршрутизирует обе части, а не пытается угадывать.

Вот в чём суть. Финансы владеют денежными правилами. Identity владеет правилами доступа. Платформа строит и эксплуатирует общие системы. Когда команды меняются позже, правила всё ещё имеют ясный дом.

Ошибки, которые оставляют правила сиротами

Большинство проблем владения начинаются не с плохого кода, а с расплывчатой подотчётности.

Правило ценообразования, шаг утверждения или лимит аккаунта по‑прежнему существует в продукте, но никто не может сказать, у кого последнее слово, когда правило нужно менять.

Одна распространённая ошибка — назначать владение тому, кто первым написал модуль. Это звучит справедливо, но ломается быстро. Первый разработчик мог написать код годы назад, перейти в другую команду или рассматривать задачу как техническую, а не бизнес‑задачу. Владение должно следовать за правилом, которое код защищает, а не за именем в старом коммите.

Ещё одна ошибка — по умолчанию сваливать все общие модули на платформу. Общий код не нейтрален. Если в модуле есть правила возвратов, лимиты мест, контрактная логика или права доступа, бизнес‑команда должна владеть этими решениями. Платформа должна владеть инструментами, инфраструктурой и общими паттернами, а не каждым правилом, которое несколько команд случайно затронули.

Команды также создают проблемы, когда делят одно правило между тремя менеджерами. Простое правило «когда клиент может приостановить подписку» может затрагивать биллинг, состояние аккаунта и нотификации. Если три менеджера могут менять по одному фрагменту без владения целым правилом, накапливаются крайние случаи. Один владелец должен нести общую ответственность, даже если несколько команд помогают с реализацией.

Резервные владельцы важнее, чем многие признают. Высокорисковые области — платежи, контроль доступа и шаги соответствия — не могут зависеть от одного человека. Назначьте основного и резервного. Если никто не может принять решение во время отпуска, болезни или увольнения, область уже уязвима.

Переименование команды не решит этого. Называть команды «core», «growth» или «experience» может привести к аккуратной орг‑карте, но не создаёт границ модулей. Коробки двигаются. Правила остаются там, где были, наполовину принадлежащие и легко теряющиеся.

Если вы спросите «кто решает конкретное правило», например право на возврат или окончание триала, и людям нужен митинг, чтобы ответить — правило уже сиротливо.

Быстрые проверки перед финальной фиксацией

Если зафиксировать карту слишком рано, вы заморозите путаницу в кодовой базе. Хорошая модель владения должна пережить новых менеджеров, переходы команд и даже заморозку найма.

Проведите короткий обзор перед тем, как делать что‑то официальным.

Во‑первых, сопоставьте каждый модуль одной бизнес‑области. Если модуль одновременно кажется и продажам, и поддержке, и финансам, граница слабая. Разделите его, переименуйте или перенесите правило в область, которая действительно его решает.

Во‑вторых, назначьте одного владельца и одного резервного для каждого чувствительного правила. Цены, возвраты, права, проверки на соответствие и доступ пользователя не должны зависеть от одного человека.

В‑третьих, проверьте видимость для менеджеров. Поставьте нового менеджера перед картой и спросите: «Кто решает изменения в биллинге? Кто утверждает изменения доступа?» Если он не может ответить за пять минут, линии владения всё ещё слишком грязные.

В‑четвёртых, стресс‑тест на сокращение штата. Уберите на бумаге одну команду или одного лидера. Если какая‑то бизнес‑область теряет своего решающего — риск сиротства остаётся.

Небольшой пример упрощает оценку. Допустим, есть модуль «subscriptions», но продукт меняет имена планов, финансы ставят правила возвратов, а поддержка правит кредиты аккаунтов. У этого модуля нет одного реального владельца. Код может находиться у одной команды, но правила живут в трёх местах. Такая схема обычно ломается при следующей реорганизации.

Вам нужна карта, которую незнакомец сможет быстро прочитать. Биллинг должен указывать на одну область. Контроль доступа — на одну область. Совместный ввод допускается, но одно лицо должно принимать решение и держать правила в согласованном виде.

Часто реальная проблема в том, что орг‑схема сменилась, а карта решений — нет. Исправьте это до того, как переводить владение модулем в планирование, найм или архитектурные документы.

Что делать дальше

Запишите карту владения, пока детали ещё свежи. Одностраничная операционная заметка обычно работает лучше, чем слайды. В ней должно быть: каждая бизнес‑область, модули внутри неё, кто решает изменения правил и кто покрывает работу, когда кто‑то меняет роль или уходит.

Держите документ коротким и чётким. Если его нельзя просканировать за две минуты — он слишком длинный. Он должен отвечать на прямые вопросы: какое бизнес‑правило живёт в модуле, какая команда владеет правилом ежедневно, кто утверждает изменения, затрагивающие биллинг или права, и когда модуль нужно разделить или почистить.

Включайте эту заметку в обычную работу команд. Просматривайте её при планировании, чтобы команды не обещали работу в областях, которыми не владеют. Используйте её при найме, чтобы добавлять людей в перегруженную бизнес‑область, а не просто в самую заметную команду. Подключайте её к разговорам о реорганизации до того, как сдвинутся ящики в орг‑карте.

Карта также помогает заметить проблемы заранее. Если две команды постоянно трогают один и тот же модуль по разным причинам — граница, вероятно, неверна. Если у модуля номинально один владелец, но на деле их трое — разделите или почистите его до следующей передачи, чтобы не получить медленную кашу.

Маленькая продуктовая команда может сделать это за пару часов. Начните с модулей, которые касаются денег, доступа, состояния клиента или правил соответствия. Оставьте споры о формулировках на потом. Ясное владение важнее идеальной формулировки.

Если команда застряла, внешний обзор может сэкономить время. Oleg Sotnikov at oleg.is работает как fractional CTO и советник стартапов; такого рода очистка владения плотно входит в его работу по архитектуре продукта, дизайну команд и операционным задачам инженерии с фокусом на AI. Иногда второй взгляд достаточно, чтобы превратить смутную реорганизацию в правила, которым люди действительно смогут следовать.