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

Полная версия

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

Настройки чтения
Размер шрифта
Высота строк
Поля
На страницу:
4 из 4

Планирование включает:

•      определение ключевых компонентов объема работ;

•      предварительные оценки и распределение по фазам/спринтам;

•      составление и верификацию roadmap (дорожной карты проекта);

•      выявление рисков и технических/организационных зависимостей;

•      согласование с заинтересованными сторонами;

•      построение общего нарратива: «что будет сделано», «в какой последовательности», «кем» и «зачем».


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


Декомпозиция объема работ


Этот навык я подробно описывал в своей предыдущей книге – с акцентом на разбиение задач в ежедневной операционной деятельности. Сейчас я расширяю его до уровня проектного мышления: Декомпозиция объема работ – это умение BA разбить крупный блок работы на логически связанные и управляемые части, так, чтобы обеспечить эффективность планирования, исполнения и контроля.


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


Также важно понимать: разный уровень декомпозиции может использоваться на разных уровнях управления. Например, для roadmap достаточно фреймворков и фаз, а для задач в спринте – уже нужны конкретные функции.


Контроль объема работ


Определить объём – недостаточно. BA должен уметь удерживать всю картину в актуальном состоянии. Контроль – это непрерывное наблюдение и вмешательство при необходимости. Это означает:

•      отслеживание прогресса по всем компонентам скоупа;

•      актуализация roadmap и декомпозиции при появлении новых требований;

•      оперативное выявление рисков и влияния изменений на уже запланированные части;

•      постоянное присутствие в роли координатора, например между командой, PO и внешними участниками.


Я считаю, что по-настоящему зрелый BA способен в любой момент времени сказать: «Я знаю, какая часть объема завершена, какая – в процессе, а какая – под риском».


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


Пример из практики


На текущем проекте мы создаём мультимедийное приложение в стиле Netflix. Я работаю с командой, ответственной за фронтенд и запуск платформ.

У меня есть чёткая декомпозиция скоупа на трёх уровнях:

•      фазы проекта

•      ключевые майлстоуны

•      фичи/функции

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


Применение


Много лет назад (а точнее – спустя три года моей работы в роли бизнес-аналитика в первой ИТ-компании), я уже достиг уровня зрелого РО BA. Формально моя должность звучала как Senior Business Analyst, и в этот момент мне доверили участие в новом клиентском проекте.


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


Он не просил юзер-стори. Не интересовался, сколько времени займёт discovery. Он хотел видеть чёткий и детализированный план объёма бизнес-аналитических работ с горизонтом в два года. Это был первый по-настоящему серьёзный вызов для меня как Пилота объема работ. Что я сделал:

Шаг 1. Построение карты типов работ

Я начал с оценки типов работ, которые могут потребоваться:

•      написание различных типов требований (data model, functional, UI/design),

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

•      онсайт и оффсайт активности,

•      анализ и документация,

•      поддержка дев/QA-команд,

•      валидация артефактов с заказчиком,

•      организация процессов,

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


Это был мой “базовый инструментарий” – всё, что BA должен уметь делать в течение жизненного цикла подобного проекта.


Шаг 2. Декомпозиция продукта


Затем я перешёл к декомпозиции самого продуктового решения. Я разбил будущий каталог на два уровня компонентов, которые предстояло:

•      проанализировать,

•      описать,

•      выдать в виде конкретных артефактов и решений.


Это создало основу для дальнейшей детализации оценки.


Шаг 3. Маппинг работ на продуктовые компоненты


Далее я построил таблицу, в которой по горизонтали разместил продуктовые компоненты, а по вертикали – типы бизнес-аналитических работ. Это дало мне удобный и наглядный способ разложить проект по полочкам.


Шаг 4. Оценка в часах


Затем началась самая кропотливая часть – я вручную оценивал, сколько часов заняла бы у меня каждая из этих задач.

Я учитывал не только время на саму работу, но и мой собственный уровень производительности. Так, например:

•      конфигурация клиентского каталога требовала механической и повторяющейся работы, которую можно было отдать BA с базовыми навыками;

•      я сравнивал, сколько часов такая задача заняла бы у меня, и выводил коэффициент, насколько медленнее (в среднем) будет работать менее опытный аналитик;

•      на основе этого я рассчитывал количество BA, которое потребуется, чтобы уложиться в 2-летний график проекта.


Пример: если мне нужно было бы 100 часов, а BA с базовыми навыками делает ту же работу в Х раз медленнее, значит, нужно уже например 150 часов, а не 100. Далее я определял сколько человек потребуется, чтобы конфигурация не стала узким местом проекта.


Шаг 5. Финализация и защита плана


