"Видеть целевую цепочку" – это навык, который требует практики и опыта. Я бы описал его как способность быть сфокусированным – в любой момент и при любых обстоятельствах вам должна быть ясна связь от начальной стадии до конечной цели всех задач и проектов. Если я вношу изменения в одно поле на странице веб-сайта, я должен понимать, как это повлияет на один из бизнес-процессов, в рамках которого используется этот веб-сайт, что в свою очередь влияет на результаты работы нашей команды. И последнее умение, которое звучит удивительно просто – умение принимать решения. Да, именно это умение напрямую влияет на эффективное использование времени. Колебания в принятии решений не допустимы. Это особенно просто, если всегда помнить и повторять себе, что откладывание или избегание принятия решения (что ведет к задержкам и, следовательно, к неэффективному использованию времени) можно преодолеть, напоминая себе: «В принятии решения всегда есть опции, из которых надо выбрать. С любой выбранной опцией я продвинусь вперед. Если что-то пойдет не так, я всегда смогу принять следующее решение, и это нормально». Таков подход. Не должно быть ситуации, когда мы говорим: «Я пока не могу принять решение», особенно если все перечисленные выше умения уже применены и использованы. Применение описанного подхода минимизирует любые сомнения. Вот и всё, что я хотел сказать про навык тайм-менеджмента; описать его не так уж и просто, но я постарался.

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

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

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

Что же такое функция? Возьмем пример из предыдущего этапа: у нас есть компонент системы под названием “система управления информацией о клиентах”. В этом компоненте существуют различные функции, такие как создание профиля клиента, редактирование профиля, просмотр и управление кредитной информацией о клиенте и многие другие. Каждую такую функцию можно далее разделить на множество подфункций или требований. Одно из требований, касающееся кредитной информации, мы уже рассмотрели на предыдущем шаге. Функция представляет собой определённый набор свойств и действий (как пользователя, так и системы), которые позволяют конечному пользователю выполнить полноценное и завершённое действие с определённым ожидаемым результатом. Как я упоминал ранее, например, функция "создать профиль клиента".

С течением времени я начал получать задачи по подготовке функций. Виды задач, активности и ответственность стали разнообразнее, что отражало мой продолжающийся профессиональный рост. Я ощущал, что уровень сложности моих задач повышается: теперь задача заключалась не просто в написании требований и их документировании. Теперь мне требовалось анализировать нужную функцию, декомпозировать её, определять и документировать необходимые требования и дизайн, корректно связывать все требования между собой в матрице требований, управлять статусом готовности и блокерами, а также подготавливать вопросы для заинтересованных сторон (stakeholders) со стороны клиента. Да, это был настоящий взрыв нового опыта! Как следствие, к задачам, связанным с функциями, добавились общие профессиональные задачи в связи с увеличившейся сложностью: проверка и поддержание (а при необходимости изменение) информационной модели/структуры требований и дизайна, поддержание их логичности, понимание работы с моделью данных, разработка спецификаций модели данных, понимание жизненного цикла разработки системы, а также развитие дополнительных и необходимых "мягких" навыков. Столько всего… наверное, я сразу «раскрыл карты» о навыках и активностях, которые буду дальше описывать, но так вот – никаких секретов! Единственное, я упомянул новое слово «стейкхолдер». Поясню: стейкхолдер – это человек, который ожидает и будет иметь какую-то выгоду от ИТ-продукта, который я создаю, или будет его использовать. В проектах компаний-поставщиков сервисов или продуктов, которые нанимают другие компании, основными стейкхолдерами всегда являются люди на стороне клиента, те, кто ожидает готовый продукт. Это может быть всего один человек, взаимодействующий с сервисной компанией, или множество людей на стороне клиента. Это люди разных уровней в организации клиента – от генерального директора до заместителя директора ИТ-департамента, экономического отдела или отдельной проектной команды, курирующей создание продукта. В большинстве случаев именно стейкхолдеры являются источниками входной информации о требованиях к продукту. Именно с ними БА выявляет требования к системе/продукту. Позже мы подробно рассмотрим БА-навык «управление стейкхолдерами».

С точки зрения процессов и активностей, у меня уменьшилось количество времени, которое я выделял ежедневно на обсуждения со своим ведущим БА, так как он стал более уверен в моем умении документировать требования и в моей профессиональности в целом. Иногда у меня даже не было ежедневных созвонов. Но вместо этого появились серьезные, хоть и нечастые, созвоны, где мы обсуждали мою подготовку документации по всей функции. Для описания активностей и навыков я возьму функцию, которой я занимался, – «Управление адресной информацией», которая является частью компонента «Система управления информацией о клиенте». Мне было поручено полностью подготовить необходимые дизайн-спецификации для разработки этой функции. Сначала мне нужно было прояснить бизнес-цели создания и понять, какие входные данные у меня есть. Единственным моим источником был мой ведущий БА, который работал и общался с командой клиента для выяснения любых вопросов. Я запланировал с ним звонок и начал готовиться к обсуждению. Заранее подготовил список вопросов, которые помогли бы мне определить границы задачи и прояснить неясные моменты. Я проверил существующие бизнес-требования, упоминавшие что-либо о адресной информации, и включил их в свой вопросный список, чтобы подтвердить, какие из них будут использоваться для создания функциональных требований. Я сделал черновую декомпозицию функции на набор предварительных функциональных требований.

Декомпозиция началась с базовой функциональности по созданию, редактированию, просмотру и удалению адреса. Затем я подумал, что поскольку система предназначена для бизнес-клиентов, они наверняка могут иметь несколько адресов. Поэтому я добавил требования по управлению списком адресов. Очевидно, потребуются требования к работе с полями/параметрами создаваемого адреса: какие поля доступны, каковы их свойства и типы. Например, некоторые поля – это простые текстовые поля, а другие представляют собой список, из которого можно выбрать только одно из предопределённых значений. Также я включил функциональность различения типов адресов – например, физический адрес и адрес для выставления счетов, при этом основные адреса могут отображаться также на главной странице профиля клиента. Плюс такого подхода к декомпозиции, прежде чем начать писать детальные требования и дизайн, заключается в том, что ты уже разделил одну большую задачу на несколько и можешь выбирать, с какой лучше начать. Когда начинаешь работу, ты уверен, что не будет пересечений в разных активностях, которые могут привести к необходимости постоянно переделывать уже готовые артефакты (требования, дизайн и т. д.). Теперь можно было и обсудить всё с моим БА.