реклама
Бургер менюБургер меню

Михаил Бахрах – Бизнес-анализ от а до я: профессионализм без усилий (страница 4)

18

Мышление или подход:

1. Взаимодействующая автономия / Collaborative Autonomy: самоорганизация в сочетании с эффективным взаимодействием с командой позволяет результато-ориентированному бизнес-аналитику работать независимо, но при этом оставаться в гармонии с командой для достижения результатов, соответствующих или превосходящих ожидания заинтересованных сторон.

2.Мастерство исполнения: управляемый исполнитель (Ты можешь это сделать? – Да, если объяснишь мне, что нужно.) / Execution Mastery: Guided Performer: ориентация на результат проявляется в готовности аналитика выполнять задачи на основе чётких инструкций, гарантируя, что действия соответствуют целям и вносят вклад в достижение измеримых результатов.

3. Уверенное любопытство / Искусство вопросов / Curious Confidence/ Questioning Excellence: я не стесняюсь задавать вопросы: стремление к ясности через вдумчивые вопросы помогает результато-ориентированному бизнес-аналитику принимать обоснованные решения и минимизировать риски, фокусируясь на создании ценности.

4. Целостность понимания (Я не даю объяснений, если сам не понимаю или не знаю) / Integrity of Understanding: такой подход гарантирует, что каждое решение и результат основаны на глубоком понимании, подчеркивая стремление к надежным, ориентированным на результат решениям.

5. Операционный мыслитель (Принятие оперативных решений) / Operational-level thinker: развивая способность управлять оперативными решениями, результато-ориентированный бизнес-аналитик гарантирует, что любые действия остаются в соответствии с более широкими целями, поддерживая фокус на создании ценности в повседневной деятельности.

Вот и закончилось общее описание, и я думаю пора углубиться в детали.

Продуктовый горизонт: владелец компонента (или набора функций)

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

Когда БА начинает работу, у него есть на входе бизнес-требования, которые должны на выходе превратиться в продукт. И как БА, я всегда держу в голове понимание о конечном продукте, за создание которого я ответственен. “Ответственен” – ОЧЕНЬ важное слово здесь! Именно это внутреннее “я ответственен за этот продукт” сильно влияет на получение удовольствия от работы, выполнение её эффективно и достижение отличных результатов.

Любой вид БА-деятельности или активности должен быть связан с конечным продуктом. Но, естественно, возможности и опыт / экспертиза БА должны соответствовать уровню продуктового горизонта. Это логично, что нельзя, например, взять начинающего БА (возможно, который работает как БА один-два года) и попросить завершить проект по созданию сложного продукта с нуля – например, коммерческого портала по продаже техники.

И моё видение о продуктовом горизонте ответственности результато-ориентированного БА (РО БА) – это уровень “владелец компонента”. Что это значит?

Любой продукт может быть разделён на компоненты. Например, упомянутый выше коммерческий портал может быть разбит на компоненты, как Вход / Регистрация пользователя, Каталог, процесс покупки и так далее. Соответственно, зрелый РО БА должен иметь опыт подготовки продуктового компонента от начала до конца. Это только часть продукта, но полноценная и готовая для интеграции в продукт. РО БА умеет и понимает, как правильно определить сложность компонента, как его декомпозировать, как его интегрировать в продукт, как максимально эффективно выдать продукт. БА вовлечён во все фазы определения компонента и его жизненного цикла до момента запуска.

И, естественно, здесь я не говорю про прямые и определённые каким-либо / или кем-то официальные обязанности БА. Тут есть множество участников, которые участвуют фактически в создании: бизнес-стейкхолдеры, разработчики, тестеры и множество других участников проекта. Нет, я говорю именно про личный подход БА к работе и к созданию продукта. Я лично для себя всегда держу в голове радостную (для меня, по крайней мере) мысль, которая двигает меня вперёд каждый день – “я создаю продукт”. Мой личный настрой. И уровень РО БА – это тот уровень, где оркестрация компонента продукта – это обязательная часть профессионального подхода.

