Бизнес-анализ: определение будущего состояния (TO BE)

Хау ду ю ду, феллоу коллигз!

Продолжим нырять в бизнес-анализ, и сегодня на повестке следующая его стадия — определение будущего состояния (TO BE). Логически она следует за изучением AS IS.

Напоминаю (и это можно узнать из начальной заметки цикла), что мы пока еще находимся в контексте стратегического анализа/discovery, а это значит, что будущее состояние мы определяем не в терминах “вот какую систему надо запилить” , а в терминах стратегии заказчика — т. е. зачем и куда он хочет прийти с помощью проекта, с которым он к нам пришел.

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

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

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

Бизнес-требования — это цели, служащие индикатором реализации бизнес-потребностей заказчика. Кстати, дополнительно и на пальцах о том, что такое бизнес-потребности и бизнес-требования в связке, можно посмотреть тут: https://youtu.be/Xfmid0muueo?si=rPKcWzUxYhvU-NQV.

Как оно на практике происходит? Как правило, заказчик не приходит к нам как к IT-подрядчикам с голой формулировкой бизнес-потребностей а-ля “у меня тут высокие издержки на ручную обработку заявок”. Заказчик приходит с проектом на разработку/доработку чего-либо. Но к этому решению рекомендуется относиться как к “мнимому” на данном этапе. Как аналитики мы, если все же колбасим стратегический анализ, должны выйти из этого решения на изучение AS IS и определение желаемых результатов от решения. Картинка, которая описывает вкратце и на пальцах весь стратегический анализ, такова:

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

Вернемся к бизнес-требованиям:

Бизнес-требования формулируются в виде целей заказчика (физического лица или организации): “Сократить потерю заявок от клиентов на 80% в течение месяца после релиза решения”. Поэтому далее по тексту периодически будет использоваться термин “бизнес-цель”, что трактуем как синоним бизнес-требования.
Бизнес-требования отвечают на вопрос “Зачем в принципе нужно решение (каким бы оно ни было )?”.
Бизнес-требования не равны бизнес-потребностям. Бизнес-потребности являются источниками бизнес-требований (и поэтому явно должны быть друг на друга оттрассированы в любой документации, где вы будете это фиксировать). Бизнес-потребности описывают, что сейчас не так (проблемы) или чего хотелось бы достичь (возможности): “У меня избыточный вес”. Бизнес-требования же будут представлены в виде точно сформулированного планируемого результата: “Сбросить 15 кг в течение 6 месяцев”.
В бизнес-целях лучше абстрагироваться от конкретных решений, чтобы избежать ментальной привязки к ним. Как минимум это точно стоит сделать на текущем этапе, ведь у нас пока еще нет решения — мы не знаем, на каком решении заказчик остановится; ради чего мы и делаем поэтапно всю описываемую работу. В дальнейшем, когда решение будет выбрано, мы сможем подтюнить бизнес-цели и их параметры, отталкиваясь уже от конкретного решения. Т. е. в конце стратегического анализа, когда мы будем понимать, что делаем и в каком объеме (скоуп), мы сможем осмыслить и дополнить цели: “Сократить потерю заявок от клиентов на 80% (перепроверив еще раз, что за счет веб-сайта как решения, на котором мы остановились, это реально сделать) в течение месяца после релиза MVP веб-сайта (перепроверив и учтя, сколько времени потребуется на продвижение и освоение именно сайта и именно его MVP в объеме таких-то функций)”.
Ключевой показатель того, что бизнес-требование качественно, — соответствие SMART.

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

SMART — это пять основных положений о том, какими в идеале должны быть бизнес-требования:

S – specific, то бишь конкретные. В цели должен быть указан конкретный результат, а не абстрактная формулировка, которую нельзя пощупать. Иногда аналитики подобным грешат. Не “Повысить эффективность”, а “Сократить время на процесс”.
M — measurable, измеримые. В цели должен быть какой-то точный индикатор того, достигнута она или нет в любой момент времени. Это может быть как количественная метрика, так и что-то, дающее ответ, достигнута цель или нет. “Увеличить прибыль на 20%” или “Получить первый заказ на услуги”. При этом это может быть искусственной метрикой, придуманной конкретно для данной цели — особенно в ситуациях, когда сложно количественно измерить качественное изменение: “Получить не менее 8 баллов в качестве средней оценки услуг по итогам опроса клиентов за год”. Метрика, естественно, может быть и интервалом, а не точным значением: “Сократить издержки на документооборот на 20-40 процентов”.
A — achievable. Достижимая, т. е. реалистичная. Это намек на то, что мы как аналитики, услышав “Заработать миллион долларов на реализации продукта”, должны подвергнуть это критическому осмыслению и постараться вывести заказчика на логическую аргументацию достижимости цели, а не тупо зафиксировать то, что прилетело. Нам как бы решение проектировать на базе цели, и то, что мы в него вложим, должно вести к достижению цели, а не в пустоту.
R – relevant, актуальная, релевантная той бизнес-потребности, с которой данная цель связана. Тут все просто: цели должны вытекать из бизнес-потребностей. “Получение дохода от продажи продукта” едва ли результируется качественно в цель вида “Получить 5 баллов в оценке юзабилити приложения от пользователей”. Косвенно через двадцать слоев — вероятно, да, но все же одно другому не соответствует напрямую.
T – time-bound, привязанная ко времени. Т. е. есть временной индикатор, ограничивающий срок на достижение цели. «В течение месяца после старта использования решения.»

