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

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

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

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

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

/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. Терминология

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

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

2. Консистентность и согласованность

Я всегда проверяю, насколько презентация согласована: есть ли логика в структуре и порядке подачи? Все ли части решения представлены связно? Нет ли разрывов в повествовании между, например, функциональной частью и архитектурной?

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

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