Системный и бизнес-анализ

17 бесплатных вебинаров для аналитиков: ИИ, требования, бизнес-процессы и микросервисы

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

Чем сложнее становятся продукты и системы, тем важнее для аналитика видеть картину целиком: от бизнес-целей и клиентского опыта до требований, бизнес-логики, данных и архитектуры. А ещё — уметь работать с изменениями и использовать ИИ там, где он действительно помогает ускорить рутинную работу.

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

Системный анализ и требования

• 28 сентября в 20:00. «Валидация требований с ИИ в техническом проекте».

• 29 сентября в 20:00. «Зелёные тесты, неверный продукт: как системному аналитику принимать работу ИИ-агента».

• 14 октября в 20:00. «ИИ-агент как супероружие Системного Аналитика: составляем ТЗ за 10 минут».

• 22 октября в 20:00. «Управление изменениями требований».

Бизнес-анализ и управление процессами

• 5 октября в 20:00. «Как связать стратегические цели компании с KPI команд».

• 6 октября в 20:00. «Как найти точки роста и улучшить бизнес-процесс: от диагностики до новой модели».

• 15 октября в 20:00. «Цели и метрики как одно целое».

• 19 октября в 20:00. «Как наладить процессы без вложений: никаких бюджетов, систем и выделенных команд».

Стейкхолдеры, клиент и продукт

• 5 октября в 20:00. «Как AI помогает продакту быстрее проверять гипотезы».

• 8 октября в 20:00. «Как запустить ИИ-продукт: от бизнес-гипотезы до первых измеримых результатов».

• 21 октября в 20:00. «Анатомия сопротивления: превращаем токсичных стейкхолдеров в союзников проекта».

• 22 октября в 20:00. «Любовь с первого касания: как CJM помогает строить отношения с клиентом».

Архитектура, бизнес-логика и интеграции

• 6 октября в 20:00. «Практические подходы к переходу от монолита на микросервисы».

• 20 октября в 20:00. «Tool Calling и MCP: интеграция ИИ-агентов с корпоративными системами».

• 21 октября в 20:00. «Основы проектирования бизнес-логики в микросервисной архитектуре».

Данные и аналитика

• 30 сентября в 20:00. «Качество данных: риски и ответственность».

• 20 октября в 20:00. «Метрики качества данных и стратегия внедрения».

Полный список открытых вебинаров смотрите в календаре мероприятий.

Делимся записью вебинара

Luma: объединяем Data Governance, Business Intelligence и Искусственный интеллект

Вместе с Arenadata на вебинаре представили совместное решение Luma и рассказали, как интеграция каталога данных, BI-платформы и искусственного интеллекта помогает выстроить единое пространство для управления корпоративными данными и аналитики.

Видео на нашем сайте

Обычная колода из 52 карт содержит почти немыслимое количество возможных комбинаций. Их количество сопоставимо с оценками числа атомов в нашей галактике.

Для первой карты существует 52 возможных позиции, для второй — 51, для третьей — 50 и так далее. Общее число вариантов равно:

52 × 51 × 50 × … × 2 × 1.

В математике это записывается гораздо короче: 52!, или «52 факториал».

За этой компактной записью скрывается число из 68 цифр:

52! ≈ 8 × 10⁶⁷.

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

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

Но здесь возникает другой вопрос: сколько раз вообще нужно тасовать колоду, чтобы считать её хорошо перемешанной?

Исследования математиков показали удивительный результат: для обычной колоды достаточно примерно семи правильных riffle shuffle — привычных тасовок, при которых колоду делят примерно пополам, а затем переплетают две половины небольшими группами карт.

После одной или двух тасовок первоначальный порядок всё ещё хорошо заметен. Даже после четырёх или пяти в колоде сохраняется значительная структура.

А затем происходит резкий переход.

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

Получается своеобразный порог.

До него колода сохраняет память о прошлом. После него эта память почти исчезает.

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

Хорошего дня! заходите на тг канал https://t.me/TradPhronesis

Так, подъехала хорошая новость недели: мои еженедельные дайджесты новостей возвращаются на Хабр!

