2024-07-10 21:02

Стратегический анализ, discovery и Vision and Scope «на пальцах»

Бизнес-анализ

Сразу оговорюсь, что в заметке будут умышленные косяки с точностью и многогранностью описываемых вещей. Я знаю, что BABOK оперирует областями знаний, а не деятельности; допускаю, что происхождения терминов могут отличаться от описанных, если призвать дотошного историка-археолога; понимаю, что некоторые понятия значат иное, если смотреть на них при свете молодой луны в третью пятницу месяца. С учетом этих допущений — поехали.

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

В наших учебных материалах мы обычно описываем то, как это концептуально происходит, так:

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

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

- Бизнес-требования (1): цели, служащие точным индикатором реализации бизнес-потребностей организации/заказчика. Детальнее о том, что такое бизнес-потребности и бизнес-требования, можно посмотреть тут: https://youtu.be/Xfmid0muueo?si=rPKcWzUxYhvU-NQV.

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

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

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

Стратегический анализ или discovery на примере:

1) Клиент обращается за покупкой учебного курса ITMINE по бизнес-анализу — решение, которое он изначально считает нужным.

2) Если я выступаю как аналитик (а я стараюсь это делать в таких случаях), моя задача — узнать или помочь клиенту осознать потребности, стоящие за этим решением. К примеру, через диалог мы выходим на:

Вижу возможность в смене профессиональной деятельности на более прибыльную.

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

Устроиться в качестве IT БА в течение полугода с з/п не менее 300$.

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

- Самообучение
- Работа с индивидуальным ментором
- Курс (причем, например, с подвариантами: ITMINЕ vs прочее IT-обучение)

У каждого варианта будут свои плюсы/минусы, стоимость и иные важные для заказчика параметры. Анализируем их, обсуждаем и решаем, на чем остановимся. Допустим, это все-таки курс по БА от ITMINE (верный выбор! :))

5) Формулируем понятное всем сторонам видение (образ) итогового решения (2):

Решением является онлайн-курс группового обучения от ITMINE, который позволит заказчику как пользователю приобрести знания/навыки, достаточные для дальнейшего трудоустройства в качестве IT БА.

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

6)Скоуп решения (3). Курс по БА от ITMINE как решение уже готов — это не кастомная разработка под заказчика, плюс данное "коробочное" решение не нужно кастомизировать после покупки. Поэтому в контексте текущей задачи скоуп формулировать не видится нужным. Но для полноты картины опишем, что в решении есть/будет верхнеуровневыми мазками:

- Тренинги
- Слайдкасты с теорией
- Тесты
- Доп. литература
- Самостоятельная практика
- Итоговое собеседование

Вот и весь discovery — теперь и заказчик, и мы понимаем, зачем, что и в каком объеме будем делать. Конечно, в IT-проектах это несколько более сложный процесс, и на каждый кусок информации необходимо выйти (применяя при этом всякие модные техники и подходы), но подчеркну, что мы тут разбираем не как проводить процесс, а пытаемся понять основные концепции этой области.

Теперь давайте посмотрим на Vision and Scope — ключевой артефакт, который содержит выработанные на этапе стратегического анализа вещи. Говоря артефакт, я не подразумеваю в обязательном порядке документ, так что аджайлисты могут не напрягаться — это набор информации, которая может быть представлена документом, страницами в системе заметок или любым иным форматом.

Vision and Scope, как несложно догадаться, содержит всю описанную выше ключевую информацию и не только её — есть еще ряд деталей, которые могут полезно ее дополнить и пояснить, и на них мы остановимся подробнее, так как я знаю, какие вещи вызывают наибольшие сложности у новичков. Могу порекомендовать следующий формат Vision and Scope, который основывается на популярном шаблоне, заложенном еще Карлом Вигерсом:

1. Business Requirements

1.1. Background and Business Needs
1.2. Business Goals and Success Metrics

2. Solution Vision

