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

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

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

Утверждение требований

Вы, возможно, сейчас задаете мне вопрос «да зачем их отправлять, если уже обсудили бизнес требования и понятно, что нужно делать?» Тут всё просто — каждый проект имеет контекст, который позволяет определить критерии, по которым просмотр и утверждение требований требуется клиентом или нет. В моем случае было несколько критериев — 1) это был проект, использующий Водопадную методологию разработки, когда сначала готовиться абсолютно вся документация, перед тем как начать создавать продукт/систему разработчиками. Соответственно, очень важно с самого начала определить даже на функциональном уровне, что хочет клиент. 2) Проект имел конкретные сроки, в которые мы должны создать продукт. Поэтому именно утверждение клиентом требований позволяло быть уверенным и застрахованным от рисков изменения требований при старте разработки, так как утвержденные клиентом требования уже не могли быть изменены.

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

Пока я ждал утверждения или комментариев от БА по итогам обсуждения списка функциональных требований с клиентом, я сконцентрировался на написании дизайна к требованиям. Дизайн выглядел примерно так же, как я уже описывал в шаге 1, поэтому не буду еще раз описывать, что я делал. Я старался постоянно улучшать качество дизайна. Но вот завершая первый же дизайн я столкнулся с новой интереснейшей задачей.

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