Я писал в июне, что мне там сообщили «Habr только про айти, иди со своими левыми темами финансируйствовай в другом месте…» Так вот, с тех пор у них там шли какие-то долгие внутренние обсуждения, и в итоге Анна (спасибо ей!) вернулась с информацией, что не-айтишные темы на ресурсе всё-таки не забанены.

Это меня радует, потому что, на мой взгляд, Хабр с большим отрывом остается самой крутой массовой UGC-площадкой в Рунете:

🐌 Благодаря системе кармы и модерации, здесь самый высокий шанс увидеть интересные-адекватные обсуждения в комментариях. Я знаю, некоторые считают «да там душнилово сплошное, Хабр уже не торт!», но я вам отвечу: ребята, во всех других местах просто всё во много раз хуже.

🐌 У Хабра самый годный редактор текстов, откуда потом очень удобно копировать статьи на другие площадки (в частности, он там не зашивает в ссылки автоматические редиректы через себя, как на VC-DTF-Pikabu-Smartlab).

🐌 Материалы на Хабре можно править даже спустя годы после их публикации (опять же, на всех остальных площадках кнопка редактирования замораживается через сутки или другой не очень долгий срок). Это удобно, если надо добавить что-то важное в свою старую статью, которую до сих пор активно гуглят (к слову, наш с Игорем Котенковым текст «Как работает ChatGPT» уже перевалил за 600к прочтений).

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

Короче, надеюсь, в этот раз у нас с площадкой всё сложится. =)

Пропустил ИТ-митап, который прошел в офисе КОРУСа 9 сентября? Обязательно ждем тебя в следующий раз! А пока делимся записями докладов 🤩

⬆️ИИ-инструменты для аналитика — что изменилось за 2 года
Спикер: Даниил Иванов, руководитель группы аналитики департамента CRM&BPM

⬆️Автоматизация тестирования с помощью ИИ — идеи, гипотезы и результаты
Спикер: Татьяна Веселова, руководитель направления ELMA департамента CRM&BPM

⬆️Безопасная разработка Android-приложения: уязвимости в вашем коде и как их исправить
Спикер: Арнольд Соболев, младший программист АО «ИнфоТеКС»

Смотри и слушай доклады в ВК Видео и следи за новостями о следующих мероприятиях 👀

#внутри_КОРУСа

Аналитик между бизнесом и разработкой: что нужно знать сегодня

Задача поставлена, но никто не может точно объяснить, что именно нужно сделать. Бизнес ждёт результат, разработчики задают десятки уточняющих вопросов, а изменения продолжают появляться по ходу проекта.

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

Подобрали бесплатные уроки, которые помогут усилить практические навыки системного и бизнес‑анализа.

Системный анализ и работа с требованиями

• 8 сентября, 20:00. «Системный аналитик и его ценность глазами компании». Записаться

• 23 сентября, 20:00. «Как системному аналитику проводить архитектурное ревью и находить риски до начала разработки». Записаться

• 22 октября, 20:00. «Управление изменениями требований». Записаться

Бизнес-анализ и процессы

• 15 сентября, 20:00. «Как аналитик 1С ведет задачу от интервью до приемки: сквозной кейс интеграции с мобильным рабочим местом». Записаться

• 6 октября, 20:00. «Как найти точки роста и улучшить бизнес-процесс: от диагностики до новой модели». Записаться

• 15 октября, 20:00. «Цели и метрики как одно целое». Записаться

Моделирование и коммуникация

• 17 сентября, 20:00. «Событийные подпроцессы в BPMN 2.0: как моделировать процессы, реагирующие на события». Записаться

• 21 октября, 20:00. «Анатомия сопротивления: превращаем токсичных стейкхолдеров в союзников проекта». Записаться

ИИ в работе аналитика

• 28 сентября, 20:00. «Инструменты ИИ в работе бизнес-аналитика». Записаться

• 29 сентября, 20:00. «Зелёные тесты, неверный продукт: как системному аналитику принимать работу ИИ-агента». Записаться

• 14 октября, 20:00. «ИИ-агент как супероружие Системного Аналитика: составляем ТЗ за 10 минут». Записаться

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

А если хотите посмотреть все открытые уроки месяца по другим направлениям — собрали их в сентябрьском дайджесте.

