Как задаются вопросы и уточняются требования у стейкхолдеров
Что проверяют
Есть ли у вас метод, или требования записываются под диктовку. Интервьюеру важно, отличаете ли вы потребность от готового решения, которое приносит заказчик, и как фиксируете договорённости. Следом обычно просят пример, когда два стейкхолдера хотели противоположного.
Как отвечать
Отвечайте на своём проекте, с настоящими ролями и цифрами. Каркас:
- подготовка: карта стейкхолдеров (кто решает, кто пользуется, кто влияет), изучение документов, регламентов и текущей системы. Вопрос, ответ на который можно прочитать, на встрече не задаётся;
- сначала as-is: как процесс устроен сейчас, кто что делает, где ломается. Просите показать на экране реальный случай, а не рассказать в общем;
- открытые вопросы, потом уточняющие: «расскажите, как вы оформляете возврат», затем «что происходит, если товар уже списан». Отдельно спрашивайте про исключения, объёмы и частоту;
- от решения к потребности: на «нужна кнопка выгрузки в Excel» спросите, что с файлом делают дальше. Часто за ним стоит отчёт, который система может строить сама;
- измеримость: «быстро» и «удобно» переводите в числа, например «ответ за две секунды при ста одновременных пользователях»;
- фиксация: после встречи короткий протокол с решениями и открытыми вопросами, затем модель (BPMN, диаграмма последовательности, прототип) и пользовательские истории с критериями приёмки. Согласие подтверждается письменно.
Конфликт требований решайте не выбором стороны, а подъёмом к бизнес-цели и владельцу продукта, с приоритизацией по MoSCoW или по ценности.
Если опыта с живым заказчиком мало, так и скажите и разберите учебный или пет-проект: какие вопросы задавали и что поменялось после ответов.
Где спотыкаются
Рассказывают идеальный процесс без единого примера. Без истории «спросил вот так, выяснилось вот это» ответ звучит как пересказ учебника.
Записывают решение вместо проблемы. Через месяц кнопка готова, а задача пользователя так и не решена.
Общаются только с руководителем заказчика и не доходят до тех, кто будет работать в системе. Самые важные исключения обычно знает оператор, а не его начальник.