Что такое exact scope в контексте продукта
Что проверяют
Умеете ли вы превращать расплывчатое пожелание в границу работ, о которую можно опереться при оценке и приёмке. Вопрос поведенческий: интересует ваша дисциплина в договорённостях, а не знание термина.
Как отвечать
Сразу снимите двусмысленность: устойчивого термина в методологиях за этим словосочетанием нет, обычно им называют точно зафиксированный объём работ. Дайте своё рабочее определение и покажите, как вы его получаете.
Сильный ответ держится на четырёх вещах: список того, что входит, и отдельный список того, что не входит; проверяемые критерии приёмки для каждого пункта; допущения и зависимости, при которых оценка верна; процедура изменения границы.
Дальше уместен короткий случай по схеме ситуация, задача, действие, результат.
> «Интеграцию с внешним сервисом заказчик описал одной строкой. Я собрал сценарии, развёл их на обязательные и отложенные, вынес ручной разбор ошибок и обратную выгрузку в список того, что не входит, и на каждый сценарий написал критерии приёмки. При сдаче спор был один, и он закрылся ссылкой на этот список».
Полезно назвать инструменты: карта пользовательских историй, декомпозиция от цели, матрица трассировки требований, определение готовности. И обязательно про управление изменениями: новое требование не отвергается, оно проходит оценку и двигает либо срок, либо состав.
Где спотыкаются
Понимают точность как объём документации. Толстая спецификация без критериев приёмки границу не задаёт, спорить по ней можно бесконечно, потому что проверяемых утверждений в ней нет.
Забывают писать, что в работу не входит. Именно этот раздел снимает большую часть конфликтов на сдаче, поскольку подразумеваемое каждой стороной обычно разное.
Рассказывают про жёсткую фиксацию и запрет любых изменений. Это не сила, а негибкость: правильный ответ про то, что изменения проходят через понятную процедуру пересмотра сроков и состава.