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

S - Situation. Наш контекст. Организация захотела мобильное приложение. Исходная потребность была конкретной и разумной: навигация по территории, карта аудиторий с расписанием ивентов, минимальный функционал взаимодействия с пользователем. Компактно, реализуемо, полезно. Главное - снижает операционную нагрузку на сотрудников.

T - Task. Задача Всё пошло по хорошо нам известным рельсам - собрать требования, зафиксировать скоуп, запустить разработку в рамках бюджета. Всё казалось прозрачным - была чёткая боль и понятное решение.

A - Action. Что произошло В процессе сбора требований каждый стейкхолдер добавлял "ещё одну нужную вещь". Личный кабинет, пуши, интеграция, новостная лента... Скоуп рос органично, ведь каждое требование само по себе выглядело логично. Никто не говорил "давайте сделаем всё". Просто каждый говорил "а вот это же несложно, правда?". В итоге прототипирование поглотило весь ресурс и до MVP мы не доползли - ни бюджета, ни, честно говоря, желания.

R - Result. Что это показало Проект в полном объёме был нереализуем с самого начала, просто никто не зафиксировал этого явно. Исходный контекст (S) не был закреплён как ограничение и остался фоном, а не рамкой. Вот здесь и живёт главная ценность STAR для меня, как аналитика - это не способ красиво рассказать историю постфактум, а инструмент удержания контекста в моменте.

Situation в моей работе - это не просто "что происходит", а скорее зафиксированные обстоятельства, относительно которых оцениваются все последующие требования. Если S не закреплена явно и не поднимается при каждом новом "а давайте добавим", то скоуп начинает расти сам по себе, и остановить его рост становится сложно

Простой вопрос, который теперь я задаю себе: "Это требование помогает решить исходную задачу или расширяет её?" Вроде и банально звучит, да вот работает только если S зафиксирована и лежит на видном месте, а не в голове у аналитика. Причем, заметьте, кроме проверки на контекст ещё можно прикинуть A, то есть потенциальные задачи, вызываемые расширением требований. И если R, то есть закрытую изначальную боль я также имею в зафиксированном виде, то отлично поможет вопрос о новых задачах из-за расширения скоупа: "Если на реализацию этого требования уйдёт n часов, насколько это приблизит нас к желанному результату?". В большинстве случаев оказывается, что изначальный план реализации и так нас приближает к результату, а все дополнительные хотелки - пожалуйста. Но в какой-нибудь следующей итерации =)

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