Частенько, по долгу службы в том числе, приходится писать всякие ТЗ, а так же вникать и (командовать) создавать документацию по продуктам и решениям. ТЗ — для отношений с клиентом, документация — для разработчиков. Основные принципы, которые должны быть, коротко, под катом.
Вот допустим, как работает ваша супер-пупер цмс? Как объясните? «Нууу, у нас тут есть куча классов, шаблонзатор, логика, всякие интересные фишки и ваще она супер-пупер, ибо на xml (phptemplate, HTML::Template)» — часто приходится слышать от разработчиков. Оно, конечно, хорошо, ребятки, но нифига не понятно.
Объясните лучше, что происходит между тем, как я ввожу адрес в строку браузера, или ввожу в форму на страничке, и тем, что я вижу на экране.
Этот, казалось бы простой вопрос, иногда приводит в замешательство даже основных разработчиков архитектуры какого-либо приложения. Но, в результате, получается хорошая картина, по типу «тут у нас запускается бутстрап, разибрает строку гет-параметра, вызывает модули по такому-то правилу, собирает те-то шаблоны, выгружает в них данные и выводит хтмл. за вывод этой части страницы отвечает такой-то модуль, за другую — другой, и т.п.» Рисуем картинку, блок-схему, как кому удобнее, и все всем понятно, даже самим разработчикам яснее становится.
Со стороны клиента то же самое: я нажимаю эту кнопку, и куда я должен попасть? А потом что? Ага, вот это понятно, в отличии от описания «нам нужна современная супер-современная-система в пастельных тонах и с максимально удовлетворяющим потребности манагеров функционалом. за $5000, не больше».
В общем описывается
1. То, что будет на входе, и то, что получится на выходе
Это основа всего ТЗ. Делается перед проектом. Если первая часть не описана, или это невозможно сделать, то тут имеет дело политика и неразбериха. Браться за такой проект — себе дороже. Выйдешь в минус или вообще провалишься.
2. Как вход и выход связаны между собой
Вторая часть важна для разработчиков, по сути — документация на проект какая-никакая. Часто, не обязательна, но при передаче кода другому разработчику (если работает не один человек) НУЖНО описать. Иначе поимеете гемморой с разборками кода и его качеством, зачастую. Делается, обычно, по окончании проекта.
Описание может быть в свободной форме, в общем случае. Часто это получается в виде какой-либо схемы со сносками (для алгоритмов), либо в виде примерных скриншотов (в случае сайта). Ну и, если это официальный документ, то все это подробно описывается словами.
Вот так кратко можно описать минимально ТЗ и документацию. В общем — хватает в 90% случаев.
Автор: divan15
