Привет, Хабр!
Премии любят все. Особенно — премии честные. Справедливая оплата труда требует учёта многих факторов, и финансистам считать их вручную очень муторно. Поэтому мы в OXYGEN решили разработать собственную систему расчёта премий для отдела продаж с помощью AI-агента.
Меня зовут Андрей Калашников, я финансовый менеджер в облачном интеграторе и дата-центре OXYGEN. Если вам интересна тема отделов продаж, денег, вайбкодинга — добро пожаловать под кат.
Зачем вообще вайбкодинг? Что не так со стандартными инструментами?
Есть 1С и Excel. Есть инструменты для расчётов, которые называют «специализированными» — различные модули, HR-платформы, CRM-ки.
Казалось бы, внедри да радуйся?
Не всё так просто!
Я приведу здесь пример, который услышал от одного человека — как я его запомнил.
Вам надо купить пиджак. Есть стандартные лекала (S, M, L, XL). Такой пиджак сядет на тысячи людей — кому-то лучше, кому-то хуже. Он универсален, но не идеален. И он не будет подходить отдельному человеку так, как сшитый в ателье по индивидуальным меркам.
Готовые системы закрывают базовые потребности, но не кастомные. Если задачу нельзя решить стандартными инструментами, придётся делать костыли и допиливать. У поставочного продукта или SaaS это доработки за отдельные деньги (от сотен тысяч до десятков миллионов рублей). Но дело даже не в деньгах, а в сложности взаимодействия заказчика и разработчика — иногда месяцы топтания на месте. Это демотивирует.
Excel позволяет многое в no/low-code, но чем больше условий, исключений и источников данных, тем сложнее поддерживать конструкцию. Формулы разрастаются, появляются технические вкладки, ручные операции, файлы плодятся. Excel прекрасен для анализа, но превращать его в полноценное приложение мы не захотели.
Нам нужна была система под себя — достаточно сложная в хорошем смысле и удобная. Мы решили ничего не покупать и не достраивать, а сделать самостоятельно.
Что сложного в расчете премий
Когда мы впервые рассказываем коллегам о нашей системе, вопрос всегда один и тот же: а зачем вообще городить огород, если премию можно посчитать в одно действие — привёл клиента, получил условных 10 процентов?
Для каких-то бизнесов это будет работать. Но у современного поставщика облачных вычислений всё устроено сложнее. Мотивация продавца должна решать сразу несколько задач. Как писал классик — слона надо есть по кусочкам.
Это:
· Контроль выполнения плана. Мы не сводим к бинарному «выполнил / не выполнил». Применяем линейную шкалу: выполнил план на 89% — коэффициент 0,89, выполнил на 76% — коэффициент 0,76. Это способ поощрять любой прогресс, а не только 100%-достижение.
· Тримминг парусов. Мы можем гибко направлять отдел продаж в нужное русло. Работа с новыми и действующими клиентами (HOLD / KEEP / FARM / HUNT), размер компаний (SMB/Enterprise или SMA/LA/KA), сегменты/отрасли, регионы/территории, кластеры/плечи, конкретные услуги (SKU) — всё это имеет значение и может менять свой вес. Это тонкая настройка. И чем она тоньше, тем точнее система приводит к нужному результату.
· Слои атрибуции. Бывает так, что у клиента может меняться менеджер. Им может стать сотрудник вообще из другого бизнес-юнита в другом регионе — ситуации бывают разные. Прирост рекуррента при этом должен качественно атрибутироваться, чтобы не создавать ложных перекосов. Чья заслуга — тот и заработал.
В миниатюре все эти блоки выглядят просто. Но затем они умножаются друг на друга, накладываются на десятки менеджеров, сотни клиентов, обширный портфель облачных услуг — и вот мы сидим на берегу озера данных без конца и начала. Вы сможете перемножить в уме две цифры; может быть, сможете даже три. Но для 12 значений нужен блокнот, калькулятор, Excel. А чтобы управлять ста тысячами уникальных строк (Excel ещё справится, человек — нет), десятками коэффициентов, сотнями взаимосвязей и сложной логикой их взаимодействия — пора пилить собственный софт на TypeScript, Python или чём-нибудь ещё.
Вручную можно считать бесконечно, зато с ошибками
Ещё в ручных расчётах риск ошибки велик — это не вероятность, а неизбежность. Люди устают, теряют концентрацию, путают строки: внимание при монотонной работе с однотипными операциями ограничено.
Автоматизация решает две задачи. Первая очевидна — скорость: то, что растягивается на месяцы, машина считает за секунды. Вторая — работа без ошибок: если формула прописана один раз, проверена на сценариях и сверена с контрольными расчётами, машина воспроизводит одну и ту же логику сколько нужно. Она не устаёт, не отвлекается и не путает строки на миллионе повторений — если алгоритм верный, результат тоже будет верным и на первой строке, и на последней.
А ведь есть ещё вопросы менеджеров
Менеджер хочет не только видеть результат, но и доверять ему: «Откуда эта цифра? А здесь почему такой маленький процент? Нет, это была не разовая продажа, а абонентская плата!». Мы тратим время на объяснения. Хотелось сократить путь: чтобы коллега смотрел детализацию, не разбираясь в формулах на двадцати листах. В перспективе — сделать интерактив и срезы данных.
В итоге мы разделили расчётную логику и интерфейс: движок обрабатывает данные по правилам, а человек работает с понятным интерфейсом и видит детализацию, а не возится под капотом.
Как мы пришли к вайбкодингу
Вайбкодинг — это программирование в режиме zero-code: вернее, код есть, но пишет его агент, не человек. Пользователь описывает задачу простым языком и получает ответ от LLM-агента, который так же легко вносит исправления по описанию.
Я видел, насколько загружены коллеги из разработки: задач много, приоритеты меняются, ресурсы не бесконечны. И подумал: можем ли мы взять часть работы на себя? Хотя бы попробовать собрать инструмент для задачи, в которой хорошо разбираемся, и пройти первые итерации. Так расчёт премий стал нашим первым экспериментом с AI-агентом.
Что конкретно мы сделали по шагам
Шаг 1. Установили среду разработки. Выбрали Visual Studio Code — бесплатный редактор для написания и редактирования кода. Он подсвечивает синтаксис и в целом удобнее для работы, особенно если в него встроен AI-агент, об этом дальше.
Шаг 2. Подключили AI через расширение. У VS Code есть система подключаемых модулей (расширений). Один из вариантов — Codex, интеграция от OpenAI. Альтернатива — Claude Code от Anthropic. Мы выбрали Codex, далее рассказываем о работе именно с ним: это вопрос личных предпочтений, кто-то работает с одной моделью, кто-то с другой. Модуль скачивается и появляется отдельной панелью прямо в интерфейсе редактора.
Способ доступа и оплаты зависит от выбранного агента. Для работы Codex необходимо авторизоваться через аккаунт ChatGPT или подключить API-ключ. Условия доступа и оплаты зависят от выбранного способа подключения.
Шаг 3. Создали пустую папку проекта — это и есть будущий проект. Открываем именно ее в VS Code. Как только редактор открывает эту папку, агент получает доступ к ней и начинает воспринимать ее как рабочее пространство, в котором будет создавать файлы.
Шаг 4. Сформулировали задачу. Я описал задачу агенту очень подробно и последовательно, как если бы общался с разработчиком. Например: «Мы будем разрабатывать систему мотивации, расчетный движок для премий менеджеров по продажам». Агент в ответ задал уточняющие вопросы — о структуре данных, о нужной логике, — и по мере ответов начал создавать файлы проекта.
Самое полезное в постановке задачи агенту — описывать правило вместе с числовым примером и ожидаемым результатом. Например: «При выполнении плана на 89% применяется коэффициент 0,89. Покажи отдельно исходную премию, коэффициент и итог после его применения». Затем добавляем пограничные случаи: что происходит при нулевом результате, неполных данных, смене менеджера или появлении новой услуги.
Шаг 5. Запустили приложение на своем компьютере. Наш инструмент написан на TypeScript с использованием React и Next.js. В текущей конфигурации для его запуска используется Node.js. Агент подготовил файлы проекта и команды: “npm install” устанавливает необходимые библиотеки, а “npm run dev” запускает сервер разработки.
Шаг 6. Проверили результат в браузере. Когда агент сообщает, что часть работы готова, смотрим результат на локальном хосте. После запуска в терминале появляется адрес, обычно http://localhost:3000. Открываем его в браузере и видим интерфейс приложения. localhost означает этот же компьютер: для проверки инструмента не требуется покупать домен или размещать сайт в интернете. Пока сервер работает, изменения в коде можно сразу проверять в браузере.
Шаг 7. Наращиваем логику итеративно. Дальше в диалоге с агентом постепенно добавляется бизнес-логика — теми же словами: «если продукт такой-то, премия умножается на такой-то коэффициент». Агент переводит эту формулировку в код, а результат снова проверяем в браузере — сходится ли расчет с ожиданиями.
Шаг 8. Донастраиваем и переспрашиваем. Если что-то считается не так, прямо говорим: «здесь неправильно, переделай». С агентом можно советоваться, просить проверить формулировки из законодательства, уточнять непонятные моменты — по сути, вести диалог.
Конечно, первое время результат получается сырым и примитивным, а чтобы довести инструмент до рабочего состояния, нужно время. Но все приходит с опытом. Главная ценность — можно сразу, почти мгновенно, посмотреть некое MVP системы, которое можно доработать.
Что оказалось сложнее, чем мы ожидали?
Первый работающий экран мы получили быстро: загружаешь файл, видишь таблицу и суммы, и кажется, что самое сложное позади. Но до состояния, когда по этим цифрам можно выплачивать людям деньги, было ещё много работы.
Главная трудность — точное понимание бизнес-правил. Агент может написать работающий код, который реализует не то, что имелось в виду. Хотя интерфейс нормальный, ошибок нет, результат правдоподобен. Заметить проблему можно, только зная правильный ответ. Здесь помогают контрольные примеры и self-checks.
При расхождении я показывал AI конкретный случай: исходные значения, ожидаемый и фактический ответ, просил объяснить вычисления и найти расхождение. Так находились ошибки в коде и неоднозначности правила.
Например, для нас важны различия между абонентскими услугами и разовыми продажами, между общей суммой и приростом относительно предыдущего периода. Для финансиста это разные экономические сущности, и в постановке задачи каждое различие приходится проговаривать: откуда берём базу сравнения, что считаем новым результатом, какие коэффициенты применяем и в какой последовательности.
Поэтому «здесь неправильно, переделай» быстро перестаёт работать. Полезнее разобрать маленький пример: данные прошлого месяца, текущего и ожидаемый результат. Например: «Абонентская плата не изменилась. Объясни, что в этом случае считается приростом и почему», а затем попросить показать промежуточные вычисления.
Вот реальный пример одного из моих боданий.
Обнаружилась ошибка в отображении прироста маржи. На условных цифрах: в сентябре выручка составляла 800, себестоимость — 600, маржа — 200. В октябре: выручка — 900, себестоимость — 650 тысяч, маржа — 250. Прирост маржи 250 – 200 = 50. Подробная расшифровка (в уровне 5) показывала правильное значение (50), а сводная таблица (в уровне 4) — 250. Сам расчёт премии в этом примере был корректным, но объясняющая его таблица вводила пользователя в заблуждение. Полночи я не мог понять, из-за чего это происходит. Оказалось, интерфейс выбирал только месяцы текущего квартала и терял сентябрьскую базу, заменяя её нулем.
Другая трудность — изменения по ходу разработки. После уточнений и новых сценариев нужно снова проверять работавшие случаи: локальная правка влияет на соседние расчёты. Поэтому нужны контрольные примеры, рабочие версии и небольшие последовательные изменения. Даже если код пишет агент, это часть разработки. Финансист здесь продолжает работать финансистом: определяет правила, разбирает исключения, проверяет цифры и отвечает за экономический смысл.
А что с безопасностью?
Вопрос безопасности возникает в двух местах: при разработке с агентом и при использовании готового приложения.
Сейчас калькулятор запускается локально. Пользователь выбирает Excel-файл через интерфейс, приложение читает его и рассчитывает премии непосредственно в браузере. В коде этого расчета нет обращения к AI-сервису: для начисления премий участие Codex не требуется.
Во время разработки ситуация другая. Запросы к облачной модели могут содержать фрагменты кода, прочитанных файлов и результатов выполнения команд. Поэтому важно контролировать, какие сведения доступны агенту и попадают в контекст задачи. Даже несмотря на то, что доступ агента ограничивается настройками песочницы и разрешений, локальное расположение проекта само по себе не означает, что вся работа происходит исключительно на компьютере. Поэтому для работы с персданными и деньгами мы выделили среду разработки с тестовыми обезличенными данными, а готовое приложение проверяли на реальных данных в отдельной среде без агента.
Что получилось в цифрах
За один расчёт мы обрабатываем несколько тысяч исходных строк за квартал. Загрузка и расчёт занимают около одной минуты. Отдельно остаются подготовка исходных данных и проверка результатов. На первую рабочую версию ушла пара недель, на последующую отладку — пара-тройка месяцев.
Куда идти дальше
В идеале мы хотим получить интерактивный дашборд, чтобы менеджер мог понастраивать параметры, поиграть с системой.
Сейчас у нас уже несколько слоёв:
· Верхний слой: фамилии сотрудников и итоговая сумма их премий. Здесь же эта сумма раскладывается по месяцам квартала — сколько заработано в первом месяце, сколько во втором, сколько в третьем.
· Второй слой детализирует месяцы в разрезе клиентов.
· Третий слой открывает разбивку по конкретным параметрам, которые повлияли.
· И так далее — вплоть до самой глубокой детализации.
Это промежуточный этап: системой пользуются только финансисты и коммерческий директор, менеджерам доступа нет. Через год-два видим инструмент не отдельным модулем, а частью единого портала компании с мобильным приложением. Коммерческий директор в любое время получит «бортовое табло» для сравнения сотрудников, бизнес-юнитов и регионов. Менеджер хоть по дороге на работу откроет телефон и в реальном времени увидит, сколько денег принёс компании с начала квартала, процент выполнения плана и набежавшую премию.
У этого есть и обратная сторона: постоянная видимость собственного прогресса может работать двояко — для одних это будет мотивацией ускориться, для других, наоборот, источником тревоги, если дела идут не так, как хотелось бы. Но этот вопрос мы оставим психологам.
Вместо вывода
Я не говорю, что AI заменит разработчиков. Я делюсь идеей, как финансистам и аналитикам, которые лучше всех знают свою предметную область, снизить порог входа в разработку инструментов. Сейчас я встречаю всё больше резюме, где помимо финансов молодые специалисты указывают Python, SQL, UX/UI, что-то ещё явно не из мира TradFi. В конце концов, такую систему можно показать отделу айти как прототип, пример того, что надо реализовать. Иногда ведь лучше один раз увидеть.
Если вам интересна тема вайбкодинга, мы с коллегами расскажем и про другие прикладные проекты в компании. Не стесняйтесь написать об этом в комментариях, делитесь мнением, задавайте вопросы. И подписывайтесь на наш Telegram, там регулярно пишем про облака и кибербез, делимся новостями компании.
