Ошибки продуктовой архитектуры, которые ранние команды совершают и исправляют

Почему это начинается рано

Ранние команды формируют продукт ещё до того, как понимают его нормальный путь. Они разговаривают с несколькими потенциальными клиентами, слышат несколько разных проблем и пытаются сказать «да» всем. Это кажется разумным, когда каждая сделка выглядит срочной. Но так продукт уходит в сторону исключений вместо понятного default.

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

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

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

Через несколько месяцев команда уже не строит один продукт с понятным потоком. Она поддерживает нечто, что ведёт себя как три маленьких инструмента, склеенных вместе. Support видит одну версию, sales описывает другую, а engineering знает ещё и третью, которая появляется только в крайних случаях.

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

Customer forks начинаются с одного исключения

Большинство customer forks не начинается с большой стратегии. Они начинаются с просьбы одного клиента сделать исключение. Возможно, ему нужен дополнительный шаг согласования, другой вид счёта или workflow, который пропускает часть обычного процесса. Запрос звучит небольшим, сделка важна, и команда хочет сказать «да».

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

Первая копия — ещё не главная проблема. Проблема начинается после неё. Теперь исправление бага требует двух проходов. Для релиза нужны две проверки. Когда основной поток меняется, кастомный путь отстаёт или ломается. Support сначала выясняет, какой версией пользуется клиент, а потом уже отвечает на базовый тикет. QA вынужден тестировать одну и ту же функцию дважды, с чуть разными шагами, и объём работы продолжает расти.

Иногда fork можно услышать раньше, чем его видно в коде. Команда перестаёт говорить об одной функции и начинает использовать раздельные названия вроде «standard flow», «client-specific version», «old billing path» или «custom screen». Как только появляется такой язык, продукт уже дрейфует.

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

Этот паттерн расползается тихо. Один особый запрос превращается в налог на обслуживание каждого спринта. К тому моменту, когда команда чувствует цену, fork уже формирует roadmap.

Смешанные правила биллинга делают простой продукт запутанным

Проблемы с биллингом начинаются рано, потому что первая настройка обычно простая: один monthly plan, один trial, одна дата продления. Потом sales обещает индивидуальную скидку, один клиент вносит оплату за год вперёд, а другой получает add-on, который продлевается в другую дату. По отдельности всё это не выглядит серьёзно. Проблемы начинаются, когда каждое исключение живёт по своей логике.

Обычно это происходит потому, что pricing хранится сразу в нескольких местах. Sales держит заметки в CRM или чате. Приложение хранит свои флажки plan и даты trial. Finance выставляет счета через другой инструмент. И каждое место отвечает на один и тот же вопрос по-своему: сколько этот клиент должен заплатить сегодня?

Хаос становится сильнее, когда скидки, trial, credits и add-ons не подчиняются одному набору правил. Скидка 20% в одной системе применяется до налога, а в другой — после. Бесплатный месяц продлевает сервис в приложении, но никогда не появляется в счёте. Add-on у одного клиента списывается сразу, а у другого ждёт продления, потому что кто-то обработал это вручную.

Потом finance задаёт простые вопросы и получает три разных ответа. Каков на самом деле тариф этого клиента? Когда начался биллинг? Какая скидка ещё действует? Почему итог в счёте не совпадает с продуктом?

Именно тогда refunds превращаются в ручную работу. Кто-то проверяет заметки продаж, кто-то читает код, кто-то сравнивает старые счета построчно. Даже небольшое исключение в биллинге может занять полчаса на разбор. Сделайте это десять раз в неделю — и стоимость уже перестаёт быть маленькой.

Исправление должно быть скучным — это хорошо. Соберите правила тарифов в один источник правды. Определите, как работают trial, скидки, продления и add-ons, до того как sales начнёт делать кастомные обещания. Если команде нужно исключение, сделайте его явным в модели биллинга, а не прячьте в заметке или скрипте.

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

Недостающие карты ответственности тормозят каждое решение

Команда может какое-то время быстро двигаться даже с неаккуратной схемой. Но потом одна проблема затрагивает signup, billing и permissions, и никто не может сказать, кто отвечает за весь поток. Баг зависает в очереди, потому что каждая команда владеет только своей частью.

Такое постоянно происходит в ранних продуктах. Product пишет правило, engineering строит часть, а support первым видит поломку. Когда клиент не может получить доступ к платной функции после апгрейда, support винит billing, billing указывает на auth, а engineering говорит, что product определил логику тарифа. Никто не совсем неправ. Но никто и не отвечает за результат целиком.

