Школа
системного анализа
и проектирования
Автор: Денис Бесков

Недостатки классического подхода к бизнес-анализу и проектированию информационных систем конца 90-х — начала 2000-х годов

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

Если глобально в мире дела обстоят неплохо — формируется культура System Design, которая идёт из сферы публичных интернет-сервисов, наконец-то активно применяются принципы DDD (появившиеся также в начале века), то в российском аналитическом сообществе новые практики пока внедряются плохо. Более того, многие владельцы аналитических процессов или просто слабо следят за новыми веяниями или предпочитают использовать знакомые классические подходы, методики и инструменты, которые имеют свои недостатки.
Время на чтение статьи: 10 минут
Не любите читать? Посмотрите видео:
В этой статье вы узнаете:
  • в чём заключается классический подход к бизнес-анализу и проектированию информационных систем, который сформировался в конце 90-х — начале 2000-х годов;
  • какие сложности и проблемы есть у классического подхода;
  • как можно решать проблемы классического подхода.
Статья будет полезна организаторам аналитических работ, владельцам аналитических процессов, а также системным и бизнес-аналитикам, архитекторам решений, руководителям проектов и всем, кто связан с проектированием информационных систем и хочет с новой точки зрения взглянуть на классические подходы к анализу и проектированию ИС.

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

Классический процесс бизнес-анализа и проектирования информационных систем
Существует большое количество зрелых источников (методологии, стандарты, руководства), так или иначе описывающих подходы к разработке информационных систем: RUP/OpenUP, ГОСТ 34, OOAD, BABOK и так далее.

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

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

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

Опытный читатель может задать закономерный вопрос: «Что насчёт гибких подходов к разработке? Agile решает эту проблему!». Да, Agile позволяет ускорить работу команды, но он не даёт ответа на вопросы «Как спроектировать систему?», «Как система должна работать?». Например, в Scrum Guide говорится, что пользовательская история на планировании спринта декомпозируется в набор задач, решение которых даст ценность. Как и на основе чего проектировать систему, в Scrum Guide не упоминается. Соответственно, гибкие подходы к разработке прогораммных систем не предлагают никаких практик анализа и проектирования.
Проблемы классического подхода
к бизнес-анализу и проектированию ИС
  1. Проблемы в части моделей бизнес-процессов и систем
Моделирование является неотъемлемой частью проектирования информационных систем:
  • моделирование бизнес-процессов позволяет структурировать основные понятия бизнеса, выстроить процессы, увидеть в них проблемные места и найти способы оптимизации;
  • модели систем позволяют сформулировать и закрепить логику, закладываемую в разрабатываемую систему.

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

Проблема 1.1. «Лишние» модели процессов AS-IS

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

Совсем исключить моделирование AS-IS тоже нельзя, потому что без понимания текущего состояния бизнеса и процессов невозможно предсказать, как оптимально перейти к целевой модели: сколько потребуется ресурсов, как перестроить инфраструктуру, как преобразовать организационную структуру и так далее. Поэтому аналитикам и проектировщикам приходится идти на жертвы:
  • собирать информацию неофициально; это чревато тем, что бизнес-процессы могут быть поняты неправильно, ключевые особенности будут упущены, а важные стейкхолдеры останутся вне поля зрения;
  • проектировать целевую модель системы, принимая риск, что она будет идти вразрез с уже существующими процессами и переход на неё может быть дорогим и сложным.
Вывод №1

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

Проблема 1.2. Излишне формальные модели бизнеса

Формальные нотации давно и широко применяются в индустрии и прошли большой эволюционный путь. Среди самых известных — нотации ARIS (VAD, eEPC), IDEF(0,3), UML (Activity), BPMN. Для аналитиков знание нотаций моделирования считается одним из основных: пункт о UML и BPMN есть буквально в каждой вакансии бизнес- или системного аналитика. И сами аналитики любят строить модели в формальных нотациях: артефакты в виде больших красивых диаграмм дают чувство значимости работы, доказывают причастность к разработке продукта.
С одной стороны применение нотации — хорошая практика в проектировании систем: предполагается, что диаграмма может однозначно пониматься всеми заинтересованными лицами.

