«Чтобы научиться решать кейсы, надо работать» ©

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

Это первая из двух статей о CancelledError — сигнале отмены задачи. В ней мы остановимся на стандартном asyncio. Узнаем, что на самом деле представляет собой CancelledError, с точки зрения event‑loop. Разберёмся, как работает счётчик отмены (cancel/uncancel), на котором построены TaskGroup и asyncio.timeout. Наконец, обсудим проблемы, которые возникают на практике, в первую очередь связанные с asyncio.shield.

До того как начать инвестировать в разработку продукта, команде стоит проверить, есть ли реальный спрос на продукт и насколько убедительно для клиента звучит ценностное предложение. Для этого на ранних этапах мы используем разные методы валидации гипотез: от анализа рынка и качественных интервью до количественных исследований, fake door тестов, concierge‑подхода и MVP.

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

Большинство продуктовых рынков со временем достигают пика конкуренции. Команды продолжают добавлять фичи и улучшать интерфейсы, но выделяться становиться всё сложнее, а порог входа для новых игроков слишком высокий.

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

Когда живешь в такой команде, твой базовый вопрос — какие проекты делать, чтобы метрики выросли. Нам тогда рассказали, что есть такие ICE/WSJF/… Потом мы поняли, что на нашем уровне энтропии такие штуки — полная чушь (и дальше расскажу, почему). Встал вопрос, как иначе выбирать, какие проекты брать в работу.

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

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

Бывает, что фича готова и её пора передавать в тестирование, но при этом не покидает ощущение, что что-то не так. Однажды внутреннее чутьё меня не обмануло и привело в исходники React.

Меня зовут Денис Кондратьев — я фронтенд-разработчик в Точка Банк. В статье поговорим, как работает приоритетный рендеринг в React, что такое проблема разрыва и разберём реальный кейс на примере корпоративного мессенджера.

Если у вас одна платформа, фронтенд работает стабильно и предсказуемо. Но стоит добавить десктоп, мобильное приложение, PWA — и простая логика превращается в гору if-ов.

Меня зовут Денис Кондратьев, я фронтенд-разработчик Точка Банк. В статье расскажу, как мы интегрировали наш мессенджер на четыре разные платформы (браузер, Electron, Capacitor, PWA) и сократили время адаптации новых фич в три раза.

Когда у вас один‑два сервиса и несколько интеграций, внешний API легко держать под контролем. Но если их десятки и каждый хочет выставиться наружу, приходится придумывать свой велосипед.

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

«Ты будешь единственным тестировщиком на проекте», — услышал я на знакомстве с командой. Ничего страшного, с кем не бывало? «У нас не было постоянного тестировщика, нужно выстраивать все процессы с нуля», — добавил мой будущий тимлид. А вот это уже интереснее. 

Меня зовут Илья, я отвечаю за качество A/B‑платформы в Точка Банке. Сегодня я хочу рассказать, как тестировщику воспользоваться безграничной властью с пользой для всех (и немного для себя).

Что делает ваше FastAPI-приложение, когда клиент неожиданно закрывает соединение? По умолчанию — ничего. Если сервису важно экономить ресурсы (например, при работе с LLM), дисконнекты приходится обрабатывать явно, иначе GPU продолжит генерировать токены в пустоту.

В FastAPI есть встроенные механизмы отмены обработки запроса при дисконнекте клиента. Однако просто включить их недостаточно: нужно подготовить ваш код к этому. Иначе возможны проблемы: зависшие транзакции и сломанный пул соединений с БД.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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