Бизнес-анализ от а до я: гид для начинающих

б) Наличие ментора и работы в команде позволяет мне совершенствовать своё мастерство каждый день. Люди по своей природе стремятся найти причину и дать полезный комментарий к любой активности другого, когда их об этом просят – конечно, если им не лень и они заинтересованы в процессе. Людей, которые равнодушны к своим обязанностям, лучше не выбирать в качестве менторов. Так в чем суть? Работа каждого дня над дизайном требований не может быть монотонной, когда вы получаете комментарии и предложения по улучшению. Комментарии не всегда могут быть приятными – на самом деле, они почти всегда вызывают дискомфорт. Однако одна из ключевых компетенций хорошего бизнес-аналитика – это умение эффективно воспринимать критику. Под 'эффективно' я подразумеваю следующий процесс: сначала внимательно слушать, затем анализировать, применять полученные замечания к своей ситуации и, наконец, принимать решение – улучшит ли предложение качество работы.

На основе своего опыта могу сказать, что 70-80% рекомендаций, которые я получал, действительно помогли мне улучшить качество выполнения задач. Интересно, что даже если комментарии напрямую не влияли на улучшение, их анализ и применение к текущей ситуации помогали выявлять другие 'пробелы' в создаваемом решении, на которые я бы, возможно, никогда не обратил внимание без этих замечаний. Например, создавая описание реакции системы на нажатие кнопки пользователем, коллега предложил, что 'выполнение открытия дополнительного поля по нажатию на кнопку должно быть описано отдельным сценарием'. Хотя функциональность кнопки была минимальна и я изначально считал, что разделять описание не нужно, проверка моего текста выявила важный 'пробел' – я не описал поведение кнопки при её повторном нажатии. В итоге, отзыв оказался чрезвычайно полезным. в) В любой деятельности всегда существует возможность для улучшений, и эти улучшения можно придумывать бесконечно, даже в самой, казалось бы, простой работе. Улучшения эти могут фактически изменять кажущуюся однообразность рабочих дней. Один из самых простых и эффективных мотиваторов к улучшениям, который я использую на протяжении всей своей карьеры, очень прост: следуйте главному принципу любого развития – личностного, физического, профессионального. Заканчивая день, спросите себя: «Что я сегодня сделал лучше или эффективнее, чем вчера?» Если есть ответ, значит, вы развиваетесь.

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

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

Теперь давайте подробнее рассмотрим, как я работал с требованиями. Занимался я этим как дополнительной активностью, изучая, что такое требования и как они формируются. Изначально требования ко мне поступали уже в готовом виде в формате списка от моего ведущего БА. Я анализировал документ с требованиями, который затем проверял и подписывал клиент, и, возможно, мой ведущий БА дополнительно разделял их на более мелкие части.

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

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

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

Например, для бизнеса требование о возможности управления информацией о клиентах может включать от 100 до 200 функциональных требований. Одно из них может формулироваться как «Система должна предоставлять пользователю возможность создать профиль клиента», другое – «Система должна поддерживать в профиле клиента следующие 10 параметров:…» и так далее. Из таких требований четко становится понятно, какая функция системы ожидается, например, функция создания профиля пользователя. Это функциональное требование также обсуждается с клиентом и подписывается им.

Затем такое требование попадает ко мне, и я разрабатываю дизайн, описывающий, как будет реализовано создание профиля клиента. Важно отметить, что все бизнес-требования и функциональные требования связаны между собой в специальном документе, который называется матрицей прослеживаемости (Traceability Matrix). Этот документ помогает быть уверенным в том, что все созданные функциональные требования необходимы и связаны с бизнес-требованием, и наоборот, что все бизнес-требования имеют функциональную реализацию.

В проектах по созданию крупных систем для поддержки бизнеса телекоммуникационных компаний, например, для одного модуля «система управления клиентами», может быть разработано 400-500 функциональных требований. При таких объемах информации создание документа, который хранит все связи между требованиями, становится абсолютно необходимым. Были случаи, когда именно благодаря этому документу удавалось находить несоответствия в связях и избавляться от ненужной работы, например, когда обнаруживалось функциональное требование, которое фактически не было связано ни с одним бизнес-требованием и, соответственно, уже не было актуальным, или когда бизнес-требование изменялось или удалялось после недавних обсуждений с клиентом.

