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

Привет! Меня зовут Александра, я системный аналитик в компании «Совкомбанк Технологии». У меня большой рабочий опыт в интеграциях и выстраивании рабочих процессов. До недавнего времени моя роль была классической — «переводчик» между бизнесом и разработкой: я писала ТЗ, рисовала схемы, проводила встречи и тестировала код. Но многое изменилось с приходом в мою жизнь N8N. В этой статье хочу поделиться с вами опытом внедрения в работу инструмента N8N.

Если вы работаете в финтехе, то знаете: продуктовые менеджеры тонут в рутине. Документация, согласования, бесконечные уточнения «а что имел в виду бизнес?», приоритизация бэклога, аналитика, стратегии... А на нормальную работу с клиентом — ту самую, ради которой мы вообще пришли в продукт – остается совсем чуть-чуть.

У нас эта проблема стала критичной, когда портфель цифровых продуктов Совкомбанка вырос быстрее, чем штат продуктовой команды. В какой-то момент мы осознали, что каждый PM тратит на рутину до 60% времени. И дело не в том, что мы плохо организовались — проблема была системной: чем больше продуктов, тем больше текстов, табличек, чек-листов и пояснительных записок.

Я сделал то, что обычно делает продакт, когда его раздражает системная проблема: попробовал собрать решение. Моим «продуктом» стал ИИ-ассистент — по сути, один большой, но хорошо собранный промпт, который превращает LLM в продуктового напарника.

Как сделать адаптацию не просто формальностью, а эффективным, комфортным и полезным процессом — для новичка, команды, проекта и всей компании?

В этой статье поделюсь опытом, практическими инструментами и стратегией, которые помогут менторам в адаптации новичков.

Привет, Хабр! На связи Алина, старший Android-разработчик в команде Инвестиций «Совкомбанк Технологии». Сегодня поговорим о том, как заставить Android Studio самостоятельно следить за порядком в коде – без ручных проверок и без вечных напоминаний в командном чате.

В этой статье мы создадим практические правила для инструментов статического анализа кода и разберем, как внедрить их в проект. На примере lint рассмотрим контроль архитектуры пакетов и обязательную документацию с QuickFix, а на примере detekt – проверку неизменяемого состояния представления без Android-зависимостей и миграцию с RxJava на Coroutines.

Системные аналитики на связи?

Тоже сталкиваетесь в работе со сложными распределенными системами, большим количеством интеграций и микросервисной архитектурой?

Тогда предлагаю вам узнать больше про модель C4 – отличный инструмент для проектирования, анализа и коммуникации между участниками команды.

Если в процессе взаимодействия с ИИ-инструментами вы долго не получаете полезного результата и теряете время в циклах взаимодействия с агентом, не торопитесь становиться скептиком. Попробуйте применить советы из этой статьи. В дополнение к основной теме затронем приемы, которые помогут улучшить ваш опыт взаимодействия с агентами.

Привет! Я Дмитрий, инженер и руководитель направления MLOps в Совкомбанке. Специализируюсь на разработке и эксплуатации ML-платформ на базе Kubernetes и GPU.

С 2010 года в ИТ: строю инфраструктуру для машинного обучения, внедряю Kubeflow и GPU-оператор, настраиваю MIG на H100 в корпоративных средах с повышенными требованиями к безопасности и надежности. В последние годы фокусируюсь на оптимизации ML-пайплайнов, повышении утилизации GPU (включая MIG-профили) и интеграции MLOps-практик в процессы продуктовых команд.

В 2022 году в некоторых командах разработки уже существовали проекты с применением ИИ, но как отдельные компоненты, не хватало единой платформы управления. По мере роста количества и сложности бизнес-задач возникла необходимость в создании ML-платформы как сервиса с едиными стандартами авторизации. Мы изучили доступные инструменты, попытались объединить их в одном Kubernetes-кластере, столкнулись с рядом ограничений — и в итоге пришли к архитектуре на базе Kubeflow и GPU-оператора.

В статье рассказываем, какие сложности были в ходе проекта, как выстроили работу с Kubeflow, настраивали H100 с MIG-разделением и что важно учесть, если вы планируете строить ML-платформу на bare-metal-GPU в корпоративной среде.

Давайте представим типичную ситуацию для разработчика: вы делаете фичу, код проходит ревью, тесты «зеленые». На первый взгляд все хорошо, вы отправляете её в релиз. А потом на проде обнаруживается визуальный баг: текст наехал на текст, цвет оказался не тот, отступ съехал. Бывало такое?

В чем проблема – ведь тесты были пройдены успешно? Дело в том, что юнит-тесты проверяют только логику. Им все равно на то, как выглядит экран.

А screenshot-тесты нужно писать вручную в большом количестве. В классическом подходе мы прописываем каждый тест, но что если у вас 50 экранов по 5 состояний на каждый? Так как же быть, если не хочется писать 250 тестов вручную, а проверку сделать нужно?

Если вы хоть раз теряли пользовательский ввод после поворота экрана или возвращались к приложению из фона и обнаруживали пустой экран вместо заполненной формы — вы знаете, о чем пойдет речь. Сохранение состояния в Android — одна из тех тем, которые кажутся простыми до первого бага в проде. Система может убить процесс в любой момент, конфигурация меняется, а пользователь ожидает, что все останется на своих местах.

В статье о том, как паттерн Memento реализуется в Android через CustomView, SavedStateHandle, Compose и навигацию.

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

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

Документация может спасти проект или убить его, если подойти к ней без дисциплины

В этой статье системный аналитик Влад показывает, как применять инженерные принципы — SRP, SSOT, ООП — не к коду, а к аналитике, описанию систем и документированию решений.

Нажми и забудь: как автоматизировать рутину с PowerShell и GUI

Это руководство пригодится всем, кто устал от рутины и хочет сделать свои PowerShell-скрипты доступными для коллег: системным администраторам, инженерам технической поддержки, DevOps-специалистам. Мы не только разберем основы создания кнопок и окон, но и ответим на ключевые вопросы: Как выбрать между WinForms и WPF, как избежать зависания интерфейса при выполнении долгих операций, и как удобно упаковать ваш скрипт в EXE или ярлык, чтобы любой сотрудник мог запустить его одним кликом.

Что такое мобильная ферма и зачем она нужна – расскажем о том, как устроена ферма СовкомТеха и поделимся отзывами коллег.

Примерно 65% критических багов в IOS-приложениях можно выловить ещё на этапе разработки, если грамотно использовать встроенные инструменты Xcode

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

В финансовой сфере дизайн — это не только про красивый визуал

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

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

Всем привет! На связи Арслан, тимлид команды тестирования компании «Совкомбанк Технологии». В этой статье я поделюсь опытом успешного внедрения методов искусственного интеллекта и больших языковых моделей (LLM) в тестирование программного обеспечения. 

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

Представьте мир, где каждое ваше платежное поручение теряется между банковскими системами. Где клиент не может оформить кредит, потому что «что-то сломалось». Где регуляторы штрафуют за несоответствие данных, а ИТ-команда разводит руками: «Но бизнес же не объяснил, что ему нужно!»

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

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

В этой статье вы узнаете, чего больше всего боятся тимлиды, и что с этим делать.

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

Привет! Меня зовут Алексей, я работаю тестировщиком в компании «Совкомбанк Технологии». Хочу поговорить о нефункциональном тестировании мобильных приложений на платформах Android и iOS.

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