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

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

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

Шаг 2 — отличный БА.

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

Через пару месяцев мой проектный БА оценил развитие моих навыков и способности и уже стал мне передавать на документирование требования и дизайн к целым функциям компонента системы. Это меня конечно же несказанно радовало, что и говорить! Это приятное ощущение, которое я описывал выше, когда ты всё лучше и чётче понимаешь, что ты именно создаешь что-то от начала до конца. Что же именно такое функция? Возьму тот же пример из предыдущего первого шага — у нас есть компонент системы, который называется “система управления информацией о клиентах”. Внутри этого компонента есть различные функции — создание профиля клиента, редактирование профиля клиента, просмотр и управление кредитной информацией о клиенте и много других. Внутри каждую функцию можно декомпозировать на множество подфункций или требований (2,3….И так далее). Одно из таких требований для функции про кредитную информацию мы и разбирали на предыдущем шаге. Соответственно функция — это определенный набор свойств и действий (как пользователя, так и системы), которые предоставляют конечному пользователю выполнить полноценное и завершенное действие с определенным ожидаемым результатом. Как я упомянул, например, функция «создать профиль клиента».

Я начал получать задачи по подготовке функций. Вариаций типов задач, активностей и ответственности стало больше — что отражало продолжение моего профессионального роста. Я чувствовал, что уровень сложности поднимается — теперь задача была не просто написать требование и задокументировать его. Теперь мне нужно было проанализировать требуемую функцию, декомпозировать, определить и задокументировать необходимые требования и дизайн, правильно связать все требования вниз и вверх в матрице требований, управлять статусом готовности и блокерами, и подготовить вопросы для стейкхолдеров(Stakeholders) на стороне клиента. Да, да! — “толпа” всего нового. И как следствие — в дополнение появились еще не только задачи связанные с функциями, но и общие профессиональные задачи, как следствие возросшей сложности: валидация и обслуживание (и изменение если нужно) информационной модели/структуры требований и дизайна и поддержание логичности; понимание работы модели данных; понимание формата работы с представителями клиента; создание спецификаций модели данных; понимание жизненного цикла разработки системы; и конечно же развитие дополнительных и необходимых «мягких» навыков. Столько всего…наверное сразу «раскрыл карты» о навыках и активностях, которые дальше буду описывать, но так вот — никаких секретов! Единственное я вижу упомянул новое слово «стейкхолдер» — поясню его и продолжим. Стейкхолдер это человек, который ожидает и будет иметь какую-либо выгоду и/или будет пользоваться ИТ продуктом, который я создаю. Для проектов компаний поставщиков сервисов или продуктов, которых нанимают другие компании — основные стейкхолдеры это всегда люди на стороне клиента, те кто ожидают готовый продукт. Это может быть всего один человек, который взаимодействует с сервисной компанией или множество людей на стороне клиента. Это люди разных уровней организации клиента — генеральный директор, его заместитель ИТ департамента, экономический отдел или отдельная проектная команда, которая курирует создание продукта. В большинстве случаев именно стейкхолдеры являются источниками входной информации о требованиях к продукту. И у них БА выявляет требования к системе/продукту. Позже мы детально рассмотрим БА навык “управление стейкхолдерами”.

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

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

