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

Первым делом я всегда проверяю свой ежедневник, где перечислены все текущие задачи и их статусы. Мониторинг и планирование задач – это ключевой инструмент эффективной работы и управления временем. Я осматриваю задачи, требующие внимания, и определяю, какой из них я займусь в первую очередь. Проверяю наличие потенциальных препятствий или блокеров для выбранной задачи, которые могут требовать вмешательства других лиц. Если такие препятствия существуют, я стараюсь запланировать обсуждение с моим БА в удобное для него время. Я делаю это сразу, не откладывая до тех пор, пока не столкнусь с трудностями из-за блокирующих задач. Эффективное планирование звонков и ключевых активностей занимает всего 5-15 минут, но позволяет мне спокойно работать дальше, зная, что важное совещание уже запланировано

Вторая задача или активность в моем рабочем дне – это звонок с моим ведущим БА-ментором, который может быть утром или вечером. Как я уже упоминал, на начальных этапах карьеры крайне важно синхронизировать формат, план, процесс и ожидания от своих активностей с ответственным за весь проект. Мы обсуждаем мои достижения за предыдущий день, возникшие вопросы и планы на текущий день. Получив отзывы от БА, я приступаю к своим ежедневным задачам.

Особенно важно, по моему опыту, проводить звонки и совещания в первой половине дня, желательно утром, чтобы максимально эффективно усвоить полученную информацию. За мои 10 лет работы у меня сложилось понимание, подтвержденное исследованиями, что сложные мыслительные процессы наиболее эффективно выполняются в ранние часы. Чем дольше человек находится в рабочем процессе, тем труднее ему воспринимать сложную информацию и выполнять сложные задачи. Существует даже выражение «обсудим на свежую голову», подчеркивающее, что вечером обсуждение важных вопросов может быть неэффективным.

В контексте моих основных задач – звонков с ведущим БА и документирования дизайна – я стараюсь придерживаться этого подхода. Проведение звонков утром помогает мне максимально эффективно решать все вопросы и затем спокойно заниматься документированием. Если вечером мозг уже устал, завершить документацию становится гораздо проще, чем проводить активное обсуждение. Важно планировать так, чтобы на митинги и встречи приходить максимально собранным и эффективным. Это же правило применимо и к тем, кто работает с обеда до поздней ночи – принципы остаются теми же.

Затем я приступаю к документированию дизайна функционального требования, используя шаблон, который был обсужден с моим ведущим БА. Важно отметить, что наличие нескольких бизнес-аналитиков в проекте является значительным преимуществом. Это способствует созданию совместного подхода в работе, что, в свою очередь, снижает количество ошибок и повышает качество конечных артефактов через внутренние обсуждения и договоренности по различным темам, например, по выбору формата шаблона для документирования.

Перед тем как подробно описать, что такое 'документирование дизайна функционального требования', я кратко определю, что такое функциональное требование. Не углубляясь в технические детали, которые будут подробно разобраны в конце этого раздела, функциональное требование – это определенное свойство системы, позволяющее удовлетворять запросы пользователя. В большинстве случаев под 'пользователем' мы подразумеваем живого человека, который взаимодействует с нашей системой. Существуют, конечно, специфические технические проекты, где 'пользователем' может быть другая система или модуль системы, использующий функции другой системы, но эти сценарии мы пока рассматривать не будем. Когда пользователь взаимодействует с системой, она реагирует на его запросы и действия определённым образом. Ожидания от реакции системы на использование определённой функции и называются функциональным требованием. Поскольку сначала создаётся система, а затем пользователь начинает пользоваться её функциями, мы называем это функциональным требованием. Это требование к тому, как должна работать функция системы, иначе система не будет нужна пользователю, если она не соответствует его функциональным требованиям.

Теперь перейдём к документированию дизайна функционального требования. Для начала уточню, что я подразумеваю под 'дизайном': это описание, спецификация или план, который демонстрирует, как должна работать или выполняться функция, чтобы соответствовать функциональному требованию. Интересный факт: если вы зададите вопрос в англоязычной поисковой системе о том, что значит слово 'design', то вам покажут определения, упоминающие 'план' или 'спецификацию' и 'функцию', даже не связанную с ИТ-сферой.