Как мы систематизировали анализ конкурентов

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

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

Как устроен процесс и что он изменил, рассказала Таня, продуктовый аналитик Naumen Erudite.

1️⃣ Зачем продуктовым аналитикам следить за конкурентами?

Для нас здесь три основные цели:

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

2. Развивать насмотренность — чем больше решений видишь, тем проще находить идеи для развития своего продукта.

3. Делиться информацией с командой — данные о конкурентах нужны не только аналитикам, но и руководителю продукта, пресейлам и проектным командам.

2️⃣ Почему решили менять прежний подход?

Информация о конкурентах хранилась в разных источниках — Google-таблицах, Jira, Miro, Confluence. Поэтому не всегда было понятно, где искать нужные данные и насколько они актуальны.

В таблице накопилось больше 50 компаний, которые мы анализировали и за которыми хотим следить. Ориентироваться в таком объеме становилось все сложнее.

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

3️⃣ Как удалось собрать все в систему?

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

В Miro сравниваем конкурентов по выручке, формату работы продукта и наличию функций. За подробностями можно перейти в Confluence, на сайт или в документацию компании.

4️⃣ Как сделали анализ регулярным?

Добавили повторяющиеся задачи: раз в две недели смотрим рассылки, Telegram-каналы и обновления продуктов, а раз в полгода пересматриваем роадмап анализа.

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

Мистери-шоппинг проводим, когда открытых источников недостаточно.

5️⃣ Почему недостаточно пересматривать всех конкурентов раз в год или два?

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

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

6️⃣ Как понять, кого анализировать в первую очередь?

Разделили конкурентов на четыре группы по степени влияния: высокий, средний и низкий уровень, а также косвенные конкуренты.

Для сравнения определили критерии: финансовую динамику, формат работы продукта — в облаке или инфраструктуре клиента — и наличие функций на базе LLM. Так проще ориентироваться среди 50+ компаний и выбирать, кого изучать подробнее.

7️⃣ Какие инструменты помогают следить за изменениями?

Для десяти ключевых конкурентов настроили Google Alerts — раз в неделю получаем подборку новостей о них. Еще подписались на Telegram-каналы и рассылки компаний, а раз в две недели выделяем час на просмотр источников.

8️⃣ Что изменилось после перестройки процесса?

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

Процесс продолжаем развивать. Сейчас тестируем автоматизацию анализа с помощью LLM: например, используем Claude для поиска информации в открытых источниках и ее систематизации в таблицах, которые раньше заполняли вручную.

Как фильтровать результат оконных функций в ClickHouse

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

В ClickHouse можно проще.

Недавно наткнулся на фичу, которая позволяет сделать такую фильтрацию вообще без использования подзапросов или CTE. Это предложение QUALIFY.

Оно работает по аналогии с WHERE, но с одним важным отличием. WHERE отрабатывает до вычисления оконных функций, поэтому оно просто их «не видит», а QUALIFY — после.

Поэтому раньше приходилось писать так:

SELECT * 
FROM (
    SELECT 
        id, 
        category, 
        ROW_NUMBER() OVER(PARTITION BY category ORDER BY created_at DESC) as rn
    FROM my_table
) 
WHERE rn = 1;

А с использованием QUALIFY запрос становится короче:

SELECT 
    id, 
    category, 
    ROW_NUMBER() OVER(PARTITION BY category ORDER BY created_at DESC) as rn
FROM my_table
QUALIFY rn = 1;

Несколько нюансов:

• В QUALIFY можно фильтровать данные прямо по алиасу из SELECT и не дублировать весь код оконной функции.

• Оконную функцию можно написать прямо внутри QUALIFY. Выводить её в итоговый SELECT не обязательно. Фильтрация всё равно сработает «под капотом».

• Если в запросе нет ни одной оконки, QUALIFY выдаст ошибку. Для обычной фильтрации всё так же используем WHERE.

Ссылка на доку.

Мои статьи по ClickHouse на Хабре.

Подборка материалов: что почитать аналитику

Собрали подборку из пяти материалов о разных задачах аналитика: от работы с требованиями и взаимодействия с командой до поиска решений и использования ИИ.

