Программа

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

Системным аналитикам приходится пояснять стейкхолдерам, почему невозможно получить одновременные идеальные свойства распределённой системы. На предыдущем докладе на AnalystDays #21 мы разбирали подходы к ограничению CAP в аварийных сценариях, а сейчас я предлагаю поразмышлять и структурировать подход к анализу ограничений PACELC в штатных сценариях.

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

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

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

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

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

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

Я покажу, где мы чаще всего ошибаемся:

• проектируем отчёты без понимания контекста решений,

• отвечаем на вопрос «как выглядят данные», а не «что здесь важно заметить»,

• обсуждаем формы и приёмы вместо смысла и фокуса внимания.

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

Часто представители разных заинтересованных сторон считают, что у них разные интересы в проекте.
Это нередко приводит к конфликту интересов, что влечёт за собой целый набор негативных явлений, повышающих трудозатраты аналитика:

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

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

В докладе разберу нюансы коммуникации со стейкхолдерами, позволяющими произвести их "вербовку":

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

А вы знали, что AI помогает аналитикам не только писать требования, но и быстро превращать их в кликабельный UI/UX-прототип? Это позволяет закрывать часть задач проще, чем через длинное ТЗ и бесконечные согласования: показать интерфейс, прогнать сценарии, проверить состояния/ошибки и поймать противоречия до разработки, когда правки стоят в разы дешевле.

В докладе я покажу практический кейс, как аналитик с помощью AI превращает требования в рабочий прототип, ускоряет согласования со стейкхолдерами и выявляет “дыры” в логике, не заменяя UI/UX-дизайнера, а усиливая качество требований и коммуникации.

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

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

Сегодня бизнес-аналитик – это тот, кто помогает бизнесу меняться, но как нужно меняться и адаптироваться самому бизнес-аналитику?

Мы рассмотрим два вектора развития бизнес-анализа в Газпромбанке:

• Стандарты и Процессы.
• Люди и Культура.

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

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

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

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

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

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

На практических примерах проанализируем преимущества и недостатки TypeSpec по сравнению с существующими стандартами типизации, такими как OpenAPI и др. Рассмотрим вопросы совместимости с различными языками программирования и влияние на процесс разработки API-интерфейсов. 

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

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

• какие существуют критерии разделения / слияния сервисов?
• как нефункциональные требования влияют на декомпозицию?
• что поможет при принятии решений, кроме Event Storming и DDD?

В финале вы попробуете приложить эти идеи к вашему проекту.

Для опытных системных аналитиков уровня middle+ / senior.

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

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

Метрики часто воспринимаются как отчётность. Но при правильном использовании они становятся инструментом управления процессом.

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

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

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

В ходе своей работы мы столкнулись с тем, что затянутый процесс согласования, отсутствие трассировки на архитектурные элементы и единого актуального набора требований привели к тому, что реальные знания о продукте «растворялись» в переписке, устаревавших диаграммах и памяти разработчиков. Именно это подтолкнуло нас искать подход, где требования становятся таким же инженерным артефактом, как и код. Поделимся тем, как мы пришли к модели «требования как код», построили процесс от написания в единых шаблонах до согласования в Git  силами всей команды (аналитики, архитекторы, разработчики, тестировщики) и продолжаем оптимизировать эту работу для нескольких параллельных версий продукта.

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

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

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

Уверен, после этого доклада вы начнёте чаще слышать то самое заветное: «Ого, я всё понял!»

GG/ГГ/GGWP/ГГВП, ачивка, скилл – игровой сленг, который прочно вошел в повседневную речь. Доклад будет тоже в своем роде про ГГ, про «хорошо сыгранную игру», про использование геймификации в госсекторе и создание экспертного сообщества.

Игровые кампании активно используются на рынке: Яндексом, Озоном, ВТБ. Поэтому нет ничего удивительного в том, что и наш ключевой Заказчик доверился «игровым механикам» для вовлечения своих пользователей в создание необходимой ценности. Для одних ценностью являются покупка товаров, для других – повышение лояльности клиентов, а для того направления, где работаю я, ценностью являются гипотезы процессной аналитики, предложения по улучшению процессов (процесс-майнинг) и предложения по повышению эффективности выполнения операций (таск-майнинг).

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

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

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