Цена здесь больше, чем один баг. Команды меняют общие части, не предупреждая друг друга. Один разработчик обновляет проверки ролей для новой функции. Через неделю другой меняет правила trial. Support узнаёт об этом только после жалоб пользователей. И вот уже команда тратит две встречи на проблему, которую можно было предотвратить пяти минутами предупреждения.

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

Это сокращает повторяющиеся споры, потому что команда перестаёт спорить по памяти. Люди понимают, кто принимает решение, кто делает ревью и кого нужно подключить заранее. Это помогает и новым сотрудникам: им не нужно гадать, относится signup к growth, backend или platform.

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

Если в вашей команде постоянно звучит: «Я думал, это их зона», составьте карту на этой неделе. Разместите signup, billing, permissions, notifications и account changes на одной странице. Назначьте по одному владельцу на каждый поток, даже если над ним работают несколько человек.

Маленький пример SaaS

Представьте SaaS-команду из трёх человек. У неё один тариф, один ежемесячный счёт и один владелец аккаунта. Signup создаёт аккаунт, billing списывает деньги с карты, а владелец приглашает остальных в команду. Всё просто и аккуратно.

Потом первый крупный клиент просит исключение. Ему нужны две роли админа, потому что finance должен видеть счета, но не менять настройки продукта. Команда добавляет несколько проверок ролей в приложении и идёт дальше.

Через месяц другой клиент просит кастомные счета. Ему нужен номер purchase order, другая дата списания и ручная проверка перед оплатой. Команда патчит billing code, потому что сделка важна, а изменение кажется маленьким.

Сразу ничего не ломается. Именно поэтому такие ошибки живут месяцами.

Проблема не только в самих исключениях. Проблема в том, что никто не записывает, где заканчивается ответственность каждого правила. Billing отвечает за даты счетов? Account system отвечает за роли? Кто решает, может ли пользователь скачать счёт, поставить workspace на паузу или изменить seats в неоплаченный период?

После нескольких быстрых релизов границы размываются. Логика аккаунта начинает проверять статус счёта. Billing code начинает читать роли пользователей. Permissions зависят от customer-specific flags. Сотрудникам поддержки нужны ручные шаги для нескольких аккаунтов.

Через шесть месяцев каждый релиз задевает одну и ту же рискованную зону. Небольшая функция вроде annual billing или нового лимита seats теперь затрагивает настройку аккаунта, permissions, генерацию счёта и email-потоки.

Команде кажется, что она стала медленной, хотя релизы по-прежнему выходят. А баги становятся всё страннее. Один клиент может добавлять пользователей без оплаты. Другой получает не тот шаблон счёта. Новая роль работает в dashboard, но ломается в admin screen, потому что две части приложения используют разные правила.

Вот так и начинаются customer forks. Никто не планировал fork заранее. Команда просто продолжала говорить «да» маленькими кусками.

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

Как проверить структуру до того, как она разрастётся

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

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

Сначала перечислите области, которые всё время меняются: pricing, permissions, onboarding, reporting и account settings — частые проблемные зоны. Для каждой области отметьте, какие правила действуют для всех клиентов, а какие существуют только для одного тарифа, одной сделки или одного клиента. Затем поставьте рядом с каждой областью одного владельца. Этот человек не делает всю работу сам — он решает, что делать, когда правила конфликтуют.

Дальше ищите дублирующиеся потоки, которые делают одну и ту же работу с небольшими отличиями, например два signup path или два шага одобрения счёта. Такие копии почти никогда не остаются дешёвыми. Они создают два места для тестирования, два места для объяснения и два места, где может что-то сломаться.

Потом останавливайтесь перед каждым новым исключением, прежде чем кто-то начнёт его строить. Спросите, почему оно не может вписаться в текущий набор правил. Этот шаг важнее, чем многие founders ожидают. Фраза «давайте просто добавим один флажок» звучит дёшево, но такой флажок часто создаёт ветку в биллинге, support, reporting и admin tools. Через неделю уже никто не помнит, зачем он вообще существует.

Не менее важна и ответственность. Если billing rules принадлежат sales в понедельник, product во вторник, а engineering в пятницу, команда и дальше будет выпускать заплатки вместо устойчивых правил. Один понятный владелец удерживает систему в согласованном состоянии, даже когда над ней работают сразу несколько человек.

