Всем привет! Я — Наталья Самсонова, старший системный аналитик ГК Юзтех. В этой статье расскажу, как, на мой взгляд, ИИ изменит практику аналитика.  

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

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

В наши дни активно набирает обороты искусственный интеллект (ИИ). На рынке заказного ПО преобладающий спрос на решения с ИИ-компонентами становится обычным явлением. В этой ситуации возникает вопрос готовности участников рынка исполнять современные требования заказчиков. 

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

Согласно SDLC создание системы ведется последовательно: анализ требований, проектирование, разработка, тестирование, развертывание и поддержка. К какой трансформации работы готовиться участникам на каждом из этапов?

Привет, мир! Меня зовут Роман Ремизов. Я — системный аналитик ГК Юзтех. В рамках цикла статей «Хроники архитектурного дизайна» я поделюсь своей экспертизой о разных автоматизированных банковских системах (АБС) и о том, что нужно знать перед тем, как приступить к архитектурному дизайну.

В условиях ограничения доступа к самым современным технологиям компании всё чаще стремятся переложить заботу о поддержании работоспособности ИТ-инфраструктуры на профессионалов. И вариантов тут два: либо консолидировать вычислительные ресурсы на собственной технологической площадке, развитием которой будут заниматься своя ИТ-служба, либо отдавать вычислительные ресурсы на аутсорсинг, то есть пользоваться услугами облачных провайдеров. Проще, конечно же, доверить управление ИТ-инфраструктурой сторонним профессионалам, однако надежнее и безопаснее развивать собственные компетенции за счет внедрения современных средств автоматизации управления Центрами обработки данных (ЦОД).

Привет всем! Я, Ипатов Александр, backend-разработчик в ГК Юзтех. Сегодня хочу поделиться своим опытом создания (в комплексе с элементами ETL, DWH) и использования BI-инструментов, не затрагивая российский сегмент, о котором в последнее время слышно очень много, в связи с событиями, связанными с запретом использования западных продуктов. На мой взгляд, общие принципы разработки и использования везде идентичные, и хочется сделать обзор именно по глобальному игроку на рынке BI решений, о нём ниже.

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

Преимущества использования BI инструментов

BI инструменты предоставляют много преимуществ, которые могут значительно повысить эффективность работы компании:

Мобильная разработка продолжает активно развиваться по разным направлениям. Попробую выбрать несколько основных трендов развития в 2025 году:

1) ИИ

C выпуска Chat GPT осенью 2022 года и появления его аналогов у Yandex, Google и других компаний мы переживаем настоящий бум различных LLM. Спектр их использования довольно широк: ассистенты в чатах, помощники-анализаторы, генераторы контента и так далее.

Весной 2024 года Google представили ИИ-помощников, интегрированных как в саму ОС Android, так и в инструменты разработки Android Studio, а также SDK для подключения ИИ-помощников уже в своё собственное приложение. Примерно в то же время Apple объявили о создании своего ИИ-помощника на базе моделей OpenAI. Из-за разных ограничений, решения доступны не все пользователям, что делает крайне актуальной разработку аналогов (чем и занимается, в частности, Сбер). Также актуальным будет создание и обучение собственных ИИ-ассистентов на базе открытых LLM (например, известная и популярная Meta-LLama), чем уже заняты крупные компании.  

2) Кросс-платформенная разработка

Не секрет, что компания Google, разрабатывающая Flutter, в 2024 году сделала открыто ставку и на Kotlin Multiplatform, объявив совместимость с данной технологией одним из своих приоритетов. В этом году они активно занимались переводом Jetpack библиотек для разработки современного приложения Android и на кросс-платформу. Flutter также не сдаёт свои позиции и всё больше завоёвывает популярность во многих компаниях. Это хорошее решение для ускоренной разработки ряда клиентских приложений. Также он становится инструментом для удобного создания приложений под ОС Aurora.i

Всем привет! На связи руководители Frontend‑практики ГК Юзтех. В этой статье мы подводим итоги 2024 года и делимся нашими прогнозами на 2025 год. Приводим мнение трех экспертов по ключевым трендам фронтенд‑разработки и фреймворков, которые будут актуальными в следующем году.

Коллеги, доброго дня и отличного настроения!

Меня зовут Ремизов Роман, я системный аналитик ГК Юзтех, и в этой статье я расскажу про использование JDBC коннектора Kafka для обработки нескольких сообщений в одном агрегате, с целью оптимизации производительности записи данных в базу.

Статья будет полезна тем системным аналитикам, на проектах которых в работе имеются высоконагруженные системы в микро-сервисной архитектуре, а в качестве очереди сообщений используется Kafka. В роли базы данных выступает PostgreSQL старше версии 15.

Всем привет! Я Родин Максим, старший разработчик ГК Юзтех. 

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

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

И, прежде чем начать, хочется определиться с условностью, которая заключается в следующем: Обновление — это не всегда переход к более новой/свежей версии какого-либо продукта, это ещё и понижение его версии, смена одного инструмента на другой, избавление от того или иного решения.

Привет всем!

Я — Ипатов Александр, backend‑разработчик в ГК Юзтех. Сегодня хочу поделиться своим опытом в интересном проекте, связанном с миграцией БД MsSQL на PostgreSQL в разрезе оптимизации хранимых процедур и функций (далее — хранимых процедур, так как процесс оптимизации не сильно завязан на том, что именно имеем на выходе).