На звонке мы определили, какие вопросы БА прояснит с клиентами, так как Например, были неясности в бизнес-требованиях, которые по своей природе и не должны быть подробно-детальными. Так же я получил ценное замечание, о котором совершенно не подумал — о интеграции моей функции с существующей в нашем продукте общей системой управления адресами. Так как адреса используются в множестве модулей/компонентов, то у нас и отдельный компонент был для этих целей. Мы обсудили, что нужен будет интеграционный маппинг (mapping — маппинг. В данном контексте это модель соответствия данных между разными интегрируемыми системами), а также мне нужно изучить нашу существующую систему управления адресами. И последним пунктом мы обсудили первые требования из декомпозированных, которые наиболее понятны и которые уже можно было бы начать документировать. Как итог звонка появились задачи для каждого, которые нужно выполнить и в определенный срок. БА попросил меня прислать итоги нашего звонка так же в письме. Как всегда, любое обсуждение планируемых задач с коллегой принесло много пользы — это большой плюс работы в команде (пусть даже и маленькой команды). В течение 30 минут я прислал митинг ноутсы (Meeting notes — МН сокращенно — значит записи с митинга) в письме, где включил информацию о том, что мы обсудили и что/кто должен сделать и когда. Я хотел бы сделать акцент на этом фантастически полезном и ценном артефакте «митинг ноутс» — им я пользуюсь все последние 10 работы в ИТ всегда и везде. Почему фантастически? Потому что этот артефакт мне помогал и помогает структурировать планы мои, команды, клиента; минимизировать риски возможных неясностей во время совещаний; защитить от возникновения любых видов споров как внутри команды, так и с клиентом по поводу любых договоренностей (которые указаны в этих записях); определить ответственные стороны/людей и сроки выполнения; и является самым надежным коммуникационным каналом по сохранению информации. Когда у каждого участника совещания есть, по сути, копия документа о договоренностях в его личной электронной почте, то потом очень сложно изменить эту информацию. Я лично отправляю МН всегда — даже когда меня никто об этом не просит. Это дает мне 100 процентную уверенность, что всем донесена информация, даже если на самом совещании кто-то был не очень вовлечен по каким-либо причинам — такой человек может потом найти время и прочитать МН позже. И за свою карьеру у меня было множество сценариев, когда МН артефакт спасал от масштабных проблем/споров на разных уровнях менеджмента между клиентами и моей компанией. Так, например, когда вопрос касается денег, а кто-то на стороне клиента упустил важный пункт, который был указан в МН, то на словах человек может в силу своей роли убеждать, что чего-то не было или что-то было неправильно понято. Но пересылка участнику МН письма 6-месячной давности, где он был в получателях и согласился со всем предложенным — решает проблему положительно почти всегда. Я приведу небольшой пример МН которое отослал, чтобы показать именно структуру МН письма — простую и очень эффективную.

Письмо, которое я отправил своему БА:

Тема письма: «Митинг нотсы от 10 июля: обсудить функцию управление адресной информацией»

Тело письма: «

Обсудили:

Требования к новой функции

Требования, которые можно брать в работу

Требования, которые нужно прояснить с клиентом (номера требований)

Экшн айтем (action items — пункты действий):

Прояснить бизнес требования с клиентом/// ведущий БА /// до конца недели (список требований прикреплен)

Изучить и включить интеграционный маппинг/// Миша /// следующие две недели.

Подготовить дизайн к требованиям А,Б,С, И так далее/// Миша /// эта неделя.

Дополнение: допиши если я что-то упустил.»

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

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

«Система должна предоставлять возможность создать адрес для клиента»

«система должна предоставлять возможность редактировать адрес для клиента»

«Система должна содержать следующие данные в адресе: тип адреса, страна, штат, город, улица, номер здания, номер офиса, индекс.»

Атомарность требований позволяет потом намного проще решать любые вопросы например, с клиентом, когда появляются вопросы или пожелания к дополнению/изменению требований. Простой пример, с которым я сталкивался — клиент может просмотреть и согласится требованиями №2 и №3, но сказать, что для №1 он хотел бы подтвердить, из каких частей приложения можно будет инициировать создание адреса. И в этом случае возможно потребуется изменение только одного требования в то время, как остальные два уже будут утверждены. Пример естественно относительный и масштабируемый — таких требований у меня было и 50, и 100 и 300 и их простота и самодостаточность позволяла иметь эффективный процесс проверки и утверждения с клиентом. С другой стороны, я мог помечать часть требований как готовых к проверке, а часть как требующих прояснений. После подготовки всех функциональных требований я проверил, что они все имеют связи в матрице отслеживаемости требований — на данный момент я проверял отслеживаемость/наличие связей между бизнес и функциональными требованиями. А именно я проверял, что каждое функциональное требование имеет по крайней мере одно бизнес-требование, которому оно требуется — то есть нет «бесполезных» функциональных требований, на которые будет потрачено время, но которые не нужны клиенту. И так же я проверял с другой стороны, что нет бизнес требований, которые не указывают ни на одно функциональное требование — т.е. что я не упустил ничего, что хочет клиент. После того как все требования были написаны, я отправил их на проверку ведущему БА, который дал немного комментариев. Я сделал правки и в итоге функциональные требования отправили на просмотр и утверждение клиенту.