2.1. Solution Options
2.2. Vision Statement
2.3. Business Risks
2.4. Business Assumptions and Dependencies

3. Solution Scope and Limitations

3.1. Major Features and Characteristics
3.2. Scope of Initial Release
3.3. Scope of Subsequent Releases
3.4. Limitations and Exclusions

4. Business Context

4.1. Stakeholder Profiles
4.2. Deployment Considerations

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

1. Business Requirements — раздел, ставящий конечной целью формулировку бизнес-требований — первой ключевой информации, которая важна по итогу стратегического анализа. Тут мы отвечаем на вопрос «Зачем?»
1.1. Background and Business Needs — здесь мы описываем бизнес-потребности организации и ситуацию, которая к ним привела (что не так; где корни проблем/возможностей; как работают ключевые процессы, с ними связанные). Наша задача по итогу — четко сформулировать проблемы или возможности, стоящие перед организацией/заказчиком.
1.2. Business Goals and Success Metrics — тут мы формулируем бизнес-требования на базе бизнес-потребностей. Как правило, они (бизнес-требования) выражаются в виде бизнес-целей. Важно понимать, что здесь мы ведем речь не про глобальные бизнес-цели организации, а про бизнес-цели как эффект от внедрения решения. Или по-иному: цели, которые организация ставит касательно изменения (термин из BABOK), способствовать которому нацелено решение.

Что такое Success Metrics или критерии успеха? Зачастую между бизнес-требованиями и решением, которое призвано их достичь, бывает пропасть:

То есть мы не можем сформировать простую причинно-следственную цепочку «Если решение будет нами как исполнителем реализовано и внедрено, то цель будет достигнута». Есть куча иных факторов, от которых зависит достижение цели. Например, я как исполнитель не могу гарантировать, что прохождение курса от ITMINE = устроиться в качестве IT БА в течение полугода с з/п не менее 300$. Мы поговорим об основных таких факторах дальше, но пока что нам может оказаться полезным сформировать критерии успеха решения на пути к достижению бизнес-целей. Т. е. какими с течением времени могут быть индикаторы того, что решение помогает достичь бизнес-целей? Как мы можем понять, что мы как исполнители сделали все в зоне нашей ответственности верно и как минимум часть, сделанная нами, ведет организацию в верном направлении? Я как автор курса могу сказать, например, что критерием успеха для меня является следующий:

Завершить курс с итоговым баллом успеваемости >=70%.

Для меня это сигнал о том, что решение играет верную роль в движении к бизнес-цели. Иначе — нет, завершение курса не поможет в достижении цели и нужно что-то менять — в самом решении или том, как им пользуются.

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

2. Solution Vision — каковы варианты решений и на чем мы по итогу остановимся. Отвечаем на вопрос «Что?».
2.1. Solution Options — если это актуально для проекта, приводим тут обсужденные варианты решений и их анализ/сравнение.
2.2. Vision Statement — формулируем образ решения, на котором остановились.
2.3. Business Risks. Бизнес-риски — это один из «вопросиков» на схеме выше, и рекомендуется совместно с заказчиком о них покумекать. Бизнес-риски — это что может пойти не так в плане достижения цели, даже с учетом готового и рабочего решения (т. е. на условной стороне организации/заказчика). Как мы уже обсуждали, реализация и внедрение решения далеко не всегда является единственным условием достижения цели. И если что-то еще может повлиять, то что конкретно и как?

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

2.4. Business assumptions and dependencies — бизнес-предположения и зависимости. Эта часть информации тесно перекликается с бизнес-рисками, потому что это также то, что является внешними вопросиками на схемах выше.

