Мой скромный опыт подсказывает, что нефиг относится к свеженаписанному коду, как к чему-то нерушимому и неприкосновенному. Не всегда (а может, вообще никогда) не удается точно предвидеть, насколько удобным получится решение. Лучше всего - сделать хоть как нибудь и посмотреть, что получилось. Потом с учетом полученного опыта переделать. В конечном итоге все только выиграют.
именно так и происходит трещина а потом пропасть между заказчиком сайта и исполнителем.
программист требует ТЗ именно такое, какое он сам представляет себе. А заказчик - в лучшем случае простой юзер, а зачастую даже представления не имеет что и как. и прогер его ломает на своем техническом слэнге. в итоге заказчик либо сдается и говорит сделай потом посмотрю, или просто уходит и говорит что никогда не выдаст дочь за такого как этот заумник очкарик...
ребята, я полагаю: как говорит закон торговли? клиент всегда прав...
и другая сторона: для того чтоб заказчик дорубился что и как, то на фирме надо просто держать юзера пройдоху, который может на пальцах разьяснить что и как и найти общий язык с заказчиком... как говориться: свой парень.
как там говорится — «любые прихоти за ваши деньги» :-)
т. е. разумно было бы оговаривать подобные изменения в договоре
написать проще чем сделать, но всё же… и не такое формализуют
Случаев несколько:
1. Считать, что заказчик сам не знает чего он хочет, и сделать, то, что ему понравится.
Плюсы:
не надо тратить время на работу с заказчиком
Минусы:
нужно быть очень умным, чтобы угадать, что хочет заказчик
если ты не такой умный, то скорее всего тебя пошлют
придется много думать
2. Надо правильно работать с заказчиком. Каждое изменение требований это отдельные $$ и дополнительное время. Все требования должны быть утверждены.
Плюсы:
девелоперам думать надо меньше
сроки имплементации сократятся
больше вероятность того что заказчик будет доволен
Минусы:
нужно тратить время на работу с заказчиком
заказчик может устать от напора и забить на заказ
стоимость проекта будет выше
3. ... или придумать требования самому и утвердить из с заказчиком, если ему лень думать о них.
4. Нанять менеджера проекта, и бить его ногами за неясные требования или отсутсвие таковых.
в нашей компани зачастую приходится подходить к программерам не с тз, а с почти с выполненным заданием :) это почти шутка. понятное дело - без хорошо продуманного проекта сделать его - проект - или невозможно или получается больше гемороя...
черезчер утрированный пример. вам в agile приходилось работать?
а слишком глубокие проникновения в моск заказчика я предпочитаю у некоторых своих людей отбивать. потому как не стоит лезть в матан, если два числа сложить не можешь.
Если вы о творческой личности у руля - то попробуйте рулить сами :)
Хотя наличие самого себя у руля, не гарантирует вам того что вы сами с собой договоритесь (вы ведь тоже можете оказаться творческой личностью) :)
Если говорить о заказчиках, то все зависит от человека и его опыта (заказчика конечно же). Не хотите мороки, делайте четкое ТЗ. Если заказчик хотел шуруповерт (но не знал этого в начале), а получил отвертку - это будет для него уроком. В следующий раз он сам подумает о подробном ТЗ, чтобы получить желаемое (хотя бы задумается, что же я хочу, чтобы не получилась опять отвертка), а не тупо даст задачу "сделайте мне то, не знаю что".
Дрельдев