Бизнес-анализ от а до я: гид для начинающих
Шрифт:
После проверки выполненной работы, мой наставник давал мне комментарии и указания, что именно нужно исправить и почему. Например, он показывал уже готовый и подписанный клиентом артефакт и объяснял, почему такой способ документирования является наиболее эффективным. Теперь давайте рассмотрим, чем именно я занимался в первые дни и недели и как выглядел мой обычный рабочий день новичка в роли бизнес-аналитика
Мой рабочий день был разделен на две основные активности: коммуникация с ведущим БА и работа с требованиями. Также была третья дополнительная активность – изучение систем и стандартов компании и продукта, которой я занимался лишь эпизодически, и в основном в контексте текущих проектных
В течение первых четырех недель моя работа состояла в документировании описания и дизайна небольших частей функциональных требований системы. Упоминание «небольших частей» не случайно – моя задача заключалась в описании ограниченного объема функциональности системы, что было оптимальным решением, учитывая мой начальный уровень опыта. Это позволяло эффективно сотрудничать с моим ведущим БА, который предварительно набрасывал и обсуждал со мной основные элементы функции. Он также объяснял, какие бизнес- и функциональные требования у нас есть на входе и что ожидается на выходе, включая дизайн требований и ожидаемый уровень детализации.
Давайте подробно опишу распорядок одного из моих рабочих дней в этот период. В последующих историях я также покажу, как изменились мои рабочие дни с постепенным профессиональным ростом, а какие аспекты остались неизменными.
Я прихожу на работу обычно между 9 и 11 утра. Эта гибкость в выборе времени начала рабочего дня – один из замечательных плюсов работы в ИТ-компании, в отличие от традиционного бизнеса, где часто требуется быть в офисе строго к определенному времени, даже если нет срочных дел или совещаний. В первые недели такая свобода была для меня необычной, но я быстро оценил это как серьезный мотивирующий фактор для эффективной работы – важно использовать рабочее время для выполнения задач в установленные сроки.
Первым делом я всегда проверяю свой ежедневник, где перечислены все текущие задачи и их статусы. Мониторинг и планирование задач – это ключевой инструмент эффективной работы и управления временем. Я осматриваю задачи, требующие внимания, и определяю, какой из них я займусь в первую очередь. Проверяю наличие потенциальных препятствий или блокеров для выбранной задачи, которые могут требовать вмешательства других лиц. Если такие препятствия существуют, я стараюсь запланировать обсуждение с моим БА в удобное для него время. Я делаю это сразу, не откладывая до тех пор, пока не столкнусь с трудностями из-за блокирующих задач. Эффективное планирование звонков и ключевых активностей занимает всего 5-15 минут, но позволяет мне спокойно работать дальше, зная, что важное совещание уже запланировано
Вторая задача или активность в моем рабочем дне – это звонок с моим ведущим БА-ментором, который может быть утром или вечером. Как я уже упоминал, на начальных этапах карьеры крайне важно синхронизировать формат, план, процесс и ожидания от своих активностей с ответственным за весь проект. Мы обсуждаем мои достижения за предыдущий день, возникшие вопросы и планы на текущий день. Получив отзывы от БА, я приступаю к своим ежедневным задачам.
Особенно важно, по моему опыту, проводить звонки и совещания в первой половине дня, желательно утром, чтобы максимально эффективно усвоить полученную информацию. За мои 10 лет работы у меня сложилось понимание, подтвержденное исследованиями, что сложные мыслительные процессы наиболее эффективно выполняются в ранние часы. Чем дольше человек находится в рабочем процессе, тем труднее ему воспринимать сложную информацию и
В контексте моих основных задач – звонков с ведущим БА и документирования дизайна – я стараюсь придерживаться этого подхода. Проведение звонков утром помогает мне максимально эффективно решать все вопросы и затем спокойно заниматься документированием. Если вечером мозг уже устал, завершить документацию становится гораздо проще, чем проводить активное обсуждение. Важно планировать так, чтобы на митинги и встречи приходить максимально собранным и эффективным. Это же правило применимо и к тем, кто работает с обеда до поздней ночи – принципы остаются теми же.
Затем я приступаю к документированию дизайна функционального требования, используя шаблон, который был обсужден с моим ведущим БА. Важно отметить, что наличие нескольких бизнес-аналитиков в проекте является значительным преимуществом. Это способствует созданию совместного подхода в работе, что, в свою очередь, снижает количество ошибок и повышает качество конечных артефактов через внутренние обсуждения и договоренности по различным темам, например, по выбору формата шаблона для документирования.
Перед тем как подробно описать, что такое 'документирование дизайна функционального требования', я кратко определю, что такое функциональное требование. Не углубляясь в технические детали, которые будут подробно разобраны в конце этого раздела, функциональное требование – это определенное свойство системы, позволяющее удовлетворять запросы пользователя. В большинстве случаев под 'пользователем' мы подразумеваем живого человека, который взаимодействует с нашей системой. Существуют, конечно, специфические технические проекты, где 'пользователем' может быть другая система или модуль системы, использующий функции другой системы, но эти сценарии мы пока рассматривать не будем. Когда пользователь взаимодействует с системой, она реагирует на его запросы и действия определённым образом. Ожидания от реакции системы на использование определённой функции и называются функциональным требованием. Поскольку сначала создаётся система, а затем пользователь начинает пользоваться её функциями, мы называем это функциональным требованием. Это требование к тому, как должна работать функция системы, иначе система не будет нужна пользователю, если она не соответствует его функциональным требованиям.
Теперь перейдём к документированию дизайна функционального требования. Для начала уточню, что я подразумеваю под 'дизайном': это описание, спецификация или план, который демонстрирует, как должна работать или выполняться функция, чтобы соответствовать функциональному требованию. Интересный факт: если вы зададите вопрос в англоязычной поисковой системе о том, что значит слово 'design', то вам покажут определения, упоминающие 'план' или 'спецификацию' и 'функцию', даже не связанную с ИТ-сферой.
Почему акцент на документировании дизайна? Всё просто. Основная цель бизнес-аналитика почти всегда заключается в подготовке документа или артефакта для команды разработчиков, чтобы они могли создать систему именно так, как её планирует использовать пользователь. Наличие только функционального требования без дизайна не даст разработчикам необходимой информации о том, что именно нужно создать. В моей 10-летней практике я не встречал случаев, когда было бы иначе. Хотя в интернете можно найти мнения, что в рамках некоторых 'гибких' методологий разработки, продукты создаются именно так – разработчикам передаётся только требование, и они каким-то образом создают то, что нужно.