Но использование формальных нотаций имеет подводные камни:

Потеря деталей

Большинство нотаций предлагают сильно ограничивать виды элементов, попадающих на конкретную диаграмму. Обычно это какие-то 2-3 вида из списка: процесс, событие, действие, исполнитель, продукт, правило и т.д.

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

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

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

Сложности совмещения проекций

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

Возникающие при этом нестыковки очень сложно выявлять и устранять, в этом должны были помогать инструменты класса CASE (например, Sparx Enterprise Architect), но применяются они достаточно редко.

Непонимание нотации и потеря смысла изображаемого

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

Ложное ощущение правильности

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

Сложно воспринимать онтологии

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

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

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

Большие временнЫе затраты на проведение интервью

Особенно сильно эти недостатки проявляются, если предметная область сложная и обширная. Предположим, что у вас есть 7-10 владельцев процессов и экспертов со стороны Заказчика. Скорей всего, не менее нескольких недель уйдёт на то, чтобы запланировать, назначить и провести с ними сессии интервью.

Большие временнЫе затраты на согласование итогов интервью между собой

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

Выявление и формулирование требований должно проводиться со всеми стейкхолдерами одновременно во избежание противоречий и потери времени на их устранение.
3. Взаимосвязи функциональных системных требований, моделей бизнеса и архитектуры
Довольно долгое время (где-то с 1995-го по 2015-й год) в индустрии считалось, что основная задача аналитика — разработка требований, а финальный артефакт работы аналитика в проекте — техническое задание, содержащее полные, непротиворечивые и осуществимые требования. Также считалось, что чем детальнее будут описаны требования, тем лучше для процесса разработки, поэтому документы требований часто раздувались до 200-300 страниц.

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

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

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

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

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

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

Большие «простыни», «портянки» требований
Громоздкие требования сложно переварить и провалидировать как Заказчику, так и команде разработки.
Вывод №4

Для успешной разработки без потери фокуса на главном в идеале нужны максимально краткие и ёмкие требования, связанные с целями бизнеса и понятные как Заказчику, так и команде.
Что лежит в основе этих проблем?
Причина 1.
Потеря взаимопонимания разработки с бизнесом из-за длинной цепочки преобразований и передачи информации
Достаточно часто звучит тезис о том, что аналитик — это «прослойка» между бизнесом и командой разработки и задача аналитика «переводить» с языка Заказчика на язык разработчиков и наоборот. Это нужно дескать потому, что разработчики не понимают как работает бизнес (и это предлагается почему-то принять за данность и не менять), а заказчики не понимают технологии и их ограничения (что в целом справедливо).

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

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

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

Информация о бизнесе и его процессах должна проходить как можно меньше преобразований на пути к системе.
Причина 2. Асинхронная распределённая коммуникация с представителями бизнеса
Рис.3 — Коммуникация с бизнес-экспертам в ходе серии интервью и изучения бизнеса и его потребостей
Вторая причина связана с интервью, о которых мы уже писали ранее. Чем больше проводится асинхронных интервью, тем выше вероятность, что вы получите конфликт в «показаниях» экспертов и потратите много времени на устранение противоречий.

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

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

Вывод №6. Взаимодействие с Заказчиком в идеале должно быть синхронным, без распределённых коммуникаций.
Вывод №6

