Как мы превратили заглавный продукт в «legacy», а теперь на нем зарабатываем

«‎Каждый выпущенный продукт особенный, я все их люблю одинаково» – так, может быть, скажет новоиспеченный ПМ-романтик-в-душе. Но проект, который идет с компанией сквозь года и разные команды, становится заглавным продуктом, заставляет сменить стэк, методологии и вообще подход к работе – такой проект вызывает особый трепет в душе любого менеджера.

На связи ZAKUPKI.GROUP, мы проектируем корпоративное ПО на Java EE.

Эта история начиналась стандартно. Заказчик – бизнес по участию в госзакупках. Сотрудники их тендерного отдела работали в гугл-таблицах, что очень неудобно: сотни закупок ежедневно, по каждой надо делать свои расчеты и проверки. Десятки открытых вкладок в окне браузера, низкий КПД и высокая вероятность допустить ошибку – все это не устраивало клиента.

К моменту обращения к нам бизнес уже начинал автоматизировать рабочие процессы с помощью питоновского фреймворка Jam.py, а нашей задачей было создать личный кабинет (с управлением пользователями и биллингом) и синхронизировать его с платформой. Но в процессе работы стало понятно, что Jam.py ограничен в возможностях и не помогает в решении нужных задач. В итоге, обсудив это с клиентом, решили писать новую CRM на Laravel – PHP-фреймворке, который мы хорошо знали.

Целью было создать систему, в которой удобно функционировать по всем этапам госзаказа: от поиска закупок до просчета логистики отправлений. Мы расширили команду и начали работу над проектом.

В какой-то момент нас озарило: такой продукт нужен всем! Действительно, удобных инструментов для автоматизации работы с закупками и до сих пор на рынке немного. Поэтому мы провели дополнительную аналитику и выявили еще больше нужд бизнеса, которые можно закрыть: поиск закупок и контрагентов, работа с контрактами, календари, оплаты и т. д. Мы хотели сделать систему максимально гибко настраиваемой, чтобы каждый мог адаптировать ее под себя.

Тут перед нами встала проблема: где брать информацию о закупках? Сначала закупки нам поставлял партнер, но данные от него поступали очень грязные. А если понадобится объединить несколько таких источников, то разные форматы и структура данных вообще не позволят их нормально обрабатывать. В идеале надо было агрегировать данные самим – притом много и в промышленных масштабах. Для этого мы пригласили Артема с его знаниями и опытом в настраивании парсеров (спойлер: Артем нам пригодился не только для парсеров, сейчас он CTO).

В итоге мы действительно опубликовали продукт и были очень рады первым продажам. Но, как истинные перфекционисты, мы не захотели на этом останавливаться и продолжили искать точки роста.

Все это время мы делали монолит на Laravel, но количество услуг и фич росло, их стало сложно вписывать в монолитную архитектуру – она для этого слишком неповоротлива, и по сути мы имели дело со спагетти-legacy-кодом. Артем предложил перейти на микросервисы, которые можно быстро разрабатывать и гибко внедрять. CRM была на голых серверах, со всеми ручными поднятиями, а теперь нам нужна была некая система оркестрации контейнеров, и мы переехали на Kubernetes.

Команде предстояло научиться работать с новыми технологиями и методологиями, и именно Артем стал идейным вдохновителем и начал привносить новые знания. Но у нас уже был техлид, и он не был готов к переменам и не поддержал наш рывок вперед, в команде завязался конфликт. В итоге техлид ушел, а за ним и все разработчики. Артем стал CTO, собрал новую команду и пустился в бой. С этой командой мы работаем и по сей день, и нынешняя компания взяла название от продукта – ZAKUPKI.GROUP.

Заказчик, помимо участия в госзакупках, решил наращивать прямые продажи лабораторного оборудования. Поэтому сейчас наш фокус сместился на разработку сайта с каталогом и магазином. И уже к этому сайту мы привязываем существующие и новые микросервисы:

Если изначально мы планировали продавать подписку на CRM-систему, то сейчас каждый из этих микросервисов можно единоразово выкупить. Но мы не отказываемся от идеи единой экосистемы для участников госзакупок, и, возможно, следующей итерацией станет создание нового фронтенда, который объединит все в одну площадку. Например, Тинькофф работают по такой же схеме – юзер думает, что находится на одной платформе, но на самом деле у них под каждую задачу есть микросервис со своим фронтом в единой стилистике.

Вы прочитали историю о том, как один продукт может сформировать вокруг себя целую компанию и дать команде работу на годы вперед! Мы растем и учимся на собственных ошибках, и поэтому в следующих статьях можем поведать об успешных или провальных кейсах, а также рассказать о внутренних процессах: формирование аналитического отдела, обучение сотрудников, внедрение новых технологий/методологий и т. п.

Пожалуйста, дайте знать, если тема показалась вам интересной, мы будем рады любым комментариям!

#crm #development #разработка #микросервисы #монолит #кейсы #kubernetes