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

Михаил Бахрах, 2023

Книга предлагает всестороннее исследование профессии бизнес-аналитика ИТ, основанное на 100% практическом опыте автора, реальных сценариях и решениях. Автор, опираясь на десятилетний опыт работы в качестве бизнес-аналитика ИТ, делится исключительными знаниями, основанными на личных успехах.Роль бизнес-аналитиков ИТ объясняется простыми словами, что делает ее доступной не только для профессионалов в этой области, но также для тех, кто вне мира ИТ и стремится попробовать себя в бизнес-анализе.В отчете LinkedIn за 2020 год навык ИТ бизнес-анализа был классифицирован как пятый по популярности и востребованности.Независимо от того, начинаете ли вы свой путь в качестве бизнес-аналитика ИТ или ищете новые идеи для профессионального роста, эта книга обещает захватывающее путешествие!

Шаг 1 — начинающий БА

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

Начнем там, где я закончил описание пути своего профессионального становления как БА в предыдущей истории. Итак, в марте 2013 года я устроился на должность БА в свою первую ИТ компанию НетКрекер, которая занимается разработкой ИТ продуктов для телекоммуникационных провайдеров. Меня сразу же подключили в команду, которая создавала для клиента многокомпонентную систему поддержки бизнеса клиента. Мой основной плюс был в знании и опыте (как конечный пользователь) по операционному домену — система управления взаимоотношениями с клиентами (customer relationship management). И поэтому я начал работать над соответствующим компонентом, под руководством ведущего БА, который уже занимался этим компонентом некоторое время. Мне это очень понравилось, что сразу же меня подключили к реальным задачам, хотя и у меня был нулевой опыт в бизнес-анализе. Так же в дополнение к задачам по проекту естественно мне предоставили множество ресурсов для изучения непосредственно самого продукта, который компания разрабатывала — из каких модулей и компонентов он состоял, какая архитектура использовалась и так далее. И кроме продукта, так же важно было изучить и знать телекоммуникационные стандарты разработки продуктов. У меня проходили каждый день утром созвоны с ведущим БА, который объяснял мне задачу, которую мне давал и так же предоставлял примеры уже аналогичных задач решенных, чтобы я мог делать по аналогии (один из главных подходов БА кстати — создавать что-либо в первую очередь по возможности на основании существующих артефактов/шаблонов). Если в процессе выполнения задачи возникали вопросы, то я их записывал и созванивался дополнительно, например, раз в день с БА и обсуждал их. Мы проверяли прогресс выполнения моих задач постоянно — иногда один-два раза в день или обязательно на следующий день. Это важный принцип, который я использую и сейчас через 10 лет каждый день в работе со своими коллегами. Принцип: никогда не жди финальный результат по задаче, чтобы проверить качество — обязательно нужно делать промежуточные проверки, чтобы заранее определить отклонение от ожидаемого результата, обсудить их и исправить. Чем позже будет обнаружено отклонение, тем дороже будет его исправлять. «Дороже» я имею в виду в любом измерении — деньги, время, ресурсы. Когда мы проверили, что я сделал, то мой БА давал мне комментарии и уточнения, что именно нужно исправить и почему. Например, он показывал уже готовый и подписанный (клиентом) артефакт и объяснял, почему именно так наиболее эффективно документировать. Чем же именно я занимался в первые дни/недели и как выглядел мой обычный рабочий день новичка БА?

Мой рабочий день разделялся на две основные активности — коммуникация с ведущим БА и работа с требованиями. Была еще третья дополнительная активность, которую я упоминал чуть выше — изучение систем/стандартов компании и продукта. Но ею я занимался очень немного времени и в основном только когда возникала какая-то реальная связь с теми проектными задачами, которые я выполнял. Я всегда пользуюсь одним и тем же подходом последние (и сейчас) десять лет в плане приоритизация между реальными задачами и получением новых знаний — я изучаю что-то новое только, если я на 100 процентов уверен, что все мои задачи уже готовы или будут готовы в нужные сроки.

Примерно в первые четыре недели я делал один и тот же тип задачи: документирование описания/дизайна небольших частей функциональных требований к системе. Я специально добавил словосочетание «небольших частей» — задача была именно описать небольшую часть какой-либо функциональности системы. Так как опыта у меня не было, то давать задачу на описание всей функциональности было бы очень неэффективно. И у нас с моим ведущим БА получалась отличная коллаборация — он примерно набрасывал/рассказывал основные части, которые у нас будут присутствовать в функции. Потом объяснял мне, что мы имеем на входе — бизнес и функциональные требования и что ожидается на выходе — дизайн требований, а также ожидаемый формат и уровень детализации.

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

