Техническое задание – To be or not to be?

Прочитал статью Станислава Малкина – Для заказчиков: если нет ТЗ.

Вообщем-то написано всё грамотно, последовательно и понятно.
Сделан напрашивающийся вывод – техническому заданию быть – to be! (Однозначно! Я сказал! © Жириновский)

И быть ему, по мнению Станислава, следует по трем вариантам:

  1. ТЗ написано самим заказчиком.
  2. ТЗ написано разработчиком заказанной системы.
  3. ТЗ написано профессиональным составителем ТЗ.

Я думаю что первый вариант имеет право на жизнь только если у заказчика уже имеется опыт написания ТЗ, основанный на втором и/или третьем варианте.
Пока пропустим второй вариант и обратимся сразу к третьему. Насколько можно судить по статье – Станислав считает этот вариант самым приемлимым, особенно для начинающих заказчиков. Однако я вижу гораздо больше минусов чем указано в статье (собственно единственный указанный минус – дополнительные расходы на написание технического задания):

  • Качество.
    На основании чего заказчик сможет судить насколько качественно написано техническое задание. Четких критериев оценки нет. Да, существуют всяческие ГОСТ-ы по написанию технических заданий, но они очень быстро устаревают, да и для интернет технологий могут нести разве что лишь рекомендательный характер. Но ГОСТ-ы не позволяют определить качество написанного технического задания.
  • Время.
    Чтобы написать качественное техническое задание технический писатель должен в достаточной мере изучить предметную область. В чём же здесь минус спросите вы – а минус в том – что насколько бы ни было качественно, точнее подробно, написано техническое задание – конечному разработчику придется потратить тоже самое время на изучение.
  • Стандарты.
    Общих стандартов нет. ГОСТ-ы есть, никто не спорит, но ГОСТ-ы скорее определяют формат документа, а не содержание и форму.
    Представим ситуацию – заказчик приходит к разработчику с ТЗ, написанным третьей стороной. Если разработчик не новичек – у него уже должен быть свой внутрикорпоративный стандарт написания ТЗ. Естественно принесенное ТЗ ему не будет соответствовать и, скорее всего, разработчик начнет настаивать не переписывании ТЗ под свой стандарт, под свои привычки. Наверняка принесенное ТЗ будет дополнено и расширено для того, чтобы оно было понятно конечному разработчику.
    Итого – на этом этапе заказчик потеряет время, деньги и нервы.
  • Большой Брат.
    Как вести себя заказчику если, принеся написанное кем-то ТЗ, конечный разработчик скажет – “Кто вам написал это фуфло? Это бред! Вот как мы это видим…” Эффект от такого варианта написания ТЗ может быть обратный – заказчик не только не съэкономит свои нервы, время и вообщем-то деньги (наличие хорошего ТЗ экономит деньги – поверьте на слово 🙂 ), но и может серьезно ухудшить отношения с разработчиком.

Итак исходя из написанного напрашивается вывод – самый правильный способ написать ТЗ – создать тройку: разработчик – заказчик – техписатель (профессионал по составлению ТЗ). В таком случае, скорее всего, все будут довольны. Хотя практика показывает, что разработчики исключают третью сторону (техписателя) и составляют ТЗ самостоятельно, ну естественно при участии заказчика.

Ну и напоследок несколько ссылок:
HabraHabr
ТЗ: макеты или текст?
ТЗ для web-разработчика
Про ГОСТ-ы
Как писать техническое задание?!
Классика
Юрий Шиляев – Что такое хорошее ТЗ на сайт?

Tagged on:

6 thoughts on “Техническое задание – To be or not to be?

  1. Sergey

    1. Качество ТЗ определяется по окончании работы. Если работы 100% выполнена как хотел клиент, то скорее всего ТЗ было сделано хорошо.

    2. Технический писательно не должен учить предметную область. Вы дальше правльно написали: берется писатель и аналитик (человек знающий предметную область) и они вдвоем пишут. Сложные технические вопросы можно на прямую уточнить у разработчика.

    3. Стандарты, которые ГОСТы, хоть и старые, но хорошие. И их следовало бы адаптировать и применять. А у нас все делают свои внутренние стандарты. Разве это хорошо?

    4. А вести себя надо очень просто: если Вы клиент и Вы считаете, что ТЗ написано грамотно, то посылаем исполнителя и исчем дальше. Если Вам культурно аргументировали и доказали, что ТЗ плохое, то можете вернуться к писателю и заставить скушать ТЗ :).

Оставить комментарий

Your email address will not be published. Required fields are marked *