Лучшие практики бизнес-анализа в проектах цифровизации государственных органов Казахстана - опыт Холдинга Самгау

Более чем “круто”

Договор подписан. То самое чувство, когда ты только погружаешься в новый, довольно сложный домен - вокруг тебя «темнота» и неопределенность. Первое знакомство с Заказчиком. Каким он будет? Насколько хорошо будет выстроена коммуникация, его готовность к консультациям. А за спиной команда, которую ты должен обеспечить качественными требованиями. Разложить витиеватое хитросплетение разнородной информации в понятную, структурированную форму. Высокая стоимость ошибки аналитики отнюдь не делает задачу проще. Ответственность. Непростой путь впереди. Но именно такой путь выбираем мы.

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

В первую очередь мы анализируем бизнес-процессы, производим их декомпозицию «сверху-вниз» или «снизу-вверх» на 5 уровней. Бизнес-процессы на определенном уровне декомпозиции формализуются и описываются с применением разных нотаций/методов. Для верхних уровней декомпозиции бизнес-процессов и демонстрации их взаимосвязи используется метод Ericsson’а Penker’а. Как-то так:

Для нижних уровней декомпозиции бизнес-процессов используется диаграмма деятельности UML. Например:

Мы не всегда используем стандартную семантику языка UML, у нас есть некоторые свои рецепты 😉

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

Затем, из каждого подпроцесса нижнего уровня выделяются варианты использования и действующие лица (Actors), формируется Use Case диаграмма. Вот как-то так…

Когда Use Case диаграмма сформирована, для каждого Use Case описывается сценарий варианта использования. Посмотри:

В шагах сценария варианта использования приводятся ссылки на бизнес-правила, для которых ведется один общий реестр:

макеты интерфейсов

каждый из которых имеет свое описание

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

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

Ну и как без диаграммы состояний… Не выискивать же разработчику в сценариях весь жизненный цикл объектов. Смотри… Тут тоже есть наш рецепт

И напоследок интеграции… ммм Сейчас уже сложно представить системы, которые бы не интегрировались с другими системами, особенно такого масштаба как наша. А в нашей их не много ни мало более 400. Смотрите как мы готовим требования к интеграциям… Определяемся со схемой интеграционного взаимодействия. Здесь много тонкостей, о которых нужно знать:

Схема готова, можно приступать к определению и документированию форматов данных:

Не забываем про справочники:

Форматы согласованы, приступаем к разработке XSD или JSON схемы:

Вуаля! Останется только протестировать. Непередаваемые ощущения, когда успешно произошел обмен первыми сообщениями. Работает! :)

Все диаграммы мы храним в одном месте

В качестве инструментов в нашем арсенале: Sparx Enterprise Architect, Confluence, Balsamiq

И в завершении, нужно все это согласовать с Заказчиком, а он ждать не любит.

Дочитал до конца? Умеешь и хочешь и работать по фэншую? Приходи, запустим Проект вместе!

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