Я прихожу на работу, думаю к часам 9 или к 10, или к 11. И эта гибкость и свобода в выборе рабочего времени — это один из удивительных и приятных плюсов работы в ИТ компании (по крайней мере, где работал я и на БА должности), после того, как покидаешь мир обычного бизнеса, где довольно часто тебя беспричинно просят обязательно быть ровно в 9 или раньше в офисе, даже если никаких срочных дел/совещаний нет. Да, в первые недели для меня это было довольно необычное ощущение, но по лично моей оценке это очень серьезно мотивирующий фактор для эффективной работы — рабочее время важно именно для выполнения задач в поставленный/определенный срок.

Первой задачей у меня всегда идет проверка моего ежедневника, где списком записаны все открытые задачи и их статус. Мониторинг и планирование задач — это мощнейший инструмент эффективной работы и тайм менеджмента (этой темы я буду касаться на протяжении всей книги, постепенно добавляя больше и больше деталей и ценностей). Я проверяю требующие внимания (открытые) и «в процессе» задачи в этом списке. Определяю какой займусь. Проверяю, не записаны ли у меня какие-либо препятствия/блокеры к выбранной задаче, которые не связаны со мной и требуют прояснения/действий от кого-либо еще. Если такие есть, то я планирую в большинстве случаев звонок с моим БА в свободное для него время. Я это делаю сразу, а не планирую это после того, как дойду до момента, когда мне уже нечего будет делать из-за блокирующих задач. Планирование звонков и основных активностей — это задача, на которую можно потратить 5-15 минут сразу и потом спокойно работать, имея назначенный нужный митинг (meeting — встреча, собрание проводимое в любом формате. По телефону, через интернет, вживую) в календаре.

Второй задачей/активностью у меня может быть звонок с моим ведущим БА ментором. «Может» — в контексте, что может быть утром или например, вечером. Как я писал выше — на начальных этапах очень важно синхронизировать формат, план, процесс и ожидания от своих активностей с тем, кто ответственен за весь результат. Мы проговариваем, что я сделал вчера, какие вопросы возникли и какие планы на сегодня. Собрав отзывы от БА, я приступаю к своим ежедневным активностям. Самый важный момент этого пункта, который я хочу подсветить — я рекомендую именно в первой половине дня (а лучше утром) иметь звонки/совещания с нужными людьми, чтобы с максимальной пользой усвоить полученную информацию. За 10 лет работы у меня сложилось устойчивое понимание (знание?) о природе человеческого мозга (и, по-моему, даже какие-то ученые делали похожее исследование) в контексте корреляции работы с информацией разной сложности восприятия и рабочим временем. Сложные мыслительные процессы или активности наиболее эффективно выполняются в ранние часы, когда человек только начинает работать. Чем больше времени человек провел в работе, тем хуже он воспринимает более сложную информацию и выполняет более сложные активности. Есть даже такое выражение «обсудим на свежую голову» — так как обсуждать что-то под конец дня не эффективно. Вот и в контексте моих двух основных активностей звонков с ведущим БА и документирования дизайна я старался следовать этому подходу. Воспринимать, обрабатывать/анализировать информацию от кого-либо и принимать решения в короткие промежутки времени во время звонков/совещаний естественно намного и намного сложнее, чем в одиночку выполнять создание и документирование информации по дизайну требований. Поэтому я старался иметь звонки по утрам, чтобы ничего не упустить и максимально эффективно решить все открытые вопросы, а потом уже заняться документированием. Если мозг к вечеру уже перегружен, то снизить нагрузку или закончить документирование — не составит труда. А вот взять и отменить митинг или придти на него, но провести его только с 70-60-50 процентной эффективностью — вот это уже негативно повлияет на цели активностей. Я привел пример естественно в контексте обычного дневного рабочего дня. Но суть та же и для людей, которые по каким-либо причинам работают с обеда и до поздней ночи.

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

Сам процесс документирования дизайна может занимать разное время и объем. Одно требование может содержать дизайн в полстраницы формата А4 и занять 30 минут на написание. Дизайн другого может занять 10 страниц и неделю на написание. Так же есть разные форматы и подходы к дизайну, которые зависят от многих факторов, окружающего нас контекста. И вот эта активность и занимает примерно 80 процентов моего дневного рабочего времени в эти дни и недели. Документировал я дизайн простейшим и надежным способом — в обычном текстовом (MS Word) документе/файле. Никаких специальных дополнительных программ. Этот документ был в онлайн (online) доступе у моего ментора — он проверял мои дизайны и оставлял комментарии в файле, которые я проверял и делал правки. Непрерывный процесс документирования, комментариев от ментора и соответствующих обновлений от меня. Самое приятное в этом процессе было наблюдать, как количество комментариев с течением времени (дней/недель) уменьшается и уменьшается, отражая обратную прямолинейную зависимость к росту качества моей работы. Еще раз повторю про плюс работе в команде и особенно с ведущими БА на старте карьеры — когда ты доверяешь профессионализму своего коллеги, то определить и наблюдать за улучшением своих личных показателей качества становится очень легко, даже не читая сотни страниц книг и статей на тему «ключевые показатели продуктивности».

