Это история о том, как амбициозная идея одного талантливого разработчика и по совместительству руководителя компании, а также ведущего разработчика, который управлял командой, была подхвачена и воплощена в жизнь её участниками – талантливыми программистами, которые годами занималась одним, а теперь нужно было делать то, не знаю что, там, где незнамо где. Но перед этим нам попалось одно испытание, из которого мы вышли победителем. О нём сначала и расскажем.
В конце нулевых, в сфере государственных закупок начались серьёзные подвижки в сторону цифровизации. Это открыло двери для большого числа компаний в мир госзаказа, когда сидя за ноутбуком ты мог решить, чем в этом сезоне будет заниматься твоя фирма и сколько она сможет заработать. Для электронных торгов начиналась эра рассвета, а ЭЦП становилась заветным ключом в эту «параллельную реальность».
Финтех, а тогда это слово ещё никто не использовал, никак не поспевал за нарастающим спросом. Это касалось как самих торговых площадок, так и порталов, которые предлагали различный сервис для участников госзакупок. Однако уже тогда было ясно, что мы на пороге всеобщей и окончательной цифровизации государственного заказа, открытых данных, которые госструктуры начинали публиковать, и станем свидетелями рождения эпохи новых программных решений и уникальных идей. Идей, доселе не рождавшихся в умах разработчиков, так как не было ни спроса на что-то подобное, ни тех, кто обладал большим опытом в решении данных задач. Ситуация была похожа на зарождение киберпанка в 80-ых: те кто был в теме знал, к чему всё идёт, но ещё не понимал, во что это всё выльется.
Пока кто-то разрабатывал очередную площадку для удобного поиска и подбора предстоящих торгов, рынок госзакупок рос не по дням, а по часам. Банки всё больше приходили к выводу, что без автоматизации в отношении выдачи банковских гарантий и кредитов на исполнение госконтрактов, а также без помощи агентов, они никак не справятся с лавинообразным потоком новых клиентов по данным направлениям. Именно в это время и начинается путь маленькой команды разработчиков, во главе с очень талантливым программистом, который и знать не знал обо всём этом. Ведь он грезил разработкой отраслевых CRM, по сути хотел делать уникальные продукты под нужды рынка, для каждого в отдельности. То есть задачи создать универсальный продукт для массового пользования не было.
Однажды нам попался очень необычный заказчик, мы и вовсе не хотели его брать, так как он не занимался добычей полезных ископаемых и ничего не производил, но он был готов заплатить очень большие деньги за очень необычную CRM. Наша команда всегда была амбициозной и лидер всегда заряжал на реализацию уникальных решений. Лозунг «Всё, что необычное – это к нам» разве что на стене не висел, а так был в умах и делах команды изо дня в день. Этому новому заказчику понадобилась не только CRM но и разработка необычных для нас программных решений для нужд бизнеса, в частности – для ведения клиентов одного конкретно взятого кредитно-страхового агентства, в котором требовался учёт и контроль работы специалистов по выпуску финансовых продуктов, но свыше 90% клиентов было связано с государственными торгами. С нас требовалась при этом и максимальная автоматизация части их работы. Всё сводилось к тому, что нужен был инструмент, который поможет ускорить оформление в банках-партнёрах финансовых продуктов, при этом будет мощным инструментом учёта и контроля всех бизнес-процессов внутри компании. У нас тогда уже был опыт интеграции с некоторыми банками в рамках решения задач в CRM наших клиентов, поэтому нам этот момент мы даже не обратили внимание.
С одной стороны, задача была понятной, с другой – специфика данной отрасли была настолько далёкой от простых продаж, что едва ли можно было взять наработки из уже написанных нами ранее для нужд наших клиентов CRM. В частности, требовалось собрать и систематизировать данные по государственным торгам за много лет: извещения, протоколы, контракты; поддерживать их в актуальном состоянии на постоянной основе. Мы были немного в шоке от нестандартности, даже с учётом наших стандартов нестандартности. Но могли лишь вопрошать, зачем то. Клиент отвечал нам, что без этого понимать, что происходит с текущими клиентами и что из себя представляют только что заведённые, невозможно. Мы улыбались и кивали, не осознаю, что нас ждёт.
Простая задача, на первый взгляд. Ну, как сказать… коллеги, по крайней мере, обмолвились об этом в пару известных мест, которые посещают разработчики каждый день, но мы что-то наткнулись на какие-то подводные камни, о которых либо никто ни слухом, ни духом, либо это осталось за кадром. И это всё, не смотря на то, что данные выгружаются в машиночитаемом формате xml на ftp, схемы опубликованы, документация открыта.
Первые же прогоны написанных нами парсеров показали, что xml файлы могут не соответствовать схемам (от отсутствия обязательных полей, до неизвестных значений, отсутствующих в enum схемах), содержать посторонние символы или быть обрезанными в произвольном месте. В схемы вносятся изменения несколько раз в год. Для нас это была череда сюрпризов, но это было потом. К слову, разговоров в профессиональных кругах о том, что на тех сайтах колхоз колхозом и застой, было много, а вот мы – чего-то не заметили.
Объём файлов для обработки у нас измерялся терабайтами. И мы только успевали выписывать счета на оплату серверных мощностей, как печь пирожки. Которые, к слову съедались – оплачивались моментально. Попытки парсить данные продолжались, при этом ftp соединение было не всегда устойчивым, часть данных на стороне госзакупок не добавлялась, а перезаписывалась поверх (ситуация не частая, но была для нас неожиданной), в любом случае, мы этого не оценили. Реализовали скачивание файлов по ftp в инкрементном режиме, стали самостоятельно отслеживать изменения, учитывать возможную перезапись файлов, и докачивать только новые. На своей стороне мы смогли выявлять, когда и какие файлы были добавлены, какие изменены, сравнивать версии. Это помогло локализовать причину появления аномалий, когда данные на сайте закупок и у нас отличались на фоне ситуаций, когда новые файлы не выгружались на ftp. Но мы были полны энтузиазма, особенно смотря на оплаченные счета и лёгкое согласование новых, ведь бюджет был открытый.
Переобработка xml файлов заняла у нас тогда три месяца в три полных прохода. Нулевой проход мы завершили за 12 часов: слишком много ошибок, о которых написано выше. Всё ещё выявляли, ну и разбирались по мере поступления. К первому проходу мы подготовились: логи ошибок, выделение битых файлов для анализа и исправлений парсеров. Ошибок мы ждали, и по горячим следам, патчили и допиливали парсеры. При этом параллельно мы делали основной функционал CRM, с учётом нестандартных пожеланий относительно функционала.
Мы ожидали, что второй проход будет успешным, но нет: полноценных тестов написано не было, и в наш небольшой «лес костылей», которые пришлось добавить для обработки истории, периодически залетал ураган. И, знаете, таких масштабов, что даже Урфину Джюсу не снилось, а он их повидал много. По итогу количество ошибок сократилось на два порядка, это стало большим достижением, но всё равно погрешностей было много, поэтому отдельные личности в команде не переставали посыпать голову пеплом. Я лично был большую часть времени заряжен оптимизмом ведущего разработчика.
Наш тимлид продолжал искать всё новые и новые пути решения проблем, и всех нас гонял. Его рвение меня всегда одновременно и восхищало и напрягало. Но зато, когда у кого-то опускались руки, он всегда мог подбодрить: оптимизм, порой – как локомотив для разработки. Однако, как по мне, с учётом скорости, мы неслись на максимуме: с одной стороны – как паровоз, а с другой – порой как паровоз на космической тяге, но всё ещё паровоз. Эти скачки в скорости утомляли. После третьего прохода процент ошибок у нас снизился до 0.01% файлов и мы выдохнули. Дальнейшие исправления вносились точечно, дули уже не то, что на холодное, просто уже не дышали перед каждым деплоем. Забегая вперёд скажу, что массовые перегрузки всего и вся были и потом, но уже за относительно небольшие периоды – до 6 месяцев.
В основу нашей разработки легла парадигма гибкости и быстрой подстройки под изменения условий. Часть логики писалась на бэке, в то время как массовые операции по пересчётам писались в виде хранимых процедур на стороне СУБД Postgres. Сейчас шутим, что будто чуяли, что однажды встанет вопрос об импортозамещении. Поэтому, пока знакомые коллеги переходили на Postgres, у нас всё уже было на нём. Особенностью нашей системы были постоянные пересчёты. Их объем в сутки очень быстро приблизился к 1 Тб, и это не давало нам возможности рассматривать СУБД только как хранилище. У нас СУБД начал использоваться как полноценный инструмент обработки. Было ещё много мелких интересных решений, но главное – это то, что самая важная и неотъемлемая часть уникальной в своём роде CRM росла не по дням, а по часам, причём во всех смыслах, иногда пугающих и нас самих. По голосу заказчика в трубке, скорость разработки пугало его тоже, но мы подозреваем, что его страх был не пропорционален скорости, а обратно пропорционален уменьшающимся промежуткам между выписыванием новых счетов. Однако они всё ещё моментально оплачивались, поэтому мы продолжали разработку.
И так, у нас, казалось бы, уникальная идея – создание CRM в сфере тендерного сопровождения и очень необычное её воплощение, знали ли мы тогда, что этот опыт ляжет в основу нашего текущего проекта? Нет конечно. Часть ребят ждали финального релиза и хотели забыть об этом волшебном мешке, который из себя представляла каждая выгрузка, как о страшном сне. Для расчёта финансовых продуктов мы делали интеграции с банками и сервисами прямо в CRM, всё это собиралось в единый комбайн и представляло из себя хоть и разношёрстный продукт, но по функционалу не имеющих аналогов. Завершив проект мы какое-то время его поддерживали, а потом заказчик собрал свою команду разработчиков внутри компании и мы подготовив подробные документации по продукту передали дальнейшую программную поддержку им.
Прошло несколько лет и мы загорелись идеей создания полезного для всех проекта, при этом связанного с какими-либо расчётами, то есть по факту решили создать расчётный сервис. Перебирая финансовые продукты банков, мы поняли, что сервисов для расчёта самых популярных из них уже выше крыши. И тут мы наткнулись на несуразные калькуляторы банковских гарантий и понеслась…
Мы сразу вспомнили тот наш проект, где в рамках тендерной CRM мы делали различные модули для расчётов. Вспомнив этот опыт, мы подошли к задаче создания калькулятора для расчёта стоимости банковской гарантии с солидный багажом. Ребята были – как на подбор, даже несмотря на то, что группа обрастала новыми сотрудниками, а небольшая часть старых коллег ушла. На тот момент у нас было пару закаленных специалистов, готовых на всё и которые могли сделать всё, они же – костяк группы из 4 бэк-разработчиков на С# и python, пара разработчиков front, два devops (старший и младший), ну и, конечно, наш ведущий разработчик - тимлид, а для всех, кто хорошо знал его, то понимал, что он на самом деле «три в одном» – программист, аналитик и переводчик между бизнесом и разработчиками. Без него огромное количество контрактов на разработку мы бы не подписали. Я бы ещё добавил – человек с железной волей и стальными нервами, особенно если учесть, что заказчики порой просят то, чего сами не понимает и, тем более, не представляют, как сложно это реализовать. Или, например, говорят, «вот это добавьте», а там работы на 4 месяца, потом говорится, что надо было ещё вчера, и ты понимаешь, что 4 месяца, но в круглосуточном режиме работы. В целом, тогда костяк команды был достаточным для такого амбициозного проекта, и можно было двигаться в направлении его реализации. Воодушевлённые очередных амбициозным проектом тимлид допустил, что в теории, создать такой инструмент, как калькулятор расчёта комиссии и ставки на выпуск гарантии с учётом тарифных сеток банков и даже разных стоп-факторов и требований к исполнителю госконтракта – в принципе реально.
Сели обсуждать. Где-то спустя час пришло понимание, что мы погорячились. Через два, уйдя вглубь обсуждений, мы полностью осознали то, что были крайне наивными и всё намного хуже, чем мы думали, и соответственно калькулятор сделать нереально. И причин на самом деле достаточно. Несмотря на наш накопленный опыт систематизации и приведения к общему знаменателю данных из разных форматов и источников, банки опирались на схожий подход. Мы поняли, что будут моменты с неприятными деталями, связанными с отличающимися наборами данных. И чем больше будет таких частностей, тем сложнее это будет поддерживать. Так что это как минимум добавляло дополнительный уровень абстракции для унификации требований к данным, которыми мы располагали.
В будущем мы столкнулись с тем, что наборы данных для скоринга меняются иногда настолько кардинально, что приходится дорабатывать не только слой взаимодействия с конкретным банком, но даже абстрактный слой между данными по организациям и требованиями банков. Мы ведь хотели сделать калькулятор который будет учитывать и параметры самой компании участника торгов. Тарифные сетки банков зависят от нескольких параметров. Часть из них неочевидные, часто описанные только словами без конкретных примеров ограничения по минимальным тарифам. К этому добавьте разные подходы к расчётам скидок/надбавок к тарифу из-за сопутствующих факторов у разных банков. В общем, чем дальше в лес, тем больше дров и длиннее становился список разных «но», «а если» и т.д. Всё это – не говоря о «вишенке на торте» – стоп-факторах, которые могут быть как достаточно формальными и простыми (регион заказчика или исполнителя, возраст компании-исполнителя и т.д.), так и слабо формализуемыми, допускающими широкую интерпретацию при реализации и человеческой оценке, например – наличие аналогичного опыта, есть ли опыт в выполнении госконтрактов по объёму. Только вот, речь – о количестве, сумме или объёму? А ещё бывает сложнее: аналогичным опытом становится сумма нескольких выполненных проектов по схожим работам, которая идентична сумме текущего контракта. Тут не то, что тёмный омут был, в котором известно кто водится, тут был тёмный омут с двойным дном и с той стороны уже стучали.
То обсуждение затянулось. Тимлид не сдавался и где-то на третьем часу очередного обсуждения всех этих моментов, которые, по сути, говорили о невозможности создания такого калькулятора, мы хотели забыть обо всём этом, как о страшном сне. Ведь фоном у большинства была мысль о том, что можно потратить много месяцев, на попытки собрать то, что с первого взгляда собрать невозможно от слова совсем, и в итоге не получить ничего удобоваримого для релиза. Было чёткое понимание, что мы должны были продолжать дорабатывать делать то, что мы хорошо умеем - создавать CRM, разные, в большом количестве, а не уходить в эксперименты с заведомо нереальным для воплощения программным продуктом. Пару раз ещё были планёрки на тему калькулятора, где было много повторений и очень много перекрёстных восклицаний. В целом, ничего нового. И наконец, после очередной такой планёрки вроде все успокоились и приняли аксиому, что его сделать невозможно. Но как это бывает, в коллективе не без сумасшедшего…
Спустя пару дней, тимлид пришёл с кипой бумаг, на которых были схемы, расчёты, заметки и я помню даже следы кофе, кто-то явно по ночам не спал, а продолжал сходить с ума. Был у нас даже локальный мем с калькулятором и приклеенной к нему наклейкой «Калькулятора не существует» с отсылкой на всем известный фильм «Матрица». В то утро все смотрели на эту кипу с опасением, так как понимали, что безумец не сдаётся и продолжает изводить себя идеей о создании калькулятора. Ну и, что надо ждать очередной планёрки-нервотрёпки. Для понимания: это был тот самый случай, когда перфекционизм не даёт покоя и человека уносит куда-то вдаль. Но пока из-за этих обсуждений «вдаль» уносило только нас, и только от намеченных сроков по очередным задачам, связанным с текущими клиентами и их CRM, которые мы поддерживали. На тот момент мы уже накопили много клиентов и редко делали что-то новое, ведя текущих клиентов. И вот, мы в тот момент, реально думали, что он идёт на принцип и просто не может принять очевидное – создать такой калькулятор невозможно!
После обеда он собрал нас на очередную планёрку, связанную с калькулятором, и буквально ошарашил фразой: «Ребята, я тут много думал, калькулятор создать невозможно, но мы это сделаем!». Сказать, что мы выпали в осадок – это ничего не сказать. Тем более что у нас одному клиенту была классика жанра, от нас ждали большой список доработок, а мы, как уважающие себя разработчики, срывали сроки, как могли. Благо, это был клиент, который с нам был уже много лет и нас это спасало. Тем более, у него без нас всё лежало и висело то попеременно, то одновременно. И между прочим не из-за нас в 99% случаев.
Та планёрка, с той самой кипой бумаг, затянулась на добрых 5 с лишним часов. Лёжа на столах под конец, мы всё ещё продолжали обсуждать, спорить, успешно доказывать как свою правоту, так и свою глупость. А тимлид всё вторил, явно находясь под кофеином. Он очень воодушевлённо объяснял, как же мы соберём этот калькулятор на основе скоринговой системы, получив калькулятор + аналитическую систему в одном флаконе. Сразу вставал вопрос – так мы будем делать скоринговую систему или точный калькулятор? Как потом оказалось, мы будем делать это одновременно, и одно будет перетекать в другое ещё очень долго. Долго – это два года разработки онлайн-сервиса «Гарантолог», соответственно.
Скоринговая система рождалась в муках. В основе был учёт:
требования банков для скоринга (тесное сотрудничество и подстраивание под них);
свойства компаний (все, которые влияют на отказ банка, надбавки на комиссию и т.д.);
тарифные сетки, от чего бы они ни зависели (здесь был основной прорыв, но дался он нам ой, как не быстро);
конвертация истории и новые поступающие данные в предоценку и подсказки для пользователей в результатах калькуляторов (на копилот это пока не тянет, но мы к этому стремимся).
В итоге, мы всё-таки собрали «это» воедино – образовалась синергия между всеми узлами. Если бы сейчас я услышал о таком, не поверил бы. Но, как говорится, и я там был, мёд пиво пил. По итогу получился продукт, который представлял собой систему обсчёта гарантии с учётом огромного количества параметров. Теперь пользователь нашего онлайн-сервиса мог вводить параметры торгов, параметры заказчика, параметры исполнителя, параметры оформления гарантии и параметры выпуска гарантии. И всё это влияло на конечный расчёт, так как на каждый банк у нас была вся сетка их тарифов и оцифрованы все условия и стоп-факторы.
Разработка калькулятора и портала, главным функционалом которого является набор калькуляторов велось одновременно через 11 месяцев активной разработки самой скоринговой системы мы большей частью переключились на функционал портала, п продолжая отладку калькулятора.
И вот, год назад, 15.11.2023 в 23:48 (с контролем всех параметров до 2 часов ночи 16.11.2023) мы как истинные ИТ`шники работающие поздними вечерами и круглыми ночами, запустили наш портал «Гарантолог» по адресу:
Сегодня мы отмечаем годовщину запуска портала. Рады, что за этот год он помог большому количеству компаний, участвующих в государственных торгах легко разобраться с ценообразованием на рынке банковских гарантий и подобрать банк под свою ситуацию.
Реклама: ООО «Аффинити индекс», ИНН: 2310198925, erid: LjN8KXWzA
Начать дискуссию