По мере работы я начал самостоятельно формулировать функциональные требования к новым бизнес-требованиям, освоив процесс за 3-4 недели. Я уже мог понимать, как из бизнес-требования формируется функциональное требование и впоследствии превращается в дизайн.

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

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

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

Создание требований

Рассмотрим бизнес-требование: «Профиль компании должен содержать информацию о кредитоспособности компании». Это требование от бизнеса и клиента ясно формулирует необходимость проверки платежеспособности компании-покупателя перед совершением коммерческих операций с предоставлением товаров в рассрочку.

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

Давайте разберём идентификатор этого требования: «ФТ-СУК-КР-1». «ФТ» означает «Функциональное Требование». «СУК» указывает на систему, к которой относится требование – Система Управления Клиентами. «КР» обозначает конкретный модуль или компонент системы – Кредитный модуль. Номер требования – 1. Правила создания таких идентификаторов позволяют легко определить, о чем идет речь в требовании. Текст требования может быть изменен, но идентификатор остается неизменным и играет ключевую роль в матрице связей/отслеживания и в любых других документах, связанных с этим требованием. Функциональное требование включает в себя несколько важных пунктов, каждый из которых имеет ключевое значение:

«Система» – это кажущееся простое слово подтверждает, что именно наша система должна реализовать указанную функциональность. Это утверждение дает 100% гарантию включения функции в систему.

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

«на главной странице…» – указывает на конкретное местоположение и содержание функции, что помогает точно определить, где именно будет реализована функция в интерфейсе.

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

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

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

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

Дизайн требования

Получив подписанное функциональное требование, я приступаю к разработке дизайна, который описывается в документе, называемом "Спецификация по функциональному дизайну" (Functional Design Specification). Стоит отметить, что подходы, описываемые здесь, адаптированы под конкретный проект и могут отличаться в зависимости от контекста.

Как начинается процесс? Сначала я создаю уникальный идентификатор для дизайна, например, ФД-СУК-КР-1. "ФД" здесь обозначает "Функциональный Дизайн". Затем формируется короткое название дизайна, которое будет использоваться как заголовок документа, например, "Просмотр кредитной информации на главной странице компании". Функциональное требование может соотноситься как с одним, так и с несколькими дизайнами.

Описание дизайна:

"Описание: Данный дизайн позволяет пользователю видеть основные кредитные показатели компании-клиента на главной странице профиля. Эта информация помогает в принятии решений."

Входные условия:

Для использования функциональности пользователь должен авторизоваться в системе СУК, выбрать компанию и перейти на её главную страницу.

Описание функциональности:

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

Шаги/Сценарий:

На странице профиля компании система отображает раздел «Кредитная информация».

В разделе «Кредитная информация» отображаются следующие поля/данные:

Кредитный рейтинг (название) – текстовое, неизменяемое.

Кредитный рейтинг (значение) – неизменяемое, цифровое, двузначное число с поддержкой десятичного значения, диапазон значений от 0 до 10.

Кредитный статус (название) – текстовое, неизменяемое.

Кредитный статус (значение) – неизменяемое, графическое отображение в виде круга с тремя цветами: красный, желтый, зеленый.

Кредитные условия (название) – текстовое, неизменяемое.

Кредитные условия (значение) – неизменяемые, три текстовых поля со значениями:

а) разрешенная рассрочка: «ХХ» месяцев;

б) статус контракта: «активен», «неактивен» или «истек»;

в) размер задолженности: «нет» или «размер задолженности».

Кредитная история (название) – текстовое, неизменяемое, оформлено как ссылка (функциональность вне границ этого дизайна, см. ФД-СУК-КР-4).

Заключение:

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

Изменение данных:

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

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

Для этих целей я разрабатываю два дополнительных документа:

Спецификация по пользовательскому интерфейсу (СПИ / User Interface Specification), которая содержит макеты того, как будет выглядеть раздел «Кредитная история» для пользователя.

Спецификация по модели данных (СМД / Data Model Specification), описывающая хранение данных, использованных в функциональном дизайне.

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

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

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