Будет представлен подход, при котором аналитики переводят человеческие ценности в проектные решения, влияющие на архитектуру системы и взаимодействие с пользователями. Участники познакомятся с практиками интеграции человеко-ориентированных НФТ и ролью аналитика как дизайнера решений.

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

В докладе будут рассмотрены:

• проблемы классического онбординга;

• фреймворк «4 карты аналитика»;

• контроль прогресса онбординга;

• критерии готовности аналитика;

• эффект для команды и бизнеса.

Доклад включает практико-ориентированные кейсы работы в enterprise- и интеграционных проектах с большим количеством систем и участников.

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

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

В 2025 году команда экспертов компании SSP Soft провела 500+ собеседований системных и бизнес-аналитиков, каждый раз проверяя знания кандидатов по 15 ключевым темам: от выявления требований и моделирования процессов до архитектурных паттернов, API-интеграций и data-анализа. 

На докладе разберем: 

• Реальные пробелы в компетенциях.
• Портрет специалистов по уровням: чем отличаются знания Middle, Middle+ и Senior на практике.
• "Обман" на собеседованиях — как часто кандидаты пытаются "выдать желаемое за действительное".
• Особенности рынка в 2025, прогноз на 2026.
• Возможные тренды в отрасли.
  

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

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

В рамках доклада разберём FPF как практическую рамку для таких случаев:

• как распаковывать задачи / поручения;
• как фиксировать решения;
• как проверять тексты на смысловую и онтологическую точность;
• как использовать эти же приёмы в работе с неживыми помощниками.

Это не обзор “про AI вообще” и не разговор о хорошем стиле. Это доклад о том, как делать рабочие тексты и решения точнее там, где ошибка в формулировке уже быстро превращается в ошибку в работе.

Как отличить момент, когда AI усиливает ваше мышление от момента, когда он его замещает? На практике — только через опыт. 

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

За 90 минут группы пройдут три профессиональных Skill'а, каждый из которых работает в паре с AI.

Вы делаете всё. Всегда на связи. Загрузка — 120%. Вы участвуете во всех спринтах, митингах, архитектурных обсуждениях. Кажется — вы ни на секунду не останавливаетесь. Но в итоге: вас называют лоу перформером.

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

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

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

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

Ключевое решение
Несколько лет назад во все артефакты внедрили раздел "История изменений". Это позволило собирать данные обо всех правках, которые делал системный аналитик и типизировать их по компетенциям, связанным с применяемыми технологиями. Теперь Отчёт ИКСА агрегирует эти и не только метрики в наглядный дашборд.

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

Доклад раскроет техническую реализацию, метрики и уроки внедрениях.

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

Я убедился в этом в ходе визита этой осенью в китайские технологические компании: Baidu, Xiaomi, Little Red Book, SenseTime и другие. И расскажу об особенностях китайской культуры и организации компаний, которые поддерживают развитие и в результате Китай готов перехватить технологическое и политическое лидерство у США в ходе промышленной революции в ближайшие 3-7 лет.

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

С недавнего времени мы в команде аналитиков разработали и приняли code-style для работы с сиквенс-диаграммами в нотации UML. Но что привело нас к такому решению и каких результатов мы достигли? 

В своем докладе я расскажу вам:

• зачем мы придумали code-style для наших UML-диаграмм;
• с какими проблемами столкнулись в процессе совершенствования code-style;
• как мы с командой изучали и внедряли Git в работу команды аналитиков;
• какие преимущества дал нам code-style;
• как наша идея по внедрению code-style вдохновила другие департаменты пойти нашим путем.
  

Меняем бизнес-логику, контент и структуру страницы — без кода и лишних релизов. Расскажу, как мы стартовали использование BDUI, чтобы ускорять разработку, быстрее запускать фичи и сокращать путь от идеи до продакшена.

История от изучения существующих реализаций, до похорон собственной реализации на примере продукта "Tele2 Билеты".

Это не доклад. Это публичный допрос профессии. 

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

 За 40 минут они разберут три темы, о которых в профессии принято молчать. 

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

