Недостатки классического подхода к бизнес-анализу и проектированию информационных систем конца 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 (VAD, eEPC), IDEF(0,3), UML (Activity), 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 предлагает проводить совместное и по времени и по ролям изучение и моделирование бизнеса и системы, чтобы избегать обозначенных выше в статье проблем потери информации, искажения, запутывания и затягивания проектов.