Как Вы планируете работу с клиентом ?

[Mulder_1]

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

я не против ТЗ , я прекрасно понимаю, что без него не обойтись , но чаще всего ТЗ ставит в жесткие рамки как исполнителя так и заказчика,

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

[Black_Monah]

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

Проблема ТЗ по адрессу: http://www.thebeautiful.narod.ru/smile9.htm советую посмотреть

[Alochka]

Проблема ТЗ по адрессу: http://www.thebeautiful.narod.ru/smile9.htm советую посмотреть

Просто супер!!!! Я так смеялась... :lol: :lol: :lol:

[Mulder_1]

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

Проблема ТЗ по адрессу: http://www.thebeautiful.narod.ru/smile9.htm советую посмотреть

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

в худшем случае , когда ты показывешь ТЗ заказчику ( и при этом еще и скажешь что за ТЗ он должен заплатить ) он может ответить : "я в этом ничего не понимаю , вот вы умные вы и делайте" , и кстати он будет прав ... в этом случае вся ответственность ложится на исполнителя (что есть плохо) но когда заказчик увидит уже конечный результат он скажет : "здесь работает только половина того , что нужно", и опять он будет прав ! , но при этом денег он болше (за доработки) платить не захочет... все .. хана ... проект провалился, и как следствие возник конфликт с заказчиком ...

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

[Black_Monah]

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

Дело в том что я не утверждаю что ТЗ необходимо писать по ГОСТ.Оно должно быть написано в той форме которая понятна и заказчику, что он хочет, и разработчику, что нужно делать.
Это определенной степени защита разработчика от самодурства заказчика и защита заказчика от самодурства разработчика. т.е. они имеют определенные правила игры.

Прилагаю файл с разного вида ТЗ, не мои разработки скаченные с интернета, откуда просто не помню скачивал год или два тому назад.