Разработка технического задания (ТЗ) на программный продукт с точки зрения заказчика

[@shell643]

Хорошая стаья, своеобразный мануал по написанию ТЗ, но смутил один момент:

В заключении хотелось бы отметить, что по моему опыту самое лучшее ТЗ – это ТЗ написанное самим заказчиком или при самом активном участии заказчика...

Заказчиками порой выступают люди, далекие не то, чтобы от работы с программистами, да и просто от компьютеров. По-этому, на мой взгляд, доверять им написание ТЗ — просто преступление. А вот активное участие — должно быть обязательным.

[@Lieman]

— нам нужен сайт, где мы будем вывешивать свои туры
— Вы хотите сайт-визитку или портал с социальными возможностями
-нам нужен сайт, гд мы будем вывешивать свои туры, и чтобы подешевле

Вот так составляет ТЗ типичный заказчик-)

[@1Tiger1]

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

[@1Tiger1]

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

[@it_analitik]

Вообще, согласен. Следовало бы рассмотреть еще один фактор: адекватность Заказчика задаче написания ТЗ.
Просто по умолчанию предполагал, что Заказчик адекватен — опрометчиво, конечно же :)

[@1Tiger1]

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

[@it_analitik]

Старался писать проще, но, видимо, не очень получилось :)

[@ViseMoD]

Я тоже отмечу, что статья полезна для прочтения заказчиками, т.к. обозначает важность этапа разработки ТЗ.

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