IнTересности

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

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

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

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

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

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

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

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