Здравствуйте, Oliver, Вы писали:

O>Привет всем,

O>Какова роль подробного технического задания в проектеразработки не маленькой системы?
O>Если проль решающая и проект 100% ждет большая задержка срока, в лучшем случае, в худшем — провал. Как тогда можно исправить ситуацию, заниямая при этом должность программиста?

O>Я буду очень благодарен за любой фитбэк.

O>Успешной недели!
Роль программиста — реализовать согласно некоторому описанию, из которого однозначно можно получить продукт.
Если ТЗ формулирует функционал неоднозначно, я считаю возможны следующие варианты — вернуть ТЗ на доработку вместе с замечаниями к нему, если аналитик возмущается (бывает и такое) — начинаешь сам дописывать ТЗ и требовать, чтобы это было оформлено как документ.
Затем требуешь, чтобы приемка велась согласано этому документу, и если находятся разногласия, то требуешь внесения изменений в ТЗ, и соответственно выход новых версий ТЗ. В случае, если захотят тебя сделать крайним при задержке сроком или провале, ты говоришь о количестве версий ТЗ, которые вышли за время разработки (это все задокументировано), что сказалось и на времени разработки, и на её качестве. Все разговоры с аналитиком надо переводить в электронную почту, чтобы в случае чего это можно было обнародовать тем, кто начнет на тебя валить все проблемы.
Сделать программера крайним это очевидно, программист же должен свою задницу прикрывать.
Я смог проработать по такой схеме 3 месяца, потом послал все нах** и уволился. Придурки...
Остальным же программерам почему то было пох, что их делают крайними, я с этим мириться не хотел Квалификация аналитиков оставляла желать лучшего, программисты же были люди довольно подкованными, просто несправедливая ситуация, наступившая прежде всего из-за попустительства менеджеров, которые уже совсем нихрена не хотели делать, или просто не знали что делать из-за недостаточной квалификации.