Технические задания и IT-системы: разбираемся, как ожидания мэтчить с реальностью
Больше половины IT-систем разрабатываются на основе некорректных или неполных требований. Такие проекты редко становятся успешными. Однако проблему можно решить, если выстроить правильное взаимодействие заказчика с разработчиками системы. В статье разбираемся, как это можно сделать, заменив текстовую документацию на другой способ фиксации требовани…
крутой подход!
Мы тоже во fuse8 отказались от плоского ТЗ в пользу более удобных и понятных инструментов. На некоторых проектах интерфейсные решения накидываем в гугл таблицах :)
Два вопроса:
1. Сколько времени занимает в среднем разработка графического ТЗ для проектов со сроком разработки от 6-ти месяцев?
2. Нет ли проблем с клиентами, когда при обсуждении графического ТЗ они начинают обсуждать его не как ТЗ, а как UX-прототипы? ) Если есть, то как работаете с этим.
2. Ой жиза. Классическая проблема, когда UX прототип начинают обсуждать как итоговый UI и просят поправить скругление на кнопке. :D Важно вовремя и грамотно объяснять заказчику какой уровень детализации обсуждаем и зачем, тогда проблем не должно быть.
1. По длительности. Где-то х1,5 к обычному текстовому описанию с таблицами.
Но в больших системах, чаще всё помодульно делается. То есть решение дробится на куски, и затем уже на каждый кусок отдельно будет готовиться граф-ТЗ.