Так ли важно ТЗ?

[Bakti9rov]

Так ли важно ТЗ?

Такой сабж...

Вопрос - так ли важно ТЗ (техническое задание, т.е. какой то письменный документ, исчерпывающе описывающий требования клиента и детализацию проекта), если пожелания заказчика меняются на ходу, когда идет постоянный диалог с клиентом?

Так вот - насколько и в каких ситуациях нужен формальный ТЗ, в чем преимущества и недостатки ТЗ-шного подхода к работе с клиентами?

 

[tf]

с тз недостаткой нет
без полно, поработай паймеш

 

[magic]

Главное, чтобы ТЗ не становилось самоцелью.

 

[whirlwind]

Если пожелания заказчика меняется на ходу, за это должен платить заказчик, а не программист, которого прожект-менеджер заставляет засиживаться после 20:00. Если вы практикуете XP и используете SVN, отношение к выкрутасам типа

>если пожелания заказчика меняются на ходу

должно быть вполне предсказуемое. Даже если вы не используете ни XP, ни SVN, ни что либо еще, наличие ТЗ является весомым аргументом в ответ на округление глаз заказчика при срыве сроков. О каких сроках может идти речь, если сроки были поставлены по конкретному ТЗ, а в последствии

>пожелания заказчика меняются на ходу

Вообще конечно все зависит от клиента. Если у вас мало клиентов, то можно обойтись и без ТЗ, т.к. заказчик знает что вы тратите на него бОльшую часть времени и готов оплачивать свою лень по поводу планирования и согласований. Если клиентов и проектов много, и выход за рамки сроков чреват срывом других проектов, то ТЗ просто необходимо. ИМХО.

PS. составление ТЗ - это еще одна статя, за которую приходится платить заказчику. И заказчик очень рад не платить, т.к. все равно аукнется на исполнителе, который будет работать ночами, пытаясь выдержать сроки. А для заказчика будет лишний повод упрекнуть исполнителя в недобросовестности. Вам нужны угрызения совести по этому поводу?

PPS. Кста, по поводу интерактивности общения с клиентом. Я то всегда думал, что представитель клиента нужен для уточнений, которые не были оговорены в ТЗ, а не для того что бы менять требования после обеда.

 

[Qwerty]

Недостатком ТЗ-шного подходя является то, что готовое согласованное ТЗ могут отдать другому, кто меньше денег запросит...
Но здесь ничего не поделаешь, как я понимаю?

 

[jonjonson]

Я так думаю, что под ТЗ многие совмещают две несовместимые вещи:
1) функциональные требования (что, но не как должно быть получено);
2) технические требования (как нечто должно быть реализовано).
Если первое по любому должно быть прозрачно и понятно оговорено, то второе проблема разработчика.
Первое может быть декларировано, но возможна ли реализация его станет известно на основе второго. А второе может меняться в течение всего проекта.

 

[Qwerty]

jonjonson
Второе далеко не всегда пишут (к сожалению), слишком уж подробно получается, быстрее спрограммировать... А потом через месяц ломать голову.
Насколько я знаю, именно это называется ТЗ, а не то, что многие думают.

Даже первый пункт рождается порой в таких муках... Когда система достаточно сложная, заказчик даже общими словами сформулировать не может толком. Вот в таких случаях и жалко терять заказ после написания ТЗ (или как его называть?).

Есть предложения, как удержать заказчика от недобросовестного ухода к другому разработчику после написания ТЗ (п.1)?

 

[Scud]

Надо просто брать за ТЗ деньги...

 

[jonjonson]

Qwerty, да нужно брать деньги за функциональные требования, так как их выяснение - это уже работа. Иногда только после их выяснения и анализа возможно вообще представить, решаема ли задача как таковая.

 

[Активист]

ТЗ - план работы прораммистов (а) - т.е. порядок и дисциплина.
Если в группе разработчиков нет плана-значит это не разработчика а так, стадо.

имхо!

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

 

[jonjonson]

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

 

[alenmau]

оно необходимо хотябы для того что-бы сначала просчитать стоимость проекта и сроки его выполнения

Если клиент не д... то он сформулирует что ему надо.

 

[StUV]

ТЗ - план

5

 

[bgm]

Bakti9rov
Вопрос - так ли важно ТЗ (техническое задание, т.е. какой то письменный документ, исчерпывающе описывающий требования клиента и детализацию проекта), если пожелания заказчика меняются на ходу, когда идет постоянный диалог с клиентом?

Так вот - насколько и в каких ситуациях нужен формальный ТЗ, в чем преимущества и недостатки ТЗ-шного подхода к работе с клиентами?

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

P.S. Немного сумбурно, но вообще уже давно назрело желание отразить собственное наболевшее понимание важности ТЗ отдельной статьей.

 

[Активист]

jonjonson
> Активист, уж чем не является ТЗ так это планом работы.
Это смотря как определять понятие слова "план"

План для менеджмента - это по большей части сроки.

План для программистов - практически тоже самое что и для строителей, своего рода "Проект с пояснительной запиской".