В прошлой статье мы разобрали первое базовое понятие BABOK — Заинтересованные стороны (ЗСт) (Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» / Хабр). Мы выяснили, что каждый проект начинается с вопроса «Кто в игре?». Но как только мы собрали нужных людей в рабочую группу проекта, перед нами встает следующий, не менее критичный вызов: что на самом деле нужно бизнесу?

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

Бизнес-аналитик может идеально собрать требования, разработчик написать код, а тестировщик протестировать его, но в итоге получится решение, которое не удовлетворяет ни одну из потребностей бизнеса. Чтобы не наступить на данные грабли, предлагаю разобрать второе базовое понятие BABOK — Потребность (Need).

Что такое потребность и где кроется подвох?

Согласно глоссарию BABOK v3.0:

«Потребность — это проблема, возможность или ограничение, представляющие потенциальную ценность для заинтересованной стороны».

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

Звучит просто? Да. Но в этом и кроется главная ловушка. Заказчики почти никогда не формулируют потребности. Они формулируют решения.

Аналитик-новичок работает как секретарь-референт: записывает мысли заказчика («нам нужна кнопка в CRM», «сделайте нам отчет») и передает в разработку.

Аналитик-эксперт работает как врач: он не выписывает лекарство, которое требует пациент, а сначала ставит диагноз, выясняя причину болезни.

Ключевая мысль: Потребность не привязана к конкретным инструментам, технологиям или интерфейсам. Она описывает разрыв между текущим состоянием (As-Is) и желаемым будущим (To-Be).

Четыре уровня потребностей: иерархия BABOK

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

Чтобы не заблудиться в лабиринте «желаний» заказчика, BABOK предлагает разделять потребности на 4 уровня. Ошибка большинства проваленных проектов заключается в том, что команда начинает работу с 3-го уровня, игнорируя первые два.

1. Бизнес-потребность (Business Need): Глобальная цель компании. Зачем мы вообще это делаем? Например: снизить регуляторные риски, увеличить долю рынка, сократить операционные расходы. В терминах BABOK это уровень стратегии: именно здесь бизнес-аналитик работает в связке с руководством и спонсором проекта. Если этот уровень не прояснён, любые артефакты ниже по иерархии становятся потенциально бесполезными.

2. Потребность заинтересованной стороны (Stakeholder Need): Что нужно конкретным группам (ЗСт), чтобы бизнес-цель была достигнута. Например: комплаенс-контролерам нужно видеть просроченные документы, а клиентам — легко их обновлять. Ключевая задача аналитика на этом уровне — не позволить потребностям одной заинтересованной стороны «поглотить» потребности другой. Нередко интересы ЗСт противоречат друг другу: то, что удобно комплаенс-контролеру, может создавать трения в UX для клиента. Фиксируйте конфликты явно.

3. Потребность в решении (Solution Need): Функциональные и нефункциональные требования к системе. Например: интеграция с базами, push-уведомления, блок-схемы процессов. Важно: Solution Need — это уже требования к конкретному решению, а не к бизнесу. Большинство команд начинают именно отсюда, полностью пропуская уровни 1 и 2. Это прямой путь к «правильно сделанному неправильному продукту».

4. Переходная потребность (Transition Need): То, о чем забывают в 80% случаев! Что нужно, чтобы перейти от старого к новому? Например: миграция данных, обучение персонала, изменение нормативной базы, временные «костыли». На практике Transition Need часто выявляется уже после запуска, когда оказывается, что сотрудники не умеют работать с новой системой, старые данные несовместимы с новой моделью или параллельная работа старого и нового процессов невозможна без временного «моста». Заложите время на выявление переходных потребностей в план ещё на этапе инициации проекта — это сэкономит недели в конце.

Классическая ошибка: кейс «Отчёт о недействительных паспортах»

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

Например: один из заказчиков, поставил задачу ИТ команде разработать «Отчёт о недействительных паспортах». В своей задаче заказчик детально описал решение — отчет должен содержать 10 колонок, ежедневно формироваться в pdf формате по расписанию и рассылаться на почту в филиалы. Сотрудники филиалов, в свою очередь, должны обзванивать клиентов из данного отчета, у которых истекает срок годности паспорта. 

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

Результат:

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

2. при отправке по электронной почте отчетов с персональными данными клиентов нарушили информационную безопасность компании, 

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

Где была ошибка? Аналитик принял решение (отчет) за потребность. Если бы аналитик применил технику «5 Почему» и выяснил реальную потребность, диалог выглядел бы так:

• — Зачем вам отчет? — Чтобы видеть клиентов с просроченными документами.

