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