Бизнес-анализ: вопросы для собеседования QA

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

Классифицирую по двум осям: «влияние × интерес» (матрица Менделоу) и «внутренние/внешние». Это даёт 4 квадранта: ключевые игроки (high/high) — управлять плотно; держать удовлетворёнными (high/low); держать в курсе (low/high); минимум усилий (low/low).

Из практики: первое, что делаю на проекте — карта стейкхолдеров на одну страницу с ролью, мотивом и каналом коммуникации. Помогает не «забыть» юриста или ИБ за неделю до релиза.

Подготовка: изучаю домен, существующие документы и систему, формулирую гипотезу о цели встречи и пишу список открытых вопросов (5–7 ключевых, не больше).

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

Из практики: после встречи в тот же день шлю summary с понятиями, решениями и открытыми вопросами — это снимает 80% будущих «я имел в виду другое».

Базовый набор: интервью (1:1), воркшопы (несколько ролей сразу), наблюдение (shadowing), анкетирование, анализ документов, прототипирование, бенчмарк конкурентов.

Выбор зависит от задачи. Новый процесс — воркшоп + прототип. Незнакомый домен — наблюдение + интервью. Массовая обратная связь — анкета. Конфликты ролей — фасилитированный воркшоп, где разногласия видны всем.

Из практики: ни один метод не закрывает картину один. Обычно комбинирую 2–3 и сверяю результаты — расхождения и есть «золото» аналитика.

Сначала пытаюсь понять, почему он «трудный»: страх потерять контроль, прошлый негативный опыт, недостаток информации, скрытые KPI. Поведение — это симптом.

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

Из практики: лучшее средство — вовлечь рано. Стейкхолдер, который ничего не решал, чаще всего «трудный» именно из-за этого.

Сначала разделяю: конфликт по сути (несовместимые цели) или по форме (одно и то же сказано разными словами). Половина «конфликтов» — терминологические.

Если по сути: вывожу стороны на общий критерий — бизнес-цель, KPI, стоимость владения. Решение принимает спонсор/PO на основании данных, а не я. Моя задача — подготовить варианты и trade-offs.

Из практики: фиксирую решение в decision log с автором и обоснованием. Это снимает «а кто это решил?» через 3 месяца.

Топ-менеджмент: pyramid principle — сначала вывод и цифры, потом 3 опоры, детали по запросу. Язык бизнеса (деньги, риск, срок), визуализации, 1 слайд = 1 идея.

Технические специалисты: контекст и ограничения подробно, диаграммы потоков и данных, явные допущения, описание edge-cases. Можно глубже в реализацию.

Из практики: одна и та же презентация в две аудитории не работает. Лучше две версии по 10 минут, чем одна на 40.

Не отвечаю «нельзя». Перевожу обсуждение в плоскость trade-offs: «можно, но это стоит X недель и блокирует Y. Какой вариант ближе к цели?»

Помогает разложить «хотелку» на потребность (что заказчик хочет получить) и решение (что он предлагает). Часто потребность реализуется проще, чем предложенное решение.

Из практики: показываю заказчику 2–3 альтернативы с ценой и эффектом. Решение он принимает сам, а я не оказываюсь «тем, кто отказал».

Использую технику «5 почему». Заказчик хочет «кнопку экспорта в Excel» — пять «почему» вниз и оказывается, что нужна интеграция с BI или регулярный отчёт на email.

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

Из практики: в 60% случаев финальное решение отличается от первоначальной «хотелки» — и это не провал коммуникации, а нормальная работа аналитика.

SWOT — матрица 2×2: Strengths и Weaknesses (внутренние факторы), Opportunities и Threats (внешние). Цель — увидеть свою позицию и опереть стратегию на сильные стороны, закрывая слабые.

Применяю на старте инициативы, при выходе на новый рынок, перед редизайном продукта. Дальше — пары: SO (сила × возможность = на чём расти), WT (слабость × угроза = что прикрывать).

Из практики: SWOT полезен только если оценки конкретны. «Сильная команда» — не пункт; «3 senior backend с опытом fintech» — пункт.