Финала с ответами не будет. Будет выбор — тот, который вы уже делаете на каждом митинге.

В 2021 году "Почта России" переходила на новую систему обработки всей международной корреспонденции.

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

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

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

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

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

• Вычислять пропущенные сущности и стрелки-призраки.

• Задавать три вопроса, которые поставят архитектора в тупик (и это хорошо — значит, вы нашли слабое место).

• Отличать схему для презентации (красивая картинка) от схемы для работы (инструкция по выживанию).

Итог: Вы унесёте не теоретические знания, а алгоритм допроса. Вы перестанете кивать. Вы начнете понимать. 

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

В докладе за основу взята "Морфология волшебной сказки" В. Проппа, которая предполагает, что все сказки развиваются в рамках определенного набора функций, совершаемых персонажами (ровно как в проекте есть определенные этапы и роли). Эта теория используется в кинематографе и политике, а мы попробуем применить ее и к реальной работе бизнес-аналитика. Узнаем, в чем сходство "Царевны-лягушки" и разработки дашборда. Найдем практическую пользу этой модели для облегчения общения с заказчиком, снижения хаотичности требований на основе реального кейса.

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

Что вы узнаете: 

1. Зачем это нужно: почему тестирование нагрузки это не задача DevOps или тестировщиков "после", а зона ответственности аналитика "до".

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

3. Инструменты: какие простые и доступные инструменты используют аналитики для тестов.

4. Результат: как эта практика предотвращает архитектурные ошибки на ранних этапах и спасает от падения в проде.

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

Я покажу два рычага на личном опыте.

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

Документация как код как закон для экосистемы. Как я продвигаю принцип «документация как код». Это не только экономия 600+ часов в год, но и правило: актуальность становится стандартом, а не подвигом. Автоматизация снижает риски на десятки миллионов рублей.

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

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

Этот интерактивный мастер-класс дает ИТ-специалистам четкий 5-минутный алгоритм для снятия волнения и подготовки к любому выступлению.

В программе тренинга:

• Эксперимент «До/После»: наглядная разница в звучании голоса при чтении сложных текстов без подготовки и после разминки.

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

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

• Управление диалогом: отработка сценария «Токсичный стейкхолдер» — учимся перехватывать инициативу с помощью пауз и снижения темпа, а не попыток перекричать оппонента.

Главный посыл: Аналитик продает не документы, а смысл. А смысл лучше всего доносится через спокойный и подготовленный голос.

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

А что если аналитик будет передавать в разработку не только требования, но и формальные, исполняемые критерии их правильности — готовые автотесты?

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

NULL в SQL — это не просто техническая особенность, а полноценный саботажник вашей базы данных. Он маскируется под безобидное «отсутствие значения», но на деле создаёт логические парадоксы, которые ломают бизнес-логику. Разные СУБД обращаются с ним по-своему: где-то он уникален, где-то равен пустой строке, а где-то — не равен сам себе. Из-за этого запросы начинают врать, отчёты показывают фейковую аналитику, а деньги тихо утекают через дыры в данных. Самые дорогие и смешные инциденты в истории IT часто связаны именно с NULL: товары становятся бесплатными, пользователи — бессмертными, а секретные агенты — внезапно раскрытыми.

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

Импортозамещение сложных корпоративных продуктов часто может восприниматься как задача «повторить функционал». На практике это иллюзия. 

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

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

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

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

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

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

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

Оценить возможности продукта и выбрать для него канал продвижения и модель монетизации.

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

Доклад посвящен методологии быстрого погружения аналитика в ИТ-проект с целью достижения максимальной эффективности работы.

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

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

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

В докладе описывается практический опыт и результаты внедрения больших языковых моделей (LLM) и простой агентной логики для автоматизации:

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

Должен ли аналитик рассматривать и предусматривать риски, или риски — это компетенция менеджеров?

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

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

В докладе мы рассмотрим один из способов структурированного поиска решений противоречий через типовые приемы ТРИЗ.

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

Сегодня в IT-индустрии доминирует идея быстрой ротации: если в проекте стало тяжело или что-то не получается с первого раза — уходи. До этого я работала программистом и проджект-менеджером, и тоже меняла компании каждые 1-2 года. Но работа в долгом проекте изменила мое мнение.

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

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

