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

Введение

Сравнение процесса написания художественных и научно-популярных книг

Всем привет! Вот я и вернулся к продолжению и следующей книге про бизнес-анализ. В самом-самом начале этой книги хочу поделиться мыслями, не связанными с бизнес-анализом. После того как я написал первую книгу, я решил, что мне нужно немного “развеяться” или отвлечься от профессиональной деятельности в моем новом и внезапно появившемся хобби – писательстве. Меня посетила фантастически увлекательная мысль написать… художественную книгу. Я реализовал эту мысль и написал художественную книгу. Естественно, я не буду рассказывать про нее здесь – ее легко можно найти на Литрес, на моей странице писателя. Здесь же я хотел бы сравнить эти два противоположных писательских направления и показать, что на мой взгляд, написание научно-популярной литературы намного сложнее, чем художественной.

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

С научно-популярной же книгой самое первое ограничение, с которым сталкиваешься, – это как раз полная противоположность художественной литературе: отсутствие свободы в создании материала. И это логично, так как описание создается про определенную профессиональную деятельность и навыки. Тут фантазировать не получится и в целом некорректно, так как делишься своим личным опытом и видением про то, что есть бизнес-анализ в моем реальном и практическом мире. А чтобы описать навыки, которые я считаю важными, их нужно сначала определить, а потом понять, как описать. Достаточно много работы уходит на создание структуры и предварительный анализ глав, частей, разделов, из которых будет состоять книга. То, что в книгах называется оглавлением, в научной книге я бы назвал структурой книги. Почему? Потому что если для художественной книги можно понемногу создавать оглавление, наполняя книгу придуманными частями одной истории, то вот с описанием научной книги это не работает, так как нужно заранее понять, где, как и что будет расположено – и в правильном порядке. Какие навыки и когда будут описаны, и на каком уровне. Например, для этой второй книги, только подготовка оглавления/структуры у меня заняла две недели. Это был очень важный этап для меня – понять, какие навыки, из моего опыта, относятся к тому или иному уровню бизнес-аналитика.

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

Синопсис предыдущей книги

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

Акцент книги был сделан на:

1. познакомить нового в бизнес-анализе читателя с этим миром и работой, которую большинство бизнес-аналитиков делает;

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

И текущая книга умышленно сделана как продолжение. Смысл, на мой взгляд, в том, чтобы дать читателю возможность выбрать ту книгу, которая ему больше подходит. Я думаю, тем бизнес-аналитикам, которые уже имеют серьёзный стаж, возможно, будет интересно читать только эту вторую книгу. Хотя, моё видение – я рекомендую и первую книгу всем, вне зависимости от уровня профессионального развития, – так как всегда, мне кажется, полезно перенимать/узнавать профессиональные практики других людей.

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

Про Книгу

В книге я расскажу о трёх уровнях бизнес-аналитика. “Уровень” определяется набором профессиональных характеристик (навыков), которыми обладает БА. И сейчас я лишь кратко опишу эти уровни, а детально мы начнём их изучать и разбирать буквально через несколько страниц и на протяжении всей книги.

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

Почему я решил использовать такой подход?

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

Второй фактор – отсутствие единой терминологии и градации должностей/уровней бизнес-аналитика в сообществе и в мире. Что я имею в виду? В каждой компании могут существовать разные уровни для должностей, связанных с бизнес-анализом. В одной компании – один или два уровня, в другой – пять или шесть. Поэтому я подумал, что не хочу привязываться к уровням должностей и общим навыкам, связанным с ними, которые существуют, например, в компании EPAM, где я работаю. И, например, так как они связаны только с моей компанией, то для любого читателя, кто не работает в моей компании, ценность описаний может быть неполноценной, а также будет иметь достаточно неразрешённых вопросов об истоках и причинах использования. Поэтому описание независимого опыта и знаний в компания-агностик формате, на мой взгляд, будет намного интереснее и полезнее.

Третий фактор – определить и показать/поделиться экстрактом понимания бизнес-анализ квалификации. Часто грань между уровнями профессионализма может размываться, когда мы говорим про один и тот же набор официальных навыков, связанных с бизнес-анализом. И через уровни бизнес-аналитика эти навыки остаются “в списке”, но, естественно и логично, должны расти и видоизменяться с ростом общего уровня.

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

Итак, какие три уровня будут представлены.

Outcome-Driven Business Analyst, или если перевести на русский – Результато-ориентированный бизнес-аналитик (РО БА). Этот уровень является как раз следующим на “лестнице” профессионального роста БА после начинающего Старшего БА, которым я закончил предыдущую книгу.

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

