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

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

Мы регулярно проверяли прогресс моих задач – иногда один-два раза в день, но обязательно на следующий день. Это важный принцип, который я по-прежнему использую в своей работе: никогда не ждать финального результата задачи для проверки качества. Обязательно нужно проводить промежуточные проверки, чтобы своевременно определить отклонения от ожидаемого результата, обсудить их и внести коррективы. Чем позже обнаруживается отклонение, тем дороже обходится его исправление – 'дороже' в любом смысле: в деньгах, времени, ресурсах.

После проверки выполненной работы, мой наставник давал мне комментарии и указания, что именно нужно исправить и почему. Например, он показывал уже готовый и подписанный клиентом артефакт и объяснял, почему такой способ документирования является наиболее эффективным. Теперь давайте рассмотрим, чем именно я занимался в первые дни и недели и как выглядел мой обычный рабочий день новичка в роли бизнес-аналитика

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

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

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

Я прихожу на работу обычно между 9 и 11 утра. Эта гибкость в выборе времени начала рабочего дня – один из замечательных плюсов работы в ИТ-компании, в отличие от традиционного бизнеса, где часто требуется быть в офисе строго к определенному времени, даже если нет срочных дел или совещаний. В первые недели такая свобода была для меня необычной, но я быстро оценил это как серьезный мотивирующий фактор для эффективной работы – важно использовать рабочее время для выполнения задач в установленные сроки.