Нужно ли вообще составлять ТЗ на сайт? Заказчик четко объясняет: «Хочу простой сайт. На нем должен быть каталог наших товаров, корзина, форма для заказа. Еще добавляем условия доставки, карту проезда к нам, информацию о компании и контактные данные. И все». Что может быть непонятно? Все обычно и даже рутинно.

Разработчик читает и четко представляет, что от него требуется. По его мнению, сделать необходимо так:

Когда работа уже почти закончена, заказчик присылает свой дизайн. Тут-то и становится понятно, что клиент видит задачу слегка по-другому. Если быть точнее, заказчик хочет, чтобы было так:

И что мы имеем? Разработчик, поняв задачи по-своему, выполнил оценку объема работ и сроков их выполнения, а также рассчитал стоимость всего проекта. Все это он озвучил заказчику. А теперь выясняется, что клиент хотел и по-прежнему хочет совершенно другого.

Если «вычесть» одно изображение из другого и сделать так называемый diff, то получится та самая разница между тем, чего ожидал заказчик, и тем, что запланировал разработчик. Отличия могут быть достаточно заметными:

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

Вот почему важно составить ТЗ. Его задача — минимизировать разницу между представлениями и ожиданиями клиента и исполнителя. Подробное техническое задание даст маленький diff, а плохое — большой.

Но не следует забывать о важном моменте: ТЗ никак не может (да и не должно) свести diff к нулю. И вот почему.

Дело в том, что и техзадание, и diff имеют свою стоимость. И понятие это шире, чем просто фиксированная сумма денежных средств. Это не только деньги и потраченное время, но и испорченные отношения, нервотрепка и так далее.

Стоимость diff'а — это стоимость всех доработок, всего того, что понадобится внести, хотя об этом изначально не было и речи. Стоимость ТЗ — это стоимость ТЗ, не больше и не меньше. Все просто: чем подробней и детальней было составлено техзадание, тем существенней его стоимость и тем меньше стоимость и величина diff'а. И наоборот.

Конечно, есть две крайности. Первая — это ситуация, когда ТЗ нет, совсем нет. И вот мы сделали фотохостинг клиенту, а он, как потом выяснилось, хотел полноценный интернет-магазин. Тут, конечно, diff окажется равным всему проекту, а его стоимость — соответственно, стоимости проекта: фотохостинг мы выкинем, а магазин сделаем. А стоимость технического задания тут нулевая.

Другая крайность — излишне детализированное ТЗ, по сути и являющееся самим проектом. Это когда в ТЗ есть абсолютно все вплоть до переменных, стилей CSS и кода. Тут, конечно, diff нулевой, а стоимость техзадания (считайте, реализации) равна стоимости всего проекта. Между этими крайностями, собственно, находится реальность. Она отражена вот на этом графике:

Синяя линия — отображение стоимости ТЗ, увеличивающейся с усилением детализации.

Линия красного цвета — отображение стоимости diff’а, снижающейся с ростом детализации.

Голубая линия отображает общую стоимость техзадания и переделок, которые предстоит выполнить. По графику видно, что у этой общей стоимости есть некое минимальное значение. Объяснение здесь достаточно простое: с определенной точки дешевле окажется что-то исправить и добавить «хотелки» клиента, чем пытаться составить идеальное ТЗ.

Отсюда делаем знаменательный вывод: задача ТЗ — хорошо описывать проект. Не больше.

Что нужно в ТЗ и чего там быть не должно

В любом случае ТЗ — это документ или часть договора. Не так важно, оформлялся ли этот договор с подписями и мокрыми печатями или был устным. Техническое задание оговаривает, какие именно работы должны быть выполнены. Очень важный нюанс: все, что описано в ТЗ, должно непременно допускать возможность оценить это объективно. То есть в техзадании должны быть объективные критерии, по которым можно будет судить о том, выполнен определенный пункт или нет.

Еще один вывод: в ТЗ не нужно обговаривать дизайн. Его невозможно оценить беспристрастно и объективно, ведь одному он понравится, а второму — нет. А общепринятых критериев, по которым можно отличить хороший дизайн от плохого, не существует.

Задача, к примеру, могла быть сформулирована так: «в голубых тонах и чтобы с облачком». Реализовать дизайн могли как откровенно ужасно, так и шедеврально. Как ни грустно, клиенту вполне может не понравиться даже самый интересный вариант. В общем, как ни выполняются объективные критерии, от негативного результата никто не застрахован.

Составляйте ТЗ так, словно знаете, что спор с клиентом будете решать в суде, причем на основе одного только текста задания. Судья, прочитав «сделать классный дизайн, который понравится заказчику», спросит у последнего, нравится ли ему получившийся дизайн. Клиент ответит, что не нравится, и все: вы как исполнитель продолжите свою деятельность через пару лет, не раньше. Очередной вывод: используйте «закрытые» формулировки, четко ограничивающие пределы вашей работы. Никаких «все должно быть удобно», ведь удобство — фактор не объективный, а субъективный.

Ценная фраза, которую непременно следует вписать в ТЗ, звучит, возможно, сурово: «Все, что не было оговорено, исполнитель выполняет на свое усмотрение». Она довольно логична. Да, клиенту нужен определенный продукт. Но заказчик не должен (да и не может) указывать разработчику, каким образом последнему следует все делать. Такой пункт, с одной стороны, уберегает от вмешательства клиента во все детали (исполнитель и так знает, какие пакеты ему использовать), с другой стороны, лишает заказчика возможности заговорить о «хотелках».

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

За источник вдохновения данной статьи стал текст товарища stg34 на хабре