И вот тут как раз я говорю, что РО БА – это такой БА, который обладает нужными навыками, чтобы, как самостоятельная единица, выполнять бизнес-анализ активности и достигать конечного и успешного результата.

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

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

Следующий уровень я назвал Powerhouse BA. И, к сожалению, дословно я перевести его не могу, так как одного слова не существует (или я его не нашёл), чтобы передать значение, которое бы именно правильно подходило с профессиональной точки зрения. Вернее, если перевести совсем просто, то это могло бы звучать как «Мощный БА». Естественно, это слишком поверхностно и непонятно.

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

Это композиция характеристик, включающая в себя в том числе:

• силу (power – мощь) и влияние человека, которая является движущей силой, способной решать сложные задачи;

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

• ключевую роль – незаменимую фигуру, от которой зависит успех проекта/продукта.

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

И последний, третий уровень должности/позиции я назвал Effortless BA. Опять, как и с предыдущим уровнем, прямой перевод может не совсем точно отражать суть – БА без усилий. И имеется в виду, естественно, не факт того, чтобы быть человеком в должности БА без усилий. Это слово я позаимствовал из фразы, которая является моим девизом в работе каждый день и девизом, который я стараюсь применять к любой задаче. Эта фраза – Effortless Superiority, которая значит «превосходство без усилий». И тут имеется в виду не превосходство над людьми, а над задачами или препятствиями, которые возникают в нашей жизни ежедневно.

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

Соответственно, под Effortless BA простыми словами я подразумеваю то же самое – такой уровень экспертизы в бизнес-анализе, что любые самые сложные действия, задачи, решения на всех уровнях он успешно выполняет без видимых усилий.

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

Вот и всё краткое описание трёх должностей/позиций/ролей, которых мы детально коснёмся в этой книге.

Теперь кратко про целевую аудиторию и назначение этой книги.

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

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

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

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

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

И, читая книгу, опытный аналитик может получить два варианта результатов или пользы. Первый – это знания о новом интересном навыке: прочитать, записать себе, протестировать и развить навык в своей работе. Второй альтернативный результат – это прочитать про навык и подумать: “А ведь верно, и я уже давно использую этот навык и опытен в нём!” И да, это тоже отличный результат, потому что, из моего опыта, это очень полезно и мотивирует позитивно – когда изучаешь что-то, и это “что-то” идеально (или почти идеально) совпадает с твоим подходом/навыком, который ты уже используешь.

Структура книги

И последнее предисловие перед описанием уровней и навыков.

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

Итак, из каких разделов состоит каждый из трёх уровней?

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

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

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

Компетентность (Proficiency) – описание навыков, знаний и методов, которые человек использует для выполнения задач. Это про то, как именно задача выполняется. То есть набор конкретных БА-навыков.

Мышление (Mindset) – я уверен, что формат мышления в разных направлениях исключительно важен в работе БА. Это внутренний механизм, формирующий поведение и процесс принятия решений. Здесь я описываю навыки, связанные с нашим мышлением.

Из чего состоит описание каждого навыка или структура навыка?

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

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

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

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

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

Иногда у меня спрашивают: “Но ведь проверяющего – преподавателя нет, чтобы узнать правильный ответ?” Я отвечаю, что смысл не в нахождении правильного ответа – их может быть несколько или даже десятки, так как каждый человек индивидуален, и решение будет индивидуальное. Смысл в том, чтобы попробовать структурировано, логично и эффективно решить задачу/вопрос – и интуитивно спросить себя: “Правильно ли я решил задачу?” Без самообмана, а именно как испытание для самого себя. Если решил правильно, на твой взгляд, и нет ни капли сомнений – можно предположить, ты владеешь нужным навыком в определённой мере.

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

В чём смысл этого подраздела? Первая цель – это объяснить “на пальцах”, как навык применяется. А как это лучше всего сделать, если не с помощью примера из нашей повседневной жизни – событий или ситуаций, с которыми мы сталкиваемся? Моё видение – если предыдущие подразделы, возможно, оставят какие-либо вопросы у читателя, то пример, как я бы применил навык во внерабочей активности, должен уж точно “расставить все точки над i”. А если вопросов не останется, то, как я упомянул выше – это будет завершение навыка в развлекательном формате.

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

