Файл: Лабораторная работа 1 Инструментальные средства управления функциональными требованиями.docx

Несколько слов о техниках работы бизнес-аналитика.

Уже пару десятков лет основной техникой моделирования функционала информационных систем является разработка вариантов использования (use cases). Техника, действительно, неплохая. Особенно если бизнес-аналитик прочитал книжку Алистера Коберна «Современные методы моделирования функциональных требований» или посетил учебный курс по разработке юзкейсов. Однако визуализация вариантов использования в виде соответствующей UML диаграммы (рис.1) до сих пор вызывает сдержанную ухмылку у разработчиков и легкое недоумение у функциональных заказчиков.

В настоящее время на уровне бизнес-архитектуры никто никаких юзкейсов не рисует. Для отображения деятельности организации используется Business Capability Map – техника, позволяющая отобразить все виды деятельности предприятия на одной картинке. Довольно часто звучит и другой термин: функциональная карта. Что это такое и как использовать эту карту в проектах, изложено ниже в виде небольшой истории о вымышленном проекте разработки системы управления инцидентами, рассказанной от лица ведущего бизнес-аналитика этого проекта.

ПРИМЕР.

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

Как-то утром, когда завтрак уже давно кончился, а обед еще не думал начинаться, в нашу комнату влетел руководитель службы бизнес-анализа. Сбивая на своем пути зазевавшихся молоденьких сотрудниц и отчаянно жестикулируя, он подлетел к моему рабочему столу и срывающимся голосом заорал: «Когда?… Почему! Где?! Где функциональные требования?». Я тяжело вздохнул, пытаясь догадаться, о чем собственно идет речь. Даже пару раз попытался перебить его, чтоб задать этот вопрос, но потом решил дать руководителю немного остыть. Минут через десять руководитель службы немного успокоился и сумел объяснить, что речь идет о системе управления инцидентами. Только что он был на планерке у Директора по ИТ, который устроил всем грандиозный разнос за отсутствие в нашей организации этой замечательной системы. Департамент эксплуатации ИТ-систем,

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

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

Без пяти девять утра следующего дня я уже стоял с красиво распечатанным рисунком у кабинета руководителя департамента эксплуатации.

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

– UML- диаграмма вариантов использования – отрапортовал я без малейшей запинки, протягивая ему картинку.

Рис. 1 UML-диаграмма вариантов использования (use case).

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

– Пойдем! – сдерживая гнев, прошипел он и, размахивая картинкой, потащил меня в кабинет директора по ИТ.

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

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

– Очень хорошо, что ты зашел. Присаживайся. Я решил оформить эти работы отдельным проектом, и мы как раз обсуждаем систему управления инцидентами с будущим менеджером проекта и внешним консультантом. Вот и еще один участник команды к нам присоединился – отметил ИТ директор, бросив на меня недолгий, но пристальный взгляд, от которого мне стало как-то не по себе. Я и руководитель службы эксплуатации сели за стол.

– Мы не будем больше рисовать такие картинки – безапелляционно заявил человек в строгом деловом костюме, идентифицированный мною, как внешний консультант. Он достал из своей папки другой рисунок и протянул его руководителю департамента эксплуатации. — Это функциональная карта типового решения по управлению инцидентами. Отметьте галочкой те функции, которые необходимы Вам в первую очередь.

Руководитель департамента эксплуатации достал авторучку и принялся последовательно расставлять галки в каждом прямоугольнике, стараясь ничего не пропустить. Некоторые он даже обвел кругом, а затем, вероятно, для пущей убедительности нарисовал несколько стрелок и положил рисунок (рис.2) в центр стола, чтоб его могли видеть все участники встречи.

Рис. 2 Нулевой вариант функциональной карты (Landscape Map)

типового решения по управлению инцидентами

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

Не понимая до конца, что следует делать с этим рисунком, но услышав слово «требования» и проассоциировав их с бизнес-анализом, проектный менеджер передал рисунок мне. На этом встреча закончилась. Я взял рисунок и вместе с участниками встречи покинул кабинет директора. В приемной консультант остановил меня и сунул мне еще один рисунок (рис. 3):

Рис. 3 Первый вариант Landscape Map

– Смотрите! – дружелюбно проговорил консультант – На следующей встрече нам надо будет определить действующих лиц решения и сопоставить их с функциональной картой. Это похоже на Вашу диаграмму, только без тощих человечков и эллипсов. Возьмите за основу этот рисунок.

