Что у наших отраслевых продуктов общее, что приходится каждый раз писать заново и почему мы публикуем реестр статусов вместо счётчика продуктов.
Содержание4 раздела
Что общего у всех продуктов
В любой системе, где есть сотрудники и клиенты, повторяется одно и то же. Человек входит под своей учётной записью, у него есть роль, и роль что-то разрешает, а что-то запрещает. Кому-то уходят уведомления, кому-то выставляется счёт, переписка лежит в одном месте и находится поиском, а журнал помнит, кто что менял.
Для этого у нас есть пять обязательных сущностей - пользователь, компания, роль между ними, ключ доступа и переопределение прав для отдельной компании, - девятнадцать пакетов-возможностей и три сервиса: вход, память и оплата. Каждый из них описан на странице ядра платформы. Всё это написано один раз и не переписывается ни под одну отрасль.
Пятую сущность мы не планировали, её подсказал случай. В прокате управляющему филиала понадобился доступ к отчётности для совладельцев парка, а обычная роль управляющего такого доступа не даёт, и таблица ролей не могла выразить это исключение. Повод был отраслевой, а решение оказалось общим, и теперь оно есть во всех продуктах.
Сколько на самом деле переносится
Обычно в этом месте называют большую долю. Мы измеряли дважды, и обе цифры оказались неудобными.
CRM проката, которую мы перевели на общую основу, - это примерно 145 000 строк на TypeScript и правила, накопленные за четыре года. Из 1872 строк схемы данных отраслевыми оказались 1650, то есть 88%. Общей обвязкой были 222 строки (разбивка по таблицам).
Второй замер жёстче. Мы построили платформу аренды, потом платформу недвижимости. Отрасли соседние: в обеих объект кому-то передают, на время или навсегда. Из 113 бизнес-понятий двух продуктов общими нашлись семь, около 6%; эту цифру мы разбираем отдельно.
Этот вывод полезен не только нам. «У нас такое уже есть, останется настроить» - фраза про обвязку, о вашем бизнесе в ней ничего нет. В тексте откуда берутся четыре недели то же самое разобрано с позиции того, кто выбирает подрядчика.
Чем это подтверждено
Перевод проката на общую основу занял четыре недели. С третьей недели операторы работали в новом приложении и оформляли в нём настоящие брони.
Узким местом оказались вовсе не сроки разработки. Трижды настоящие данные проката противоречили спецификации общей основы, и каждый раз мы переписывали спецификацию, а данные оставляли как есть. Основа, которая не выдерживает встречи с продуктом, проработавшим четыре года, ещё не основа.
Один побочный результат оказался важнее запланированных. Бизнес-правила вроде «нет выдачи машины, пока договор не подписан и залог не внесён» мы встроили прямо в слой, к которому обращаются внешние ИИ-агенты. Теперь агент не может обойти правило, даже если ничего о нём не знает: в ответ он получает отказ и название нарушенного условия. Каждому следующему продукту эта защита достаётся бесплатно.
Табло, без прикрас
| Статус | Штук |
|---|---|
| В эксплуатации | 1 |
| Пилот | 2 |
| Ждут миграции | 4 |
| Расходятся со спецификацией | 4 |
| Не приведены к основе | 2 |
| Названы, не начаты | 3 |
| Заменены другими | 2 |
| Полное соответствие спецификации | 0 |
Счёт взят из реестра на 22 мая 2026 года, он опубликован в CSV.
Из восемнадцати записей в эксплуатации одна, а статуса, который спецификация назначила целью, пока нет ни у одной.
Счётчик продуктов - маркетинговое число, реестр статусов - инженерное, и заметно ошибиться может только реестр. «Восемнадцать продуктов на общей основе» переживёт любое расхождение с реальностью, а строка «одна в эксплуатации, ноль в полном соответствии» задаёт работу.
Если вы строите семейство продуктов у себя, пригодится не наш код, а привычка. До первого продукта решите, какой слой вправе знать об отрасли, выпускайте общую основу версиями и ведите реестр честно - настолько честно, чтобы на него было неприятно смотреть. Реестр, от которого никто не морщится, никто и не обновляет.
Как это выглядит для заказчика, мы разбираем в тексте о сроках внедрения.
Часто задаваемые вопросы
Что именно общее, а что пишется каждый раз заново?
Общее то, что устроено одинаково в любой системе с сотрудниками и клиентами: кто вошёл под своей учётной записью, какая у него роль, что роль разрешает и запрещает, кому уходят уведомления, кому выставляется счёт, где лежит переписка и кто что менял. Сюда же относятся шифрование персональных данных и переводы. Всё это не зависит от того, сдаёте вы экскаваторы в аренду или продаёте квартиры, поэтому пишется один раз. Заново пишется предметная область: объекты отрасли и правила перехода между этапами. У проката это единица техники, бронь и отгрузка, у агентства недвижимости - объект, объявление и сделка. Слова похожи, а правила внутри разные, и больше всего времени уходит именно на правила.
Насколько велика доля, которую приходится писать заново?
Больше, чем ожидают почти все, и мы сами в начале ожидали меньшего. Обе цифры ниже измерены. В CRM проката, которую мы перевели на общую основу, из 1872 строк схемы данных 1650 оказались отраслевыми, то есть 88%, и только 222 строки были той обвязкой, которую даёт основа. Вторая цифра ещё жёстче: когда мы построили второй продукт в соседней отрасли, у двух продуктов из 113 бизнес-понятий общих нашлось семь, около 6%. Если вы выбираете подрядчика, вывод простой: фраза «у нас такое уже есть, останется настроить» говорит об обвязке, о вашем бизнесе в ней ничего нет. Второй случай мы разобрали в отдельном тексте, потому что цифра там неудобная и требует подробностей.
Зачем вообще строить общую основу, если переносится так мало?
Потому что экономия появляется не там, где её ищут. Прежде чем новый продукт займётся своей отраслью, ему нужны вход, компании, роли и права, счета с подключённым настоящим платёжным провайдером, приём сообщений от клиентов, уведомления, переводы, журнал изменений и шифрование персональных данных. В первый раз на этот список уходят месяцы, он одинаков для любой отрасли, и незаметная ошибка в нём всплывает на аудите безопасности, хотя на демонстрации её не видно. Когда эта часть уже построена, следующий продукт сразу начинается с самого бизнеса. Отраслевые правила всё равно были бы разными, и сэкономить на них никогда не получалось.
Почему вы публикуете реестр статусов, а не число продуктов?
Потому что счётчик продуктов - маркетинговое число, а реестр статусов - инженерное, и заметно ошибиться может только реестр. Фраза «восемнадцать продуктов на общей основе» переживёт любое расхождение с реальностью: она верна, пока хоть что-то работает. Строка «одна в эксплуатации, две в пилоте, полного соответствия спецификации нет ни у одной» задаёт работу, потому что каждый статус кто-то должен сдвинуть. Мы ведём реестр вручную и обновляем его при каждом выпуске спецификации как раз затем, чтобы он тихо не съехал к первой формулировке. По той же причине в репозитории спецификации нет исполняемого кода: спецификацию, которая сама поставляет среду выполнения, уже не с чем сверить.
