Резюмирую:
1. Гораздо более результативно будет уделить 3 часа одной компании, чем по часу 10-ти. Мало того, что это структурирует Ваши требования, но и определит формат решения, по которому Вы уже далее будете запрашивать стоимость реализации.
2. Качество проработки вашей задачи напрямую зависит от сотрудника IT-компании — Вашего собеседника. Бизнес-аналитик будет лучшим из возможных.
3. Определить компетентность можно по неочевидным вопросам, которые задаются не просто так.
4. Недостаточная проработка на начальном этапе может привести к страданиям и боли в конце.
Полностью соглашусь с автором, не много от себя добавлю.
1 . Проработаное ТЗ всему голова, исправление до реализации ТЗ стоит намного дешевле чем во время реализации его. Бизнес требования, функциональные и не функциональные требования, архитектура данного проекта, метрики нагрузки и роста.
2. При заключение договора с подрядчиком/исполнителем нужно прописать ключевые метрики: требование к коду, требование к дизайну. Механизм к диплою на прод и откатака версии с прода.
3. Время реакции на исправления багов
4. Время по реагированию на инцинденты и штрафные санкции.
5. Описать в договоре процедуры передачи авторского права, передачи части работы по графику и приемку данной работе.
Основные моменты добавил, если что-то упустил коллеги меня дополнят.
Да, однозначно! Время реакции тоже прям болячка распространенная. Еще вот любименькое, когда MVP запускается, там баг на баге и подрядчики такие "Ну мы же говорили! Поправим на след. неделе". И пока поправляют, там новых проблем насыпало...
А исправление багов уже идет за счет исполнителей а им не выгодно это выполнять.
MVP не подразумевает баги, MVP это минимальный функционал но рабочий
Если грамотно MVP сделали, то да. Что не всегда есть в реальности)
На пример можете привести кейс
А вот даже есть такой! Там надо в деталях расписывать) Позже займусь и опубликую) Спасибо за идею!)