Второй продукт взял из первого 6% бизнес-логики и всё равно вышел заметно быстрее. Экономия пришла оттуда, куда её обычно не закладывают в план.
Содержание5 разделов
Цифра, которая нас удивила
Мы делаем софт для двух бизнесов, которые звучат как один и тот же бизнес. Первый сдаёт вещи посуточно. Второй продаёт недвижимость и управляет ею. Если описать одной фразой, в обоих случаях кто-то платит за пользование зданием или машиной в течение какого-то срока.
Когда мы начинали второй, все участники исходили из того, что большая часть первого перейдёт как есть.
Вместе эти два продукта описывают 113 бизнес-понятий: то, о чём софт обязан знать, вроде клиента, договора, правила расчёта цены, брони. Общих оказалось семь (оба списка по понятиям).
Шесть процентов.
Второй продукт всё равно вышел намного быстрее первого. Понять почему полезнее, чем знать саму цифру, потому что ровно та же логика решает, окупится ли автоматизация внутри вашей собственной компании.
Почему у двух похожих бизнесов почти нет общего
Фраза, которая делает их похожими, и есть та фраза, в которой спрятаны все различия.
У прокатной компании есть машины. Они либо есть, либо их нет. У застройщика есть дома на стройке, где каждая квартира проходит стадии готовности: проект, коробка, отделка, приёмка, и половина бизнеса состоит в том, чтобы отслеживать, на какой стадии что находится. Машины, готовой на шестьдесят процентов, не бывает, поэтому и заимствовать в первом продукте было нечего.
Аренда открывается и закрывается за неделю. Сделка с недвижимостью идёт месяцами и включает покупателя, продавца, агента, а часто и банк, и каждый смотрит на одну и ту же сделку со своей стороны. Мы точно знаем, до какого места доезжает попытка считать это бронью с дополнительными полями: до первой комиссии, которую надо разделить на троих.
И у прокатной компании есть клиенты. У компании по недвижимости есть клиенты, собственники и инвесторы: люди, которые ничего через систему не покупают и заходят только посмотреть, что происходит с их активом. В первом продукте им нет никакого соответствия, и это самый ясный признак того, что бизнесы изначально были разными.
Где на самом деле была экономия
Ничто из перечисленного не делает второй продукт дешёвым. Экономия лежит ниже, в той части, которую не видит ни один клиент и которую не расписывает ни одно коммерческое предложение.
Прежде чем платформа недвижимости сможет заняться недвижимостью, ей нужно вот это:
| Что нужно любому продукту | Кто это замечает |
|---|---|
| Входы, компании, роли сотрудников, права | Никто, пока это не сломано |
| Биллинг, подключённый к настоящему провайдеру | Финансы, ежемесячно |
| Сообщения из WhatsApp и Telegram в одной очереди | Тот, кто на них отвечает |
| Уведомления, переводы, журнал изменений | Аудиторы и юристы |
| Шифрование персональных данных | Все, один раз |
В первый раз этот список занял месяцы. Он одинаков независимо от того, идёт речь про хетчбэк или про двушку. Второй продукт взял готовыми 18 из 19 наших общих пакетов (INITE, общая основа). Это та же механика, которая нужна любой компании, автоматизирующей процесс, и потому её выгодно один раз построить и дальше владеть ею самим.
Когда она уже построена, второй продукт начинается сразу с интересной работы. Приём это скучный, и поэтому в планы его обычно не включают.
Правило, по которому мы решаем
Всё расставляет один вопрос: сделал бы второй продукт это по-другому?
Если оба сделали бы одинаково, строим один раз. Если разрешить каждой команде писать свою версию, получатся четыре слегка разные системы входа и одна и та же ошибка, исправленная четыре раза.
Если продукты действительно расходятся, делаем отдельно. Одна гибкая версия на оба случая обычно оказывается сложнее для чтения, чем дублирование, которое она должна была убрать.
Входы и права проходят без спора. Ценообразование проваливается сразу: сезоны и тарифы с одной стороны, комиссии и несколько сторон сделки с другой. Когда решить не выходит, оставляем отдельно, потому что слить потом стоит вечера, а разделить потом стоит квартала.
Почему это важно, если вы не строите софт
Почти каждая компания, которая просит нас что-то автоматизировать, описывает процесс как свой собственный. Правила обычно и правда свои.
Своей почти никогда не бывает вся обвязка вокруг: собрать обращения из нескольких каналов в одну очередь, решить, кто чем занимается, передать человеку то, в чём система не уверена, записать, что произошло, и отчитаться по этому потом. Эта механика одинакова для клиники, логистической компании и проката оборудования. Она же дольше всего строится с нуля.
Поэтому мы и запускаем один-три процесса за две-четыре недели (INITE Protocol), а не за два-три квартала: механику никто не строит заново. Вы платите за правила, которые ваши, и поэтому же арифметика окупаемости вообще сходится.
Ошибка, которой стоит избежать, та самая, которую мы чуть не сделали сами: считать, что раз две вещи звучат похоже, то дорогие части перенесутся. Обычно они не переносятся. Начните с того, чтобы выяснить, какие части вашего процесса действительно ваши, и трезво оцените, насколько обычно всё остальное. Как раз поэтому оно и обходится дёшево.
Часто задаваемые вопросы
Если почти ничего не перенеслось, общий фундамент вообще стоило строить?
Он и был единственной причиной, по которой второй продукт получился быстрым. Путаница возникает потому, что экономия вылезает там, где её никто не закладывает в план. Прежде чем платформа недвижимости сможет сделать хоть что-то про недвижимость, ей нужны входы в систему, компании, роли и права сотрудников, биллинг, подключённый к настоящему платёжному провайдеру, приём сообщений от клиентов в WhatsApp и Telegram, уведомления, переводы, журнал того, кто и что менял, шифрование персональных данных. Этот список занимает месяцы, он одинаков и для проката автомобилей, и для продажи квартир, а любая незаметная ошибка в нём всплывает не на демо, а на аудите безопасности. Один раз построенный фундамент означает, что второй продукт стартует там, где начинается собственно бизнес. Отраслевые правила в любом случае были бы разными, и сэкономить на них было нельзя изначально.
Почему два таких похожих бизнеса разделили так мало?
Потому что они похожи только на слух. Оба описываются как «кто-то платит за пользование объектом в течение срока», и в этой фразе прячется каждое различие, которое имеет значение. У проката есть машина, которая либо существует, либо нет; у застройщика есть дом на стройке, где каждая квартира проходит стадии готовности, прежде чем в ней вообще можно жить. Аренда открывается и закрывается за несколько дней; сделка с недвижимостью идёт месяцами и включает покупателя, продавца, агента, а часто и банк, и каждый смотрит на одну и ту же сделку со своей стороны. У прокатной компании есть клиенты; у компании по недвижимости есть ещё собственники и инвесторы, которые ничего через систему не покупают и заходят только посмотреть, что происходит с их активом. Когда всё это выписано на бумагу, шесть процентов совпадения перестают быть загадкой. Загадка в том, почему кто-то ждал большего.
Как вы решаете, что строить один раз, а что для каждого продукта отдельно?
Мы задаём один вопрос: сделал бы второй продукт это по-другому? Если оба продукта сделали бы одинаково, строим один раз, потому что разрешение каждой команде писать свою версию заканчивается тем, что компания поддерживает четыре слегка разные системы входа и чинит одну и ту же ошибку четыре раза. Если продукты действительно расходятся, делаем отдельно, потому что одна гибкая версия на оба случая обычно оказывается сложнее для понимания, чем то дублирование, которое она заменила. Входы и права проходят этот тест без спора: пользователь, компания, кому что разрешено, и любое расхождение здесь между продуктами это ошибка, а никакая не особенность. Ценообразование проваливает тест сразу: в аренде сезоны и тарифные сетки, в недвижимости комиссии и несколько сторон, и универсальный модуль расчёта цен на оба случая раздражал бы всех. Когда решить не выходит, оставляем отдельно, потому что слить потом легко, а разделить потом тяжело.
Что это значит для компании, которая автоматизирует собственные операции?
Тот же принцип работает на гораздо меньшем масштабе, и обычно именно он определяет, окупится автоматизация или тихо не окупится. Почти каждая компания, которая просит нас что-то автоматизировать, описывает процесс как уникальный, и конкретные правила действительно чаще всего уникальны. Уникальной почти никогда не бывает окружающая механика: собрать обращения из нескольких каналов в одну очередь, решить, кто чем занимается, передать человеку то, в чём система не уверена, записать, что произошло, и потом отчитаться. Эта часть одинакова для клиники, логистической компании и проката оборудования, и она же дольше всего строится с нуля. Когда мы называем срок 2-4 недели на запуск одного-трёх процессов, недели вместо кварталов получаются именно потому, что механику никто не строит заново. Вы платите за правила, которые ваши, а не за обвязку, которая ничья.