Взаимодействие с Заказчиком в идеале должно быть синхронным, без распределённых коммуникаций.
Ещё раз посмотрим на выводы
  • Минимум преобразований
    Информация о бизнесе и его процессах должна проходить как можно меньше преобразований на пути к целевой системе.
    1
  • Общаемся одновременно
    Взаимодействие с Заказчиком в идеале должно быть синхронным, без распределённых коммуникаций.
    2
  • Быстрое моделирование
    Моделирование бизнеса, текущих процессов и погружение в предметную область должны быть достаточно быстрым и дешёвым для Заказчика (а точнее — рентабельным и обоснованным).
    3
  • Простые и наглядные модели
    Модели бизнеса должны быть достаточно простыми, однозначными и наглядными, чтобы их можно было легко понять и вычислить недочёты.
    4
  • Краткие и ёмкие требования

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

    5
  • Создаём требования вместе
    Выявление и формулирование требований должно проводиться со всеми стейкхолдерами одновременно во избежание противоречий и потери времени на их устранение.
    6
Что делать и какие есть альтернативы?
Можно подобрать подход, в котором бы синхронная, короткая по времени коммуникация бизнеса и команды разработки, минуя этап разработки функциональных требований, позволяла построить наглядную и простую модель бизнеса, переходящую в модель системы.

Среди практик, помогающих получить подобный подход, можно выделить, например:
  • Impact Mapping — практика формулирования функционального состава релиза ИС или продукта, исходя из прагматичного анализа его целей;
  • User Story Mapping — практика определения функционального состава ИС или продукта, исходя из модели автоматизации выбранного процесса (backbone).

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

Поэтому я бы хотел сделать отдельный акцент на культуру DDD (Domain Driven Design) и в частности пока малоизвестный в российском сообществе метод совместного анализа и проектирования в виде сессий Event Storming.

Именно Event Storming предлагает проводить совместное и по времени и по ролям изучение и моделирование бизнеса и системы, чтобы избегать обозначенных выше в статье проблем потери информации, искажения, запутывания и затягивания проектов.
Резюме
  1. В индустрии сложился устоявшийся подход к бизнес-анализу и проектированию информационных систем. Таким подходом руководствуются руководители во многих проектах.
  2. Классический подход предполагает, что анализ и проектирование состоят из большого количества этапов, включая предпроектное обследование бизнеса, проведение интервью с экспертами, моделирование процессов, формулирование и согласование требований. Заканчивается процесс проектирования получением проектной модели системы.
  3. В теории подход выглядит хорошо, потому что позволяет разработать подробные модели бизнеса, требования к системе и модели системы. Но такой подход имеет свои подводные камни.
  4. Проблемы классического подхода создают потребность в новых подходах, которые позволят путём синхронных коммуникаций создавать простые и наглядные модели бизнеса и системы. Среди таких подходов мы особенно выделяем DDD и Event Storming:

Воркшоп Миры Карлаш


«Event Storming как техника моделирования предметной области и моделирования микросервисов»

4 часа, вечер будней
Воркшоп будет полезен аналитикам, которые хотят научиться быстрому исследованию бизнес-процессов, изучить технику моделирования предметной области, выделять микросервисы.
Что будет на воркшопе:
  1. Введение в Event Storming
  2. Big Picture
  • Выделение основного процесса
  • Разбор событий
  • Добавление бизнес-правила и проблем (вопросов)
3. Process Modeling
  • Добавление подпроцессов
  • Добавление элементов техники: команд, смежных систем, пользователей
4. System Design
  • Выявление функционально независимых процессов
  • Выявление агрегатов
  • Построение кандидатной функциональной архитектуры
Об авторе
Денис Бесков
Основатель и руководитель школы, Автор курсов,
ИТ-предприниматель и методист
  • Более 20 лет в индустрии на позициях разработчика баз данных, архитектора, системного аналитика, руководителя отдела анализа (35 человек) и менеджера продуктов
  • Основной автор федеральных профстандартов «Системный аналитик» и «Менеджер ИТ-продуктов»
  • Основатель баркэмпов Product Camp Russia и консалтинговой компании Product.Vision
  • Организатор Летнего Аналитического Фестиваля 2013 и онлайн-марафона «Проектные истории» 2016, конференции Systems/Design
  • Более 20 выступлений на ИТ-конференциях
  • Certified Professional for Requirements Engineering (IREB CPRE)

■ Другие статьи на тему Бизнес-анализ