Важно: SMART не обязателен (в контексте M, А и T). Точнее, далеко не всегда возможен. Я рекомендую пытаться к нему прийти, но в разумных рамках. Если видим, что с этим возникают трудности, лучше отпустить и иметь просто цель как понимание, ради чего тут мы все дружно собрались. Яркий пример — монетизация продукта. Заказчик может не иметь бизнес-плана и конкретных ожиданий по тому, сколько он заработает на продукте. Если подобное есть — прекрасно. В противном случае вы, конечно, можете пообщаться с ним на эту тему и даже что-то помочь выработать, но эта инициатива вполне себе может зайти в никуда, особенно если заказчик начинает от подобного уставать и вполне себе ок с тем, что необоснованность инвестиций в разработку — это его риски. “Заработать бабос на продукте” — явно понимать всеми сторонами эту цель и держать ее в фокусе на протяжении всего проекта — уже гораздо лучше, чем ничего.

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

Важно: под Vision and Scope не подразумевается Word-документ. Стоит относиться к нему как к набору информации по результатам стратегического анализа, который вы ведете там, где вам удобно / где работает команда / где хочет заказчик. Это может быть Word-документ, Google-документ, набор логически связанных страничек в пространстве проекта в Confuence, набор заметок в Notion и даже набор информации в RMS-системе, если у вас все по-взрослому. Т. е. грубо говоря, от того, что мы все такие аджайлнутые, необходимость фиксировать в той или иной детализации итоги discovery не устраняется, и не стоит трактовать заявление “Мы не пишем Vision and Scope — у нас скрам!” как повод хлопнуть бокал смузи от гордости.

Если отталкиваться от содержимого документа Vision and Scope (а умные люди за нас уже предложили там разделы, которые важны для стратегического анализа), то что еще можно выработать на данном этапе, кроме бизнес-требований?

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

Во-первых, есть такое понятие, как критерии успеха (success metrics).

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

Я уже разбирал, что такое критерии успеха, в этой заметке, но приведу для удобства и тут. Там фигурировал пример, что если я как автор курса по бизнес-анализу предоставляю его заказчику в виде решения, то каковой может быть бизнес-цель заказчика? Например, “Устроиться в качестве IT БА в течение полугода с з/п не менее 300$”. Как исполнитель решения могу ли я быть уверенным в том, что само по себе оно (курс) приведет заказчика к достижению цели? Нет, конечно. Достижение подобной бизнес-цели может зависеть и от прочих “проектов” заказчика: не сидеть на попе, а рассылать резюме; пройти курс по технической подготовке; прокачать английский до уровня X. Также есть и контекст, который может всячески повлиять на достижение цели и который также вне зоны моего контроля: количество вакансий на рынке, например. Так вот критерии успеха могут тут помочь заказчику и исполнителю (если ему, конечно, не плевать на такое) оценить успешность участия самого решения в достижении бизнес-целей — чтобы своевременно понять, что не так с решением и, вероятно, внести корректировки. Я как автор курса могу предложить заказчику следующий критерий успеха: “Завершить курс с итоговым баллом успеваемости >=70%”. Для меня это маркер того, что решение помогает двигать заказчика к бизнес-цели. Если этот критерий успеха не достигнут, то, на мой взгляд, курс не помогает в достижении исходной цели и нужно что-то менять — в самом решении или том, как им пользуются.

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

Во-вторых, есть бизнес-риски (business risks). Опять-таки, вытащу описание из уже упомянутой заметки про discovery: бизнес-риски — это что может пойти не так в плане достижения цели, даже с учетом готового и рабочего решения. Это все то, что может негативно повлиять на применимость решения к достижению бизнес-целей. Выше я уже затронул, что внедрение решения далеко не всегда является единственным условием достижения цели. И если что-то еще может на это повлиять, то что конкретно и как? Для примера с целью про обучение выше бизнес-риском будет пункт “Могут закончиться вакансии на рынке для БА” или “Заказчик по личным обстоятельствам может не вовлечься в курс настолько, насколько нужно, чтобы достичь очерченного критерия успеха”.

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