Скучно ли это создавать дизайн требований с утра до вечера неделями? Для меня это было фантастически интересно так как а) я создавал! — это один из главных двигателей и критериев моей удовлетворенности моей работой (я буду часто это повторять через книгу). Тот факт, что ты что-то создаешь — очень приятен! Главное прослеживать, пусть даже просто в своем воображении, цепочку связей между своей деятельностью и финальным итогом. Если я просто описал обычную кнопку, которая активирует что-то в системе — > я визуализирую это в глобальных масштабах так сказать — когда мою кнопку разработчики создадут в системе, которую потом протестируют и запустят для клиента, который предоставит эту систему в пользование своим пользователям, то пользователи/продавцы в магазине будут проводить покупки для клиентов, с помощью функции, созданной по моему дизайну. Пусть это ИТ система/приложение/программа, но почти в 99 процентах случаев программы нужны для внедрения в бизнес-процессы, а значит в повседневную жизнь кого-то. Значит кому-то я улучшил/упростил работу. б) наличие ментора/команды позволяет оттачивать своё мастерство каждый день — любой человек по своей натуре всегда старается найти причину и дать полезный комментарий к любой активности другого, когда его об этом просят. Если конечно только ему не лень и без разницы, но таких людей к себе в менторы лучше не записывать. Так о чём я? — о том, что каждый день написание дизайна не может быть одинаково, когда у вас есть комментарии от кого-то, а значит пункты к улучшениям. Не всегда комментарии могут понравиться (по факту они почти никогда не нравятся), но также одна из основных задач и черт хорошего БА это научится воспринимать эффективно критику, комментарии, отзывы и рекомендации к улучшению чего-либо. Под «эффективно» я подразумеваю: в первую очередь внимательно выслушать, потом проанализировать, применить к своей ситуации и принять решение — улучшит ли что-либо предложение, сделанное кем-либо. Моё внутреннее ощущение, что 70-80% рекомендаций, которые я получил за весь период мне помогли улучшить качество выполнения задач. Причем довольно часто сами комментарии могли не иметь прямого влияния на улучшение, но вот их анализ и применение к ситуации — именно сами действия помогали выявить совершенно другие «дыры» в создаваемом решении, на которые без этих комментариев я бы никогда не обратил внимания. Простой пример: я создаю небольшое описание реакции системы на нажатие кнопки пользователем. Потом коллега просматривает этот дизайн и оставляет комментарий «мне кажется выполнение открытия дополнительного поля по нажатию на кнопку должно быть описано отдельные сценарием». Так как функциональность кнопки минимальна я считаю, что разделять описание не надо, но я проверяю, что я написал. И нахожу важный «пробел» в описании функциональности кнопки — я не описал как должна работать кнопка при ее повторном нажатии. Отзыв в любом случае оказался очень полезным. в) в любой активности можно искать возможности улучшений и улучшения эти можно придумывать бесконечно в самой простой (такая существует???) активности/работе. Улучшения, которые будут по факту изменять кажущуюся однообразность работы и дней. Один из самых простых и эффективных мотиваторов к улучшениям, который я использую через всю свою карьеру очень прост. Следовать главному принципу любого развития (личностного, физического, профессионального и так далее) — закончив день спроси себя «а что я сегодня сделал лучше/эффективнее, чем вчера?» Если ответ есть, то мы развиваемся. Конечно, каждый день делать улучшения может быть сложно, поэтому периоды сравнений могут варьироваться. Но если вы не сравниваете результаты своего труда с предыдущими — то, как вы поймете, что что-то улучшается или может даже ухудшается в вашей экспертизе? И еще у этого мотиватора я обожаю факт того, что он всегда имеет психологическое влияние на ваше общее состояние по итогам проверки улучшений — если это окончание задачи, дня, недели, когда вы завершили какую-то активность и видите что создан артефакт следующего уровня качества (пусть даже всего лишь немного лучше) по сравнению с предыдущим, то это дает позитивный настрой, энергию на весь оставшийся день и на начало следующего дня/недели/месяца. Ну во всяком случае у меня это так — может я чрезмерно оптимистичен.

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

