Многие думают, что большие компании не совершают ошибки. Но даже если у вас налажен процесс код‑ревью и всё тщательно проверяется, риск накосячить никогда не равен нулю. Хотя, конечно, всегда лучше учиться на чужих ошибках, чем на своих.

Меня зовут Юрий Беглецов, я технический продакт в Точка Банк. Мы с командой делаем универсальные API, чтобы клиенты могли интегрировать банк и дочерние сервисы прямо в свои системы. Иногда у нас тоже бывают провалы — обидные, серьёзные и даже забавные. Две истории из серии «никогда больше» — под катом.

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

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

«Обучил, запустил и забыл» — плохая стратегия работы с ML‑моделями, но она часто встречается после удачного тестирования. Качество моделей может незаметно снижаться, и если пропустить этот момент — последствия могут дорого стоить. Когда мы начали задумываться о системе мониторинга, одна из наших моделей начала выдавать предсказания, которые требовали незамедлительного вмешательства в выстроенную работу. Но разум подсказывал, что проблема не в процессе, а в модели. О том, каким трудоемким оказалось наше расследование, и как мы восстанавливали и изучали каждую составляющую процесса почти вслепую, читайте по ссылке.

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

Привет! Меня зовут Мария Аркуша, я продакт-менеджер в Точка Банк. Сегодня хочу рассказать, как нам удалось ускорить и упростить процесс разработки и выкатывания новых фич в продукте. 

Онлайн‑чат — одна из главных точек контакта клиента с банком. От того, каким будет диалог, зависит не только пользовательский опыт, но и ключевые показатели. Системная работа над качеством поддержки — реальный рычаг влияния на эффективность бизнеса. Необходимо регулярно оценивать диалоги: отмечать, где специалист справился хорошо, а где упустил важные моменты. Своевременная обратная связь даёт возможность поддерживать единый стандарт коммуникации на высоком уровне.

В Точка Банк эту задачу решают диалог‑коучи — эксперты, которые оценивают чаты по множеству критериев и проводят подробные разборы на специальных встречах. Но при потоке в сотни обращений в день часть диалогов не попадает в разбор, а часть может оцениваться субъективно.

Мы задались вопросом: можно ли сократить объём рутинной ручной работы и при этом сохранить — а возможно, и повысить — точность оценки? Гипотеза была простой: если использовать LLM для предварительной оценки чатов, то диалог‑коучи смогут работать только с отобранными, действительно показательными диалогами без необходимости просматривать весь массив вручную.

Привет, Хабр! Меня зовут Евгений Сабиров, я развиваю тестировщиков в Точка Банк. Много лет занимаюсь подготовкой докладчиков к конференциям, грейдирую и собеседую тестировщиков. И за это время не мог не заметить, насколько размыта зона ответственности этой роли: где-то тестировщик отвечает за коммуникацию с клиентами и проработку дизайна, где-то — только за написание автотестов, при этом про анализ требований даже не вспоминают. Такая размытость сама по себе нормальна: разным командам нужны разные навыки.

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

В этой статье я попробую очертить роль тестировщика, выделить её ключевые обязанности и показать, как эти активности вписываются в процесс разработки. Это поможет самим тестировщикам яснее понимать ценность своей работы, а руководителям — более чётко распределять зоны ответственности внутри команды.

Работоспособность любого приложения может быть подвержена угрозам: от сбоев в работе до кражи персональных данных. С этими рисками следует работать через регулярные и комплексные проверки кода на уязвимости, которые должны быть полностью автоматизированными. 

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

Меня зовут Алексей Исламов, я администратор СИБ в Точка Банк. В статье предлагаю готовый вариант реализации такой системы из open‑source инструментов, которым может воспользоваться каждый.

Часто Kanban ассоциируется с продуктовыми командами. Но мы в Точка Банк решили внедрить его в Devexp — это команда, которая занимается предоставлением и сопровождением, а также разработкой и развитием инфраструктуры и сервисов для разработчиков. У ребят уже была небольшая база в виде простой панели в проекте Jira, но отсутствовали необходимые процессные метрики. Мы использовали системный подход STATIK, но адаптировали его с учётом специфики инженерной работы.

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

Наверняка вы сталкивались с ситуациями, когда модель начинает вести себя в проде не так, как задумывалось: например, ведётся на провокации пользователя или даёт некорректные ответы. Зачастую такие ошибки безобидны, но случаются и не очень приятные ситуации. А если речь идёт о чат-боте, который отвечает на вопросы в юридической или медицинской сфере — практически любая ошибка может быть критичной. 

Итак, мы плавно подошли к тому, что нужно каким-то образом валидировать ответы LLM. Давайте разберёмся, как это делать.   

У нас в Точка Банк много продуктов, для которых нужны SEO-лендинги: онлайн бухгалтерия, эквайринг, электронный документооборот. Создание одного сайта — это несколько недель работы с участием редактора, дизайнера, разработчика, тестировщика, верстальщика. Не страшно, если нужен один сайт. Но когда их много, на их создание уходит колоссальное количество времени. 

Меня зовут Василий Полосухин — я фронтовый техлид в Точка Банк. В статье рассказываю, как мы сделали визуальный конструктор страниц и научились собирать сайты без кода.

