5 правил хорошего ТЗ
Пишем Техническое Задание.
Когда благое дело превращается в идиотизм.
Правила для заказчиков и исполнителей.
Правило первое. Определитесь для кого вы пишите ТЗ. Логично предположить что ТЗ пишется для технического специалиста, который в дальнейшем будет выполнять это задание. Отсюда вывод: все что господин заказчик гордо называет Техническим Заданием, таковым конечно же не является, т.к. заказчик не знаком с процессом разработки сайтов и не способен составить грамотное ТЗ. Как следствие мы получаем жутко путанное описание и хорошо если это описание на 3-5 страничек, но встречается и 30 страниц беспорядочного потока мыслей от заказчика. Эти с позволения сказать «технические задания» просто разрушают мозг. Предположим, что вы все таки получали такое ТЗ и думаете что вы «попали»... не расстраивайтесь, все будет совсем плохо если при любом удобном поводе заказчик будет отсылать вас к такому ТЗ. Если говорить честно, то и среди технических специалистов, людей способных сделать удобное и понятное ТЗ крайне мало и необходимо внимательно относится к его составлению, не отдавая все на откуп технического писателя. Каждый специалист будет искать в ТЗ информацию для решения своих задач, поэтому ТЗ должно быть грамотно структурировано.
Правило второе. Пишите в ТЗ только, то что можете себе представить. Не надо выдумывать слова - если у вас в голове нет картинки, то велика вероятность, что вы получите совсем не то что хотели.
Правило третье. Не выдумывайте функциональность, которая сейчас не нужна. Явным признаком того, что вы хотите больше чем Вам нужно, но даже понятия не имеете что же вы всетаки хотите являются выражения «и т.д.» Как правило «и т. д.» появляется в тексте когда у составителя кончается полет фантазии. И составитель предлагает исполнителю придумать самостоятельно что же ему делать. Не знаю как Вам, но мне кажется это достаточно глупо заставлять исполнителя придумывать себе задание.
Правило четвертое. Примеры, примеры, и еще раз примеры. Приводите примеры данных! Если мы делаем Интернет-магазин, то в карточке товара возможно будут данные о размерах или цвете, приводите возможные значения, граничные значения или количество отображаемых значений.
Правило пятое. Поясняющие картинки, скриншоты, UML-диаграммы и даже рисунки от руки — в общем все что может графически пояснить задание будет очень и очень кстати. Главное не переборщить и как говорят врачи «не навредить», запутав ситуацию только сильнее.