На основе всех этих данных я собрал план работ на два года, с точной оценкой в часах, распределением задач, типами исполнителей и учётом рисков. Я презентовал его Delivery Manager’у – и получил одобрение. Проект начался уже с чётким и структурированным скоупом, что дало мне контроль в дальнейшем.


В итоге, по завершении проекта, план отклонился от фактического выполнения всего на 19–20%. Для первой серьёзной попытки планирования с таким уровнем точности это был отличный результат – и с тех пор этот подход стал моей профессиональной опорой в любых проектах.


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


Множество неизвестных на старте планирования

Одна из ключевых сложностей при планировании объема работ – это большое количество неизвестных. Это естественно: когда создаётся что-то новое, невозможно сразу иметь полное понимание типа, содержания и объема задач. Что бы ни было запланировано – всегда появятся дополнительные элементы и корректировки.


Сложность усиливается тем, что людям по природе ближе ясность и определенность. Но с новым скоупом так бывает редко. При этом сроки на начальное планирование часто крайне сжаты – нужно начинать работы «ещё вчера».


Типичный ответ на вопрос: «Сколько времени займёт создание этого компонента?» – «Сначала нужно провести дискавери». Однако на полноценную дискавери (2–8 недель) зачастую нет времени, несмотря на её важность.


В таких ситуациях мой подход – сфокусироваться на достижении результата с разным уровнем точности. Даже неточный план – это всё равно план. Он даёт старт, создаёт основу для движения, снижает неопределённость.


Что я делаю:

•      Использую текущие знания и опыт, чтобы составить черновой план

•      Разбиваю задачи на части и прикидываю длительность каждой

•      При необходимости обращаюсь к внешним источникам (включая интернет и внутренние базы знаний)

•      Закладываю буферы и указываю на зоны риска


Главная задача в условиях неопределённости – как можно быстрее встроиться в контекст и собрать максимум исходных данных. Это ускоряет переход от тумана к структуре.


Определение критериев декомпозиции


Любое планирование требует декомпозиции – разбиения продукта на составные части. Однако нет универсального критерия, подходящего под любой продукт. В зависимости от контекста я выбираю один или комбинирую несколько критериев, например:

•      По технологическому стеку: фронтенд, бэкенд, интеграции, аналитика

•      По функциональным блокам: логин, каталог, корзина, заказ, оплата

•      По типу работ: анализ, дизайн, реализация, тестирование


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

1.      Провожу сессии с командой, где обсуждаю возможные критерии и получаю обратную связь

2.      Изучаю максимум контекста: цели продукта, тип команды, ограничения


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


Баланс: время – ресурсы – цели


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

•      Мало ресурсов → нужно больше времени

•      Меньше времени → нужны дополнительные ресурсы

•      Недостаток времени и ресурсов → нужно сокращать объем


Мой подход в таких ситуациях:

•      Оценка рисков по каждому из параметров

•      Раннее предупреждение менеджеров, особенно по вопросу ресурсов. Лучше заявить о дефиците квалифицированных специалистов в самом начале, чем пытаться закрыть пробел на поздних стадиях

•      Гибкость целей – обсуждение возможности перераспределения объема работ или приоритизация задач


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


Вопросы для самопроверки


Вопрос 1:


Ты как БА подключился к проекту, где уже работают три бизнес-аналитика. У каждого из них – своя Scrum-команда, отвечающая за определённый компонент нового веб-сайта по продаже обуви. Тебя назначают ответственным за компонент “Каталог продуктов”. К концу недели твоя команда ожидает:

•      План разработки компонента,

•      Разделение на логические части,

•      Подготовленные пользовательские истории на следующий спринт.


Вопрос:

Какие действия ты предпримешь на этой неделе, чтобы качественно подготовиться к обсуждению с командой в пятницу?


Вопрос 2 (продолжение):

Прошло четыре спринта (два месяца). Возникла проблема: команда отстаёт от плана на 35%. На ретроспективе команда сообщает, что пользовательские истории требуют постоянных уточнений у аналитика, из-за чего тратится лишнее время и не удаётся завершать запланированный объём. При этом оценки спринтов команда считает адекватными.


Вопрос:

Проанализируй ситуацию. Укажи по две возможных причины / проблемы / зоны улучшения в каждой из следующих областей:

•      Планирование объема работ

•      Декомпозиция работ

•      Контроль выполнения работ


Применение вне работы


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


Я фиксирую всё: планы по профессиональному развитию, важные личные цели, семейные задачи, хобби. Обычно набирается от 7 до 12 крупных направлений. После этого я распределяю их по кварталам – важно видеть, в каком периоде какие крупные фокусы будут у меня в жизни.


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


Завершающий этап – создание записи с чекбоксами в приложении. Этот список всегда под рукой: на телефоне и на ноутбуке. Я регулярно сверяюсь с ним, отмечаю выполненное, корректирую приоритеты.


