Быть или не быть техническому заданию?
Когда задумывается новый сайт, все кажется таким понятным. Удобный интернет-магазин должен делать сотни продаж в сутки, яркий лэндинг – внушать доверие и заманивать посетителей, визитка – вызывать острое желание позвонить именно по этим телефонам и т.д. Это стандартные и утрированные требования заказчиков к сайтам. А еще они довольно пространные и для их воплощения существуют сотни решений. Не факт, что исполнителю удастся с первого раза сделать сайт именно таким, каким он видится заказчику. Только если первый не обладает экстрасенсорными способностями. Для того чтобы не гадать на кофейной гуще и составляется техническое задание – ТЗ. Это своего рода мост, на котором встречаются две стороны и мирно пьют кофе, обсуждая будущий проект.
Представьте, что вы работаете без ТЗ
Многие сегодня идут на большой риск – думая, что экономят время, сразу кидаются в работу. Давайте пофантазируем и возьмем для примера не сайт, а дом – его легче представить.
Приходит заказчик и говорит: «Хочу большой красивый дом за городом, в который мне и моей семье захочется приезжать на выходные». Отлично, у исполнителя кроме строительного образования есть практический опыт, и даже собственный загородный дом, который он сам строил и потому обожает. Думается, что задача не стоит выеденного яйца и возводится двухэтажный дом с гаражом и оранжереей. Приезжает заказчик и начинается самое интересное. Он не может понять, что будет делать с женой в таком большом доме, он представлял что-то одноэтажное, и с садом, а не оранжереей – с цветами все равно возиться будет некому.
Как при отсутствии ТЗ понять – кто из двух сторон не прав? А не правы оба – один дал нечеткое задание, а второй не потрудился узнать, что в представлении заказчика значит «большой…дом, в который захочется приезжать». Исполнитель решил, что «собаку съел» на строительстве загородных домов, и попался. Теперь нужно сносить постройку и возводить новую, ломать оранжерею и заниматься садом. В пассиве потраченное время, деньги, недовольство заказчика, а в активе… ничего, разве что горький опыт и наука на будущее.
Нужно ли говорить, что переделать программную часть сайта ничуть не легче, чем перестроить дом? Сэкономив один-два дня на разработке четкого технического задания, можно потерять месяц на том, чтобы переделать сайт в соответствии с требованиями заказчика.
ТЗ – это документ на все случаи жизни
Многие думают, что заменить ТЗ может договор. Но в договоре проект обычно не рассматривается детально. Он предназначен для обсуждения общих моментов: назначение исполнителей, сроков выполнения работ, стоимости.
В техническом задании речь идет о том, как будет выглядеть сайт, причем, что важно, рассматриваются те вопросы, которые поддаются объективной оценке. Как это? Представьте, что вы закончили работу и выносите ее на обсуждение третьему лицу. Приглашенный эксперт, прочитав ТЗ и оценив сайт, сможет точно сказать, какие пункты задания выполнены, а какие – нет. Например, можно описать в ТЗ, что на главной странице будут один слайдер, навигационное меню, место для двух рекламных баннеров, ссылка на каталог товаров, «полезности» в виде календаря, калькулятора, 1-2 ссылок на какие-то страницы сайта в «подвале» и т.д.
Такие детали, которые не поддаются объективной оценке, например дизайн, не описываются в ТЗ. Всем нужен эргономичный и привлекательный дизайн, но представления о его воплощении всегда будут субъективными. «На вкус и цвет…», помните, да? Если говорить о дизайне, то он оговаривается отдельно – веб-дизайнер плотно работает с заказчиком, показывает ему бренд бук, оговаривает шрифты, цвета, возможность использования векторной графики и т.д. Полученная информация учитывается разработчиком сайта.
Один важный пункт, который должен быть в ТЗ – «все, что не предусмотрено в техзадании, выполняется на усмотрение исполнителя». Задача разработчика – подать этот пункт правильно, не оскорбляя заказчика. Он не должен бояться, что за свои деньги купит что-то не то, в то же время исполнитель защищает себя от ненужного вмешательства в его работу.
Если отвечать на вопрос, заданный в заголовке, то техническому заданию однозначно быть. Только так можно максимально уменьшить количество расхождений начального замысла и конечного результата.