Все выступления

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

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

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

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

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

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

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

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

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

Затем мы превратим расчеты в инструмент влияния. Вы освоите фреймворк формулирования гипотез («Делаем X — меняем Y на Z%») и на основе своих расчетов предложите решения по снижению оттока и росту прибыли. На выходе у вас будет четкий алгоритм оцифровки фич и понимание того, как аргументированно защищать или отсекать задачи в бэклоге, опираясь на деньги, а не на интуицию.

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

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

Но у нас не было права «приказать» — изменения нужно было внедрить среди 250+ аналитиков и разработчиков, включая партнёрские команды, где мы не имели прямого влияния.

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

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

Расскажу, как повторить это у себя, даже если вы не руководитель.

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

Мы разберём:

1. Откуда вообще берутся качественные элементы бэклога — из бизнес-требований, ожиданий стейкхолдеров и задач пользователей.
2. Почему «каждая фича должна быть полностью промышленно применимой» — не догма, а часто карго-культ.
3. Как грамотное дробление US повышает доверие клиента и обеспечивает путь от идеи к результату.
4. Критерии и техника разработки: интерфейс, исходные данные, альтернативные сценарии, CRUDLS, приоритеты, сквозные функции и т. д.
5. Распространённые ошибки: разделение задач по специализациям, объединение лишних изменений «заодно» и потеря пользовательской цели.

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

1. выявлять нарушения правил формирования US,
2. перерабатывать бэклог для повышения его качества,
3. представлять свои собственные решения,
4. голосовать за лучшее решение.

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

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

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

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

Но есть плохая новость: так больше нельзя. И хорошая: виноваты в этом… мы с вами. Бизнес-аналитики.

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

На докладе мы честно разберем:

— Почему описание полей «ИНН — для ввода ИНН» — это прошлый век, а «как оформить возврат платежа за 20 секунд» — новая реальность.
— Как внедрить Shift Left для документации и почему об этом должен думать аналитик на этапе прототипов, а не разработчик перед сдачей.
— Какие метрики увидят CEO: -30% нагрузки на поддержку, +40% качества данных — и при чем здесь вы.
— Живой пример из практики (и да, с цифрами): как мы перестали писать «руководства оператора» и начали проектировать информационный продукт.

Бонусом — чек-лист из трех шагов, чтобы завтра же перестать быть частью проблемы и стать частью решения. И, конечно, разберемся, почему ISO — это не бюрократия, а профессиональный инструмент защиты своей экспертизы (и аргумент в споре с разработчиком, который считает, что «и так понятно»).

Приходите. Будет не скучно. Я обещаю: после этого доклада вы перестанете ненавидеть документацию и начнете использовать ее как конкурентное преимущество. А заодно узнаете, при чем тут гномы, тролли и «каменные плиты».

Для кого: бизнес-аналитики, системные аналитики, Team Lead, Product Owner, все, кто устал отвечать на одни и те же вопросы пользователей.

Вы сталкивались с клиентом, который агрессирует, меняет требования на ходу и игнорирует договорённости? Как не потерять проект, команду и самообладание в такой ситуации?

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

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

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

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

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

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

Что вы получите:

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

• Научитесь быстро находить слабые места в архитектуре данных.

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

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

Бывали ли у вас своего рода «провалы» в коммуникации?

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

Хотя вы всё объяснили. Правда объяснили. Схему нарисовали. Табличку сделали. Проговорили несколько раз на согласованиях.

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

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

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

По итогу доклада у вас будут:
— чек-лист «готовности к переводу», который можно использовать не только на себе, но и на своих подопечных (если вы, например, менторите начинающих аналитиков);
— набор моих переводческих практик и примеры их применения для разных ролей в команде
… и много пищи для размышления :)

Доклад для тех, кто хотя бы раз думал: «Я же нормально объяснил, что опять пошло не так?...»

Всем привет!

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

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

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

Мы разработали подход, который, благодаря использованию ИИ, позволяет добиться качественного анализа и разработки требований при ускорении процесса до x3 - x5 по сравнению с "ручной" работой.

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

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

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

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

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

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