Сегодня несколько слов о техниках работы бизнес-аналитика. Уже пару десятков лет основной техникой моделирования функционала информационных систем является разработка вариантов использования (use cases). Техника, действительно, неплохая. Особенно если бизнес-аналитик прочитал книжку Алистера Коберна «Современные методы моделирования функциональных требований» или посетил учебный курс по разработке юзкейсов. Однако визуализация вариантов использования в виде соответствующей UML диаграммы до сих пор вызывает сдержанную ухмылку у разработчиков и легкое недоумение у функциональных заказчиков. Пару месяцев назад в заметке Так ли уж близки корпоративная архитектура и бизнес-процессы? я писал о том, что на уровне бизнес-архитектуры никто никаких юзкейсов не рисует. Для отображения деятельности организации используется Business Capability Map – техника, позволяющая отобразить все виды деятельности предприятия на одной картинке. Довольно часто звучит и другой термин: функциональная карта. Что это такое и как использовать эту карту в проектах я позволю себе изложить в виде небольшой истории о вымышленном проекте разработки системы управления инцидентами, рассказанной от лица ведущего бизнес-аналитика этого проекта.
Как-то утром, когда завтрак уже давно кончился, а обед еще не думал начинаться, в нашу комнату влетел руководитель службы бизнес-анализа. Сбивая на своем пути зазевавшихся молоденьких сотрудниц и отчаянно жестикулируя, он подлетел к моему рабочему столу и срывающимся голосом заорал: «Когда?… Почему! Где?! Где функциональные требования?». Я тяжело вздохнул, пытаясь догадаться, о чем собственно идет речь. Даже пару раз попытался перебить его, чтоб задать этот вопрос, но потом решил дать руководителю немного остыть. Минут через десять руководитель службы немного успокоился и сумел объяснить, что речь идет о системе управления инцидентами. Только что он был на планерке у Директора по ИТ, который устроил всем грандиозный разнос за отсутствие в нашей организации этой замечательной системы. Департамент эксплуатации ИТ-систем, являющийся основным заказчиком такой системы, и Служба разработки ИТ-решений перевели все стрелки на нас, заявив, что система управления инцидентами уже пару лет остается абстрактной мечтой, потому что служба бизнес-анализа так и не удосужилась собрать требования. Резонное возражение, что с такой задачей к нам никто не обращался, естественно, не возымело действия, и уже через полчаса мы сидели в кабинете руководителя департамента эксплуатации и выслушивали его рассказ о космических кораблях, бороздящих просторы…
Из этого разговора я вынес совсем немного. Оказывается, наша служба поддержки разделена на два уровня. На первом уровне работают начинающие специалисты, не способные решить большинство поступающих проблем. Какие-то инциденты они решают, но их основное занятие заключается в направлении запросов на ту или иную группу сотрудников второго уровня. И вообще самое главное, чтоб пользователи самостоятельно подтверждали закрытие инцидентов, потому что с ними подписан соответствующий SLA. Набросав в visio простенькую UML диаграмму, остаток дня я посвятил строительству веселой фермы.
Без пяти девять утра следующего дня я уже стоял с красиво распечатанным рисунком у кабинета руководителя департамента эксплуатации.
– Что это у тебя? – поинтересовался руководитель департамента, выходя из своего кабинета.
– ЮэМэЛь диаграмма вариантов использования – отрапортовал я без малейшей запинки, протягивая ему картинку.
Он нацепил очки, взял мой рисунок и на несколько секунд опустил на него взгляд. Когда руководитель службы эксплуатации вновь поднял голову, я по косвенным признакам сообразил, что картинка ему понравилась как-то не очень. Наверное, такое же выражение лица, сочетающее сдерживаемый гнев и полную безнадежность, бывает у него от известия о случившейся проблеме минус первого приоритета.
– Пойдем! – сдерживая гнев прошипел он и, размахивая картинкой, потащил меня в кабинет директора по ИТ.
Директор, как назло, оказался в своем кабинете. Вместе с ним за столом сидели еще двое и о чем-то оживленно беседовали. Одного из участников обсуждения я знал. Он работал у нас в проектном офисе. Другой же человек, в строгом деловом костюме, был мне незнаком.
Прервав обсуждение, ни с кем не поздоровавшись, руководитель департамента эксплуатации подошел к директору и, пробурчав: «Как Вы думаете, что это?», сунул ему мой рисунок. Взглянув на рисунок, директор улыбнулся и добродушно ответил: «Пляшущие человечки, я полагаю». Он небрежно передал мой рисунок другим собеседникам, которые тут же принялись его заинтересованно разглядывать, а сам обратился к руководителю департамента эксплуатации:
– Очень хорошо, что ты зашел. Присаживайся. Я решил оформить эти работы отдельным проектом, и мы как раз обсуждаем систему управления инцидентами с будущим менеджером проекта и внешним консультантом. Вот и еще один участник команды к нам присоединился – отметил ИТ директор, бросив на меня недолгий, но пристальный взгляд, от которого мне стало как-то не по себе. Я и руководитель службы эксплуатации сели за стол.
– Мы не будем больше рисовать такие картинки – безапелляционно заявил человек в строгом деловом костюме, идентифицированный мною, как внешний консультант. Он достал из своей папки другой рисунок и протянул его руководителю департамента эксплуатации. – Это функциональная карта типового решения по управлению инцидентами. Отметьте галочкой те функции, которые необходимы Вам в первую очередь.
Руководитель департамента эксплуатации достал авторучку и принялся последовательно расставлять галки в каждом прямоугольнике, стараясь ничего не пропустить. Некоторые он даже обвел кругом, а затем, вероятно, для пущей убедительности нарисовал несколько стрелок и положил рисунок в центр стола, чтоб его могли видеть все участники встречи.
– Отлично! – резюмировал консультант и передвинул листок менеджеру проекта. – Вот наш scope. По этой карте мы будем отслеживать прогресс на всех фазах проекта, начиная с уточнения требований и вплоть до ввода системы в эксплуатацию. Впрочем, и после запуска системы функциональная карта нам еще пригодится.
Не понимая до конца, что следует делать с этим рисунком, но услышав слово «требования» и проассоциировав их с бизнес-анализом, проектный менеджер передал рисунок мне. На этом встреча закончилась. Я взял рисунок и вместе с участниками встречи покинул кабинет директора. В приемной консультант остановил меня и сунул мне еще один рисунок:
– Смотрите! – дружелюбно проговорил консультант – На следующей встрече нам надо будет определить действующих лиц решения и сопоставить их с функциональной картой. Это похоже на Вашу диаграмму, только без тощих человечков и эллипсов. Возьмите за основу этот рисунок.
Вернувшись на свое рабочее место, абсолютно счастливый тем, что все так удачно сложилось, я быстро отсканировал картинку и отправил её проектному менеджеру в качестве сопроводительных материалов для следующей встречи, намереваясь посвятить остаток рабочего дня обустройству веселой фермы. Однако после обеда раздался звонок. Менеджер проекта управления инцидентами ехидно поинтересовался, как у меня дела, и спросил, не желаю ли я вместе с ним поработать над границами проекта. Пришлось тащиться к нему и выслушивать утомительные рассуждения о том, что запуститься следует всего через шесть недель, и если не удастся сузить рамки проекта, то митигировать риски срыва сроков будет решительно невозможно. В общем, он потребовал, чтоб к завтрашней встрече с разработчиками я указал на функциональной карте стадии проекта и приоритеты требований. К счастью, в нашей службе бизнес-анализа работало достаточное количество молодых привлекательных сотрудниц, и одной из них я перепоручил эту мегаважную и необычайно срочную задачу. Получилось у неё примерно следующее:
Слегка пожурив её за унылую цветовую гамму и излишне формальный подход, следующим утром я вместе с менеджером проекта отправился на встречу с разработчиками. Тем уже было известно про наше новое развлечение в виде системы управления инцидентами, и встретили они нас во всеоружии. В ходе этой встречи мы узнали много нового, в частности, то, что служба бизнес-анализа и проектный офис у нас полные идиоты, совершенно не разбирающиеся в информационных системах (уверен, это замечание относилось не лично к нам, а скорее к молодой сотруднице, готовившей картинку). Также мы узнали, что еще полтора года назад компания закупила лицензии на программный продукт «Сервис-менеджер», на котором и следует реализовывать проект. Кроме того разработчики осыпали нас градом непонятных слов, из которых я сумел запомнить только малую часть. Чаще других звучали айтил, ЕэСБи и еще какие-то трехбуквенные сокращения. В общем, сплошной ТиСиПи-АйПи. В какой-то момент они начали ругаться друг с другом, обсуждая, следует ли дозакупить недостающие лицензии или «нафигачить экранную форму в интранете». Затем позвали начальника отдела интранет-решений и повесили на него задачу разработки формы для заведения и закрытия инцидентов. В конечном счете руководитель службы разработки отобрал у меня исходную картинку, нарисованную консультантом и, пообещав к завтрашнему утру самостоятельно нарисовать правильное решение, вместе с проектным менеджером выгнал с совещания.
На следующее утро в почтовом ящике я обнаружил новый рисунок. Я удалил с него несущественные технические детали: названия серверов, пиктограммы баз данных и прочую муть и в таком виде отправил его консультанту:
Получил в ответ письмо благодарности за отличную работу и переслав его своему непосредственному руководителю, я смог, наконец, забыть об этой суматошной задаче. Снова задача напомнила о себе ближе к осени, когда на веселой ферме приближался сезон дождей.
Позвонил проектный менеджер и сказал, что завтра у него управляющий комитет с докладом о статусе проекта. Что разработчики практически ничего не сделали, а тестирование прошли два модуля из восьми. Впрочем, проблема понятна. Дело в том, что нам хронически не хватает программистов на си-плюс-плюс и юзабилити дизайнеров для интранет-сайта. А еще, оказывается, отправка смс сообщений с компьютера стоит денег. Мы должны что-то платить алчному оператору связи, и чтоб рассчитать эту сумму, нужны нефункциональные требования. Одним словом, в итоге во всем оказались виноваты бизнес-аналитики. Я понял, что просто так мне не отвертеться, и позвонил консультанту, попросив его помочь в подготовке к завтрашней встрече. Он оказался на удивление отзывчивым человеком и к утру прислал следующую картинку:
Видели бы вы, с каким апломбом проектный менеджер докладывал по этой картинке статус проекта. Он рассказал и про цветовую легенду функциональной карты, отображающую статус работ по конкретной задачи, и о пиктограммах, визуализирующих уже протестированные модули, и про С++, и про важность эргономичного пользовательского интерфейса, и даже поставил под сомнение целесообразность смс-уведомлений. В общем, все, наконец, поняли, что во всем виноваты вовсе не аналитики. В отличие от разработчиков и тестировщиков, нас с проектным офисом даже похвалили. А в конце квартала мне выписали хорошую премию. И теперь я регулярно рассказываю о преимуществах функциональных карт перед диаграммами вариантов использования. Все у нас стали описывать функциональность именно так. Хотя порой мне немного жаль, что мы отказались от UML диаграмм. Ведь функциональная карта – источник постоянных споров и разногласий в нашем дружном коллективе. Разработчики, администраторы, проектные менеджеры и даже заказчики постоянно что-то на них зачеркивают, обводят и исправляют. С UML диаграммами такого не было. Потому что это стандарт! К тому же, диаграмма вариантов использования – единственная картинка, которую в этом проекте я нарисовал сам.
Другие статьи по теме:
- Так ли уж близки корпоративная архитектура и бизнес-процессы
- Эскизы архитектурных решений
- Функциональная карта – не территория
Канал «Архитектура ИС» в Telegram: https://t.me/it_arch
UPDATE: 4 июля 2018 года в ВШБИ(Москва, улица Трифоновская, д. 57, корп. 1) бесплатный вебинар по этой теме. Обязательная регистрация по этой ссылке
Класс!!! :-).
Прочитал на одном дыхании, спасибо.
Ситуация так близка и знакома.
Остальные главы бизнес-романа когда ждать в публикациях.
Очень здорово. 😉
В самих схемах понравился переход от разделения по ролям к разделению к технологиям.
Функциональная схема — документ, разъясняющий процессы, протекающие в отдельных функциональных цепях изделия (установки) или изделия (установки) в целом.
Мораль – используйте процессы! С самого начала. И правильно.
Функциональная схема – это другой инструмент. А споры о том, что важнее для EA процессы или capabilities, вроде бы, уже закончились. Большинство склоняются к capabilities, разве не так? Модели процессов слишком детальны(требуют много времени на документирование и поддержку), изменчивы и не учитывают такие важные факторы как ресурсы, компетенции и пр.
“А споры о том, что важнее для EA процессы или capabilities, вроде бы, уже закончились. ” – это различные точки зрения на предприятие, которые одинаково важны.
Также capabilities легко выводятся из процессов, но не наоборот, так что не очевидно что более важно.
“разве не так?” Учитывая, что нет единого мнения о понятии “capabilities” то нет так.
“Модели процессов слишком детальны(требуют много времени на документирование и поддержку), изменчивы и не учитывают такие важные факторы как ресурсы, компетенции и пр.” скорее все Вам встретилось неудачное использование процессов.
“слишком детальны” не обязательно т.к. обычно есть уровни детализации процессов. Похоже, что функциональная схема – это пример одного из таких уровней. (хотя возможно что это всего лишь flow-of-assets)
“требуют много времени на документирование и поддержку” – по сравнению с чем? с проваленной аудиторской проверкой и потерей сертификации?
“изменчивы” – вот оно agility где было спрятано
“не читывают такие важные факторы как ресурсы, компетенции и пр.” – вполне учитывают и т.п
Thanks,
AS
Замечание о проваленной аудиторской проверке было особенно страшным 😀 На самом деле, я предпочитаю терпимо относиться к любым верованиям и предрассудкам. Путь будут и бизнес-процессы и use cases и прочие формы описания деятельности, включая русскоязычную прозу. При наличии любых таких описаний архитекторам будет проще рисовать функциональные карты
RE “Замечание о проваленной аудиторской проверке было особенно страшным” An example of the incident management improved by processes – http://improving-bpm-systems.blogspot.ch/2015/07/bpm-helps-medical-emergency-service-to.html . Before using BPM, people died on streets during waiting for emergency services.
Максим, откуда Вы узнали про функциональные карты? Есть ли у них “родитель” и “нотация”? Нашёл только 1 раздел в англоязычной wiki: “Capability Management and EA”, которая ссылается на Strategic Capability Network (13-ый слайд здесь http://www-935.ibm.com/services/us/ceo/leansixsigma/pdf/201204_bpm_at_ibm.pdf). Но это не совсем то, о чём поведано в “вымышленной истории”
У IBM эта тема называлась Component Business Model https://www-935.ibm.com/services/us/imc/pdf/g510-6163-component-business-models.pdf Другие чаще говорят о business capability maps. Впервые я услышал про функциональные карты от консультантов McKinsey. Затем, то же самое показали консультанты из Accenture
Спасибо за источники, будем изучать!
Похоже на окорпоративленную customer jorney map.
Максим, а чем квадратики на функциональной карте отличаются от FEATURES в требованиях (у Леффингвелла, у Вигерса)? Есть ощущение, что это одно и то же.
В принципе, в этот формат можно положить любые сущности. Даже в карту ИТ-ландшафта Archimate можно засунуть практически все что угодно. Если вы фичами оперируете, то да, можно писать фичи. Но есть еще и юзкейсы и пользовательские истории, эпики, capability, требования по ISO 29148
В фичу, насколько помню, тоже запихивают что угодно, что волнует заказчика\потребителя – функции, атрибуты качества, структуру системы, ограничения на проектирование.
Спасибо за интересную статью!
Максим, спасибо за интересную статью!
Написал большой комментарий про ценность вариантов использования как я её понимаю и почему Вы призываете от них отказываться.
И понял, что не призываете 🙂
Т.к. на функциональной карте по факту расположены юзкейсы, которые представляют все те же цели заинтересованных лиц, что и в классической UC диаграмме.
Но всё равно кажется, что классический вью – он немного другие задачи решает:
* UC диаграмма – идентификация экторов (пользователей и других заинтересованных лиц) и выявление их целей (в том числе для проверки полноты);
* Функциональная карта – распределение юзкейсов по бизнесовым компонентам. То есть получается, даже не техническим подсистемам, а по интерфейсам, в Вашем примере – UI для клиента, UI для саппорта, “без UI”, могло бы быть “API Центробанка”, “Общепродуктовая система аудита” и т.п.
Но если вариантов использования много, то при накидывании их сразу на функциональную карту разве не высоки риски потерять цели и как следствие фичи? Да и с компонентами пока не понятно – какие они там должны быть, если система посложнее трёх юзкейсов.
А с обычной UC можно оставить только юзкейсы одной роли, пойти к сотруднику и спросить – ещё что-то делаешь? И он вспомнит, что ещё рассылает отчёты по инцидентам.
Ну то есть кажется, что всё-таки есть идентификация заинтересованных лиц и вариантов использования, а есть разделение их на компоненты. И функциональная карта – это небольшое осветление: система из черного ящика становится серым, благодаря тому, что архитектор+команда принимают решение о том – по какому принципу делить интерфейс, через который юзкейсы доставляются потребителям. После этого (полнота и качество выявления ЗЛ и ВИ уже проверены, информация о потребностях и шагах уже выявлена) действительно человечки уже можно убрать – визуальный шум.
И вот как раз по тем функциям, которые “нарисовались” без юзкейсов – стало ничего не понятно.
Что за автозаведение и автозакрытие? Это интеграция между двумя системами: сайт и инциденты? Зачем тогда это выносить в карту, это же обязаловка, как логирование и авторизация. И почему тогда это отметили низким приоритетом, как без интеграции будет работать эта связка систем.
Если это не интеграция, а какое-то предупреждающее заведение без обращения клиента, то вопрос – что это за случаи? Например, мы хотим, чтобы был заведён инцидент если сайт не доступен? Тогда второй вопрос – кому это надо? Клиенту не надо, он спит. А кто-то хочет, чтобы утром клиенты не столкнулись с упавшим сайтом. Кто это? Кто будет определять какие ситуации надо “инцидентить”, возможно настраивать определение этих ситуаций?
С рассылкой уведомлений вроде попонятнее, но всё равно куча вопросов. Что значит “сделали нотификацию SMS”? Это клиенту или оператору? Как клиент выберет канал нотификации – доработка сайта включена в функцию “ядра” или её просто не стали показывать на карте? Рассылка с хардкодом или кастомизируется по типу события и статусу клиента (VIP / не VIP)?
Ну и пример с тем, что оказывается по инцидентам необходимо отчитываться, и никто про это не вспомнил, глядя на эту замечательную карту – я тоже могу литературно и смешно рассказать, чтобы все увидели, как этот архитектор забегал, когда начальство стало требовать отчётность по результативности этой непонятной системы с автозаведением инцидентов.
Это я всё к тому, что карта понравилась, но посыл “больше мы не будем рисовать такие картинки” в отношении юзкейсов не понятен. При всём при этом согласен, что неподготовленным людям показывать “мужиков с яйцами” не результативно.
Спасибо за комментарии 😉
Good reading your posst