Идея была не моя. Мне принесли задумку сервиса для Пхукета, а моей задачей было превратить её в работающую систему. Где-то между шестью кнопками и первой настоящей заявкой появился PostgreSQL.
В июле меня подключили к проекту с довольно понятной идеей.
Ребята, которые живут на Пхукете, хотели собрать в одном Telegram-боте вещи, которые обычно существуют отдельно друг от друга: аренду жилья, байков и автомобилей, визы и бордер-раны, обмен валют, полезную информацию и помощь в экстренных ситуациях.
У проекта уже были люди, которые понимали местный рынок, договаривались с партнёрами и придумывали, каким должен быть сервис.
Моя часть была другой: собрать это технически.
Так появился «Незнайка про Пхукет».
Вначале было шесть кнопок
Первая схема выглядела почти безобидно:
- недвижимость;
- авто и байки;
- виза и бордер-ран;
- обмен валют;
- SOS и полезное;
- канал.
Если смотреть на неё издалека, можно решить, что здесь работы примерно на вечер. Это опасное расстояние.
Потому что за кнопкой «Арендовать байк» довольно быстро появляется сценарий.
Какой транспорт нужен?
На какой срок?
С какой даты?
Нужна ли доставка?
Куда?
Как связаться с человеком?
Потом нужно показать сводку, дать исправить данные, сохранить заявку и передать её тому, кто будет заниматься заказом.
С бордер-раном веселее: направление, тип штампа, дневной или ночной рейс, дети, дата поездки, место в микроавтобусе, контактный номер, точка забора, доплаты и итоговая стоимость.
Кнопка постепенно превращается в маленький бизнес-процесс.
Я собирал не чат, а граф
Бота я строил как набор связанных сценариев.
Есть узлы с текстом.
Есть кнопки.
Есть переменные.
Есть условия.
Есть переходы между ветками.
Есть внешние запросы.
Есть состояния, которые нужно помнить между сообщениями.
Это оказалось удобнее, чем пытаться представить весь проект одним длинным диалогом.
Пользователь видит несколько сообщений в Telegram. Я вижу граф.
И чем больше становился бот, тем очевиднее было, что главное здесь не сами сообщения. Главное — куда человек пришёл, что уже выбрал и что система должна сделать дальше.
Потом понадобилось место для заявок
Первые версии я не хотел усложнять раньше времени. Поэтому заявки из разных веток начали складываться в Google Sheets: аренда отдельно, бордер-раны отдельно, недвижимость, обмен валют.
Для небольшого проекта таблица вообще замечательная штука. Её можно открыть глазами. Можно быстро поправить данные. Можно отдать менеджеру без отдельной админки и недель разработки того, что пока никому не нужно.
Поэтому некоторое время архитектура выглядела примерно так:
Telegram → сценарий → заявка → Google SheetsДля первого рабочего варианта этого было достаточно.
Потом у заявки появился второй конец
Если бот собрал заявку, это ещё не значит, что что-то произошло. Её должен увидеть человек.
Поэтому следующий кусок системы появился уже вокруг менеджеров. Заявка приходит в Telegram. Менеджер может принять её или отказаться. После нажатия кнопки статус меняется. У пользователя появляется возможность видеть свои заявки.
То есть постепенно возникла маленькая операционная система вокруг бота:
клиент → заявка → менеджер → статус → клиентНикто не говорил: «давайте сделаем CRM». Она просто однажды обнаружилась внутри.
Недвижимость сломала простую архитектуру
С заявками на байк всё довольно линейно. Собрали данные, передали, ждём ответа.
Недвижимость работает иначе. Человеку нужны варианты. У вариантов есть район, цена, количество комнат, срок аренды и другие параметры. Партнёры могут вести свои объекты каждый у себя. Пользователь хочет отфильтровать каталог, посмотреть несколько предложений, выбрать конкретное и уже потом отправить заявку.
И вот здесь таблица перестала быть просто таблицей с заявками. Я начал использовать её как источник данных для каталога. А это совсем другая работа.
На маленьком количестве объектов всё выглядит нормально. Потом появляется ещё один партнёр. Потом ещё данные. Потом бот должен быстро фильтровать их под каждого пользователя.
И однажды становится понятно, что Google Sheets медленный не потому, что Google плохой. Просто я попросил электронную таблицу притворяться базой данных.
Поэтому сейчас появляется PostgreSQL
Эту часть я как раз переделываю. Идея довольно простая.
Партнёрам не нужно менять привычный способ работы только потому, что у нас появился бот. Они могут продолжать вести свои данные там, где им удобно. А отдельный процесс периодически забирает изменения и складывает их в PostgreSQL. Уже оттуда бот получает каталог для поиска и фильтрации.
Получается примерно так:
источники партнёров → синхронизация → PostgreSQL → ботДля меня это гораздо интереснее, чем просто «поставил Postgres». База появилась не потому, что архитектура с ней выглядит солиднее. Она появилась в момент, когда реальное использование сделало старое решение неудобным.
Мне вообще нравится такой способ развития систем. Сначала самое простое решение, которое работает. Потом проблема. Потом следующий слой. Не наоборот.
Параллельно бот продолжал разрастаться
Кроме коммерческих веток появилась большая часть с полезной информацией.
Документы.
Иммиграционные вопросы.
Паспорта.
Полиция.
ДТП.
Медицина.
Экстренные номера.
Разные бытовые ситуации на острове.
В результате внутри уже не несколько линейных диалогов, а довольно большой граф со своими меню, возвратами, fallback-сценариями и отдельными кусками логики.
И где-то в этот момент формулировка «бот с услугами» перестала нормально описывать происходящее. Скорее это маленький интерфейс между человеком и кучей разрозненных вещей вокруг него.
А потом пришла заявка
11 августа бот получил настоящую заявку на обмен валюты.
Не тестовую. Не мою. Не от человека из команды, которому можно написать: «я сейчас поломаю, не трогай».
Просто кто-то открыл бота, прошёл сценарий и отправил заявку.
Один пользователь. Одна заявка. Никаких красивых графиков роста.
Но для проекта это оказался довольно важный момент.
Пока системой пользуешься сам, странная кнопка остаётся странной кнопкой. Можно переделать её завтра. Можно удалить половину ветки. Можно очистить таблицу. Можно сломать что-нибудь вечером и починить утром.
Когда приходит другой человек, внутри той же системы внезапно появляются:
- его время;
- его деньги;
- его контакт;
- его ожидание результата.
И архитектура перестаёт быть исключительно твоей проблемой.
Первые люди уже меняют то, что я строю
Почти сразу появился следующий вопрос. Что делать, когда менеджеров несколько?
Разослать заявку всем?
Кто первый принял, тот забирает?
Нужно ли скрывать её у остальных?
Показывать контакт клиента сразу или только после принятия?
Что произойдёт, если два человека нажмут кнопку одновременно?
Неделю назад эти вопросы можно было спокойно отложить. Теперь это уже следующая часть разработки.
И в этом, пожалуй, самое интересное во всём проекте. Архитектуру начинает определять не моё представление о красивой системе. Её начинает определять поведение людей внутри неё.
Что здесь вообще от меня
Не идея сервиса. Не знание Пхукета. Не партнёрские договорённости.
Я сборщик этой системы. Мне достаются разрозненные требования, реальные процессы и ограничения Telegram. А дальше нужно сделать так, чтобы всё это стало одной штукой: сценарии, состояние, заявки, интеграции, каталоги, менеджеры, статусы, синхронизация и теперь PostgreSQL.
Наверное, поэтому этот проект я кладу именно в «Лабу», а не в «Работу». Он ещё не закончился. Я могу открыть сегодняшний граф через месяц и обнаружить, что половины архитектуры уже нет. И это здесь нормально.
Потому что интересен мне как раз сам момент превращения.
Сначала тебе дают идею.
Ты собираешь прототип.
Потом прототип начинает выполнять настоящую работу.
А потом в него приходят люди.
И только тогда начинается разработка.
Бот: @neznaika_phuket_bot. Проект развивается, поэтому отдельные сценарии и внутренняя архитектура ещё меняются.