Читать книгу Бизнес-анализ от а до я: гид для начинающих - - Страница 16

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

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

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

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