Консультанту на заметку

[egorius]

Объём любой части техзадания должен быть пропорционален сложности её реализации.

Например, если некоторое требование реализуемо очевидным образом, незачем описывать его на трёх страницах со скриншотами. Но более опасны «подводные камни» — когда одно простое с виду предложение в техзадании может обернуться тысячью-другой строк кода из-за того, что требование не ложится на архитектуру системы. Ошибка в оценке сроков реализации в таком случае практически гарантирована.

Comments

[zlobny-reader.livejournal.com]

Это точно о техническом задании, а не о техническом проекте, спецификации, постановке к разработке?
У нас обычно ТЗ содержит функциональные требования в терминах, понятных закачкику. То есть про реализицию там может ничего не быть. Опять же, с использованием разных инструментов, в дальнейшем, реализация можеть быть как очевидной, так и сложной.
Хотя я согласна, что подробно описывать, что 2+2 должно возвращать всегда 4 - не стоит ;-)

Лично меня всегда "радует" желание заказчиков включить в ТЗ "система должна работать в режиме 24x7". На всякий случай, даже если речь идет не о жизненно важной системе.

[egorius.livejournal.com]

Имеется в виду тот документ, который приходит разработчику (у нас это именуется «функциональным дизайном», например). Наверное зря я обозвал его ТЗ.

[loveyoupeople.livejournal.com]

также недопустимо включать в ТЗ или как его там фразы типа: по желанию заказчика в систему будут включены модули синхронизации данных с внешними базами (Блумберг, Шлюмберг, Хэзэнберг,...)

особенно следует избегать многоточий

[egorius.livejournal.com]

Синхронизация данных вообще неприятная штука, а уж с внешними системами... И почему-то всё время люди, отвечающие за эти внешние системы, как на подбор неадекватны и курят какую-то странную траву.