Важно: риск — это не гипотетическая вероятность в абстракции от контекста. Пусть “Могут закончиться вакансии на рынке для БА” — это с какой-то вероятностью актуально для любой временной точки, но считать это риском стоит только тогда, когда видны предпосылки. Например, в ситуации упадка IT-отрасли. В состоянии ее подъема и очевидной активности на рынке считать это риском не имеет практического смысла.

Что по поводу рисков нужно проработать:

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

Рассмотрим политики на примерах с курсом выше:

Уклонение (устранение неопределенности, которая порождает риск). Допустим, есть риск “Заказчик может не вложиться в курс достаточным образом, т. к. на этот период был запланирован месячный отпуск на Гавайях”. Как только это подмечено, с заказчиком стоит обсудить, что эта штука может серьезное повлиять на достижение очерченного критерия успеха, и может быть решено или хотя бы просто порекомендовано убрать отпуск на этот период.
Передача (условный перевод ответственности на кого-то еще). Возьмем тот же риск. Я как исполнитель могу поступить и проще: включить в договор пункт о том, что заказчику не будет выдан сертификат об успешном прохождении курса, если заказчик пропустил X занятий. При этом подразумевается, что получение сертификата — это обязательный критерий успеха на пути к достижению бизнес-цели. Насколько удачной будет такая политика — отдельный вопрос, но имейте в виду, что она существует.
Снижение (проведение мероприятий по сокращению вероятности или влияния риска). Например, “Заказчик может не суметь качественно участвовать в онлайн-мероприятиях курса, т. к. находится в условиях плохого Интернета”. Сокращение вероятности — это порекомендовать заказчику обеспечить себе надежное Интернет-соединение с таким-то коннекшном заранее до курса. Сокращение влияния — это включить в скоуп решения записи тренингов и выдачу их заказчику.
Принятие риска — принимаем факт существования риска и живём дальше.

Что можно сформулировать в плане рекомендаций по работе с бизнес-рисками:

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

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

Добавлю тут и третье, хотя это относится к любому этапу анализа: в процессе стараемся фиксировать, где в информации у нас предположения (assumptions), а не то, что мы считаем условно фактом. Это наши допущения, на которых может базироваться любая иная выработанная в рамках стратегического анализа информация. Т. е. предположение — это некая информационная формулировка, по поводу которой у нас нет уверенности в ее истинности. Причинами часто являются невозможность прояснить информацию (например, на стороне заказчика уволился и стал недоступным человек, владеющий знаниями), невозможность в принципе перевести информацию в плоскость фактов (например, мы базируем бизнес-цель на гипотезе о том, что приложение установят 15 000 пользователей), нехватка времени/желания на чьей-либо стороне заниматься раскопками (например, изучать рынок — долго и затратно: выдвигаем гипотезу о том, что юзерам нужен будет наш продукт). Предположения ситуативны. Т. е. это не бизнес-риски или цели, которые объективно существуют и которые нам лишь нужно понять. Предположения у вас могут быть, а могут и не быть — зависит от того, сколько информации вы или вы + заказчик перевели в плоскость фактов. Собственно, причина того, что мы их явно фиксируем, в том, что со временем они могут исчезнуть — и желательно периодически на протяжении проекта их проверять и стараться устранить. Например, бизнес-цель для курса считаем корректной (в частности её параметр T), предполагая, что заказчик начнет обучение в ближайший месяц. Допустим, я не уверен в этом, потому что заказчик как-то колеблется в плане того, когда ему стартовать обучение. Т. е. в отдельном “разделе” Vision and Scope у меня будет “AS-1. Заказчик начнет обучение в течение месяца”. А пояснением для бизнес-цели в том месте, где она сформулирована, будет текст “См. AS-1”.

Поговорим теперь о том, как выработать очерченную выше информацию.

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

Вопросы, которые актуальны для данного этапа и которые стоит задать заказчику (естественно, “обернув” их понятно и безболезненно для получателя):

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

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

Дабы помочь ему в этом, можно применить как советы из предыдущей заметки, так и ряд новых:

1) Донесите до заказчика, ради чего вы эту работу собираетесь делать:

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

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

2) На этом этапе устное общение уже можно более свободно разбавлять письменным. Иногда это даже поможет, т. к. вы сможете качественнее продумать ход мысли и подачу информации в плане помощи.

3) Как вы можете эту самую помощь оказать, если у заказчика возникают проблемы в формулировке того, что на данном этапе нужно:

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

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

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

- Не-а, не думал о таком, но понимаю ценность этого.

