Распространенные ошибки при составлении ТЗ на создание сайта
Распространенные ошибки при составлении ТЗ на создание сайта
«Распространенные ошибки при составлении ТЗ на создание сайта» Конечно, когда мы набираем хорошую команду, шансы получить хорошее ТЗ у нас возрастают в разы. Но остаются факторы риска. Первый из них, когда мы начинаем раньше времени работать над ТЗ.
Поскольку, когда мы пишем ТЗ — очень конкретное мелкое текстовое описание, то должно быть так: мы в голове представляем картинку, картинку переводим в текст, дальше ожидаем, что клиент прочитает текст, и создаст в голове картинку, которая была у нас. — Но это какие-то чудеса телепатии, которые не работают. Поэтому мы договариваемся сначала «на пальцах», на «бумажных тиграх», и только после этого начинаем заливать всё это в цемент.
Вторая проблема — очень часто заказчики, проектировщики упускают из ТЗ описание интерфейсов. Интерфейс — важная часть продукта, его необходимо описывать.
Далее проблема с плохим ТЗ . Если ТЗ идёт полотном структурированного текста — это плохо. В таком ТЗ невозможно разобраться. Идеальное ТЗ должно идти древовидным списком.
Очень плохо, если ТЗ становится бессистемным. То есть вся информация перемешана — тут и функционал, и цвет кнопочек, вдруг вклинивается требование к дизайну.
Кроме того, плохо, когда в ТЗ начинают сквозить дыры в логике. Об этом мы уже говорили, — не должно быть чёрных дыр и хвостов, всё должно быть связано логически.
ТЗ не должно быть слишком примитивным. — Это значит, что оно ничего не описывает. Например, 28 страниц для ТЗ — это очень мало даже на крохотный сайт. На живой сайт ТЗ не может быть слишком простым, поскольку тогда оно не описывает ничего, оно не даёт нам реализовать качественный продукт.
Также неверное вставлять в ТЗ куски кода, адовые схемы, всю xml-выгрузку. — Это неправильно, поскольку такое ТЗ никто никогда не прочитает. И худший случай будет, если клиент возьмёт ТЗ на 400 страниц, и попросите ответить на следующий день, а на следующий день скажут, что «принимаем». И ты смотришь ему в глаза, и понимаешь, что он не читал его.
Да и не может прочитать его обычный человек.
Ещё плохой момент, когда ТЗ начинает писать «кто попало». — Когда ТЗ пишет менеджер, клиент или секретарь, который зашёл кофе попить, ничего путного не выйдет. ТЗ — очень важный структурный документ с множеством взаимосвязей, — его должны писать профессионалы. Потому как клиент может сформулировать требования со своей стороны, и мы часто так работали, что мы «на вход» получали именно ТЗ от клиента.
Но мы его воспринимали, как некий входящий бриф, как почву для размышлений, который мы разбираем на атомы и сами уже формируем формат документации.
Кроме того, ТЗ не должен писать менеджер, потому как менеджер и проектировщик находятся немножко на разных полюсах разработки. У менеджера главные ценности — сроки, бюджеты. У проектировщика в голове лежит это условное качество продукта, то есть, соответствие продукта заявленным задачам заказчика.
И, когда мы объединяем все эти функции в одном человеке, то получается, что, когда во время работы ему будут прилетать задачи его направленности, он будет принимать их важность приоритетной, а написание ТЗ будет откладывать в долгий ящик, который со временем вылетит, и «аукнется» так, что все потом полягут.
В итоге мы понимаем, что ТЗ должен писать человек, обладающий данной компетенцией, — который будет, в некотором роде, составлять оппозицию менеджеру.