Онлайн-курс, вебинар Анализ бизнес-процессов и требований в проектах

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

Цель курса — дать участникам воспроизводимую технологию работы бизнес-аналитика: как выявлять и описывать бизнес-процессы (AS-IS/TO-BE), переводить их в проверяемые функциональные и нефункциональные требования, оформлять спецификации/ТЗ и поддерживать матрицу трассировки требований (RTM) и контроль изменений (Change Requests) до приемки результата. За 2 дня участники собирают «скелет» документации по сквозному примеру (или по своему проекту), получают шаблоны и чек-листы качества требований, которые можно сразу применить в работе.

Курс ориентирован на бизнес-аналитиков, системных аналитиков, аналитиков по автоматизации, руководителей проектов и продуктов, владельцев процессов и кураторов внедрений, а также сотрудников функциональных подразделений (финансы, закупки, HR, производство, сервис), которым необходимо формализовать «как должно работать». Отдельный акцент сделан на корпоративные и государственные проекты, где критичны прозрачность требований, доказуемость согласований и управление изменениями.

Уровень подготовки: достаточно базового понимания процессов и проектной работы; опыт BPMN/UML не обязателен.

1. Роль бизнес-аналитика в проекте и границы ответственности. В модуле разбирается разделение ролей BA/SA/PM/PO и зоны пересечения ответственности, специфика согласований и контрольных точек в корпоративном и гос-контуре, фиксация границ scope через ограничения и допущения, построение карты стейкхолдеров и ожиданий (влияние/интерес/риски), а также настройка мини-регламента работы с требованиями (Definition of Ready/Done, порядок согласования, протоколирование решений) с практикой по составлению stakeholder map и первичного scope (in/out) для своего или учебного кейса.
2. Сбор требований: интервью, наблюдение, воркшоп, анализ документов. Модуль посвящен подготовке к интервью (цель, сценарий, ожидаемые артефакты), техникам выявления требований (5W1H, «как есть/как должно быть», pain–gain, события и исключения), правилам документирования договоренностей (протокол встречи, решения, открытые вопросы, next steps), работе с типовыми источниками в корпоративных и гос-проектах (регламенты, приказы, формы, отчетность, интеграции), управлению конфликтом интересов и предотвращению типовых ошибок сбора требований; практикум включает подготовку плана интервью и списка уточняющих вопросов и рисков.
3. Моделирование бизнес-процессов: AS-IS / TO-BE и границы процесса. Участники учатся выбирать уровень детализации (L0–L3), корректно фиксировать AS-IS без «улучшательства», проектировать TO-BE с ролями, контрольными точками и обработкой исключений, применять BPMN на практическом уровне (события, задачи, шлюзы, пулы/дорожки) и извлекать требования из модели процесса; по итогам выполняется практическая сборка диаграммы процесса (AS-IS или TO-BE) с ролями и ключевыми исключениями в удобном инструменте (diagrams.net/Visio и т.п. — по выбору).
4. Структура требований: классификация, качество и формулировки. В модуле систематизируются уровни требований (business/stakeholder/functional/non-functional), подробно разбираются нефункциональные требования (производительность, безопасность, отказоустойчивость, UX, аудит-лог), критерии качества и типовые дефекты формулировок (неоднозначность, «ускорить», «удобно», «как сейчас»), форматы описания (shall-требования, use case, user story, rules/constraints), роль глоссария и единых определений для снижения споров, а также подходы к ревью требований по чек-листам; практика включает переработку «сырых» требований в проверяемый вид и составление глоссария терминов.
5. User Stories, критерии приемки и подготовка к тестированию. Модуль связывает требования с приемкой результата: от структуры user story и формулирования ценности до ограничений и допущений, построения acceptance criteria в формате Given/When/Then, согласования Definition of Ready/Done с командой и заказчиком, перехода от требований к тестовым проверкам и поддержания критериев приемки при изменениях; практическая часть — написание user stories с критериями приемки и перечнем тестовых проверок на уровне бизнес-логики.
6. Трассировка и управление изменениями (Change Requests). Участники осваивают матрицу трассировки требований (RTM) и связи «требование ↔ цель ↔ процесс ↔ задача ↔ тест ↔ релиз», правила версионности и ведения истории изменений, стандарт обработки change request (вход, оценка влияния, решение, согласование), обзор приоритизации (MoSCoW/WSJF и применимость), а также работу с рисками требований по влиянию на сроки/стоимость/качество и переговорные сценарии «нужно срочно»; в практикуме собираются RTM и оформляются 1–2 CR с оценкой влияния.
7. Требования в корпоративных и гос-проектах: спецификация, согласования, доказуемость. В модуле рассматривается типовой пакет документов и ожидаемые контрольные процедуры «тяжелого контура», оформление протоколов согласований и «следов решений» для снижения юридических и контрактных рисков, требования к интеграциям и данным (интерфейсы, справочники, качество данных), нефункциональные требования по ИБ и доступам (RACI, роли, аудит), а также структура мини-ТЗ/спецификации под проект; практическое задание — собрать структуру спецификации на 5–7 разделов под свой кейс.
8. Итоговая сборка: комплект артефактов BA для проекта (итоговый проект). Финальный модуль объединяет результаты в единый пакет: карта стейкхолдеров и границы scope, модель процесса AS-IS или TO-BE с ролями и исключениями, набор требований и глоссарий, user stories с критериями приемки, RTM и change requests с оценкой влияния; формат — короткая защита в конце второго дня с разбором типовых ошибок и рекомендациями по улучшению артефактов. Практическое задание. К завершению 1-го дня участники формируют черновик stakeholder map, scope, AS-IS/TO-BE процесса и список требований «черновиком», чтобы на 2-й день довести требования до проверяемого вида, добавить приемку, трассировку и контур управления изменениями.