Статья посвящена принципиальной структуре аналитической метамодели и метамодели верхнего уровня абстракций (с элементами такими как цель, ценность, принцип, стратегия, тактика, миссия...)

Я придерживаюсь убеждения, что задача анализа в IT — это борьба с неопределённостью, с целью прийти к пониманию, которое выражается в виде модели. Неважно как представлена модель: в виде диаграммы, текста, таблиц, всё равно это модель. Модели бываю разные: модель проблемы, решения, предметной области, модель бизнеса, модель системы, разные модели. И статья целиком состоит из моделей, где будет использоваться простой вымышленный случай, когда потребовалось создание системы. Клиент: Пекарня ООО «Три яблока», которая специализируются на производстве выпечки с начинкой из яблок. Заказ: Информационная система поддержки нового продукта пекарни на всех этапах жизненного цикла продукта. Итак, допустим бизнес-аналитики собрали все бизнес-требования, описали все бизнес-процессы. Системные аналитики описали модель данных и процессы на системном уровне. А разработчики реализовали систему по этим описаниям. Тестировщики тоже отработали, критических багов нет. А клиент говорит: «Это не то, что нужно!» Давай разбираться, где что-то в анализе могло пойти не так. Нас интересует только проблемы анализа.

Нам потребуется следующая иерархия уровней абстракций:

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

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

• Модели не соответствует решаемой задаче аналитика.

• Модели не согласованы внутри себя.

• Модели не согласованы между собой.

• Реализация по моделям не соответствует тому, что требуется пользователям и бизнесу.

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

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

Еще один способ – движение точек зрения навстречу друг другу:
сверху вниз – вовлечение пользователей в процесс разработки;
снизу вверх – вовлечение разработчиков в обсуждение задач и проблем бизнеса.

А если эти два способа совместить, получим приближение к Agile. В нем эти способы закреплены следующими 2-мя принципами:
1. Частая поставка работающего программного обеспечения;
2. Общение представителей бизнеса с разработчиками должно быть ежедневным на протяжении всего проекта.

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

1. Чаще ли стали достигать цели работы?
   В простых случаях – Да, в сложных и больших проектах Agile требует дополнительной организационной работы и методологий, которые уже тяжелы.

2. Стал ли лучше процесс и результат анализа?
   По своей сути Agile – это непрерывная корректировка текущего результата с желаемым. Время на комплексный анализ и проработку вариантов ограничено. Основной способ проверки гипотез – практика, а не рассуждения.

Данная статья описывает не организационные способы решения проблем анализа указанные в начале статьи. Тут представлен «старый» аналитический поход. А про Agile я не просто так рассказал, далее к нему еще вернусь.

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

Задача анализа — это борьба с неопределённостью, с целью прийти к пониманию, которое выражается в виде модели.

А что есть модель? Что описывают модели? Если убрать из рассмотрения парадигмы, то в сухом остатке (исходные, базовые, основные) модели описывают, как субъект выполняет действие над объектом, или субъект взаимодействует с другим субъектом. Дополнительными моделями и элементами моделей могут выступать события, интерфейсы и состояния.

Но основой, вокруг которой всё строится это: субъект, действие, объект. При этом без разницы в каком виде построена модель: BPMN, Use case или UML Диаграмма последовательности. Всё равно, это модель как субъект выполняет действие над объектом, или субъект взаимодействует с другим субъектом.

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

Напомню проблемы, которые нужно решить:

• Модели не согласованы внутри себя.

• Модели не согласованы между собой.

Для этого нужно выставить первое требование к моделям: Модели на всех уровнях абстракции должны представить собой систему.

Есть еще одна проблема, которую я указал в начале доклада:

• Реализация по моделям не соответствует тому, что требуется пользователям и бизнесу.

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

И вот, второе требование: Модели, в совокупности, должны давать ответ на вопрос, что требуется пользователям и бизнесу. Назначение и ограничения могут быть заданы в виде бизнес-требований, но нам нужно понять их, то есть построить модель.

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