Вернувшись на свое рабочее место, абсолютно счастливый тем, что все так удачно сложилось, я быстро отсканировал картинку и отправил её проектному менеджеру в качестве сопроводительных материалов для следующей встречи, намереваясь посвятить остаток рабочего дня обустройству веселой фермы. Однако после обеда раздался звонок. Менеджер проекта управления инцидентами ехидно поинтересовался, как у меня дела, и спросил, не желаю ли я вместе с ним поработать над границами проекта. Пришлось тащиться к нему и выслушивать утомительные рассуждения о том, что запуститься следует всего через шесть недель, и если не удастся сузить рамки проекта, то митигировать риски срыва сроков будет решительно невозможно. В общем, он потребовал, чтоб к завтрашней встрече с разработчиками я указал на функциональной карте стадии проекта и приоритеты требований. К счастью, в нашей службе бизнес-анализа работало достаточное количество молодых привлекательных сотрудниц, и одной из них я перепоручил эту мега важную и необычайно срочную задачу. Получилось у неё примерно следующее (рис.4):

Рис. 4 Второй вариант Landscape Map.

Добавлены стадии проекта и приоритеты требований

Слегка пожурив её за унылую цветовую гамму и излишне формальный подход, следующим утром я вместе с менеджером проекта отправился на встречу с разработчиками. Тем уже было известно про наше новое развлечение в виде системы управления инцидентами, и встретили они нас во всеоружии. В ходе этой встречи мы узнали много нового, в частности, то, что служба бизнес-анализа и проектный офис у нас полные идиоты, совершенно не разбирающиеся в информационных системах (уверен, это замечание относилось не лично к нам, а скорее к молодой сотруднице, готовившей картинку). Также мы узнали, что еще полтора года назад компания закупила лицензии на программный продукт «Сервис-менеджер», на котором и следует реализовывать проект. Кроме того разработчики осыпали нас градом непонятных слов, из которых я сумел запомнить только малую часть. Чаще других звучали айтил (ITIL), ЕэСБи (ESB) и еще какие-то трехбуквенные сокращения. В общем, сплошной ТиСиПи-АйПи (TCP|IP). В какой-то момент они начали ругаться друг с другом, обсуждая, следует ли дозакупить недостающие лицензии или «нафигачить экранную форму в интранете». Затем позвали начальника отдела интранет-решений и повесили на него задачу разработки формы для заведения и закрытия инцидентов. В конечном счете руководитель службы разработки отобрал у меня исходную картинку, нарисованную консультантом и, пообещав к завтрашнему утру самостоятельно нарисовать правильное решение, вместе с проектным менеджером выгнал с совещания.

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

Рис. 5 Третий вариант Landscape Map.

Добавлены возможности ИТ-инфраструктуры

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

Позвонил проектный менеджер и сказал, что завтра у него управляющий комитет с докладом о статусе проекта. Что разработчики практически ничего не сделали, а тестирование прошли два модуля из восьми. Впрочем, проблема понятна. Дело в том, что нам хронически не хватает программистов на С++ и юзабилити дизайнеров для интранет-сайта. А еще, оказывается, отправка смс сообщений с компьютера стоит денег. Мы должны что-то платить алчному оператору связи, и чтоб рассчитать эту сумму, нужны нефункциональные требования. Одним словом, в итоге во всем оказались виноваты бизнес-аналитики. Я понял, что просто так мне не отвертеться, и позвонил консультанту, попросив его помочь в подготовке к завтрашней встрече. Он оказался на удивление отзывчивым человеком и к утру прислал следующую картинку (рис.6):

Рис. 6 Окончательный вариант Landscape Map.

Добавлены статусы работ и необходимые ресурсы

Видели бы вы, с каким апломбом проектный менеджер докладывал по этой картинке статус проекта. Он рассказал и про цветовую легенду функциональной карты, отображающую статус работ по конкретной задачи, и о пиктограммах, визуализирующих уже протестированные модули, и про С++, и про важность эргономичного пользовательского интерфейса, и даже поставил под сомнение целесообразность смс-уведомлений. В общем, все, наконец, поняли, что во всем виноваты вовсе не аналитики. В отличие от разработчиков и тестировщиков, нас с проектным офисом даже похвалили. А в конце квартала мне выписали хорошую премию. И теперь я регулярно рассказываю о преимуществах функциональных карт перед диаграммами вариантов использования. Все у нас стали описывать функциональность именно так. Хотя порой мне немного жаль, что мы отказались от UML диаграмм. Ведь функциональная карта — источник постоянных споров и разногласий в нашем дружном коллективе. Разработчики, администраторы, проектные менеджеры и даже заказчики постоянно что-то на них зачеркивают, обводят и исправляют. С UML диаграммами такого не было. Потому что это стандарт! К тому же, диаграмма вариантов использования — единственная картинка, которую в этом проекте я нарисовал сам.