Как общались с заказчиком на ранней стадии проекта?
Что проверяют
Умеете ли вы выявлять задачу, а не записывать пожелания, и фиксируете ли договорённости.
Как отвечать
Опишите процесс, а не факт встреч.
1. Кто участвует. Первым делом собирается список заинтересованных сторон: кто платит, кто пользуется, кто согласует, кого затронет изменение. Разговор с одним человеком почти всегда даёт искажённую картину.
2. Проблема, а не решение. Заказчик обычно приходит с формулировкой решения: «нужна кнопка выгрузки». Задача аналитика докопаться до проблемы: зачем выгрузка, что с ней делают дальше, как обходятся сейчас, сколько это стоит времени. Часто выясняется, что нужна не кнопка, а отчёт по расписанию.
3. Цели и критерии успеха. По какому измеримому признаку поймём, что сделали правильно. Без этого приёмка превращается в спор о вкусах.
4. Границы. Что входит в систему, а что остаётся снаружи, с какими системами будет обмен. Контекстная диаграмма на одном листе снимает половину недопонимания.
5. Ограничения и допущения: сроки, бюджет, законодательные требования, существующая инфраструктура. Допущения фиксируются письменно, потому что именно они потом оказываются неверными.
6. Проверка понимания. Пересказать своими словами, показать прототип или набросок экрана, пройти сценарий вслух. Дешевле переделать эскиз, чем реализацию.
7. Фиксация. После каждой встречи письменное резюме с решениями и открытыми вопросами, отправленное на подтверждение. Устная договорённость через месяц вспоминается всеми по-разному.
Про технику разговора: открытые вопросы вместо наводящих, не подсказывать ответ, спрашивать про исключения и про то, что происходит, когда что-то идёт не так. Именно ветки ошибок обычно и не описаны.
Где спотыкаются
Записывают пожелания как требования, не выясняя цель.
Общаются только с одним представителем заказчика.
Не фиксируют договорённости письменно.
Обсуждают только основной сценарий и забывают про исключения.