Доклад для аналитиков, которые сомневаются — продолжать или искать что-то новое.

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

В докладе я расскажу о DocsGuru — AI-агенте, встроенном в Mattermost, который отвечает на вопросы пользователей на основе корпоративной документации, используя RAG-подход и семантический поиск.

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

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

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

Но уверены ли вы, что вы пользуетесь ими ровно так, как задумывал автор модели — Саймон Браун?

В рамках доклада расскажу:

• что же на самом деле автор вкладывает в модель;
• где аналитики обычно ошибаются в части использования модели;
• как автор рекомендует отображать некоторые составляющие диаграмм;
• какие диаграммы есть в C4 кроме привычных 4-х уровней;
• как Саймон Браун рекомендует оформлять диаграммы;
• некоторые интересные вопросы, которые задают Саймону о модели, и как он на них отвечает.

Доклад полностью основан на книгах и выступлениях Саймона Брауна.

Доклад о внедрении гибких методологий и переходе на корпоративные стандарты ведения документации в момент реализации крупнейшего в истории команды проекта по разработке.

У вас есть идея, как можно сделать лучше, предложить изменение или для себя придумали перспективное изменение. Вроде всё хорошо. Но одновременно с интересом может идти страх и отторжение, нежелание пробовать новое. Это плохо? Нет, это нормально: сработала часть мозга, которая вырабатывает удовольствие от привычного и стабильного. А можно ли убедить как-то иначе?

Мы рассмотрим изменение с точки зрения баланса удовольствия в настоящем и будущем. Оно есть и там, и там. Для этого мы рассмотрим Change Brain Energy Scorecard-модель и составим 7-компонентную структуру, которая поможет сформулировать вашу идею и предложение так, чтобы мозг активировал систему удовольствия от будущего и сам захотел меняться и пробовать новое.

Мастер-класс для тех, кто развивается и меняется сам, помогает меняться другим и ищет инструмент, чтобы сделать процесс понятным и нестрашным.

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

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

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

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

Ключевой метод — отказ от попытки сделать всё и фокусировка на минимально жизнеспособном продукте (MVP). В докладе показано, как декомпозировать «слона» задач, отделив критический для дедлайна минимум (20%) от вторичных функций. Объясняется логика создания ударной микро-команды (аналитик, разработчик, тестировщик) с максимальными полномочиями и параллельной работой. Особый акцент сделан на временном компромиссе: часть процессов автоматизируется, часть временно выполняется вручную, чтобы выиграть время.

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

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

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

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

Код сегодня стал дешёвым. LLM генерируют сервисы, API и схемы быстрее, чем команда успевает договориться о терминах. Разработка всё чаще идёт «по вайбу» — и в этот момент требования перестают защищать от ошибок.

Проекты ломаются не из-за кода и не из-за user story. Они ломаются из-за неверного контекста: размытых границ, смешанных доменов, противоречивого языка и неосознанных ограничений. И это зона прямой ответственности аналитика.

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

Код можно переписать. Ошибку в контексте — нет.

Почему бизнес-процессы «рассыпаются» на стыке ERP и Digital-систем? Потому что классические роли аналитиков исчерпали себя. Мы представляем новую ключевую роль — Интеграционного аналитика — и на реальном опыте показываем, как она становится архитектором сквозных процессов, побеждая хаос разрозненности.

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

Доклад — это готовый кейс трансформации и roadmap для внедрения.

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

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

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

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

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

Доклад раскрывает особенности подхода "бизнес-архитектура как код" при помощи инструмента dochub на примере электронной коммерции.

Готовы ли вы пройти SQL квиз? Проверим, как хорошо вы знаете тонкости, неочевидные и порой забавные особенности языка. Присоединяйтесь, чтобы в игровой форме узнать что-то новое! А главное помните: пишите так, чтобы потом ваш код нельзя было использовать для следующих квизов!

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

Рассмотрим практику: как по формулировкам, сценариям и отчётам вовремя увидеть серую зону, перевести смутное “что-то не так” в понятные вопросы и аргументы, и зафиксировать границы так, чтобы их можно было отстоять в обсуждении с ЛПР.