- Ок, давайте вместе подумаем. Нам нужно отталкиваться от бизнес-потребности, а потому логично предположить, что цель (будем называть это бизнес-требованиями) состоит в том, чтобы по итогу сократить потери заявок на услуги за счет внедрения решения. Согласны? Есть, что добавить еще из целей?

- Согласен. Да, нам надо устранить эти потери.

- Огонь! Смотрите, чтобы цель была качественной, нам бы добавить в нее показатель, который поможет определить, достигнута она или нет, плюс ограничить во времени. Есть идеи?

- Нуу, наверное надо привязаться к тому, что заявки больше не теряются…

- Ага, вы как всегда блестящие идеи генерируете! Давайте подумаем: вы говорили, что у вас сейчас теряется около 5% заявок, т. к. они поступают по куче разных каналов, и сложно это все безошибочно собрать воедино. Раз мы тут ведем речь об IT-решении для сбора заявок, то логичным было бы предположить, что мы консолидируем каналы, по которым они приходят, за счет чего человеческий фактор, который их теряет, станет меньше заметен. Согласны?

- Агась!

- Ок, тогда насколько разумным будет сокращение потерь до нуля, т. е. полное устранение потерь? Человеческий фактор не устранится, просто вероятность его срабатывания снизится. Вы согласны с тем, что надо оставить задел на это — например, снизить потери до 1%?

- Ну ок, разумно.

- Хорошо, тогда итоговая цель — снизить потери заявок на услуги до 1% в течение… А в течение какого периода? Есть какие-то ограничения или стремления с вашей стороны? Если нет, то смотрите: это будет IT-решение, и нужен будет некий период адаптации администратора к нему. Логично ли, что это будет спустя какое-то время после релиза? Например, мы возьмем месяц на полное внедрение системы в рабочий процесс. И после этого за следующий месяц можно сделать замеры, какое количество заявок было потеряно. Согласны или есть поправки?

- Согласен, логично.

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

- Да, сделаем и удостоверимся.

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

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

- Ок, тогда оформим это в виде рисков… (дальше логика подачи информации, полагаю, понятна)

Что в рамках этапа может помочь в плане специальных техник?

1) Есть довольно очевидная техника, которая, тем не менее, для кого-то может оказаться открытием: Business Objectives Model.

Почему техника очевидна? Фактически это просто mind map, который визуально позволяет показать трассировку от бизнес-потребностей к бизнес-целям, а затем, в контексте будущих этапов, и к элементам скоупа решения, которые позволят их реализовать. Т. е. просто помните о том, что такие вещи в процессе можно прорабатывать и показывать всем визуально, и для этого прекрасно подойдёт обычный mind map.

2) Lean Canvas. Затрагивает больше, чем текущий и предыдущий этапы, но упомяну уже сейчас. Фактически эта техника покрывает почти весь discovery, не считая скоупа решения. По своей сути это также простая техника: вы просто несете на воркшоп визуальный канвас со всеми ключевыми блоками информации и совместно этап за этапом его там заполняете. Т. е. это готовый фреймворк для того, чтобы сделать обсудить все описанное выше, причем визуально. Хотя “готовый” — сказано сильно, ибо он ориентирован на масс-продукты. Для заказной разработки его придется поковырять, чтобы адаптировать к её специфике. Поэтому поясню описанное в статье с учетом того, что мы рассматриваем применимость техники в более широком понимании, чем сугубо для продуктов:

“Проблемы” трактуем или даже переименовываем в “Бизнес-потребности” или “Проблемы/Возможности”, а не как проблемы целевой аудитории (пользователей) — о них еще рано говорить на данном этапе бизнес-анализа.
“Сегменты клиентов” трактуем/переименовываем в “Классы пользователей”, а еще лучше — в “Заинтересованные лица”. О том, как и для чего проводить анализ заинтересованных лиц, обсудим в заметке про этап планирования бизнес-анализа.
“Уникальное Ценностное Предложение” трактуем/переименовываем в “Ценности”, и это будет представлять собой ценности решения для стейкхолдеров. Также рано еще пока об этом говорить — у нас нет пока ещё решения.
“Решение”, как уже очертили, рано еще рассматривать — это для будущих этапов.
“Каналы”, “Конкурентные преимущества”, “Источники доходов”, “Структура расходов” — все это можно убрать, т. к. для заказной разработки эти секции либо неактуальны, либо имеют гораздо меньшее значение на данном этапе.
“Ключевые метрики” трактуем/переименовываем в “Бизнес-цели и критерии успеха”.
Добавляем секции вместо убранных, которые актуальны для стратегического анализа в нашем понимании. В частности, на данном этапе это может быть секция “Бизнес-риски”. В будущих этапах появятся и иные полезные.

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