Для этой проверки не нужен воркшоп или комитет. Один founder, один product lead и один engineer часто могут сделать это меньше чем за час. Если страница уже выглядит неаккуратно, лучше исправить это до начала следующей функции. Рост только сделает беспорядок дороже.

Ошибки, которые наставники видят снова и снова

Ранние команды создают долгосрочные проблемы, называя их временными решениями. Для клиента появляется один особый workflow. В заметках продаж остаётся одно исключение по цене. Один инженер говорит: «Потом всё поправлю». Но потом обычно не наступает, и продукт начинает носить старые решения везде.

Кастомная работа наносит наибольший вред, когда команда воспринимает её как частный случай, а не как продуктовое решение. Если founder согласился на особый approval path, формат экспорта или admin screen, этому решению нужно своё ясное место в системе. Если оно не подходит, командe стоит либо держать его отдельно, либо сказать «нет». Оставлять его наполовину внутри основного продукта — это и есть путь к росту customer forks.

Биллинг запутывается по-своему. Команды хранят правила в чатах, PDF с предложениями или в таблице, которую обновляет только sales. Потом engineering строит по памяти. Support тоже отвечает по памяти. И вскоре никто уже не может сказать, какое правило настоящее: то, что в приложении, то, что в контракте, или то, что пришло в Slack три месяца назад.

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

Одни и те же признаки повторяются снова и снова. Команды добавляют ещё один флажок вместо того, чтобы убрать старое правило. Sales и engineering описывают один и тот же тариф разными словами. Support вынужден спрашивать одного человека, прежде чем отвечать на вопросы по биллингу. Никто не владеет картой того, кто принимает product rules и кто их обновляет.

Проблему флажков легко не заметить, потому что каждый флажок кажется дешёвым. Один для legacy pricing, один для кастомного клиента, один для старого trial flow. Через какое-то время уже никто не понимает, какие сочетания ещё важны. Код может по-прежнему работать, но команда с каждым спринтом двигается медленнее.

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

Короткая проверка перед следующим спринтом

Многие ошибки архитектуры остаются незаметными, пока команде не приходится объяснять продукт вслух. Короткая проверка перед planning спринта может поймать их, пока исправление ещё дешёвое.

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

Используйте четыре простые проверки. Может ли новый коллега объяснить тарифы и биллинг за пять минут? Может ли support сказать, кто владеет каждым сломанным потоком? Может ли команда проследить один запрос клиента от signup до счёта на реальном примере, а не по схеме? Можно ли убрать одно старое исключение, не ломая продукт?

Здоровые продукты обычно проходят этот тест с несколькими шероховатостями, а не с полной путаницей. Support может назвать владельца. Engineering может объяснить, где живёт правило. Finance может сказать, почему счёт выглядит именно так. Новым сотрудникам не нужен отдельный тур, чтобы понять, кто за что платит.

Попробуйте один сценарий. Клиент регистрируется на trial, апгрейдится на третий день, а потом просит перейти на annual billing. Если вашей команде нужны три Slack-треда и две догадки, чтобы объяснить результат, остановите спринт и сначала приведите в порядок этот путь.

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

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

Большинству ранних команд не нужен полный rebuild. Им нужна одна понятная работа по очистке той части продукта, где появляется больше всего исключений. Выберите область, которая чаще всего всплывает в support, sales или planning. Для многих команд это логика биллинга, поведение для конкретных клиентов или workflow, за который никто полностью не отвечает.

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

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

Следующий шаг менее комфортный. Поставьте на паузу новые кастомные обещания, пока команда не согласует границу между продуктовой работой и разовыми задачами. Если sales предлагает особый billing flow для одной сделки или founder снова говорит «да» очередной кастомной ветке, команда добавляет ещё больше скрытых издержек. Короткая пауза сейчас дешевле, чем месяцы патчей потом.

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

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

Если одни и те же проблемы продолжают возвращаться, внешний обзор может помочь до того, как код застынет вокруг неверных решений. Oleg Sotnikov через oleg.is работает со стартапами и небольшими бизнесами как Fractional CTO и advisor, часто именно над такими вопросами: границы продукта, логика биллинга, выбор инфраструктуры и переход к AI-augmented software development. Практический ревью на этом этапе обычно намного дешевле, чем исправлять неверную структуру после начала роста.

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