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

Вот такое короткое письмо, из которого каждый понял, что от кого и когда требуется. Очень рекомендую его использование в любых ситуациях и для любой аудитории. Естественно, уровень детализации и стиль написания зависят от типа целевой аудитории. Если это менеджерское совещание, то формат должен отображать только суть, простым и понятным языком. Если же это созвон с техническими командами и проектными менеджерами, то можно и нужно описать детально принятые решения с техническими ключевыми моментами и детальным планом действий. Если есть сомнения в правильности понимания каких-то пунктов, то перед отправкой митинг-ноутс очень рекомендую напрямую уточнить у нужного человека, что именно имелось в виду. Если доступа у вас нет или прояснение невозможно, потому что клиент сказал что-то, что вы поняли, но возможно не на 100% правильно, то в самих митинг-ноутс обязательно нужно указать или оставить примечание к неясному пункту: «Пожалуйста, поправьте или дополните этот пункт, если есть неточности», и можно также упомянуть конкретного человека.

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

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

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

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

Атомарность требований позволяет затем значительно упростить решение любых вопросов, например, с клиентом, когда появляются запросы или пожелания к дополнению или изменению требований. Приведу простой пример, с которым я сталкивался: клиент может просмотреть и согласиться с требованиями №2 и №3, но пояснить, что для №1 он хотел бы уточнить, из каких частей приложения можно будет инициировать создание адреса. В этом случае, возможно, потребуется изменение только одного требования, в то время как остальные два уже будут утверждены. Этот пример, конечно, условный и масштабируемый – у меня было 50, 100 и даже 300 таких требований, и их простота и самодостаточность обеспечивали эффективный процесс проверки и утверждения с клиентом. С другой стороны, я мог помечать часть требований как готовых к проверке, а другую часть – как требующих прояснений.

После подготовки всех функциональных требований я проверил, что все они имеют связи в матрице отслеживаемости требований. На тот момент я контролировал наличие связей между бизнес и функциональными требованиями. Я проверял, чтобы каждое функциональное требование соответствовало по крайней мере одному бизнес-требованию, то есть чтобы не было «бесполезных» функциональных требований, на которые будет потрачено время, но которые не нужны клиенту. Также я проверял, чтобы не было бизнес-требований, которые не указывают на какие-либо функциональные требования, т.е. чтобы я не упустил ничего, что хочет клиент. После того как все требования были написаны, я отправил их на проверку ведущему БА, который дал несколько комментариев. Я внес правки и, в итоге, функциональные требования были отправлены на просмотр и утверждение клиенту.

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