➡️ ИИ для бизнес-аналитика

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

➡️ Как подружить работу дизайнера и аналитика

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

➡️ Мягкие навыки аналитика

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

➡️ Как продуктовый аналитик помогает разработке двигаться быстрее 

Как подготовить задачу так, чтобы сократить количество уточнений и переделок, расставить приоритеты и иногда найти решение без дополнительной разработки.

➡️ Рецепты самопомощи аналитика

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

Сохраняйте подборку, чтобы материалы всегда были под рукой ❤️

Инфостарт завершает прием заявок в программу INFOSTART A&PM EVENT 2026. До 28 августа аналитики, архитекторы, руководители проектов и специалисты по автоматизации могут предложить доклад или практическую активность.

В программе предусмотрены не только классические выступления, но и мастер-классы, воркшопы, круглые столы, тренинги и деловые игры. Около 70% расписания планируется отвести практическим форматам, остальные 30% — докладам с кейсами, рабочими инструментами и разбором ошибок.

Основные направления конференции:

• управление проектами и продуктами;

• инструментарий и прикладные компетенции аналитика;

• архитектура и автоматизация решений на 1С;

• управление командами и soft skills.

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

INFOSTART A&PM EVENT 2026 пройдет 12–14 ноября в Санкт-Петербурге. Прием заявок завершится 28 августа.

Подробности и форма подачи заявки — на сайте Инфостарт.

Как евангелист не только ЛИМС, но и ноу-код конструкторов приложений, нашел OneBase — Open-source платформа для бизнес-приложений https://onebase.ivantitov.tech/index.html

Open-source платформа для создания бизнес-приложений. Слоган Пишем как в 1С — без 1С. Знакомые концепции 1С (настройка и программирование на русском языке).

Приложение полностью в одном файле (как и DataExpress), метаданные (формы, скрипты) хранятся отдельно в YAML. Доступно использование в качестве хранилища локального файла базы SQLite, а для совместной работы можно развернуть PostgreSQL.

Вобщем будут следить за новостями и попробую собрать какое-нибудь приложение.

В целом точно будет полезно для различных MVP и проверки гипотез.

Новый выпуск «Сколько стоит WMS» — про CAPEX склада

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

Говорим о том:

— сколько стоит простой и холостые пробеги ричтраков и как оптимизация маршрутов может сократить расстояние перемещений на 25–37%;
— когда вместо покупки ещё одного ричтрака за 2,2–5,7 млн ₽ можно эффективнее использовать существующий парк;
— сколько стоит низкая плотность хранения при аренде склада класса А;
— как уплотнение хранения с 0,35 до 0,50 позволяет получить эквивалент 1 050 м²;
— в каких случаях WMS может отложить расширение склада на 12–24 месяца;
— что меняется при переходе на узкопроходное хранение (VNA).

И главное — считаем три сценария в рублях: дополнительная техника, новые площади и инвестиции в WMS + оборудование.

Выпуск: «Сколько склад переплачивает за технику и квадратные метры. Считаем окупаемость WMS через CAPEX»

🎧 Слушать: MAVE (выбрать удобную платформу) и Яндекс.Музыка

📄 Разбор с расчётами: статья

Голоса и звук созданы с помощью искусственного интеллекта.

Первый день Летнего ТехФеста — в нашем влоге

В офисе ИнфоТеКС мы открыли Летний ТехФест и провели воркшоп по Event Storming — это 90 аналитиков, техлидов и ни одной скучной лекции. Всех участников ждали полное погружение в практику и нетворкинг.

Смотри, как это было, в нашем влоге!

P.S. В нашем TG-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.

Документация, которую никто не читает, и документация, которую читают. В чём разница

Работал в командах, где документация была, и где её не было. И в командах, где она была, но не работала. Последнее - хуже всего.

Документация, которую не читают, обычно такая: большие страницы в Confluence с заголовками и подзаголовками. Написана когда-то давно. Возможно, даже правильно написана. Но устарела, и никто не знает насколько.

Документация, которую читают, обычно такая: короткая заметка прямо рядом с задачей. «Почему мы сделали именно так». «Что пробовали до этого». «Что точно не трогать и почему». Как правило, написана человеком, который только что через это прошёл.

