Вопросы на собеседовании бизнес-аналитика

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

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

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

Бизнес-требования описывают цели компании, которые можно измерить, например сократить время обработки заявки. Пользовательские описывают, что нужно менеджеру, который эти заявки обрабатывает. Функциональные описывают, что умеет система: «Система должна дать клиенту возможность отменить заявку». Нефункциональные описывают, каким условиям она отвечает: «Страница открывается быстрее чем за 2 секунды при 200 запросах в секунду» или «Система недоступна не больше 12 часов за год».

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

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

User story — короткая запись потребности от лица пользователя: «Как покупатель, я хочу отложить товар, чтобы купить его позже». Use case описывает по шагам, как пользователь работает с системой: кто действует, что должно быть выполнено до начала, основной сценарий и альтернативные. Для процесса с ветвлениями и ошибками беру use case, для небольшой доработки хватает истории.

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

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

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

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

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

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

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

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

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

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

«Использую MoSCoW. Must — требования, без которых цель не достигается. Should — важные, они повышают шансы на успех. Could — полезные, но цель достигается и без них. Won’t — то, что сейчас на цель не влияет. Категорию Must согласую с заказчиком, иначе туда попадает всё».

«ICE (Impact, Confidence, Ease) считает оценку как произведение влияния, уверенности и простоты. RICE построен по тому же принципу, и уверенность в нём остаётся субъективным весом. Модель Кано подходит для ранних исследований, когда нужно понять, какие функции ждут пользователи, а для повседневного бэклога она тяжеловата. MoSCoW удобен на стратегических сессиях, где обсуждают видение продукта на верхнем уровне».

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

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

Соединю клиентов с их заказами за последние 90 дней через LEFT JOIN и оставлю тех, у кого заказа не нашлось: «SELECT c.id, c.name FROM customers c LEFT JOIN orders o ON o.customer_id = c.id AND o.created_at >= CURRENT_DATE - INTERVAL '90 days' WHERE o.id IS NULL».

В Scrum три роли: product owner, Scrum master и разработчики. Событий пять: спринт, планирование спринта, ежедневный Scrum, обзор спринта и ретроспектива. Бэклогом продукта управляет product owner, а бизнес-аналитик помогает ему готовить требования к элементам бэклога.

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

«Спрошу, кто будет смотреть дашборд и как часто, какое решение он хочет по нему принимать и что значит „как идут продажи“ в цифрах. Узнаю, что происходит сейчас: откуда заказчик берёт эти цифры и что делает, когда они плохие. Пока не пойму, какую задачу решаем, к графикам не перейду».

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

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

«Нарисую два пула: покупатель и магазин. У покупателя процесс начинается стартовым событием „захотел купить книгу“: он находит книгу и оформляет заказ, заказ уходит в магазин потоком сообщений. Магазин проверяет наличие, и здесь исключающий шлюз: если книги нет, покупателю приходит отказ, а если она есть, он оплачивает заказ. Второй исключающий шлюз проверяет оплату. Если она не прошла, заказ отменяется и покупатель получает уведомление, а после успешной оплаты магазин собирает и отправляет книгу, и процесс заканчивается событием „книга доставлена“».

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

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

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

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

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

«Хочу больше работать с бизнесом напрямую. Сейчас требования приходят ко мне через менеджера проекта, а мне интересно выяснять у заказчика, какую задачу решает доработка. У вас аналитик работает с заказчиком, это то, что я ищу».