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

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

Если глобально в мире дела обстоят неплохо — формируется культура System Design, которая идёт из сферы публичных интернет-сервисов, наконец-то активно применяются принципы DDD (появившиеся также в начале века), то в российском аналитическом сообществе новые практики пока внедряются плохо. Более того, многие владельцы аналитических процессов или просто слабо следят за новыми веяниями или предпочитают использовать знакомые классические подходы, методики и инструменты, которые имеют свои недостатки.

Время на чтение статьи: 10 минут
Не любите читать? Посмотрите видео:

В этой статье вы узнаете:

• в чём заключается классический подход к бизнес-анализу и проектированию информационных систем, который сформировался в конце 90-х — начале 2000-х годов;
• какие сложности и проблемы есть у классического подхода;
• как можно решать проблемы классического подхода.

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

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

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


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

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

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

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

Моделирование является неотъемлемой частью проектирования информационных систем:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В арсенале аналитика казалось бы присутствуют различные форматы выявления требований:

• бенчмаркинг;
• работа с фокус-группами;
• проведение семинаров с клиентами;
• наблюдение за пользователями;
• анализ нормативной и технической документации;
• интервью и так далее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На пути от бизнеса к системе есть как минимум три больших этапа-фазы:

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

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

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

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

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

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

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

Среди практик, помогающих получить подобный подход, можно выделить, например:

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

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

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

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