Да, замечательно и правильно, когда дело касается юзерфлоу. Но всё, что описано в статье, точно не серебряная пуля, и не ноухау.
Визуальными прототипами/макетами невозможно или сложно показать, например: - нефункциональные требования и SLA; - интеграции; - системные кейсы-вычисления; - зависимость состояний элементов от наборов параметров. Точнее можно упороться и накопипастить одинаковых макетов, где будет отличаться единственная строка, но лучше описать в ТЗ.
Способ начинать с макетов/прототипов прекрасен, но совсем без ТЗ жизнеспособен, если есть много если, напр.: - говорим о стандартных штуках, типа магазинов на битриксе; - внутри команды есть экспертиза по компонентам, которые затрагиваются в проекте; - нет необходимости поддерживать проект другой командой.
Способ начинать с макетов - прекрасен, если у клиента в принципе есть понимание как должен работать софт. Тогда именно на основании прототипирования мы ТЗ и пишем. Но чаще у клиента в голове есть потребность, то-есть функционал и он понятия не имеет какие кнопочки ему нужны в приложении. Типичный пример: "нам надо реализовать НДС в услугах нашего банка" и всё и думай теперь. Клиент понятия не имеет, нужно ли ему пользовательское приложение в принципе для реализации этой задачи.
Да, замечательно и правильно, когда дело касается юзерфлоу.
Но всё, что описано в статье, точно не серебряная пуля, и не ноухау.
Визуальными прототипами/макетами невозможно или сложно показать, например:
- нефункциональные требования и SLA;
- интеграции;
- системные кейсы-вычисления;
- зависимость состояний элементов от наборов параметров. Точнее можно упороться и накопипастить одинаковых макетов, где будет отличаться единственная строка, но лучше описать в ТЗ.
Способ начинать с макетов/прототипов прекрасен, но совсем без ТЗ жизнеспособен, если есть много если, напр.:
- говорим о стандартных штуках, типа магазинов на битриксе;
- внутри команды есть экспертиза по компонентам, которые затрагиваются в проекте;
- нет необходимости поддерживать проект другой командой.
Да, согласен, ТЗ нужно по многим причинам.
Мы тут скорее про подход разработки для заказчиков, которые все вот хотят свой проект запустить, но ждут "когда напишется ТЗ", а оно все не пишется.
Когда речь касается SLA и бекенд-штук - то да, без четких требований и логических схем не обойтись.
И мы любим такие проекты, когда заказчик приходит с четким пониманием и требованием 💚
Способ начинать с макетов - прекрасен, если у клиента в принципе есть понимание как должен работать софт. Тогда именно на основании прототипирования мы ТЗ и пишем.
Но чаще у клиента в голове есть потребность, то-есть функционал и он понятия не имеет какие кнопочки ему нужны в приложении.
Типичный пример: "нам надо реализовать НДС в услугах нашего банка" и всё и думай теперь. Клиент понятия не имеет, нужно ли ему пользовательское приложение в принципе для реализации этой задачи.