Бизнес-анализ от а до я: профессионализм без усилий

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример:

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

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

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

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

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

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

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

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

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

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

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

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

Пример:

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

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

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

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

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

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

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

Ответственный исполнитель

Моё видение: ответственность – это внутреннее качество, связанное с осознанием своих обязанностей.

“Я делаю это, потому что понимаю, что должен, чтобы завершить проект успешно.”

Ключевые характеристики:

• самодисциплина и организованность,

• понимание последствий своих решений,

• готовность признавать и исправлять ошибки,

• следование установленным правилам и процессам проекта.

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

Вот как я измеряю свой уровень ответственности – критерии, которые, возможно, будут полезны и читателю:

1. Я всегда отвечаю в кратчайшие сроки – принятие ответственности.

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

Такой ответ может разблокировать всю цепочку людей, ожидающих информацию.

2. Я подтверждаю тип действия, который выполню – осознание ответственности.

Задачи бывают разные, и уровень ответственности может трактоваться по-разному. Например:

Менеджер говорит “Подготовь презентацию”. БА думает, что займётся только своей частью, но команда может ожидать больше.

Поэтому я сразу уточняю, что именно входит в мою зону ответственности.

3. Я сообщаю промежуточный статус – контроль ответственности.

Если готова часть – я сообщаю. Если задача завершена – тоже обязательно сообщаю.

Неочевидность завершения может создать задержки, даже если всё было сделано.

4. Я не “перекидываю” задачи напрямую другим – расширение ответственности.

Если задача адресована мне, я стараюсь не переадресовывать её, а взять под контроль и довести до конца.

Это позволяет мне развивать экспертизу, навыки и понимание бизнес-домена.

Я говорю: “Я проанализирую с командой и дам ответ через 4 дня” – вместо “обратитесь к другим”.

Итог:

Для БА эти критерии особенно важны, потому что именно БА – “мост” между потребностями бизнеса и конечным ИТ-продуктом.

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

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

Как я упоминал ранее, для каждого уровня будет два раздела:

1. Профессиональные навыки

2. Навыки или факторы мышления

Начнём с профессиональных и первого в списке —“Инициатор и создатель структур артефактов”.

Каждый навык я буду описывать в 4-5 подразделах, чтобы рассказать про него всесторонне. Названия навыков будут указаны также на английском – изначально я формулировал их именно на английском языке.

Инициатор и создатель структур артефактов

/Artifacts patterns driver/

Описание

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

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

Что это за навык?

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

Чем отличается артефакт от его шаблона?

Возьмём, к примеру, пользовательскую историю. Артефакт – это конкретная история с критериям приемки: «Как пользователь, я хочу…». Шаблон артефакта – это структура, определяющая формат будущих историй, включая метаданные (данные о данных). В этом случае – поля: заголовок, описание, критерии приемки, пользовательский интерфейс и т.д.

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

Главная ценность этого навыка – снижение усилий на создание артефактов (как личных, так и командных) при максимизации их пользы для всех заинтересованных сторон.

Также важно, что в английском названии навыка я специально использовал слово driver – инициатор. Такой аналитик не просто может разработать эффективный шаблон – он сам инициирует, продвигает и внедряет шаблоны в процессы. Он – идейный лидер в этой области. Его мышление настроено на то, что при старте любой активности (проекта, продукта, инициативы) он первым делом анализирует, какие шаблоны артефактов потребуются, и создает их с учётом специфики контекста. Это глубоко встроено в его профессиональную практику.

Важно отметить: я говорю про шаблонизацию любой аналитической деятельности, а не только пользовательских историй или требований. Примеры включают: заметки с митингов (meeting notes), планирование и проведение встреч, подготовку и проведение discovery-фазы (фаза исследования/выявления требований – ее мы обсуждали в предыдущей книге), отчётность – и всё остальное, где есть повторяющиеся, структурируемые элементы.

Применение навыка:

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

Ситуация: начинается новый проект, на котором есть 4 стрима/команды. Есть экселька/таблица с пачкой (800–900) функций от клиента. Есть продукт, который нужно трансформировать/кастомизировать под эту пачку требований. Дальнейшие шаги?

Решение: моя первая мысль – это проанализировать контекст. Я разбираюсь, какова цель предоставления этих требований от клиента. А цель, как первый этап, – это проверить соответствие требований плану и возможностям продуктовой компании, а также подтвердить общее понимание каждого требования между клиентом и исполнителем. В первую очередь мне становится интересно, в каком правильном формате эти требования могут быть представлены для команды, чтобы начать с ними работать. Я анализирую информационную систему для выбора и решаю в пользу системы, похожей на Джиру (JIRA), но позволяющей полностью создавать индивидуальные/кастомные конфигурации сущностей. Я не планирую сразу же обсуждать с командой, как и в каком формате мы будем писать дизайн требований, критерии приёмки. Первой задачей для меня является построить информационную модель артефактов таким образом, чтобы минимизировать сложность восприятия информации, а также максимально упростить навигацию/использование артефакта. Принимая во внимание контекст и цель, я создаю шаблон сущности одного требования, который содержит для начала следующие поля:

•      “название”, “описание” – базовые поля, чтобы понять требование;

•      “статус” – обязательное поле для отслеживания изменений/переходов в жизненном цикле требования;

•      “ответственный стрим/команда” – определение ответственных;

•      “доступность в продукте” – понимание, существует ли в продукте такая функциональность уже или нет;

•      “комментарии” – поле, где любой участник сможет оставить комментарии;

•      “категория требования” – категория требования для группировки.

Факторы, которые я учитываю:

•      возможности информационной системы/программы для создания записей;

•      контекст проекта;

•      чёткое определение цели или результата работы с конкретным артефактом.

Подход, который я использую всегда при подготовке шаблонов артефактов, – “обкатка” / “тестирование” модели как можно раньше. В данном примере выше я, после подготовки модели, не делаю экспорт всех 800 требований в новую систему и не прошу БА начать работать над требованиями. Первым делом, как только я создал первую версию шаблона, я тут же беру одно требование и пытаюсь сам создать его в системе – если мне всё понятно и все нужные данные хорошо ложатся в модель, то ок, и я могу идти “дальше”. И я подробно заполняю все известные данные по требованию в системе. И из моего опыта почти всегда появляется какой-нибудь упущенный момент. И это вполне ожидаемо – невозможно учесть всё и сразу, когда создаёшь шаблон артефакта. И в этом и плюс подготовки сначала шаблона артефакта – чтобы его “обкатать” и получить потом шаблон, который можно будет применять к 10, 100, 1000 сущностей без боязни сломать модель, если, например, какое-то поле не будет учтено.

Челленджи / сложности

В этом разделе я поделюсь сложностями, с которыми может столкнуться РО БА при применении этого навыка. Раз уж мы заговорили о навыке шаблонизации, то давайте «отшаблонизируем» и области, где могут возникать сложности. Я выделю следующие направления (подумал прямо сейчас, «из головы», что бы это могло быть): качество / время, фаза проекта, сложный организационно-командный контекст (сетап / setup / настройка/конфигарация).

Качество / время – думаю, это довольно универсальная зона челенджа, присущая практически всем навыкам и процессам. Например, в полноценной проектной реализации постоянно возникает вопрос: что выбрать – выдать компонент, функцию, продукт отличного качества, но с задержкой, или наоборот?

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