Бывали ли случаи изменения требований заказчиком после разработки

Что проверяют

Не столько сам случай, сколько вашу реакцию на изменения. Смотрят, воспринимаете ли вы правки как норму работы и есть ли у вас процесс, который защищает и сроки, и отношения с заказчиком.

Как отвечать

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

Что важно показать в рассказе:

• выяснили причину, а не только формулировку: изменился рынок, пришло требование регулятора, заказчик увидел прототип и понял, что нужно другое. Настоящая причина часто меняет решение;
• оценили влияние: какие уже сделанные части затрагиваются, сколько стоит переделка, что сдвинется по срокам. Оценка даётся в терминах объёма и рисков, а не «сделаем как-нибудь»;
• дали заказчику выбор: расширить сроки, урезать другой объём, выпустить в две итерации. Решение принимает он, но с понятной ценой каждого варианта;
• зафиксировали письменно: обновлённое требование, история изменения, новая версия документа или задачи. Это защищает всех, включая заказчика;
• сделали выводы на будущее: раньше показывать макеты и прототипы, резать объём первой версии, отделять стабильное ядро от изменчивой части.

Хорошо, если добавите разницу между уточнением (мы неверно поняли, правка бесплатна) и новым требованием (объём вырос, это отдельная работа). Умение проводить эту границу и есть зрелость аналитика.

Где спотыкаются

Рассказывают историю с обидой на заказчика. Тон важнее фактов.

Говорят «мы просто сделали как просили» без оценки влияния. Это выглядит как отсутствие процесса.

Не называют, чем всё закончилось. Результат нужен, даже если он неудачный: важно, какой вывод сделан.