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

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

— Подробно и с примерами расскажу про проблемы стыковки постановщика и разработчика.

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

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

— С технической стороны напомню об инструментах для совместного проектирования и постановки задач Impact mapping, сценарии пользователя, User story mapping, 4 context architecture. Расскажу, как наиболее эффективно пользоваться этими инструментами.

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

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

В ходе доклада выясним:

— К какими проблемами может привести неаккуратная работа с требованиями;

— Как выглядит сквозной процесс управления требованиями;

— Контрольные точки в процессе управления;

— Какие инструменты и методы могут применяться на разных этапах процесса;

— На что обратить внимание при работе на разных этапах. Риски и сложные моменты при управлении требованиями.

В конце, конечно же, сделаем выводы и подведем итоги.

— Мотивация и эффективность: может ли быть одно без другого?

— Каковы причины неэффективности? С какими из них можно бороться?

— Топ-5 причин неэффективности бизнес-аналитиков по результатам наших исследований

— Методы и инструменты борьбы с неэффективностью: как помочь самому себе и как это сделать совместно с тимлидом?

1. Уникальность или универсальность? Надежность или риск? Простота или красота? На что стоит сделать упор при разработке вашего продукта и причем тут Нориаки Кано

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

3. Приоритизация бэклога, маркетинг, принятие решений о необходимости доработок: с чем еще может помочь модель Кано?

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

В нашем докладе:

— Шаблоны — ограничение или помощь аналитику;

— О структуре шаблонов документации и подходе при их создании;

— Чек-лист для согласования шаблонов с клиентом перед стартом проекта;

— Как трансформировать шаблоны под конкретный проект с минимальными усилиями;

— Каких ошибок избегать при составлении проектной документации.

— Рынок IT-разработки привык работать плохо. Аналитики перекладывают риски на дизайнеров, дизайнеры на разработчиков, исполнители на заказчиков.

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

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

— Функциональная модель, внешние и общие функции: что это и почему важно.

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

В BABOK описан общепринятый алгоритм разбора проблемы (discovery). Этот алгоритм мы превратили в бизнес-игру, через которую вы научитесь им пользоваться, а также найдете точки профессионального роста.

Мы будем:

• Экспериментировать с алгоритмом работы в ограничениях.

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

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

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

ЦА: аналитики, архитекторы, менеджеры, заказчики изменений.

Игра рассчитана на 20 участников.

Продолжительность: 90-120 минут.