Вот, собственно, что я хотел рассказать про реальные первые месяцы моей работы бизнес-аналитиком. Я не общался с клиентом и не занимался выявлением бизнес- или функциональных требований – таких обязанностей у меня не было, так как не было и опыта, и нужно было сначала изучить базовые активности. Я даже не знал, какой используется и из чего состоит цикл разработки программы/системы. А использовали мы методологию разработки, которая называется «Водопад» (Waterfall). Почему «Водопад»? Потому что создание системы/продукта поделено на этапы, которые всегда выполняются в последовательном порядке – один за другим. Отсутствие этих навыков и знаний – было ли это плохо или негативно в плане моего опыта? На мой взгляд, нет, так как я получал полноценный опыт в самом базовом и необходимом БА навыке – документирование требований и их дизайна.

То, что я описывал выше, как вы поняли, это «жесткие» навыки (Hard skills). А вот какие из «мягких» навыков (Soft skills) я бы подсветил, в которых я получал опыт и считал важными? Думаю, я стартовал с трех основных мягких навыков, которые я назову в формате ролей: командный игрок, мистер-вопрошайка и тайм-менеджер. Уточню, что некоторые приобретенные способности, которые я называю «мягкими» навыками выше, не являются прямо официальными навыками, которые указаны в книгах, или, возможно, они указаны, но в других терминах. Я написал именно «стартовал», так как все эти три навыка я продолжал развивать на протяжении своей БА карьеры. Расскажу кратко о них и почему именно они мне показались (или нет) важными на старте:

Командный игрок

Я начинал свою карьеру в команде, состоящей всего лишь из меня и ведущего бизнес-аналитика, но это уже была команда! Эффективная команда – это залог успешного достижения любых целей в любой деятельности (и не только в ИТ-сфере, разумеется). Один из критериев «эффективной» (продуктивной, быстрой, ценной и т. д.) команды – это ситуация, когда все её участники являются командными игроками. Иначе командой это назвать нельзя. Кто такой «командный игрок» в плане работы? Для меня это человек/коллега, который: понимает и знает (да! у командного игрока есть обязанность «понимать и знать») командные цели, проблемы, планы, подходы к работе; умеет и обладает способностями принимать решения вместе с командой, воспринимать любые отзывы и критику от команды позитивно и использовать их для своего профессионального улучшения и для достижения целей команды, оценивать и принимать подход к распределению задач рационально с точки зрения эффективности для всей команды, быть честным и открытым для команды даже при обнаружении самостоятельно созданных проблем, постоянно стремиться к улучшению процессов в команде, слушать команду, соблюдать авторитет ведущего команды (ведь именно он в итоге ответственен за команду перед всеми выше стоящими) и последнее простое, но очень важное – уважать свою команду в любых плоскостях (например, никогда не опаздывать на встречи или, если не успевает, предупреждать).

Почему этот «мягкий» навык я включаю в начальный список? Я думаю, на любом этапе профессионального развития человек должен стараться приобретать те навыки, которые наиболее актуальны в данный момент времени. Когда только начинаешь путь бизнес-аналитика, то почти нет жестких навыков, которыми ты можешь выделиться и помочь команде или проекту. И команда (проектная или БА) может оценивать тебя именно по мягким навыкам, которые, в свою очередь, могут существенно ускорить и улучшить приобретение жестких навыков. И так как я уже упомянул слово «команда», становится логичным, что первый и ключевой навык должен быть связан с командой. Не может быть сценария, когда у бизнес-аналитика нет команды, так как процесс создания продукта или проекта невозможен без команды. И соответственно бизнес-аналитик, который является хорошим (а лучше «отличным») командным игроком, – это то, на что команда будет смотреть в первую очередь. Команда может сказать: «Да, этот бизнес-аналитик ещё новичок и не очень разбирается в БА-специфике, но он отличный командный игрок – мы им довольны».

Почемучка

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

Управленец временем

Вот и последний из упомянутых «мягких» навыков – тайм-менеджмент или управление временем. Этот навык особенно важен и сложен для бизнес-аналитиков, поэтому его развитие следует начинать сразу же с начала карьеры. Что такое тайм-менеджмент простыми словами? Я бы описал его как способность человека в определённой обстановке (например, на работе) и в данном контексте (проектном, продуктовом, коммуникативном, командном и так далее) выполнять свои задачи (активности, процессы, артефакты) максимально эффективно с точки зрения распределения времени на задачи, которые нужно выполнить. Ключевая фраза «максимально эффективно» означает, что на все задачи затрачивается минимально возможное время при получении максимальной пользы/ценности от их выполнения с максимально возможным качеством. «Минимизация временных затрат» как показатель эффективности участвует, думаю, во всех сферах труда и личной жизни.