Хотя стоп! Последняя вводная ремарка именно для русскоязычной версии книги – за всё время работы я всегда использовал только английский язык в коммуникациях и документациях. Поэтому в этой книги будут присутствовать английские слова написанные на русском, а также написанные на английском (в основном названия навыков и перевод). Надеюсь, это не отпугнет читателя и если какие-либо слова не будут понятны, то их всегда можно загуглить. Умышленно я не стал переводить их так как именно написанные англоязычные слова я хотел использовать в контексте, где они были указаны.

1. Уровень: Результато-ориентированный БА

Outcome-driven BA

Введение

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

Я включил следующие характеристики этого уровня:

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

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

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

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

Организация и координация деятельности/активностей с командой/клиентом.

Планирование, декомпозиция и контроль объема работ (Scope of work).

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

Искусство объяснения – уровень «Контекстуальная ясность».

Мышление:

Коллаборативная автономия: профессиональный уровень (полная самоорганизация и высокая эффективность на уровне команды).

Мастерство исполнения: Ведомый исполнитель («Ты можешь это сделать?» – «Да, если объяснишь, как.»).

Уверенное любопытство/Искусство вопросов: Я не стесняюсь задавать вопросы.

Целостность понимания: Я не даю объяснений, если сам не понимаю или не знаю.

Операционный уровень мышления: принятие решений на уровне повседневных операций.

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

Большая часть навыков, которые я описываю в этой книге – это как… скажем так, это как компоненты «души» или «естества» бизнес-аналитика.

Возможно, немного примитивный, но пример: вот в вакансии Х написано требование о владении навыком «печатание текстов». Это конкретный профессиональный навык, например для позиции секретаря/помощника руководителя. Такой же, как «документирование артефактов» для бизнес-аналитика. Вот, например, есть этот навык «печатания» у человека и указан опыт – 15 лет. И печатает все 15 лет этот человек тексты с помощью наведения пальцев на клавиши и их нажатия. И в среднем скорость печати у него – 100 знаков в минуту. Но никто его не спросит про навык «адаптация печатания в зависимости от контекста», верно? А, например, если такой навык взять и проверить, то может оказаться, что человек этот печатает со скоростью 100 знаков в минуту, а мог бы печатать со скоростью 200 знаков в минуту, если бы с использованием навыка адаптации он бы изменял подход к расстановке пальцев, использовал дополнительные инструменты и так далее – чтобы увеличивать скорость печати и эффективность результатов.

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

Теперь давайте рассмотрим, как эти навыки связаны с общим описанием уровня.

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

1. Инициатор и создатель структур артефактов / Artifacts patterns driver: как результато-ориентированный бизнес-аналитик, создание и поддержание эффективных шаблонов артефактов (например, пользовательские истории, диаграммы процессов, документы требований) обеспечивает ясность, согласованность и возможность повторного использования артефактов в проектах, что напрямую способствует достижению измеримых результатов, соответствующих целям заинтересованных сторон.

2. Организация и координация активностей с командой или клиентом / Activities Setup and Orchestration (Team/Customer): способность организовывать и координировать BA-активности способствует согласованности команды и сотрудничеству с заинтересованными сторонами, прокладывая путь к достижению ощутимых результатов за счёт структурирования процессов, создающих ценность.

3. Пилот объема работа – Планирование, декомпозиция и контроль объёма работ (Scope of work) / Scope Pilot: разделение сложных объёмов работ на управляемые компоненты, даже на базовом уровне, гарантирует, что каждая часть работы непосредственно способствует достижению целей заинтересованных сторон, отражая ориентацию на результат.

4. Презентер решений / Solution Presenter: результато-ориентированный бизнес-аналитик начинает развивать способность эффективно представлять решения, чтобы заинтересованные стороны могли увидеть реальное влияние предлагаемых результатов на бизнес-цели.

5. Искусство объяснения / Explanatory Excellence – Contextual Clarity level: уровень контекстуальной ясности: чёткое объяснение, адаптированное к контексту, помогает заинтересованным сторонам понять связь между активностями аналитика и ожидаемыми результатами, обеспечивая согласованность и доверие к создаваемой ценности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я подразумеваю сознательность во взаимодействии с проектной командой и процессами: что каждый процесс и каждое взаимодействие разложены “по полочкам” в голове и 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 часа, может оказаться поверхностным, с нехваткой важных деталей и, как следствие, потребовать доработок уже в процессе, когда часть артефактов будет оформлена и начнёт «ломать» логику модели.