И немного про изучение требований и как я с ними работал. Требованиями я занимался как дополнительной активностью — усваивал, что это и как они создаются. Изначально требования я получал уже готовые в формате списка от моего ведущего БА. Я изучал документ с требованиями, которые он подготовил, потом документ проверил и подписал клиент, и возможно ведущий БА их дополнительно декомпозировал (разделял еще на несколько). У нас было два типа требований — функциональные и бизнес. Это и сейчас для меня является самым простым, логичным и последовательным разделением. Сначала идут бизнес требования к системе, которые формируются клиентом. Чаще всего, по факту, их создает БА в тесном взаимодействии с клиентом. Эти требования определяют границы решения, которое хочет клиент. Эти требования исходя из названия — это то что хочет бизнес. НО! Это всё-таки требования именно к системе, а не к бизнес-процессами или к определенной деятельности клиента. Обычно бизнес-требование — это одно предложение, написанное понятным для бизнес-клиента языком и в то же время, определяющее ожидания от системы. Например, «Должна быть возможность хранить информацию о клиентах» или «Оплата заказа в системе должна поддерживать оплату пластиковыми картами и с банковского счета». Мы видим здесь описание желания (по факту требования) бизнеса без каких-либо деталей о том, что, как и где. Но бизнесу/клиенту ведь важно именно это — поэтому длинный список таких требований создается и подписывается с клиентом, чтобы он был 100 процентов уверен, что это будет сделано. Все остальные детали попадают в функциональные требования. Функциональные требования, в данном контексте, были декомпозицией бизнес-требований. Они необходимы, чтобы уже с нужной точностью и детализацией определить, что же именно (какие функции) должна поддерживать система. Те функциональные требования, которые я изучал, выглядели как одно, максимум два предложения. Например, для бизнеса требования о возможности управления информацией о клиентах могло подготавливаться 100-200 функциональных требований. Одно из них могло звучать как «Система должна предоставлять пользователю возможность создать профиль клиента», другое «Система должна поддерживать в профиле клиента 10 следующих параметров о клиенте:….» И так далее. Из таких требований было однозначно понятно поддержка какой функции ожидается — Например, функция создания профиля пользователя. И это функциональное требование так же просматривалось с клиентом и подписывалось им. Потом вот такое требование попадало ко мне, и я создавал дизайн, как именно будет реализовано создание профиля клиента. Важно упомянуть что все бизнес-требования и функциональные требования были связаны между собой в отдельном документе, который назывался матрицей прослеживаемости/взаимосвязей (Traceability Matrix). Документ помогал быть уверенным, что все созданные функциональные требования действительно нужны и связаны с бизнес-требованием и наоборот, что все бизнес-требования имеют функциональную реализацию. Так как мы создавали серьезные большие системы для поддержки бизнеса телекоммуникационных компаний — только для одного модуля/компонента «система управления клиентами» могло быть создано 400-500 функциональных требований. При таких объемах информации с требованиями, создание документа, который хранит все связи между требованиями, было абсолютно необходимо. И были такие ситуации, когда именно этот документ помогал находить несоответствия в связях и избавляться даже просто от лишней ненужной работы — Например, когда находилось функциональное требование, которое по факту не было связано не с каким бизнес-требованием (и соответственно не было более актуальным). Или возможно бизнес-требование изменилось или было удалено по итогам недавних обсуждений с клиентом. Потихоньку я начал заниматься и сам написанием функциональных требований к новым появляющимся бизнес-требованиям, так как за 3-4 недели уже разобрался, как выглядит бизнес-требование, потом функциональное требование и как оно превращается в дизайн.

Про свои активности в течение рабочего дня я кратко рассказал, а теперь немного в другой плоскости хотел бы посмотреть на это и рассказать про непосредственно сами артефакты и конкретный пример, как из одного бизнес требования я создавал функциональное требования и потом документировал дизайн для этого требования и из каких частей состоял этот дизайн. Естественно, примеры ниже это выдуманные примеры, которые я создал для визуализации — описание бизнес и функциональных требований не содержат и не раскрывают никакой коммерческой информации. Мои личные ощущения сейчас — то, как я создавал функциональное требование и потом дизайн к нему по своей «природе»/структуре не сильно отличается от того, как я делаю это сейчас. Изменились инструменты, немного формат и терминология (стала более модная), но сама смысловая нагрузка, подход и акцент остались те же. Если бы сейчас я попал на проект с тем же проектным контекстом, методологией и условиями, то вполне вероятно я бы пошел тем же путем к созданию и написанию требований/дизайна, как и 10 лет назад. Итак, я уже работаю полтора-два месяца, как БА в моей первой ИТ компании и я уже начинаю создавать/писать сам функциональные требования для новых компонентов/модулей системы. В плане «новых» главная ценность для меня это то, что на меня также стала распространяться ответственность за создание требований на основании существующих бизнес-требований, которые заранее все уже подготовлены и подписаны с клиентом на все новые компоненты. У меня появляется задача создать функциональное требование и дизайн к нему.