Заказная разработка. Надоело писать скучные ТЗ. Решили перейти на прототипирование. Понятно, что от какой-то, пускай и минимальной документации, совсем уйти не получится, но все вроде как выигрывают от этого. Заказчик наглядно видит пример того, что получит в итоге + возможность "потыкать в эт самое". Вовлеченность здесь самая важная метрика. Ну и нам меньше писать текстов которые заказчик как обычно подмахнет не читая, либо начнет читать и переспрашивать или еще хуже - примет, а позже начнет читать и переформулировывать все на свой лад. Однако вопрос у руководства возник - как эти прототипы утверждать у заказчика документально, чтобы в случае чего потом этим утверждением аргументировать факт принятых работ?
Логично. Но хотелось бы сократить объем ТЗ за счет присутствия прототипа. Например в некоторых местах описывающих блоки с элементами заменить на что-нибудь вроде "согласно прототипу" и т. д. То бишь у нас пока нет такого опыта внедрения прототипов в официальном порядке. До этого прототипы просто показывались заказчику, но не использовались в составе проектной документации.
Прототип это MVP (Minimum valuable product). Что бы заказчик оценил концепцию конечного продукта раньше, чем пройдут месяцы-года разработки и он поймет надо ему это или нет. Чаще всего прототипы пишутся на простейших фреймворках которые позволят показать сценарии и процессы, а затем утвердив приступают к написанию на конкретном фреймворке\языке\платформе с нуля.
То о чем пишите вы, это модель. Старшая сестра Mockup'a и Wirefram'a.
По ней можно делать простые проекты, но без ТЗ будете косячить. Как бы детально вы эту модель не нарисовали.
Всем надоело писать ТЗ, но надо.
Модель должна идти параллельно с ТЗ, как визуализация ТЗ.
Она позволяет упрощать донесение задач, или стейкхолдеров\фич проекта как то разработчиков так и до заказчиков у которых проблемы с чтением документов на большое количество страниц.
Прототип — это такая же часть проектных решений (по ГОСТ 34 макеты относятся к стадии Технического проекта), как и требования ТЗ. Чертежи же подписывают?
Прототип фиксирует решения:
1. Какие экраны будут у системы
2. Как будут взаимосвязаны экраны
3. Какие блоки будут на каждом экране
4. Каково будет взаиморасположение (компоновка) блоков на экране.
5. Каковы будут относительные пропорции блоков и элементов
6. Каково будет поведение блоков и элементов (если прототип динамический)
Но вы учтите, что прототипы не описывают требования к атрибутам качества, ограничениям, программным интерфейсам, платформе, алгоритмам и т.д., а это всё очень важные компоненты свойств промышленной системы / ПО.
Сначала есть тех.задание от клиента. Обычно оно выглядит как говно и по нему 50% всего проекта придется додумывать самим. Это нормальная ситуация и бороться с ней не нужно.
Решается так:
1) Берем список хотелок клиента (это он обычно ТЗ называет)
2) Пишем нормальное ТЗ (прототип входит в ТЗ)
3) Утверждаем
4) Работаем
Средний
Простой
Простой