PESTLE — анализ внешних факторов: Political, Economic, Social, Technological, Legal, Environmental. В отличие от SWOT, смотрит только наружу.

Применяется при выходе на новый рынок, регуляторных изменениях, оценке рисков долгосрочной инициативы. Например, новый закон о персональных данных = Legal-фактор с прямым влиянием на архитектуру.

Из практики: PESTLE и SWOT часто делают в паре — PESTLE кормит O/T для SWOT.

GAP-анализ сравнивает текущее состояние (AS-IS) с целевым (TO-BE) и описывает разрыв: что не хватает в процессах, людях, технологиях, метриках.

Шаги: 1) описать AS-IS с метриками; 2) определить TO-BE с измеримыми целями; 3) выписать дельту; 4) приоритизировать и оценить инициативы для закрытия разрыва.

Из практики: главная ошибка — TO-BE без метрик. «Хотим быть быстрее» — не цель. «p95 ответа < 300 мс к Q3» — цель.

AS-IS — модель текущего процесса как он есть, со всеми костылями. TO-BE — модель целевого процесса после изменений. Часто рисуются в BPMN для наглядности.

Пример: оформление кредита AS-IS — 7 ручных шагов, 3 дня, 4 системы. TO-BE — 2 шага, 15 минут, 1 окно с автоматическим скорингом.

Из практики: AS-IS обязателен. Без него TO-BE — это фантазия, а не план изменений; не видно, какие операции исчезают и куда деваются люди, которые их делали.

Бизнес-модель — описание того, как компания создаёт, доставляет и захватывает ценность. Самый ходовой инструмент анализа — Business Model Canvas (9 блоков) или Lean Canvas.

Анализирую каждый блок: кто клиент, какую ценность даём, как доставляем, как зарабатываем, какие ресурсы и партнёры нужны, какова структура затрат. Ищу слабые звенья и риски.

Из практики: Lean Canvas удобнее для стартапов и новых продуктов — в нём есть «проблема» и «несправедливое преимущество», которых нет в классическом BMC.

Persona — собирательный образ типичного пользователя: имя, роль, цели, боли, контекст использования, барьеры. Не средняя температура, а конкретный архетип.

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

Из практики: 3–5 персон достаточно. Больше — никто не помнит, меньше — пропускаются важные сегменты.

KPI выводится из бизнес-цели вниз: цель → метрика успеха → KPI команды. Если KPI не связан с целью — это просто число.

Критерии: SMART (конкретен, измерим, достижим, релевантен, ограничен по времени) + единственная интерпретация + контролируем командой. «NPS > 50» — KPI; «улучшить впечатление» — нет.

Из практики: всегда добавляю «counter-metric» — что не должно ухудшиться. Иначе KPI «скорость доставки» легко выполняется через падение качества.

Успех определяется ДО старта в виде измеримых критериев: бизнес-метрика (выручка/конверсия/время), пользовательская метрика (NPS/retention), операционная (стоимость поддержки), сроки/бюджет.

После релиза смотрю на разницу между прогнозом и фактом по этим метрикам через стабильное окно (4–8 недель). Без baseline сравнивать не с чем — поэтому baseline снимается заранее.

Из практики: «сделали в срок» — не критерий успеха проекта. Это критерий успеха исполнения. Успех — это изменение метрик у пользователя/бизнеса.

MVP — минимально жизнеспособный продукт: минимальный набор функций, который позволяет проверить ключевую гипотезу с реальными пользователями. Не «дешёвая первая версия», а инструмент обучения.

Границы определяю от гипотезы. Гипотеза: «пользователи готовы платить за X». MVP включает только то, без чего эта гипотеза не проверяется. Всё остальное — в backlog.

Из практики: каждую фичу прохожу вопросом «если её не будет, гипотеза не проверится?». Если ответ «проверится» — фича не в MVP.

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

Использую для поиска болей и зон роста. Часто оказывается, что 80% негатива — на 1–2 этапах, и точечная доработка даёт больший эффект, чем редизайн всего.

Из практики: строю CJM на реальных интервью, а не на гипотезах. Иначе это «как нам кажется, ведёт себя клиент».

