Дрельдев

А у нас хорошие аналитики.

а у нас солнце, море и девушки ;D

Мой скромный опыт подсказывает, что нефиг относится к свеженаписанному коду, как к чему-то нерушимому и неприкосновенному. Не всегда (а может, вообще никогда) не удается точно предвидеть, насколько удобным получится решение. Лучше всего - сделать хоть как нибудь и посмотреть, что получилось. Потом с учетом полученного опыта переделать. В конечном итоге все только выиграют.

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

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

Случаев несколько:
1. Считать, что заказчик сам не знает чего он хочет, и сделать, то, что ему понравится.
Плюсы:
— не надо тратить время на работу с заказчиком
Минусы:
— нужно быть очень умным, чтобы угадать, что хочет заказчик
— если ты не такой умный, то скорее всего тебя пошлют
— придется много думать
2. Надо правильно работать с заказчиком. Каждое изменение требований это отдельные $$ и дополнительное время. Все требования должны быть утверждены.
Плюсы:
— девелоперам думать надо меньше
— сроки имплементации сократятся
— больше вероятность того что заказчик будет доволен
Минусы:
— нужно тратить время на работу с заказчиком
— заказчик может устать от напора и забить на заказ
— стоимость проекта будет выше
3. ... или придумать требования самому и утвердить из с заказчиком, если ему лень думать о них.
4. Нанять менеджера проекта, и бить его ногами за неясные требования или отсутсвие таковых.

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

самая большая проблема во всем этом верна подмечена вот в этой фразе - "Программист по своей природе существо ленивое и самовлюбленное"...

/* Программист … код свой переписывать не любит */

Свой не любит. Чужой — вполне. Поэтому вот вариант решения: ротировать программистов, ухаха.

черезчер утрированный пример. вам в agile приходилось работать?

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

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