Anastasiya Borisyuk

У меня был несколько иной вопрос. Понятно, что второй подход более правильный и дает более прогнозируемые результаты.
В начале статьи вы говорите о том как минимизировать риски иных ожиданий заказчика. Ну и получается, что посыл статьи такой "ребят не проводите аналитику просто ради аналитики, включайте туда метрики, вот вам шаблон МВП, делайте нормальную аналитику с проверками гипотез и по фен-шую и будет всем счастье".
По мне так, в начале озвученный вопрос - на чьей стороне проблема, однозначно у подрядчика.
От него зависят будут у Ивана работать ли «классические» аналитики (похуже) или «продуктовые» (получше), которые и качественные вопросы задают и помогают бороться с проблемой, а не фиксировать ее на бумаге.
Задача подрядчика помочь заказчику понять что ему именно подход 2 нужен.

В начале статьи вы задаёте вопрос «Как провести этап аналитики и составить ТЗ, чтобы ожидания заказчика и исполнителя совпали?» и потом «на чьей стороне возникает проблема, как ее устранить?». Судя по гипотетической ситуации приведённой в статье у вас сработали риски с оценкой - дизайн был основан не на реальных данных, плюс не было выявлено критериев приемки ни на этапе аналитики, но в ходе изменений макетов и урезания функционала. Понятно, что все упирается в бюджеты, но можно ли это считать все таки недоработками со стороны подрядчика?