Если подходить напрямую, то вероятнее всего вы попробуете построить верхеуровневую модель бизнеса. Поискав различные представления, скорее всего найдете Business Model Canvas Александра Остервальдера. И в этом табличном представление обнаружите элементы, которые могут оказать непривычными, если до это вы описывали только операционную деятельность организации. Вы можете попробовать использовать Архитектурные фреймворки, BIZBOK или TOGAF. Но без конкретных примеров они представляют собой теоретические абстракции. По моему мнению, сложность в том, что они созданы не для того, чтобы кого-то научить, они нужны для тех, кто уже знает и понимает, и хочет систематизировать знания.

Ячейка «Почему» отвечает за назначение остальных ячеек в этой строке, но ее уровень абстракции выше. Это хорошо видно на матрице Захмана первой версии.

Если взять матрицу Захмана третьей версии, то тут этот момент замылен в определениях «Системные цели и способы», но это не собственные цели системы, это цели бизнеса, реализацию которых должна обеспечивать система.

И с этим выводом формируется «Краеугольный камень анализа»:
1) Модели на всех уровнях абстракции должны представить собой систему.
2) Назначение элементов системы определяет система.
3) Назначение самой системы находится на вышестоящем уровне абстракций. То есть его определяет вышестоящая система (экосистемы).

Следствие: Нельзя построить модель «Назначений и ограничений» не сменив уровень абстракций. Но вы не можете сменить уровень абстракций, так как метамодель этого уровня отличается от привычной для нижних уровней. То есть для элементов модели информационной системы вы можете найти назначение в модели бизнеса, а для элементов бизнеса вы может попасть в такую ситуацию, что назначение и ограничения есть – это бизнес требования, а модели и понимания нет.

Как Agile решил эту проблему?
В Agile есть принцип: «Общение представителей бизнеса с разработчиками должно быть ежедневным на протяжении всего проекта». Он не всегда соблюдается, но именно это общение должно обеспечить понимание командой назначения и ограничений.

Есть еще технические приемы. Как много вы думали над тем, почему часть User Story после слова «чтобы» очень тяжело написать? И почему критерии INVEST именно такие?

Шаблон User Story:

Как <субъект>, я хочу/могу <выполнить деятельность или получить объект>, чтобы <зачем или почему>.

INVEST — критерии хорошей User Story:

Independent — независимая от других историй;
Negotiable — обсуждаемая, отражает суть, а не детали;
Valuable — ценная для клиентов, бизнеса и стейкхолдеров;
Estimable — оцениваемая по сложности и трудозатратам;
Small — компактная, может быть сделана командой за одну итерацию;
Testable — тестируемая, имеет критерии приемки.

Дело в том, что эти критерии описывают требования и ограничения к User Story как некой маленькой системе. А зачем и почему – это назначение нашей системы и абстракция верхнего уровня, которую тяжело написать если нет понимания. Так это же полностью соответствует краеугольному камню, который я описал ранее.

В 2020 в руководство по Scrum добавлен понятие Цель продукта, а рамках планирования особое внимание уделяется вопросу «Почему» для цели спринта. Agile сосредоточен на верхней части пирамиды абстракций. Авторы не глупые люди, они понимают, что это залог успеха.

Для проработки вопроса назначения и ограничений вместе с Agile подходом можно использовать дополнительные методики: Дизайн мышление, Impact mapping и JTBD. Все они хорошие, рекомендую попробовать практиковать. Но тут есть большое «НО» – это не будет работать, если у вас команда неопытных аналитиков. Несмотря на кажущуюся легкость и заявленную опору на простой здравый смысл использовать Agile могут только квалифицированных специалисты с достаточным опытом. Потому что Agile игнорирует уровни абстракций. А в Scrum, по идее, вообще нет аналитиков, есть кроссфункциональная команда, которая работает, не обращая внимание на уровни абстракции.

Итак, Agile – это подход, который делает упор на организационные способы решения задач с опытными профессионалами. Используя различные приемы, указанные ранее, можно получить некоторое представление о назначении и ограничениях, в виде набора стикеров, job stories и mind map.

А есть ли более строгий, аналитический способ понять назначение и ограничения?

Этому посвящена вторая часть статьи.