Разница не в формате и не в инструменте. Разница в том, когда написана и зачем. Полезная документация пишется сразу после того, как разобрался, пока контекст свежий. И для конкретного читателя. Для того, кто столкнётся с этим следующим.

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

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

Обновляйте документацию при каждом изменении кода, включайте это в Definition of Done.

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

Пишите понятные заголовки, стабильные якоря и прописывайте единые шаблоны.

Как у вас в команде устроена документация, которая реально используется?

С structural уязвимостью оберточного AI-бизнеса: почему следующий уровень — это агрегаторы

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

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

Шаг 1. Что скопировали все (базовая архитектура)

Посмотрите на 90% AI-сервисов, появившихся за последний год. Их бизнес-модель выглядит максимально просто:

Пользователь → Чат-бот (обертка) → Одна модель (GPT / Claude / DeepSeek)

Предприниматель не строит инфраструктуру. Он делает удобную оболочку, берет API и продает доступ.

Шаг 2. Почему это произошло именно сейчас

Раньше создание такого сервиса требовало денег на разработчиков. Сегодня сам ИИ (тот же Claude) пишет фронтенд, бэкенд и дизайн за неделю. UX паттерны чат-ботов стандартизированы, их легко скомпилировать.

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

Шаг 3. Появление структурной уязвимости

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

Архитектура меняется с этой:

Пользователь → Чат-бот → (GPT или Claude)

На эту:

Пользователь → Чат-агрегатор → Множество чат-ботов/моделей → (GPT, Claude, DeepSeek, Gemini)

Шаг 4. Почему агрегатор забирает рынок

Пользователю в 2026 году уже в большинстве случаев плевать, какая именно модель работает под капотом. Ему не нужен «доступ к Claude» или «доступ к GPT». Ему нужно решить задачу: написать код, перевести текст, сделать анализ.

Агрегатор снимает с пользователя необходимость выбирать. Он работает по принципу ИИ-агента (то, что сейчас продвигает Microsoft): пользователь не открывает разные программы, он отдает команду, а система сама решает, куда ее направить:

Запрос на код → уходит в Claude.

Поиск и анализ → уходит в Gemini.

Локальная быстрая задача → уходит в локальный DeepSeek.

Пользователь сидит за одним столом и заказывает всё что угодно из всей отрасли.

Шаг 5. Аналогия с парком аттракционов

Представьте парк развлечений.

Текущие оберточные боты — это люди, которые стоят у каждого аттракциона и продают отдельный билет: на колесо обозрения, на тир, на карусель.

Агрегатор — это единое приложение парка. Вы покупаете абонемент, заходите и просто говорите: «Хочу покататься». Система сама ведет вас на свободный аттракцион.

Когда на входе в парк стоит 500 продавцов отдельных билетов (оберточных ботов), спрос на них падает, потому что появился один человек у входа, продающий удобство выбора.

Итог

Бизнес-уязвимость «волка в бикини» на рынке AI не в том, что клоны делают плохой продукт. А в том, что массово копируя устаревающую одноуровневую архитектуру Пользователь-Бот-Модель, они сами подготавливают почву для своего собственного поглощения агрегаторами нового типа.

Строить еще одну обертку под одну модель — это продавать билет на карусель, когда напротив уже открывается касса всего парка. Пишите что не умеет ИИ в 2026 - году).

Как выглядит миграция с Power BI, когда дашбордов 155, а команда никогда не писала на Python

В новой статье GlowByte разбираем кейс «Дикси»: почему в шорт-листе остались Sigla Vision и Apache Superset, что перевесило в итоге и почему мы не стали переносить всё разом.

Цифры на середину 2026:

✅ 37 дашбордов уже мигрировали

✅ time-to-market со 210 дней до 112

✅ CES вырос с 3,5 до 3,8

Плюс честно про минусы Sigla Vision и четыре вывода для тех, кто только собирается мигрировать.

👉 Читать: https://habr.com/ru/companies/glowbyte/articles/1063906/

System Design на собеседовании: как не утонуть в требованиях, нагрузках и архитектуре

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