Актуальность проектов, связанных с миграциями серверов и баз данных с зарубежных платных продуктов (Microsoft, Oracle) на аналогичные отечественные или зарубежные open‑source решения (в разрезе статьи будем рассматривать Postgres) в 2024 году очень велика. Те решения, которые были реализованы и поддерживались на протяжении 5–10 лет, потребовалось практически в формате «пожара» переносить на аналогичные. А бизнес, который привык к уже полностью сформированным и отработанным рабочим процессам, не готов к потере эффективности и, как следствие, потере клиентов сервисов, заказов и бизнес‑метрик.

В одном из таких проектов мне удалось поучаствовать. Из начальных условий: проект по переносу БД из MsSQL начался примерно 3 года назад.

На самом деле, проект был более обширный — перенос монолитного сервиса на микросервисы, в том числе, как один из элементов — перенос БД.

Хочется отметить, что перенос схем, таблиц, индексов и других элементов базы данных прошел относительно спокойно. Чего не скажешь о переносе хранимых процедур. Язык T‑SQL, на котором пишутся хранимые процедуры в MsSQL, конечно же имеет отличия от PL/pgSQL, который используется в PostgreSQL. В связи с чем, непосредственно миграция хранимых процедур заняла много времени: точное число хранимых процедур я не назову, но порядок — около 800 штук (среди которых 500 стали работать хуже после миграции, их то и предстояло оптимизировать).

Елизавета Акманова, старший аналитик ГК Юзтех, снова на связи. Сегодня у меня в планах обсудить, зачем и где нужны API Gateway. Для этого верхнеуровнево пройдём по архитектуре этого паттерна, рассмотрим решаемые задачи. Ключевой вопрос на сегодня: Когда стоит использовать эту технологию? Это полезный инструмент но, увы, не всегда.

Всем привет! Меня зовут Лида Анисимова, я backend разработчик продукта — платформы мотивации сотрудников Тил Эйчар. В этой статье хочу рассказать о нашем опыте реализации push-уведомлений. Если вы, как и я полгода назад, ничего не знаете о том, как работают push-уведомления — эта статья для вас. Расскажу о том, с какими трудностями мы столкнулись, покажу, как отправить первый push и какие данные вам могут понадобиться.

Всем привет! На связи снова Алина — аналитик продукта Тил Эйчар. 

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

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

Введение

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

Привет, меня зовут Нина Полторакова, я ведущий тестировщик в ГК Юзтех. 

На данный момент мы с командой занимаемся разработкой и поддержкой ИТ-решений по направлению Life — страхование жизни.

В этой статье я хочу поделиться несколькими приёмами, как не сойти с ума, тестируя страховые продукты. 

Вместо вступления

За свои более чем 12 лет в сфере тестирования и обеспечения качества я успела и потестировать, и поруководить, и побывать совершенно на разных проектах, начиная с крохотных коммерческих, заканчивая огромными и пугающими госконтрактами. Но как-то исторически сложилось, что меня тянет на страховые проекты, а страховые проекты тянет ко мне.

Да у вас, голубчик, аддендум

Первое, что поражает, когда ты приходишь тестировать страховые продукты — это обилие страховых терминов. 

Аддендумы, ИСЖ, периоды охлаждения, полупроводки, периоды ответственности, КВ структуры, андеррайтинги, бррр, тут бы с тестированием разобраться сначала! 

Но невозможно протестировать то, значение чего ты не понимаешь, поэтому, чтобы не сойти с ума — ищите словарь терминов и сокращений, он на проекте точно есть. 

Всем привет! С вами снова я, Елизавета Акманова, старший аналитик в ГК Юзтех. Сегодня хочу поделиться, почему и как мы с командой discovery перешли на описание API с помощью OpenAPI, и при чём здесь системный дизайн. 

Привет, я Саша. В продуктовом дизайне уже более 6 лет. Успел поработать как в небольших стартапах, так и в крупных продуктах в B2B и B2C сегментах, а ещё я веду канал о дизайне. 

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

Всем привет! Меня зовут Алина. Я работаю аналитиком более 3-х лет, сейчас –  в ГК Юзтех с продуктом Тил Эйчар. Это программа лояльности и мотивации персонала, которая позволяет снизить стоимость привлечения новых сотрудников и удержать текущих сотрудников.

Это статья будет полезна, в первую очередь, для бизнес и системных аналитиков, а также для дизайнеров, проджект менеджеров и даже тестировщиков. Аналитики смогут поразмышлять над описанными подходами в плоскости своих непосредственных задач, дизайнеры – над тем, в какой момент определяться с внешним видом компонентов для загрузки и ошибок, проджект менеджеры – над оценкой временных затрат на похожие задачи, а тестировщики – над структурой тест-планов для тестирования таких ЭФ.

Введение

Сегодня поговорим об экранных формах (далее – ЭФ), для отрисовки которых нужно получить данные из нескольких источников. В связи с этим возникает ряд вопросов, на которые нужно ответить прежде чем приступать к разработке. Например:

Всех приветствую в своей новой статье! Меня зовут Елизавета Акманова. С некоторыми читателями уже знакомы с предыдущих тем, для новых представлюсь: я системный/бизнес аналитик с опытом работы 3 года. Было много проектов разного уровня и сложности: начиная с монолитов в команде из 4 человек, заканчивая 50+ микросервисами из 90 человек. Но все проекты объединяло одно: API. Абсолютно в каждом присутствовал этот термин, приходилось работать с проектированием API, и сегодня я хотела бы рассказать про подходы, как это можно делать и подчеркнуть особенно метод API-first.