Без морализаторства — только инструменты, которые помогают принимать решения осознанно и не терять уважение к себе.

В новом продукте аналитик редко остаётся в роли «того, кто только оформляет требования». При работе с крупным функционалом аналитик неизбежно участвует в формировании продуктовой логики: сценариев, ограничений, компромиссов.

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

В ходе выступления слушатели узнают:

• какой юридический минимум необходим аналитику: ключевые понятия в сфере ПДн, основные нормы ФЗ №152, ПП №1119, Приказа ФСТЭК №21,
• как извлекать конкретные требования из нормативных источников,
• как трансформировать нормы права в функциональные и нефункциональные требования, а также критерии приемки,
• какие типичные ошибки приводят к нарушениям и штрафам,
• зачем необходимо вести журнал учета операций,
• в чем разница между логированием и журналированием ПДн.

Слушатели получат:

• чек-лист для выявления ПДн в системе,
• готовый вариант использования (USE CASE) «Фиксация операции с ПДн в «Журнале учёта ПДн»,
• сформированные функциональные и нефункциональные требования, а также критерии приемки.

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

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

Целевая аудитория: Бизнес и системные аналитики — синьоры и тимлиды. 

С чем уйдут участники доклада:

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

Доклад посвящён архитектуре и принципам построения NRT-отчётности (Near-Real-Time) — системы обработки данных в режиме, близком к реальному времени. В докладе рассматриваются её ключевые преимущества, особенности, архитектурные решения и используемый софт. 

Цель NRT-отчётности — оперативно предоставлять актуальные данные для принятия управленческих решений, быстрого выявления рисков и автоматизации бизнес-процессов. 

Доклад будет полезен ИТ-специалиста, аналитикам данных и руководителям, участвующим в проектировании, разработке и сопровождении систем оперативной отчётности.

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

В докладе я хочу рассказать про технологию, которая упрощает жизнь пользователям: авторизацию с помощью внешнего провайдера идентификации (IDP).

Поговорим о типах провайдеров идентификации,  потенциальном бизнес-эффекте от интеграции с ними.

Поделюсь опытом  нашей компании: на какие моменты стоит обратить внимание при выборе внешнего провайдера и что продумать при его подключении.

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

Аналитики редко ошибаются в выводах. Гораздо чаще они ошибаются в моменте, форме и масштабе разговора. Проблема в том, что у руководителей верхнего уровня другая оптика: они хотят "разделаться" побыстрее и двигаться дальше. И еще у вас 10 минут против 40 минут, вы ведь не удивлены, что совещание задержалось? 

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

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

P.S. По крайней мере, вам будет легче туда вписаться и вырасти.

С внедрением DBT, Git и CI/CD аналитика перестает быть просто запросом данных — она становится дата-продуктом, который должен быть документированным, тестируемым, повторяемым и стабильным.
Системный аналитик выходит за рамки SQL и становится владельцем части дата-платформы. Он участвует в разработке, тестировании, ревью кода и управлении SLA.
В докладе я расскажу, как DBT, Git и CI/CD-процессы меняют роль аналитика, повышают качество данных и сокращают время вывода аналитических решений в продакшн.
Будут приведены конкретные примеры из практики:

• как аналитики создают и управляют ветками,
• как бизнес-тесты интегрируются в CI/CD,
• как SLA и документация становятся частью разработки.

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

В докладе я расскажу:

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

Любое собеседование — это стресс и испытание не только для кандидата, но и для собеседующего.

Как собеседующему всего за 1 час понять, что человек обладает достаточными hard-скиллами, умеет ответственно работать и при этом сможет влиться в команду? Задача не из простых.
Каких ошибок надо избегать кандидату на собеседовании? 

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

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

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

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

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

Доклад посвящен технической реализации RAG (Retrieval-Augmented Generation) с использованием современных инструментов. Мы разберем, почему для сложных ТЗ с таблицами критически важен правильный парсинг (LlamaParse), как организовать хранение знаний в векторной базе (Pinecone) и связать всё это в единый процесс без глубокого программирования с помощью n8n. 

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

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

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