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

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

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

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

Есть бизнес-требование, которое звучит как «Профиль компании должен содержать информацию о кредитоспособности компании» — то есть требование от бизнеса и клиента довольно прозрачно. При любых коммерческих, торговых операциях между компаниями, компания продавец при предоставлении товаров в рассрочку, должна проверять и быть уверенной в платежеспособности компании-покупателя. Для данного бизнес-требования я, возможно, напишу 10-20 функциональных требований, но здесь опишу только одно.

На основании данного бизнес-требования я создаю функциональное требование «ФТ-СУК-КР-1. Система должна предоставлять на главной странице профиля компании обобщенную информацию о кредитном статусе клиента включая следующую информацию: кредитный статус, кредитный рейтинг, текущие кредитные условия». Что это за «ФТ-СУК-КР-1»? Это уникальный идентификатор требования, который в дальнейшем будет использоваться для матрицы связей/отслеживания и для упоминания в любых других связанных с этим требованием документах. Так же правила создания идентификатора создаются таким образом, чтобы, зная их можно было легко определить, о чем это требование. «ФТ» — значит Функциональное Требование. «СУК» — название системы куда входит требование «Система Управления Клиентами». «КР» — название модуля/компонента внутри системы «Кредитный модуль». И конечно же номер требования. Текстовка требования может изменяться, но идентификатор — никогда. Само требование состоит из следующих важных пунктов: 1) «Система» — это простое, но важное слово, которое 100 процентов подтверждает, что именно наша система должна поддержать определенную функциональность. 2) «должна» — тоже ключевое слово в требовании, которое очень явно говорит, что система именно «должна» поддержать функциональность, а не «может» или «будет» предоставлять что-то. Это важно — всего одно предложение, но оно может стоить десятки тысяч долларов например, и малейшая неясность в написании может быть использована как заказчиком, так и исполнителем. Например, использование словосочетания «Система может…» — может трактоваться как не обязательная часть функциональности системы и читаться как «ну может система будет выполнять такую-то функцию, а возможно и не может». 3) «предоставлять информацию на странице…» — описываем «местоположение» и «что», чтобы точно определить, где будет находиться функция. 4) «следующую информацию:…» и в заключение я определяю какую точно информацию мы должны предоставлять, а именно какие параметры. Есть вероятность, что какие-то еще параметры будут добавлены или нет, если это будет доступно с точки зрения проектного контекста. Но вот эти три упомянутых параметры точно будут присутствовать. Ну вот функциональное требование и готово! Возможно, у вас возник вопрос «а откуда и как ты всего лишь на основании короткого и общего бизнес-требования решил написать такое функциональное требование? Откуда детали про где и что?». Первая часть ответа — понимание как, где и что частично появляется у меня как раз на основании моего доменного опыта, о котором я упоминал ранее в этой книге. Я много лет работал в бизнесе и был именно конечным пользователем множества бизнес-систем, которые почти всегда содержат примерно одинаковый набор параметров и функций (и как я говорил, это был один из критериев, по которым меня рассматривали на эту работу без ИТ опыта). Соответственно в нашей системе для клиента я предлагаю наиболее распространенный подход в данном случае к информации о платежо/кредитоспособности клиента. Вторая часть ответа — именно сейчас я описываю исключительно действия, связанные с документированием требований. На самом деле, естественно, существуют еще коммуникационные действия — такие, как обсуждение требований, обновлений требований и их подписание. Т.е. для моего только что написанного функционального требования я НЕ начну тут же документировать дизайн. Сначала будет внутреннее рассмотрение с моим ведущим БА, возможные правки, а потом будет обсуждение с клиентом и возможные правки от него и потом подписание требования. И только потом в я начинаю документировать дизайн к этому функциональному требованию.