Один движок, разные ниши: как не переписывать систему под каждую отрасль
Система поиска клиентов для автосервисов и для клиник — это одна система или две? Разбираю границу, по которой проходит разделение на движок и данные, и чем приходится платить, когда её проводят неточно.
Можно ли сделать систему поиска клиентов один раз и переносить её на другие отрасли?
Можно, если ниша в ней — это данные, а не код. Движок умеет искать, отсеивать, разбирать текст и проверять цитату, но нигде не знает, про какую отрасль речь. Всё отраслевое собрано отдельно: запросы, слова, фразы, которыми говорит покупатель, площадки и пороги. Новая отрасль тогда означает новый набор данных, а не новую ветку кода.
Я делаю автоматизацию для клиник, автосервисов, салонов красоты и ещё нескольких отраслей. Вопрос, который возникает сразу: это одна система или восемь разных?
Ответ зависит от того, где проходит граница между тем, что умеет система, и тем, что она знает про отрасль.
Граница проходит по знанию об отрасли
Правило простое: в движке не должно встречаться названия отрасли. Нигде. Ни в условии, ни в имени функции, ни в комментарии.
Это звучит как мелочь, но проверяется механически и потому работает. Как только в коде появляется «если это клиника, то», система перестаёт быть одной. Дальше она расходится на ветки, и каждая следующая отрасль добавляет ещё одну развилку в место, которое уже и так трудно читать.
Движок умеет общее. Найти страницы. Выбросить явно не то — по адресу и заголовку, не читая текста. Проверить, есть ли в тексте нужные слова. Понять, похож ли текст по смыслу на описание проблемы. Разобрать его моделью и достать, кто человек и что ему надо. Сверить сохранённую цитату с исходной страницей дословно. Оценить и разложить по корзинам.
Ни один из этих шагов не требует знать, что речь про автосервисы.
Что значит «отрасль — это данные»
Отраслевое знание собирается в один набор. Там лежат поисковые запросы, по которым вообще имеет смысл искать. Слова, по которым идёт быстрый отсев. Фразы, которыми человек в этой отрасли описывает свою проблему — а они везде разные: владелец автосервиса и администратор клиники жалуются на одно и то же разными словами. Площадки, где эти люди пишут. И пороги, с которых начинается «это похоже на заявку».
Такой набор можно показать заказчику. Он читается как текст, а не как программа, и человек из отрасли сразу видит, где я угадал, а где нет. Это неожиданно ценная часть: правки приходят не от программиста, а от того, кто в этой отрасли работает.
Новая отрасль после этого — не новая разработка. Это новый набор данных и прогон на нём.
Чем пришлось заплатить за неточную границу
Честная часть. Граница у меня получилась не с первого раза.
Сначала был один вид набора — для поиска. Потом понадобилось больше: не только находить людей, но и писать им первое сообщение, вести карточку, работать с ответом. Я не стал переделывать первый вид, а сделал второй, расширенный, поверх него.
В итоге стало два реестра вместо одного, две переменные окружения, которые выбирают активный набор, и правило приоритета между ними. Каждая новая отрасль теперь регистрируется в двух местах. Забудешь второе — поиск работает, а рассылка не видит набора, и причина не очевидна.
Это классическая цена за то, что возможность добавили расширением, а не заменой. Работает, но объяснять приходится дольше, чем если бы я сразу свёл всё к одному виду набора с необязательными частями.
Вывод, который я забрал: если новая возможность требует расширить описание, лучше потратить день и расширить единственное описание, чем за час сделать второе рядом с первым.
Когда этого не надо
Разделение на движок и данные стоит усилий, если отраслей будет больше одной. Для одной это лишний слой: вы будете поддерживать абстракцию, у которой ровно одна реализация.
Признак, что пора разделять, простой. Вы ловите себя на том, что копируете файл и меняете в нём десяток строк. Вот эти десять строк и есть ваш пакет отрасли, а всё остальное — движок.
Что забрать себе
Три вещи, не зависящие от инструментов.
Заведите правило, которое можно проверить механически: название отрасли не встречается в движке. Механически проверяемое правило живёт дольше договорённости.
Складывайте отраслевое знание в один набор, который читается человеком из этой отрасли. Тогда правки будут приходить от него, а не от вас.
И если новая возможность требует расширить описание — расширяйте единственное, а не делайте второе рядом. Второе описание потом живёт вечно.
Как такая система выглядит в работе, показываю в кейсе про поиск клиентов с CRM внутри Telegram. Отраслевые страницы — это та же мысль, только про услуги: клиники, автосервисы и остальные собраны из одного набора решений. Нужна такая система под вашу отрасль — напишите.