Начнем со второго — внешние зависимости. От чего внешнего зависит успешное функционирование нашего решения в применимости к достижению бизнес-целей? У многих в работе бизнес-риски и зависимости смешиваются, и катастрофы тут нет, но для лучшего понимания и разграничения рекомендую следующий подход:
- Бизнес-риски — это потенциальные негативные факторы на стороне организации/заказчика. Это ответ на вопрос «Что еще может пойти не так в плане достижения цели, помимо решения и его использования?» Т. е. есть курс по бизнес-анализу — а кроме самого курса что может негативно повлиять на трудоустройство заказчика с требуемыми параметрами?
- Зависимости — это то, от чего зависит успешность применения решения (т. е. это на условной стороне решения) к достижению целей. В идеале, конечно, лучше, чтобы их совсем не было, как и бизнес-рисков, но это нереально — мы можем их только минимизировать. Это ответ на вопрос «От чего зависит успешность разработанного нами решения, дабы оно способствовало достижению целей?»

Теперь, что такое бизнес-предположения? Это наши допущения/предположения, на которых базируется любая иная выработанная в рамках стратегического анализа информация. Предположение — это некая информационная формулировка, которая не является для нас близкой к факту, т. е. нет уверенности в ее истинности. Причинами часто являются невозможность прояснить информацию из-за коммуникаций (например, на стороне заказчика уволился и стал недоступным человек, владеющий знаниями), невозможность в принципе перевести информацию в плоскость фактов (например, мы базируем бизнес-цель на гипотезе о том, что приложение установят 15 000 пользователей), нехватка времени/желания на чьей-либо стороне заниматься раскопками (например, изучать рынок — долго и затратно: выдвигаем гипотезу о том, что юзерам нужен будет наш продукт).

Предположения/допущения ситуативны. Т. е. это не бизнес-риски или зависимости, которые объективно существуют. Предположения у вас могут быть, а могут и не быть — зависит от того, сколько информации вы или вы + заказчик перевели в плоскость фактов. Собственно, причина того, что мы их явно фиксируем, в том, что со временем они могут исчезнуть — и желательно периодически на протяжении проекта их проверять и стараться устранить. Предположения могут касаться (а точнее, на них может основываться) любая остальная информация, которую мы прорабатываем на данном этапе:

Бизнес-цель считается корректной, предполагая, что…
Выбранное решение считаем оптимальным, базируясь на допущении, что…
Элемент скоупа решения считаем полезным/нужным, предполагая, что…
Бизнес-риск считается справедливым, основываясь на допущении…

Представив, что у меня не было возможности (беседа с потенциальным заказчиком курса идет 30 минут) прояснить некоторые из деталей, я сопроводил бы свой Vision and Scope для заказчика рядом явно выделенных предположений, чтобы а) заказчик обязательно обратил на этот список внимание, б) в дальнейшем я периодически возвращался к этому списку, чтобы перепроверять, все ли предположения еще верны или появились факты, либо добавляющие нам с заказчиком уверенности (а значит из списка предположений это просто можно убирать), либо опровергающие их (и это не есть хорошо — значит, надо корректировать цель/решение/скоуп и вырабатывать новые):

Что общего между бизнес-рисками, зависимостями и предположениями? Все эти вещи, повторюсь, — это вопросики, которые могут негативно повлиять на достижение бизнес-требований. А еще эти вещи не на нашей стороне. Тут, как говорится, наши полномочия все. Общий посыл таков:

Мы отвечаем за качество разработанного решения и единичек его скоупа. А теперь давайте вместе подумаем (и мы поможем вам в этом: покажем, почему это важно, и профасилитируем процесс совместного обдумывания):
- Какими могут быть риски на стороне организации? Сработавший бизнес-риск помешает достичь цель.
- Каковы внешние зависимости для разрабатываемого нами решения? Нарушенная (сломанная) зависимость сломает что-то и в решении — имейте это в виду (и, если применимо, вот, что стоит делать, дабы она не сломалась).
- Вот допущения, выдвинутые в процессе стратегического анализа и на которых базируется цель, критерий успеха, решение, скоуп, whatever. Либо давайте закроем их и превратим в факты (добавим уверенности этой информации), либо же нам нужно понимать и принимать, что если какое-то из них окажется неверным, это сломает то, что на допущении основывается.

