Всего за 199 руб. Купить полную версию
Первый шаг: Я опишу свой старт как БА в своей первой ИТ-компании, о чем я кратко уже упоминал в предыдущей истории. В это время я работал в роли помощника опытного БА, создавая небольшие фрагменты требований.
Второй шаг: Здесь я расскажу о периоде, когда я уже 'набил руку' в работе с требованиями и начал действовать как самостоятельный БА, способный описывать и управлять требованиями по определенной функции системы.
Третий шаг: В этом этапе я увеличил масштаб своей работы до уровня компонентов системы.
Четвертый шаг: На этом этапе я уже работал как product owner, ответственный за компонент системы.
Если говорить о временных рамках моего становления как регулярного БА, то это примерно 1.5 года, с марта 2013 года до конца 2014 года. Затем последовал период, когда я еще не был официально старшим БА, но уже выполнял его функции. Это продолжалось еще 4-6 месяцев до второй половины 2015 года. Таким образом, мне потребовалось около двух лет, чтобы стать хорошим начинающим старшим БА или просто отличным БА.
Время, необходимое каждому человеку для развития навыков, всегда индивидуально и зависит от множества факторов, включая компанию,
в которой работает человек, тип проекта или команды, используемую методологию, профессиональный уровень команды и так далее. Кому-то может потребоваться год, а кому-то четыре года, чтобы стать высококвалифицированным БА, готовым к переходу на следующую позицию. Единственное, что одинаково для всех, это ожидания 'контекста' (проекта, продукта, внутренней или внешней команды) относительно уровня владения навыками БА, и это является 'контрольной точкой' для понимания собственного уровня. Моя книга это именно та 'подсказка', которая помогает бизнес-аналитикам развиваться, понимая уровни и определяя навыки БА на основании моего опыта.
Теперь немного о уровнях в рамках позиции 'регулярный БА'. Первый и второй шаги я отнес к первому уровню БА, который я бы описал как 'стабильный и уверенный создатель требований'. Регулярный БА на этом уровне может свободно определить и задокументировать требования к конкретной функции системы это его основная задача и требование к уровню. Я намеренно привязал два шага развития к этому уровню, поскольку на начальном этапе карьеры БА важно сосредоточиться на ключевом навыке умении 'правильно' задокументировать требования. Что значит 'правильно', я объясню подробнее в описании этих шагов 1 и 2.
Второй уровень БА связан с третьим шагом и отражает способность БА работать на уровне функции системы, создавать логичные и высококачественные требования, а также профессионально взаимодействовать с командой и выполнять роль владельца функции. На этом уровне БА использует логически обоснованную структуру для документирования требований, понимает жизненный цикл требований, следит за рисками и знает ключевых клиентов (stakeholders), их зоны ответственности. При необходимости он также может общаться с клиентами при поддержке проектного менеджера или ведущего БА. Такой БА обладает знаниями о жизненном цикле проекта, он самоорганизован и умеет чётко и понятно передавать свои мысли, идеи, вопросы и решения.
Третий уровень отражает уже зрелого регулярного бизнес-аналитика, который, возможно, уже частично выполняет обязанности старшего БА и готов к переходу на новую позицию или должность. Такой аналитик работает также как владелец компонента системы. Он понимает и может заниматься оценкой своих времени и трудозатрат, а также знает, как оценки проводятся на уровне проекта. Этот аналитик разбирается в плюсах и минусах различных методологий, является доверенным лицом проектной команды и клиентов. Кроме того, такой БА хорошо разбирается в подходах к выявлению требований, включая знания о фазе discovery, умеет адаптироваться к изменениям в требованиях и эффективно планировать своё рабочее время в соответствии с приоритетами задач. Уточню очень кратко термин 'Дискавери фаза' (Discovery phase), так как я буду использовать его довольно часто, хотя подробно мы коснемся этого только в конце книги. Простыми словами, Дискавери фаза это обычно активность в специально выделенный временной промежуток для выявления самых первоначальных целей проекта или продукта, требований и границ планируемого решения. Это, как правило, самый первый этап любого проекта или продукта.
Зачем я написал про эти уровни внутри регулярного БА? Для меня важно показать с помощью этого относительного подхода к их определению, что нельзя просто рассматривать кого-то как обычного БА с конкретным набором навыков и опыта. Мы должны понимать, что уровни владения и виды навыков могут быть различны. Я использую 'относительный подход', потому что каждый может выбрать собственный способ разделения, и это всего лишь один из возможных вариантов. Один БА может только начинать писать качественные требования, в то время как другой уже полностью управляет жизненным циклом требований для конкретного компонента и фактически является почти старшим БА.
Итак, я описал, о чем будет эта история, из чего она будет состоять, и как я понимаю подуровни регулярного БА. Теперь мы погрузимся в самое главное и полезное это те навыки, которые использует бизнес-аналитик. Единственное, что осталось уточнить перед этим это определение навыка, типы навыков, связанные с ними активности и масштаб их использования в контексте бизнес-анализа.