Проектная вовлеченность: очень сознательный, надежный, и ответственный исполнитель.

Сам термин, думаю, ясно определяет, что означает эта характеристика.

Проектная вовлечённость БА также определяет его профессионализм и успешность завершения создания продукта. Если при создании продукта мы говорим про ИТ-систему или приложение, то под проектом подразумеваются процессы, правила и ресурсы, которые необходимы и используются для успешного создания продукта. И тут как раз подходит упоминание, которое я делал выше – в создание продукта вовлечена вся проектная команда. И именно люди являются ключевой составляющей любого проекта (да и вообще любого объекта на Земле – как физического, так и интеллектуального, неосязаемого). Уровень интеграции БА в проектный контекст играет также ключевую роль. Например, БА с чёткой идеологией “я создаю продукт” не сможет ничего “создать”, если он не может интегрироваться с командой.

И тут я как раз упоминаю про три критерия вовлечённости: сознательный, надёжный и ответственный исполнитель. Я понимаю и уже описывал в прошлой книге достаточно “мягких” навыков, которые ожидаются от БА и являются частью успеха работы в команде. Но сейчас я говорю именно, как бы я сказал, о критериях, а не навыках – о модели поведения РО БА, которая выражается в этих словах. Это важно как для самого БА, так и для проектной команды. Да-да, эти слова выглядят очень простыми – и они действительно таковыми являются, но… давайте каждое слово разберём в контексте проектной вовлечённости или активности.

Сознательный исполнитель

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

Пример:

Проектный менеджер подходит к БА и говорит:

“Завтра нужно организовать митинг с клиентом по презентации новой функции Х и оценке, насколько изменится планирование с её включением в объём работ по проекту.”

Поведение сознательного исполнителя БА:

БА быстро в голове прокручивает текущий контекст / ситуацию на проекте и говорит:

“Давай я запланирую этот митинг через неделю, так как похожую функцию мы планировали месяц назад, и тогда у команды разработчиков были подозрения на сверхсложность. Поэтому нет смысла презентовать завтра эту функцию клиенту, так как велики риски, что мы потом не сможем её запланировать и реализовать.”

Поведение не очень сознательного БА:

БА считает, что раз менеджер попросил, то нужно организовать митинг – и делает это без лишних вопросов.

(Пример без детального контекста, просто как иллюстрация.)

Надёжный исполнитель

Кажется, что “надёжный” пересекается с “ответственный” – или даже похожи – но я вкладываю разный смысл в эти слова. Один из примеров объяснения разницы:

надёжный человек часто бывает ответственным, но ответственный – не всегда надёжен. Например, сотрудник может быть очень ответственным, но ненадёжным, если он перегружен задачами и не всегда выполняет обещания вовремя.

Надёжный – это критерий или характеристика БА (или любого человека), которая присваивается ему субъективно другим человеком – любым участником проектной команды. БА получает эту характеристику через действия, которые приводят к результату, ожидаемому командой: подготовка артефактов, организация митинга, объяснение специфики функциональности и т. д.

Пример:

Команда попросила запланировать митинг, чтобы обсудить план работ на следующий спринт.

Надёжный БА заранее создаст митинг, чтобы команда выделила время и все участники подключились. БА подготовит повестку и список вопросов и заранее вышлет их команде.

Не очень надёжный БА, например, может создать митинг за день до его проведения – ограничив доступность участников. Или придёт без повестки / списка тем для обсуждения.

Согласитесь, тут вопрос не в экспертизе или профессионализме БА. Он может быть экспертом в артефактах, но просто из-за загрузки упустил подготовку.

Основные черты надёжного исполнителя:

• предсказуемость и устойчивость – команда знает, чего ожидать от работы с таким БА;

• исполнение обязательств без необходимости контроля – особенно ценно для высококвалифицированного БА.