Фаза проекта – потребность в создании и работе с артефактами во многом зависит от того, на какой фазе проекта БА присоединяется. Часто бывает так, что аналитик подключается уже на поздних этапах – например, когда разработка продукта близка к завершению, и остаются лишь финальные штрихи. В таких ситуациях БА должен рационально оценить целесообразность создания шаблонов: где они принесут ценность, а где станут избыточными. Возможно, ближе к завершению разработки стоит сосредоточиться на шаблоне проверки требований для QA, а не тратить ресурсы на шаблоны описания требований, 90% которых уже реализованы.

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

Другой вариант организационной сложности – наличие внутри проекта команды бизнес-аналитиков, где каждый привык работать по своему устоявшемуся подходу. В этом случае РО БА, выступая как драйвер инициативы по шаблонизации, может столкнуться с сопротивлением или даже отказом от использования новых шаблонов. Здесь от него потребуется акцент на «мягких» навыках: построение сотрудничества, ведение переговоров, презентация решений и убедительная аргументация причин, по которым предлагаемые шаблоны принесут пользу всей команде.

Вопросы на самопроверку

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

Ниже я предлагаю два примера с контекстом.

Рекомендую:

а) сначала ответить самостоятельно – насколько внутренне ощущается уверенность в логике;

б) обсудить с опытным аналитиком;

в) если хочется, прислать мне ответы или доп вопросы в LinkedIn – с радостью поделюсь своим мнением.

Вопрос 1

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

Продукт – e-commerce портал по аренде автомобилей. Срок проекта – около двух лет.

На первом встречном митинге все БА сообщили, что требования оформляют в свободном стиле – каждый по-своему.

Вопрос:

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

1. Не создавать шаблон вовсе, адаптируясь под текущую практику.

2. Создать шаблон только для своего стрима.

3. Создать единый шаблон для всех стримов и убедить коллег в его полезности.

Вопрос 2

Контекст:

Ты заходишь на новый проект на самом старте. Первая фаза – дискавери по 20 новым компонентам/фичам, которые клиент хочет добавить в существующий OTT-продукт (в стиле Netflix). На всю фазу выделено 2 месяца.

Вопрос:

Какой формат шаблона для дискавери-артифактов ты бы предложил?

Какие 7 ключевых разделов ты включил бы в него, чтобы использовать универсально по всем компонентам?

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

• Насколько легко выстроилась логика?

• Были ли трудности в последовательности рассуждений?

• Насколько глубоко и чётко получилось декомпозировать ответ?

Я лично часто чувствую внутри интуитивный «профессиональный дискомфорт», если мой ответ не совсем выверен. Это полезный внутренний индикатор. Прислушивайтесь к нему.

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

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

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

После первого успешно проведённого дня рождения я задумался: «А ведь через год всё это снова повторится!» И тогда я решил проанализировать пройденные шаги, внести коррективы:

•      поменять порядок задач для повышения эффективности,

•      добавить недостающие шаги,

•      предусмотреть вариативность (например, список мест, где можно купить призы в зависимости от количества детей),

•      заложить временные буферы.

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

Возможно, кто-то спросит: «Зачем так серьёзно подходить к простому празднику?»

Мой ответ прост: профессиональные привычки естественно перетекают в повседневную жизнь.

Если это делает процессы лучше и создаёт больше радости для близких – разве это не замечательно?

Ремарка

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

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

Как именно их осваивать – путь индивидуальный.

Я делюсь своим опытом, подходами и примерами, надеясь, что они помогут вам открыть что-то новое.

Организация и оркестрация активностей

/Activities Setup and Orchestration (Team/Customer)/

Описание

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

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

Организация активности

Когда бизнес-аналитик начинает работу на новом проекте, его первая задача – понять, чем заняться, в каком порядке и почему. Способность быстро и точно сформулировать план действий на основе целей и контекста проекта – признак зрелого РО БА.

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

Я неслучайно говорю об организации активности, а не, например, о “разработке подхода к бизнес-анализу”. Почему? Потому что “подход к БА” – это чаще всего про структуру документов, формат взаимодействия со стейкхолдерами, механики декомпозиции и приоритезации. Это важно, но далеко не то, что критично в первые дни проекта. За всю мою карьеру мне ни разу не приходилось сразу документировать подход к бизнес-анализу в качестве самого первого шага. Всегда есть более срочные и ценные активности.

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

Организация активности – это:

•      Определение ключевых действий и их цели.

•      Определение приоритета на основе контекста.

•      Выстраивание логической последовательности действий.