Планирование стало для меня не просто инструментом – это способ жить осмысленно. Квартал за кварталом я выстраиваю траекторию жизни: ставлю цели, разбиваю их на шаги, отслеживаю движение. И да – поставить галочку рядом с выполненной задачей – это маленькое, но очень личное удовольствие.


Ремарка


Хочу поделиться своим образом мышления относительно этого навыка.

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


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


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


И, в завершение фраза, которая только что пришла в голову: план – это эффективное начало любой активности человека.

Презентер решений

/Solution Presenter/


Описание


Как часть своего профессионального роста результато-ориентированный бизнес-аналитик начинает развивать способность эффективно представлять решения, чтобы заинтересованные стороны могли увидеть реальное влияние предлагаемых результатов на бизнес-цели. Описывая этот навык, я бы хотел сделать особенный акцент именно на словосочетании в названии – “презентер решений”. Речь идёт именно об умении представлять решения.


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


Основными компонентами процесса и навыка презентации решений являются:

•      подготовка презентации,

•      понимание решения,

•      ведение презентации,

•      обработка результатов презентации.


Поэтому определение этого навыка я сформулировал бы следующим образом:

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


Если меня спросить оценить сложность этих компонентов по 10-балльной шкале, я бы сказал:

•      подготовка – 10 баллов,

•      понимание – 4 балла,

•      ведение – 6 баллов,

•      обработка – 2 балла.


Хотя сложность выполнения компонентов разная, важность всех компонентов высокая.


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


Подготовка

Подготовка презентации решения включает в себя несколько ключевых пунктов:


1. Анализ целевой аудитории, для которой будет сделана презентация.

Важно понимать, кому будет адресована презентация, чтобы правильно выбрать формат, объём и участников презентации. Да-да, участников-презентёров может быть несколько, и это задача бизнес-аналитика – определить их состав и зоны ответственности каждого.

Целевая аудитория – это те люди (стейкхолдеры), для которых подготавливается презентация решения. Аудитория может быть однородной (например, сотрудники одного отдела, одной роли, одного домена) или разнородной (например, менеджеры C-уровня, операционные работники, конечные пользователи, представители разных департаментов).

Да, целевая аудитория может измениться в последний момент перед началом презентации, но базовый анализ и понимание должны быть проведены заранее.


2. Формат презентации как артефакта.

Формат зависит от целевой аудитории и типа решения. Например, если аудитория смешанная – менеджеры и технический персонал, – формат, скорее всего, должен быть тоже смешанным: сочетание верхнеуровневого визуально-понятного описания с техническими деталями в нужных местах (например, архитектурная диаграмма).

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

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

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

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


3. Объём презентации как артефакта.

Это универсальный параметр для любой презентации, но в случае презентации решения он особенно критичен. Объём должен быть заранее продуман, соответствовать длительности встречи и включать акценты на ключевых частях.

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

Объём также зависит от формата презентации как процесса. Если ожидается активное взаимодействие с аудиторией, на каждый раздел должно быть запланировано определённое количество минут. Также нужно заранее предусмотреть блок вопросов и ответов в конце.

Самое важное – из моего опыта: лучше сделать презентацию короче с запасом, чем на 30 слайдов, зная, что времени хватит только на 20.

Если на встрече говорят: «Оставшиеся слайды, пожалуйста, изучите офлайн», – это плохая практика. У аудитории сразу возникнет вопрос: «Если 30% мы должны смотреть офлайн, то зачем тогда тратить время на остальные 70%, которые тоже можно было бы посмотреть в своём темпе?»


4. Формат презентации как процесс (ведение презентации).

Важно учитывать не только презентацию как артефакт (документ в PowerPoint, Miro, Confluence и т.п.), но и сам процесс презентации:

•      Что будет озвучено БА, а что останется на слайде?

•      Какие инструменты будут использоваться?

•      Кто будет помогать?

•      Кто отвечает за документирование вопросов и решений?


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

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


5. Определение ожидаемых результатов.

Самое главное – заранее определить, к какому результату должна привести презентация. Каждый участник должен понимать, зачем она проводится, и к какому решению всё должно свестись.

И, как при выявлении требований, важно достичь единого понимания в команде.

Примеры:

•      БА считает, что цель – обсудить e2e-процесс;

•      технический лидер – что надо выбрать стек для фронтенда;

•      архитектор – что главное – определить список интеграций.


Без выравнивания этих ожиданий презентация может превратиться в хаотичное обсуждение, а не в точку принятия решения.


Понимание решения


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


1. Терминология

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

Конец ознакомительного фрагмента
Купить и скачать всю книгу
На страницу:
4 из 4