MoSCoW (Must/Should/Could/Won’t) — быстро и просто для релизного scope. RICE (Reach × Impact × Confidence / Effort) — числовая приоритизация backlog продукта. ICE — упрощённый RICE без Reach. Kano — оценка фич по влиянию на удовлетворённость (must-have, performance, delighters).

Выбор зависит от задачи. Релиз — MoSCoW. Сравнение десятков идей — RICE. Понимание ценности фич для пользователя — Kano. Не одна техника на все случаи.

Из практики: главный риск — Confidence в RICE «по интуиции». Поэтому всегда фиксирую источник оценки (данные/эксперт/гипотеза).

Stakeholder Analysis Matrix — таблица с осями «влияние» и «интерес» (матрица Менделоу). Каждый стейкхолдер попадает в один из 4 квадрантов, определяющих стратегию работы с ним.

Расширенная версия включает: роль, отношение (поддерживает/нейтрален/против), канал коммуникации, частоту контакта, риски. Получается план коммуникаций на проект.

Из практики: матрица — живой документ. Пересматриваю на ключевых точках (после демо, смены руководства, релиза).

BRD (Business Requirements Document) — документ на языке бизнеса: цели проекта, бизнес-потребности, scope, бизнес-правила, заинтересованные стороны. Отвечает на «что» и «зачем».

SRS (Software Requirements Specification) — техническая спецификация на языке системы: функциональные и нефункциональные требования, ограничения, интерфейсы. Отвечает на «как именно».

Из практики: BRD читает спонсор и бизнес, SRS читает команда разработки. Один документ для обоих почти всегда плох в обеих ролях.

FRS — документ с детальным описанием функциональных требований: что система должна делать, какие сценарии выполняет, какие правила применяет. Это «середина» между BRD (зачем) и SRS (всё, включая НФТ и интерфейсы).

Содержит use cases или user stories, бизнес-правила, описание интерфейсов с другими модулями, требования к данным.

Из практики: в Agile-командах FRS как отдельный артефакт часто не пишут — его роль играют user stories с AC и спецификации в Confluence.

Vision & Scope — короткий документ (5–10 страниц) на старте проекта: бизнес-контекст, проблема, целевая аудитория, ключевые возможности (in scope) и явно — что НЕ входит (out of scope), допущения, ограничения, риски.

Цель — выровнять понимание у всех стейкхолдеров, что мы делаем и не делаем. Защищает команду от scope creep.

Из практики: блок «out of scope» — самый ценный. Именно туда идут «а ещё хорошо бы…», и команда не размывается.

Матрица трассировки связывает бизнес-требование → функциональное требование → элемент дизайна → реализация → тест-кейс. Показывает, что каждое требование реализовано и проверено, и наоборот — что нет «лишнего» кода без обоснования.

Используется в регулируемых отраслях (банки, медицина, авиация), а также при крупных изменениях для impact-анализа.

Из практики: даже без формальной матрицы полезно держать связь «требование ↔ тест» — это сокращает регрессию при изменениях вдвое.

Базовая структура: 1) Контекст и цели; 2) Глоссарий; 3) Действующие лица и сценарии; 4) Функциональные требования; 5) Нефункциональные требования; 6) Интеграции; 7) Данные и миграции; 8) UI-требования; 9) Ограничения и допущения; 10) Приёмочные критерии.

Каждое требование — с уникальным ID для трассировки. Каждое — атомарно, проверяемо, без слов «удобно», «быстро», «современно».

Из практики: ТЗ на 200 страниц никто не читает целиком. Лучше модульная структура с оглавлением и cross-links — читатель ищет своё, а не всё.

Глоссарий — словарь предметных терминов проекта с однозначными определениями. Снимает путаницу: «клиент», «заказ», «лид» в разных отделах часто значат разное.

Веду один общий глоссарий, на который ссылаются BRD/SRS/UI. При появлении нового термина — сразу в глоссарий, до первого использования.

Из практики: 30% «дефектов требований» — это терминологические расхождения. Глоссарий стоит часа работы и экономит недели.