В новом выпуске AvitoCode Саша Кучук, тимлид в Авито, разбирает весь путь от постановки задачи до финальной защиты решения:

• как собирать требования и не упустить нефункциональные;

• как быстро прикинуть нагрузку и не закопаться в расчётах;

• как выстроить домены и API, перейти от high-level к low-level design;

• как выбирать технологии под конкретные ограничения;

• как вести себя на защите решения и на что смотрят интервьюеры при оценке.

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

Смотреть:
📺  YouTube
🔵 ВК 
📌 RuTube

Лето в разгаре, а ИТ-вакансии ждут ваших резюме (публикуем цифры зарплат на ХХ)

Про нас как работодателя: компания SSP SOFT работает в сфере заказной разработкой ПО и предоставления выделенных команд на ИТ-аутсорсинг для крупных клиентов. У нас почти всегда есть открытые вакансии — ждем новых сотрудников. По размеру компании — мы «средний бизнес» (около 500 человек) с проектами федерального уровня.

Рабочие места у нас в московском офисе, в ЦАО у самой Красной площади. А еще есть вакансии в департамент разработки в Томске и на удаленку из любой точки России.

Работа в SSP SOFT — это реальные проекты, поддерживающая атмосфера, где работать — продуктивно, без выноса мозга и микроменеджмента. Летом 2026 ищем опытных спецов, кто готов в профессиональное будущее вместе с нами.

Горячие вакансии:
1️⃣ Разработчик DWH
2️⃣ Аналитики: ритейл и гибрид (2 вакансии)
3️⃣ Разработчик ЦФТ
4️⃣ 1С - аналитик и консультант (2 вакансии)
(на вакансии см. ссылку ниже, перейдя на ХХ-ру)

Что предоставляет экосистема SSP SOFT:
✅ Мы пишем код, который формирует завтрашний день. Никакой скучной рутины.
✅ Центр компетенций и личное менторство ускорят развитие до максимума.
✅ Офис, гибрид или фулл-удаленка? Есть все варианты.
✅ Время — ваш ресурс. Мы его уважаем.

Подробности о вакансиях читайте на нашей странице ХХ.ру, но там откликаться необязательно. Ждем резюме напрямую в ЛС нашей HR Lead (https://t.me/AONikitina).
Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».

Желаем всем хабровцам успешной карьеры в 2026 году 🚀

🏕️ Ваши друзья не понимают, зачем идти в лес с IT-шниками.

Саша планирует поехать на DebugCamp в сентябре. Это наш регулярный выезд на природу на 20 человек — проводим 2 раза в год. Саша написал нам честно: «Зову всех, но в кругу нет кто согласился».

Знакомо?

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

На самом деле DebugCamp - это два дня с понятной программой. За 48 часов вы:

- Формулируете личный запрос (карьерный, технический, продуктовый)

- Получаете идеи от 10+ коллег — не small-talk, а разбор рабочих задач: приносите свою — группа помогает найти решение

- Проходите квест-ориентирование «Тропа Выживания» с инструктором

- Участвуете в вечернем разборе карьерных вопросов в кругу коллег у костра

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

Сомневаться - нормально. Вы не один такой.

Если хоть раз думали «а почему бы и нет» - программа здесь

#DebugCamp #DebugSkills #ITмероприятия #поход #нетворкинг

Почему современные интерфейсы иногда усложняют жизнь

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

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

1️⃣ Как изменилось взаимодействие человека с интерфейсами?

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

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

2️⃣ Почему даже современный интерфейс может утомлять пользователя?

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

3️⃣ Получается, «проще» не всегда означает «лучше»?

Именно. Иногда в погоне за минимализмом или новыми трендами мы убираем то, что было интуитивно понятно. 

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

4️⃣ Можно ли создать интерфейс, который будет удобен для всех?

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

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

5️⃣ Как понять, что новое решение действительно улучшает интерфейс?

Я бы каждый раз спрашивала себя: станет ли пользователю действительно проще после этого изменения? Если решение выглядит современно, но увеличивает количество действий, заставляет переучиваться или сильнее отвлекает, возможно, это не улучшение, а шаг назад.

→ Подробнее своим опытом Динара поделилась в статье.