Одно ядро, восемнадцать записей в реестре и одна в проде
Что у наших отраслевых продуктов общее, что приходится писать заново каждый раз, и почему мы публикуем реестр статусов вместо счётчика продуктов.
Что стоит под всеми продуктами сразу
В любой системе, где есть сотрудники и клиенты, повторяется одно и то же. Кто-то входит под своей учётной записью. У него есть роль. Роль что-то разрешает и что-то запрещает. Кому-то уходят уведомления, кому-то выставляется счёт, переписка лежит в одном месте и находится поиском, а журнал помнит, кто что менял.
Это пять обязательных сущностей - пользователь, компания, роль между ними, ключ доступа и переопределение прав для отдельной компании, - девятнадцать пакетов-возможностей и три сервиса: вход, счета и ассистент. Написано один раз, не переписывается ни под одну отрасль.
Пятая сущность появилась не из проекта, а из случая. В прокате управляющему филиала понадобился доступ к отчётности для совладельцев парка, а обычная роль управляющего его не даёт. Таблица ролей этого выразить не могла. Повод был отраслевым, решение оказалось общим, и теперь его наследуют все.
Сколько на самом деле переносится
Здесь принято называть большую долю. Мы измерили дважды, и обе цифры оказались неудобными.
CRM проката, которую мы перевели на общее основание, - это 318 757 строк и четыре года накопленных правил. Из 1872 строк схемы данных отраслевыми оказались 1650, то есть 88%. Общей обвязкой были 220 строк.
Второй замер жёстче. Мы построили платформу аренды, потом платформу недвижимости. Отрасли соседние, обе про объект, который кому-то передают на время или навсегда. Из 113 бизнес-понятий двух продуктов общими нашлись семь. Около 6%, и разбор этой цифры стоит отдельного чтения.
Отсюда следствие, полезное далеко за пределами нашей кухни. «У нас такое уже есть, останется настроить» - фраза про обвязку, а не про ваш бизнес. Откуда берутся четыре недели разбирает то же самое со стороны того, кто выбирает подрядчика.
Чем это подтверждено
Перевод проката занял четыре недели, операторы работали в перестроенном приложении с третьей и вели через него настоящие брони.
Узким местом были не сроки разработки. Трижды выходило так, что настоящие данные проката противоречили спецификации основания, и каждый раз мы переписывали спецификацию, а не данные. Основание, которое не выдерживает контакта с четырёхлетним работающим продуктом, ещё не основание.
Один побочный результат оказался важнее запланированных. Бизнес-правила вроде «нет выдачи машины, пока договор не подписан и залог не внесён» мы вписали прямо в тот слой, который вызывают внешние ИИ-агенты. Теперь агент не может обойти правило, даже не зная о его существовании: слой возвращает отказ с указанием на нарушенное условие. Каждый следующий продукт получает это даром.
Табло, без прикрас
| Статус | Штук |
|---|---|
| В проде | 1 |
| Пилот | 2 |
| Ждут миграции | 4 |
| Расходятся со спецификацией | 4 |
| Не приведены к основанию | 2 |
| Названы, не начаты | 3 |
| Заменены другими | 2 |
| Полное соответствие спецификации | 0 |
Восемнадцать записей. Одна в проде. И статуса, который спецификация назначила целью, нет пока ни у одной.
Счётчик продуктов - маркетинговое число, реестр статусов - инженерное, и ошибиться заметно может только первое. «Восемнадцать продуктов на общем основании» переживёт любое расхождение под собой. «Одна в проде, ноль в полном соответствии» создаёт работу.
Тем, кто строит семейство продуктов у себя, отсюда переносится не наш код, а привычка: решить до первого продукта, какому слою разрешено иметь мнение, поставить общее основание под версию и вести реестр честно - настолько честно, чтобы на него было неприятно смотреть. Реестр, от которого никто не морщится, никто и не обновляет.
Как это выглядит со стороны заказчика, а не разработчика, разобрано в сроках внедрения.
01Что именно общее, а что пишется каждый раз заново?+
Общее - то, что устроено одинаково в любой системе, где есть сотрудники и клиенты: кто вошёл под своей учётной записью, какая у него роль, что роль разрешает и запрещает, кому уходят уведомления, кому выставляется счёт, где лежит переписка и кто что менял. Сюда же шифрование персональных данных и переводы. Ничего из этого не зависит от того, сдаёте вы экскаваторы или продаёте квартиры, поэтому пишется один раз. Заново пишется предметная область: объекты отрасли и правила перехода между этапами. У проката это единица техники, бронь и отгрузка. У агентства недвижимости это объект, объявление и сделка. Слова похожи, правила внутри разные, и время стоят именно правила.
02Насколько велика доля, которую приходится писать заново?+
Больше, чем ожидают почти все, включая нас самих в начале. Две цифры, обе измеренные. Первая: в CRM проката, которую мы перевели на общее основание, из 1872 строк схемы данных 1650 оказались отраслевыми, то есть 88%, и только 220 строк были той обвязкой, которую даёт основание. Вторая жёстче: когда мы построили второй продукт в соседней отрасли, из 113 бизнес-понятий двух продуктов общими оказались семь. Около 6%. Отсюда простое следствие для любого, кто выбирает подрядчика: фраза «у нас такое уже есть, останется настроить» описывает обвязку, а не ваш бизнес. Разбор второго случая мы вынесли отдельно, потому что цифра там неудобная и заслуживает подробностей.
03Зачем вообще строить общее основание, если переносится так мало?+
Потому что экономия приходит не оттуда, где её ищут. Прежде чем новый продукт сможет заняться своей отраслью, ему нужны входы, компании, роли и права, счета, подключённые к настоящему платёжному провайдеру, приём сообщений от клиентов, уведомления, переводы, журнал изменений и шифрование персональных данных. В первый раз этот список занимает месяцы, он одинаков для любой отрасли, и любая незаметная ошибка в нём всплывает не на демонстрации, а на аудите безопасности. Построенное однажды, оно позволяет следующему продукту начинаться там, где начинается собственно бизнес. Отраслевые правила в любом случае были бы разными, и выигрыша там никогда и не было.
04Почему вы публикуете реестр статусов, а не число продуктов?+
Потому что счётчик продуктов - маркетинговое число, а реестр статусов - инженерное, и ошибиться заметно может только первое. Фраза «восемнадцать продуктов на общем основании» переживёт любое расхождение под собой: она остаётся верной, пока хоть что-то работает. Строка «одна в проде, две в пилоте, полного соответствия спецификации нет ни у одной» создаёт работу, потому что каждый статус кто-то должен сдвинуть. Реестр ведётся руками и обновляется на каждом релизе спецификации ровно затем, чтобы не сползти тихо к первой формулировке. Отсюда же правило держать репозиторий спецификации свободным от исполняемого кода: спецификация, которая поставляет рантайм, перестаёт быть проверяемой хоть по чему-нибудь.