•      Декомпозиция крупных задач до управляемого уровня (например, активности, которые можно завершить за день).

•      Постоянная сверка с участниками проекта: менеджером, командой, заказчиком.

Каждый новый проект я начинаю с прямых вопросов:

•      “Что от меня ожидается?”

•      “Какие задачи стоят в приоритете у команды?”

•      “Какие цели у заказчика?”

Это важная информация – фундамент для создания единого списка активностей, в котором будут учтены:

1.      Потребности команды.

2.      Ожидания заказчика.

3.      Моё собственное профессиональное видение как БА.

Оркестрация активности

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

Оркестрация – это комплексный навык, так же агрегирующий в себе:

•      Приоритезацию

•      Декомпозицию

•      Оценку усилий

•      Тайм-менеджмент

Эти навыки должны быть развиты на экспертном уровне. Почему? Потому что именно такая экспертиза позволяет не просто участвовать в активности, а эффективно ими управлять в режиме реального времени.

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

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

Применение

Совсем недавно у меня была ситуация, в которой потребовалось максимально проактивное применение навыка организации и оркестрации активности.

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

В какой-то момент вопрос был направлен прямо ко мне:

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

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

С этого момента и началось применение моего навыка вживую.

Я начал действовать не “со следующего утра” и не “после окончания митинга”, а в ту же минуту, как сказал “Да, я займусь этим”.

Вот как шаг за шагом я организовывал эту активность:

1. Понимание контекста – цель и артефакты

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

• Какова основная цель этой активности? (Зачем мы вообще делаем маппинг?)

• Какие артефакты ожидаются на выходе? (Что должно быть создано и в каком виде?)

2. Перехват управления митингом

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

3. Подтверждение плана – быстрый фидбэк-цикл

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

4. Декомпозиция и приоритезация

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

5. Старт активности – конкретика, сроки, исполнители плюс общее сообщение по плану на неделю

Так как сроки были предельно сжаты, в течение часа я подготовил и отправил всем участникам сообщение с:

• Четким описанием задач/активностей и важность и смысл.

• Конкретными сроками – План на неделю;

• Конечную цель;

Каждое взаимодействие – это мини-договор: кто, что, когда и где. Без этого не будет продуктивной активности.

Когда все участники понимают, к чему мы идём и как это связано с результатом, вовлечённость и синхронность значительно повышаются.

Хочу выделить ещё один принципиально важный момент:

Меня попросили организовать активность потому что у меня есть отличный опыт в использовании ИТ-системы, в которой нужно задокументировать артефакты. То есть формально ожидания были:

1.      Подготовить систему.

2.      Определить и запустить активности по наполнению этой системы.

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

Почему?

Потому что без активности – нет артефактов. Активности – первичны. Артефакты – следствие.

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

Я часто иллюстрирую этот принцип таким примером:

Если на красном проекте меня спросят – “Когда ты подготовишь артефакт, описывающий подход к бизнес-анализу?”

То мой ответ будет: “Я подготовлю этот документ в последнюю очередь. Когда проект станет зелёным.”

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

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

Организация активностей

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

Например, проект только начался. Команда разработки ожидает юзер-стори с оформленными требованиями для начала работы. В то же время клиент хочет провести новые Discovery-сессии. Как понять, чем заняться в первую очередь?

Здесь важно выявить возможные критерии приоритезации. Для Discovery-сессий это могут быть:

•      доступность клиента (например, только на этой неделе или только по вторникам);

•      стадия проекта (плановая discovery-фаза или дополнительные сессии уже во время разработки);

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

•      готовность материалов (если требуется серьёзная подготовка – или наоборот, ничего не нужно);

•      формат сессий (удалённо, на стороне клиента, в офисе), и другие параметры.

Для юзер-стори:

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

•      доступность команды (готова ли команда обсуждать детали в процессе или только во время планирования);

•      требования к оформлению (текстовые, графические и т.д.);

•      текущий статус бэклога (пуст или уже содержит готовые элементы).

После выявления критериев можно оценить относительную важность каждой группы активностей. Но и здесь возникает вызов: каждая заинтересованная сторона будет “тянуть одеяло на себя”. Если писать юзер-стори вместо проведения Discovery-сессий – клиент может быть недоволен. Если проводить только сессии – дев-команда может быть заблокирована без входящих требований.

И здесь задача БА – самостоятельно принять оптимальное решение.

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

Оркестрация активностей

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

