Фаннур, спасибо что прокомментировал статью. При этом дал достойный комментарий.
Я подумаю над твоим предложением)))

Юрий, спасибо за комментарий.
“З – это совместно проработанное решение. ” – полностью согласен. Обращу внимание что тут важны способы проработки. =)
“То, что имеем на этапе 1, это не более, чем набор функциональных требований.” – Тут смотря что называть этапом 1. Ну и по моему опыту набор Функциональных требований как минимум без Бизнес требований и Не функциональных требований хотя бы верхнеуровневых не даёт системного понимания продукта. Надеюсь что вы это так же понимаете.

Смотрите, Набор функциональных требований:

Необходимо разработать Транспорт, позволяющий мне как человеку доехать до офиса.
Я хочу иметь возможность посмотреть кто позади меня едет и обгоняет что бы не попасть в аварию
Я хочу иметь возможность поворачивать и т.д.

Если дать подрядчикам это оценивать, то кто-то будет оценивать машину, кто-то велосипед, кто-то самокат, а кто-то вообще самолёт или катер.

При этом если добавить не функциональные требования:
Необходимо что бы я своё расстояние от дома до офиса в 20 км проезжал не более чем за 20 минут
Необходимо что бы ТС мог передвигаться только по дорогам так как в принципе моя дорога до офиса асфальтирована и не содержит перекрёстных переправ и т.д.
Тут уже можно понять что Катер и Самолёт нам не нужен.

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

Конечно пример синтетический, но мне кажется демонстративным.

Роман, спасибо за комментарий. Можете пожалуйста написать как вы поняли из статьи в результате чего у вас возникает проблема выбора подрядчика с разными оценками? Либо описать конкретную ситуацию из вашей практики и я постараюсь тогда вас направить.

Сергей, спасибо за комментарий. По мне, заказные Спайки были бы конечно достаточно хорошим решением. Часто проблема возникает на этапе определения источника финансирования или простыми словами: Кто и от куда платить будет))

Было бы интересно прочитать продолжение – некое реально проведенное исследование, содержащее следующие ингредиенты.

– Опрос хотя бы 100, а лучше 1000 потенциальных заказчиков, которые стоят на пороге создания своего “ИТ-решения”. В чём основные проблемы заказчиков, пытающихся найти подрядчиков?

– Разница между подходами в США, Европе и России. Где больше слушают клиента и делают то, что ему нужно, а где пытаются доказать клиенту как лучше?

– Индикаторы того, что заказчик реально знает, что ему нужно на ранней стадии. Например, наличие “бэклога”, где заказчик систематизировал результаты опроса рынка, хотя бы на 100, а лучше на 1000 конечных пользователей. А нужно ли вообще ТЗ составленное по ГОСТу? Или достаточен бриф с хорошей систематизацией результатов опроса, весами и объективно получающейся структурой и пониманием приоритетов?

– Работа с концепцией MVP. Когда и заказчик и подрядчик понимают, что создаваемый продукт – это только начало эксперимента и проверки рабочих гипотез. Насколько введение концепции создания MVP (каким бы полным не был продукт) снижает психологическое напряжение заказчика и подрядчика от завышенных ожиданий?

Матвей, большое спасибо вам за отзыв! В голове есть много полезных мыслей, которыми надо делиться, но никак системно пока не получается делать статьи. Такие отзывы мне помогают больше писать и более системно. =)