В Точка Банк нет арт-директоров или лидов, которые принимают финальные решения по дизайну. Мы верим, что сильный дизайн рождается в совместной работе, а не в «указах сверху». Чтобы сохранять консистентность и высокое качество в экосистеме продуктов, нам нужен был процесс: как переопыляться, делиться хорошими решениями и держать планку. Так появилось дизайн-ревью — одни дизайнеры отсматривают макеты других и предлагают идеи по улучшению.

На старте небольшой команде хватало нескольких ревьюеров. Но когда команда выросла до 50+ дизайнеров, процесс начал буксовать. Ревью из помощника превратилось в узкое горлышко: сроки срывались, ревьюеры выгорали, качество проседало.

Мы прошли через это и перестроили процесс так, чтобы он масштабировался на десятки кейсов, прокачивал команду — и при этом не тормозил работу. Рассказываем, как.

Мы в Точка Банке делаем свою LLM. Чтобы она работала хорошо, недостаточно просто обучить её на куче текстов. Для получения осмысленного и предсказуемого поведения модели, нужен Alignment — дообучение с учётом предпочтений и ограничений. В статье расскажу, какие методы применяют в современных моделях, и как мы адаптировали их под себя.

Привет! Меня зовут Мария Аркуша, со мной Николай Нафтулин, мы продакт-менеджеры в Точке. Сегодня расскажем, как мы одновременно создавали Точка Стор — продукт для предпринимателей, с помощью которого любой может быстро собрать свой сайт или витрину в Telegram.

Объясним, как мы делали практически одинаковые продукты, и как объединение ресурсов помогло продвинуть и развить продукт, усилить экспертизу команд и сэкономить ресурсы компании. 

Сегодня просто написать хорошую модель уже недостаточно: важно постоянно следить за её предсказаниями, так как поведение клиентов меняется со временем, и модель может терять в их качестве. Чтобы эффективно отслеживать её работу, нужна система мониторинга, которая определяет методы и частоту проверок, критерии отклонений. Построение целой системы часто пугает ML-команды объёмом работ — так модели остаются и вовсе без мониторинга. 

Одна из наших моделей, которая предсказывает отток клиентов, начала выдавать странные результаты. Стоит отметить, что она на тот момент уже не использовалась, поскольку была разработана новая, но старая оставалась как индикатор оттока с устаревшей методологией. Мы решили разобраться в странном поведении и понять, какие признаки нужно добавить в мониторинг, чтобы не упускать важные детали из виду.

Нам важно, чтобы поддержка пользователей была на высоком уровне, поэтому у нас есть десятки сервисов для организации обучения специалистов поддержки. Я работаю над одним из таких проектов. Он активно развивается: ежемесячно добавляем более 10 новых страниц — сейчас в проекте их больше 120.

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

Два года назад в Точке появилась новая роль — prompt-инженер. Первые полгода инженеры работали над разными кейсами: от классификации данных до разработки AI-ассистентов. Для этого пригодился опыт и маркетолога, и копирайтера, и инженера АСОИУ. Ещё prompt-инженеры участвовали в генерации синтетических данных для коллег из ML — для этого важно было понимать основы Data Science. 

Привет! Меня зовут Екатерина Шихиева, я лидер prompt-инженеров в Точке. Из-за обилия задач и проектов процесс найма промптеров почти не останавливается. Сейчас у нас отлажен подбор кандидатов, грейдирование и внутренний менторинг — но в этих процессах всё не так просто. Об этих подводных камнях и нюансах расскажу в статье.

Иногда стек технологий в разработке становится похож на зоопарк. Количество технологий растет, одни и те же задачи решаются разными инструментами, которые дублируют друг друга. В итоге команде «смотрителей» каждый раз нужно выбирать, кого из голодных львов покормить первым. 

Меня зовут Ирина Колесникова — я тимлид в финтех-компании Точка. В этой статье расскажу, как мы столкнулись с «зоопарком» при переезде с Vue на React, и что помогло превратить хаос в систему. 

У нас есть внутренний плагин для Фигмы, который проверяет макеты на соответствие техническим параметрам. За несколько лет он сэкономили нашим дизайнерам много сил, а компании — денег.

В статье поделюсь техническими деталями создания плагина для тех, кто захочет повторить наш опыт. 

Теория ограничений — это метод управления, разработанный Элияху Голдратом в 1980-х годах. Для популяризации своих идей он написал несколько книг в формате бизнес-романов, где на реальных кейсах показал инструменты, которые помогают разложить любую проблему по полочкам и найти возможные пути решения. 

Когда мы в Точке узнали про теорию ограничений, она показалась нам серебряной пулей, которая может решить все проблемы. В том числе и проблему сбоев, так как всего за пять месяцев года мы получили абсолютно негуманный размер манибэка. Мы заручились поддержкой практикующего тренера Саши Брызгаловой и начали разбираться, как повысить качество сервиса. Подробности — под катом.

Привет, Хабр! На связи команда LLM-dev из Точки. Как несложно догадаться, наша основная миссия — учить и улучшать внутреннюю LLM и модели, связанные с ней. Для этого нужно очень-очень много текстовых данных, которые надо где-то хранить и как-то уметь с ними работать. А ещё нужно ставить эксперименты, которые надо как-то трекать и воспроизводить, писать и отлаживать много кода, и делать всё это в команде. 

О том, как сделать код читаемым, эксперименты — воспроизводимыми, а время на написание и рефакторинг своего и чужого кода — минимальным, и поговорим в этой статье. И всё это без привязки к готовой инфраструктуре внутри компании.