Чем больше направлений работы – тем сложнее мозгу быстро переключаться и возвращаться в нужный контекст. Например, вы только что завершили приоритетные активности из группы A и переключились на новую группу B. Но через два дня вам нужно вернуться в A, чтобы заняться оставшимися задачами. Каждое возвращение требует времени на “перезагрузку” контекста.

Почему я фокусируюсь на этом именно в рамках роли бизнес-аналитика? Потому что именно в работе БА наблюдается самая высокая степень контекстного расслоения. В течение одного дня вы можете:

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

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

•      провести дискуссию о приоритетах бэклога,

•      участвовать в discovery-сессии,

•      оформить результаты в систему.

Я не эксперт во всех IT-ролях, но, насколько могу судить, ни одна другая роль не требует такой многомерности и гибкости мышления. Разработчик, QA, дизайнер – их направления более узко специализированы. БА же работает на стыке коммуникации, анализа, документации и организации взаимодействия.

Именно поэтому я считаю важным прокачивать навык оркестрации как можно раньше. Он кажется простым – “взял и спланировал” – но с ростом вашей зрелости как эксперта и масштабов проектов сложность этого навыка неизбежно возрастает. Его развитие требует постоянных тренировок и внимательного отношения к самому себе.

Вопросы на самопроверку

Полезные вопросы, чтобы посмотреть и оценить свои же размышления!

Вопрос 1:

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

Он рассказывает, что:

•      Раз в неделю у него было по одному митингу с каждой командой по текущему спринт-бэклогу.

•      Раз в две недели – митинги по планированию следующего спринта.

•      Два раза в неделю – встречи с ключевыми стейкхолдерами для уточнения и согласования требований.

•      Остальное время он тратил на подготовку и написание пользовательских историий.

Когда ты впервые подключаешься:

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

•      Стейкхолдеры говорят, что встречи с аналитиком неэффективны: те же вопросы можно обсудить в чате. Также жалуются на повторные вопросы по уже согласованным требованиям.

Вопрос:

Как ты, как результато-ориентированный бизнес-аналитик, организуешь и приоритезируешь свои активности, чтобы учесть оба типа фидбека – от команд и от стейкхолдеров?

Вопрос 2:

Ты работаешь как бизнес-аналитик на активном проекте и замечаешь, что почти каждый день заканчиваешь работу не в 18:00, а в 19:00–20:00.

Ситуация:

•      Дев-команды просят больше сторей на спринт.

•      QA-команда часто обращается с вопросами по тест-кейсам.

•      Митинги идут по расписанию.

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

Вопрос:

1.      Какие три вероятные причины твоей переработки?

2.      Какие три решения ты мог бы применить, чтобы эффективно работать в даже в более комфортном графике (например, с 9:00 до 16:00) и сохранять/улучшать результативность?

3.      Какие новые активности или изменения в текущем процессе могли бы улучшить ситуацию?

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

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

Мой простой и действенный подход:

1.      Записываю активность в электронный блокнот (например, Apple Reminders). Как только она «на бумаге», мозг освобождается от необходимости её помнить.

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

На это уходит 10–20 секунд. Всё. Активность запланирована – и можно двигаться дальше.

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

Ремарка

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

Важно: сокращение времени не должно снижать ценность результата.

Поэтому я стараюсь регулярно переосмысливать подход к активностям:

•      на уровне часа,

•      дня,

•      недели.

Я ставлю себе вызов: «А могу ли я достичь того же результата, но быстрее?»

Такой взгляд помогает не просто управлять временем, а усиливать свою эффективность – и на работе, и за её пределами.

Пилот объема работ – планирование, декомпозиция и контроль

/Scope Pilot/

Описание

После навыков, связанных с артефактами и активностями, мы подходим к следующему блоку – к навыку, который отвечает не столько на вопрос “как?”, сколько на “что?”. Что именно нужно сделать? Что включает в себя наш путь? Что составляет продукт или проект?

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

На этом уровне BA я называю этот навык “Пилот объёма работ” – человек, который не просто участвует в проекте, а ведёт его по траектории выполнения объёма работ, как пилот ведёт самолёт по маршруту. Он понимает, как построен скоуп, умеет навигировать в нём сам и способен помогать другим.

Этот навык складывается из трёх компонентов:

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

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

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

Это не последовательные стадии, а скорее параллельно применяемые практики, которые BA осваивает и комбинирует на протяжении всей жизни проекта. Обсудим кратко каждую.

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

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

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

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

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

•      составление и верификацию 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. Терминология

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

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

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

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