• — Зачем их видеть? — Чтобы блокировать им сделки, пока они не обновят данные.

• — Зачем блокировать? — Чтобы избежать штрафов от регулятора (Бизнес-потребность!).

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

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

Рабочие техники: как докопаться до сути?

В арсенале бизнес-аналитика есть множество инструментов (Elicitation & Collaboration), но для выявления истинных потребностей я рекомендую четыре самых эффективных: в BABOK v3.0 они описаны в разделах Elicitation & Collaboration (глава 4) и Strategy Analysis (глава 6). Все четыре техники работают на одной логике: перейти от артефакта («отчёт», «кнопка») к контексту («зачем», «для кого», «что изменится»).

1. Метод «5 Почему» (5 Why) (Метод «5 почему»: как он работает, что чаще всего забывают, и как провести тренинг для команды / Хабр). Простейший, но мощнейший инструмент анализа первопричин. Задавайте вопрос «Почему?» до тех пор, пока не упретесь в фундаментальную бизнес-цель или ограничение.

2. Jobs to be Done (JTBD) (Самый подробный разбор JTBD, CJM и персон — что нужно вашей команде и как использовать все эти фреймворки / Хабр). Концепция «Работа, которая должна быть сделана». Формат: «Когда [ситуация], я хочу [мотивация], чтобы [ожидаемый результат]». Это смещает фокус с функций системы на контекст жизни пользователя.

3. Анализ первопричин (Диаграмма Исикавы) (Применение диаграммы Исикавы для решения корпоративных проблем / Хабр). Если проблема комплексная (например, «падают продажи»), техника помогает разложить её на факторы: Люди, Процессы, Технологии, Среда. В контексте BABOK диаграмма Исикавы — это инструмент анализа текущего состояния (As-Is Analysis), который помогает понять, почему разрыв между As-Is и To-Be вообще возник.

4. Интервью по методу Laddering (Лестница умозаключений). Менее известная, но очень точная техника для работы с неартикулированными потребностями. Аналитик задаёт серию вопросов, поднимаясь от конкретного атрибута продукта/функции к ценностям заказчика: «Почему это важно?» → «Что это даёт вам?» → «Какую цель это помогает достичь?». Особенно эффективна при работе с топ-менеджментом, который привык мыслить категориями стратегии, а не требований.

Опыт «БКС Мир инвестиций»: No KPI — No Need

В компании «БКС Мир инвестиций» мы выработали прагматичный подход к фиксации потребностей. Прежде чем брать задачу в бэклог и писать бизнес-требования, команда в лице бизнес-аналитика обязана ответить на следующие вопросы. Этот подход соответствует концепции Business Analysis Planning (BAP) из BABOK, где перед запуском аналитической работы фиксируется контекст: зачем мы это анализируем и как будет измеряться успех. Без ответов на эти вопросы бэклог превращается в список технических задач, оторванных от стратегии.

1. Какую бизнес-проблему мы решаем? (Описание разрыва между As-Is и To-Be).

2. В чем измеряется успех? (KPI / Метрика. Если потребность нельзя измерить — это не потребность, а «хотелка»).

3. Какие альтернативы мы рассмотрели? (Обязательное поле, заставляющее аналитика и заказчика думать за пределами первого пришедшего в голову IT-решения).

4. Что произойдет если это не делать? (Оценка угроз и упущенной выгоды, если задача не будет сделана)  

Мини-чеклист: «Действительно ли я нашел потребность?»

1. Я отделил проблему от способа её решения?

2. Знаю ли я, как именно бизнес будет измерять успех этого изменения (KPI, деньги, время, риски)?

3. Выявил ли я переходные потребности (обучение, миграция, временные процессы)?

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

5. Рассмотрели ли мы хотя бы 2–3 альтернативных пути достижения этой цели (включая организационные изменения без написания кода)?

6. Проверил ли я, что потребность соответствует хотя бы одному из трёх типов BABOK: проблема, возможность или ограничение — и не является просто «хотелкой» без бизнес‑контекста?

7. Согласована ли потребность со спонсором проекта или лицом, принимающим решения (ЛПР)? Устная договорённость — это не согласование. Нужна зафиксированная подпись или письменное подтверждение.

Итог

Потребность — это второе звено в причинно-следственной цепочке BABOK. Нет правильных заинтересованных сторон → нет правильной потребности → нет правильных требований → нет ценности.

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

Что дальше в цикле? Следующая статья будет про Изменение (Change): какие перемены произойдут в процессах, системах и головах людей? Как спроектировать переход от «сегодня» к «завтра» и почему сопротивление изменениям может убить даже самое гениальное решение. Подпишитесь на наш блог, чтобы не пропустить.