Почти каждый фейл проекта начинается одинаково: команда честно закрывает задачу, а бизнес потом разводит рукам

Почти каждый фейл проекта начинается одинаково: команда честно закрывает задачу, а бизнес потом разводит руками — «это вообще не то».

Проблема не в коде и не в тестах. Проблема в том, что перепутали потребность и решение.

3 шага, чтобы не попасть в эту ловушку на собесе и в работе:

1) Спросите «зачем?»
Не «что вы хотите сделать?», а «какую боль это снимет?».
Если ответ звучит как готовый фичефлаг, кнопку или экран — вы пока копаете решение, а не потребность.

2) Отделите цель от промежуточного шага
«Нужен новый дашборд» — это не цель.
Цель может быть такой: сократить время реакции саппорта, снизить потери лидов, убрать ручные ошибки.
Дашборд — только один из вариантов.

3) Проверяйте, можно ли измерить результат
Хорошая потребность всегда оставляет след в метриках: быстрее, дешевле, меньше ошибок, выше конверсия.
Если измерить нечего — очень вероятно, что формулировка слабая.

На собесе это часто проверяют простым вопросом:
«Почему вы выбрали именно это решение?»
Сильный кандидат не защищает первое пришедшее в голову. Он показывает логику: боль → цель → варианты → выбор. 🧠

Запомните жестко, но полезно: хороший аналитик не тащит в проект чужое решение. Он вытаскивает настоящую потребность.