В общем, и свою попу прикрыли, и заказчику дали более комплексный анализ, чем «хозяина, наша хата с краю, мы только ПО пилить».

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

3. Solution Scope and Limitations — каким будет наполнение решения в общих чертах. Отвечаем на вопрос «В каком объеме?».

3.1. Major Features and Characteristics — собственно, сам скоуп.
3.2-3.3 Scope of Initial Release и Scope of Subsequent Releases — очередность поставок, если решение будет разрабатываться итеративно (и есть уже понимание этого в каком-либо виде). Для решения «Курс по бизнес-анализу от ITMINE» подобное неактуально, т. к. это коробочное решение сразу поставляется в фиксированном и полном виде.
3.4. Limitations and Exclusions — любого родя пояснения, ограничивающие трактовку скоупа, дабы лишний раз убедиться, что заказчиком это не будет забыто или интерпретировано неверно.

Например:

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

4. Business Context — т. к. мы закрыли три ключевые информации главами выше, тут мы поясняем дополнительные детали, полезные для понимания итогов discovery.
4.1. Stakeholder Profiles — анализ стейкхолдеров в процессе discovery важен, и тут можно привести его результаты: какие стейкхолдеры идентифицированы, как их разбить по категориям, каково их влияние на цели и решение, что учесть в работе с ними. Анализ стейкхолдеров может стать источником ряда важных вещей в артефакте: даст понимание того, кто является целевыми пользователями решения, кто и как может повлиять на цели, критерии успеха и иные важные параметры (а потому будет источником бизнес-рисков и внешних зависимостей), каковым должно быть наполнение решения (на базе потребностей стейкхолдеров). Тут нечего особо пояснять, т. к. у нас не гайд по проведению стратегического анализа или написанию Vision and Scope. Сложных для понимания концепций в этой главе нет.
4.2. Deployment Considerations — что еще надо сделать, чтобы решение, разработанное согласно скоупу из главы 3, заработало и начало наносить непоправимое счастье. Заметьте, что это не описание проектных работ или работ по размещению решения в операционной среде — все это работы, интересующие проектного менеджера, а не аналитика. Тут мы ведем речь (по крайней мере я рекомендую это так трактовать) о так называемых transition requirements — требованиях, имеющих временный характер и описывающих дополнительные активности, необходимые, чтобы решение эффективно встроить в целевую среду: перенести все текущие данные в новое решение; обучить пользователей; создать админские аккаунты; оформить страничку в Google Play и т. п.

Для курса я бы мог это указать так, и я очерчу цепочку мысли:

Есть курс от ITMINE с неким фиксированным скоупом — его я приводил выше, и он был бы описан в разделе 3 артефакта.
Есть проектные работы по разработке этого решения — точнее, они были, когда курс разрабатывался. Это мне как аналитику не важно — я ими оперировать в документе не буду; т. к. в IT это геморрой того, кто управляет проектом (аналитики оперируют целевым решением, а не его разработкой).
При этом курс, когда применяется к пользователям (= стартует учебная группа), нельзя просто так взять и кинуть в человека — надо сделать дополнительные действия, чтобы группа в него встроилась: собрать Google-аккаунты для доступа к YouTube-роликам, оформить в LMS-системе, разослать начальное письмо-инструкцию и прочие подобные моменты. Вот это и есть те самые transition requirements, которые стоит на текущем уровне понимания (допуская, что по мере углубления в проработку решения масштаб таких вещей может измениться) пометить в данном разделе.

Как-то так. Надеюсь, это было познавательно, и понимание того, что такое стратегический анализ aka discovery и как он информационно фиксируется аналитиком, прояснилось (и уже не так страшно разбираться в том, что курили авторы популярного шаблона Vision and Scope).
Как обычно, буду рад любому фидбэку в канале или чате ITMINE (https://t.me/itmineba), и не брезгуйте стратегическим анализом в работе — недаром с него концептуально начинается всякий бизнес-анализ.