Бизнес-анализ от а до я: гид для начинающих
Шрифт:
После подготовки всех функциональных требований я проверил, что все они имеют связи в матрице отслеживаемости требований. На тот момент я контролировал наличие связей между бизнес и функциональными требованиями. Я проверял, чтобы каждое функциональное требование соответствовало по крайней мере одному бизнес-требованию, то есть чтобы не было «бесполезных» функциональных требований, на которые будет потрачено время, но которые не нужны клиенту. Также я проверял, чтобы не было бизнес-требований, которые не указывают на какие-либо функциональные требования, т.е. чтобы я не упустил ничего, что хочет клиент. После того как все требования были написаны, я отправил их на проверку ведущему БА, который дал несколько комментариев. Я внес правки и, в итоге, функциональные требования были отправлены на просмотр и утверждение клиенту.
Утверждение
Вы, возможно, сейчас задаете мне вопрос: «Зачем их отправлять, если уже обсудили бизнес-требования и понятно, что нужно делать?» Тут всё просто – каждый проект имеет контекст, который позволяет определить критерии, по которым просмотр и утверждение требований требуется клиентом или нет. В моем случае было несколько критериев: 1) это был проект, использующий водопадную методологию разработки, когда сначала подготавливается абсолютно вся документация, прежде чем начать создавать продукт/систему разработчиками. Соответственно, очень важно с самого начала определить даже на функциональном уровне, что хочет клиент. 2) Проект имел конкретные сроки, в которые мы должны были создать продукт. Поэтому именно утверждение клиентом требований позволяло быть уверенным и застрахованным от рисков изменения требований при старте разработки, так как утвержденные клиентом требования уже не могли быть изменены.
А в целом это моя рекомендация и очень полезная практика – без привязки к критериям, всегда иметь процесс утверждения требований, который в дальнейшем спасет вас от рисков и проблем в середине проекта, когда клиент вдруг решит, что создается не та система, которую он хотел. У меня было в будущем достаточно ситуаций, когда моя настойчивость в утверждении требований спасала от финансовых потерь со стороны моей компании-поставщика продукта. Например, клиент подписывал требование, а уже во время разработки продукта через 6-8 месяцев внезапно приходил какой-то другой представитель клиента и говорил: «Нет, это так не должно работать – меняйте на вот такую логику». В ответ на это мы доставали подписанный документ его же компанией и сообщали, что любые изменения будут делаться только через запрос на изменение, который будет стоить денег. И тут хочу упомянуть еще один важный момент – когда вы пишете функциональное требование, в котором описано парой слов, что «можно указать номер дома», это может показаться не важной деталью системы. Но когда в середине проекта придет клиент и скажет: «Ой, забыл, допишите еще номер дома, блока или промышленной зоны», тогда вы оцените влияние этого изменения, и оно, возможно, будет стоить десятки тысяч долларов для клиента, потому что, чтобы добавить информацию о промышленной зоне, нужно будет изменить визуальный интерфейс приложения, модели хранения данных, интеграционный интерфейс и возможно даже сторонний модуль адресов. И тогда вы подумаете: «Ох, как хорошо, что я утвердил функциональные требования с клиентом!» И естественно, я не имею в виду вербальное утверждение (просто в разговоре с клиентом). Я говорю о документальном утверждении – через электронную почту, в электронной системе управления разработкой/задачами или подписании бумажного документа.
Пока я ждал утверждения или комментариев от БА по итогам обсуждения списка функциональных требований с клиентом, я сосредоточился на написании дизайна к требованиям. Дизайн выглядел примерно так же, как я уже описывал на первом этапе, поэтому не буду еще раз описывать, что я делал. Я старался постоянно улучшать качество дизайна. Но вот завершая первый же дизайн, я столкнулся с новой интересной задачей.
Как вы, наверное, помните, в примере дизайна функционального требования последним пунктом я описывал раздел "изменение данных". Когда я написал дизайн к своему первому функциональному требованию по адресной системе и дошел до этого раздела, то я задал себе вопрос: «А какие данные и где будут меняться?» И я понял, что у меня появилась новая задача, отличная от тех, что были, когда я просто помогал своему БА создавать дизайн функций в существующем компоненте. Отличие проявилось в том, что теперь я занимался созданием компонента (Адресная система) «с нуля», и соответственно никакой модели данных в данный момент не существовало вообще в системе и никто о ней не знал. Я понял, что это я тот человек, который ее должен создать. То есть буквально взять приложение для моделирования данных и начать ее рисовать, а затем перевести в общепринятый формат документа.
Моделирование требований
«Пойду» по порядку: что такое эта модель данных в общем и в контексте
Почему наличие или создание модели данных важно при подготовке такой вещи, как книга или любой системы? На примере книги я бы построил такую логическую цепочку, и всё выглядит довольно прозрачно:
1.Цель создания почти любой сущности в нашем мире – это её использование человеком.
2.Использование человеком означает использование функций предмета или системы.
3.Функции предмета или системы – это как раз та функциональность, которую мы также опишем для системы или для книги. Для книги главная функция – это «читать книгу».
4.Но чтобы читать что-то, нужно иметь этот предмет или систему физически, то есть должно быть описание и модель того, как будет выглядеть книга и из каких объектов она будет состоять.
5.К тому же, все части книги должны иметь правильные свойства. Представьте, если из нашего примера мы укажем свойство «вес» для объекта обложки равное 30 кг? Вряд ли такую книгу будет возможно читать!
6.Также все объекты должны быть связаны между собой правильными связями. Мы ведь не хотим, чтобы страницы были склеены между собой, а текст указан только на обложке, а не на листах книги.
Из этого примера, я думаю, становится видно, что невозможно планировать детальное описание функций чего-либо без создания модели данных. От модели данных зависит корректность создания функционального дизайна, дизайна пользовательского интерфейса, разработки кода и возможностей системы для конечного пользователя. От согласованности и логичности созданной модели данных в дальнейшем будет зависеть расширяемость системы и её адаптивность к изменениям. Именно с помощью создания модели данных можно корректно оценить интеграционные возможности между разными системами, ведь в любой интеграции основную роль играет правильная синхронизация информации между двумя системами. Информация равна данным.
Какие инструменты я использовал для создания модели данных? Я использовал профессиональную программу для моделирования/проектирования, Архитектор Корпорации (EA = Enterprise Architect), для создания модели. В настоящее время доступно множество более простых программ, о которых я расскажу позже. В EA я создавал всю модель, а затем экспортировал её в обычный документ Word, который можно было переслать кому нужно – БА, разработчикам или клиенту для ознакомления. Также функциональность EA позволяет автоматически генерировать этот документ, который является частью дизайна системы. Что интересно, EA позволяет выгружать созданную модель непосредственно в код, создавая необходимые объекты, связи и их свойства прямо в нужном месте в кодовой базе у разработчиков.
Вот как выглядел процесс создания модели в общих чертах: я пересмотрел функциональные требования и начал проектирование объектов адресной системы. Естественно, основным объектом был «адрес». От этого объекта, например, наследовались такие объекты, как «адрес офиса» и «юридический/биллинговый адрес». «Наследовались» здесь означает тип связи между объектами, при которой нижестоящий объект наследует все свойства вышестоящего объекта и дополняется своими уникальными свойствами.
Если объект «адрес» включал атрибуты, такие как «улица» и «номер дома», то я предполагал, что «адрес офиса» также будет иметь эти атрибуты. Для атрибутов я также определял свойства, например, тип атрибута (число, текст или список значений) и его обязательность для заполнения, то есть он не мог быть пустым.