Техническое задание на разработку: что необходимо и достаточно для MVP если инициатор продукта не из ИТ

Техническое задание на разработку: что необходимо и достаточно для MVP если инициатор продукта не из ИТ

Последние проекты в которых мы участвовали в разных ролях, консультирование, трекинг и менеджмент стартапов от 0 до MVP, проектирование новых ИИ инициатив в крупных компаниях и корпорациях - все про хождение по полю вокруг одной и той же грабли: писать код по повествовательному описанию идеи заказчиком.

Между «идеей» и «кодом» есть мир требований, много слоев уточнений что и как надо запрограммировать программисту что бы сразу попасть в сердечко пользователю.

В классике, например, у Карла Вигерса в «Разработка требований к ПО» — это целая экосистема:

- бизнес-требования,

- бизнес-правила,

- пользовательские требования,

- атрибуты качества,

- системные требования,

- функциональные требования,

- внешние сервисы и ограничения.

И только потом

- спецификация требований к ПО

которую можно отдавать разработчикам.

Был проект где столкнулись с ситуацией: проектирование клиентского пути почему то заказчик ожидал от front-end девелопера и считал его джунишкой, из-за того что тот в отсутствии требований и user-flow делал «как чувствовал» и в сжатые сроки делал не то что молча ожидал заказчик. В общем идеи, проджекта и команды разработки недостаточно.

Ввиду ситуации на рынке у