Здравствуйте

Вопрос скорее к опытным спецам... Начав вникать в систему Java, я то и дело натыкаюсь на мнение что разработка продукта складывается из двух основных этапов. Это моделирование, затем кодирование... и для этого придумали такую хорошую штуку как UML. Замечательно! Но есть одно НО (имхо). Когда речь идет о вменяемом ТЗ или коробочной версии, этот вариант - то что доктор прописал. А если идет долгоиграющий проект... и в середине пути заказчик вдруг спохватывается - "А, блин, мы забыли еще такую фичу!"... А она, оказывается, может внести коренные изменения во всю идеологию проекта, заложенного еще в лохматых годах. Как быть? Некоторые коллеги по цеху могут сказать - "Ну и что...??? Любой каприз за Ваши деньги! Переделаем, догоним... и перегоним!". Но у меня возникает опасение что может произойти снижение мотивации конечных исполнителей проекта. И, как следствие, провал. И деньги тут уже ни причем. Бывали ли Вы в такой ситуации... и есть ли советы по выходу из таких кризисов. 
Прошу прощения если оффтопик. 

maxlab, "конечные исполнители проекта" - "рядовые" кодеры? 
Я как раз в такой ситуации(с постоянными сменами требований).
имею несколько заметок:
1) снижение мотивации - не обязательный финал; альтернатива - повышение мотивации создания гибкой структуры. Тут от человека зависит  - сможет ли он/она подойти философски к постоянным(как часто происходят такие сюрпризы?) переделкам. Сможет - будет все нормально.
2) повышая модульность и универсальность можно значительно снизить время/затраты на (пере|до
|раз)работку и "снижение мотивации".
Собственно, я не "опытный спец", просто хотил заметить, что не всё так плохо 

1) Все должно обговариваться в контракте.
2) 


Вы должны при проектировании предвидеть такую ситуацию. Нужно систему строить так, что бы её можно было расширить с минимальными затруднениями. И опять же, такие моменты тоже нужно обговаривать в контракте.



И верно. Главное что деньги капают.  ... Вам разве не все равно "что" работать?   

3)


Чей мотивации? У программистов не будет мотивации?    Зарплата - это мотивация. Есть зарплата - есть мотивация.   


Нет, я не бывал. Совет всегда один: будет грамотное управление проектом - будет все хорошо.

ИМХО.

С нужно писать думая на перёд. Тоесть 99% проектов приходится дописивать или вносить сильные изменения.Поэтому нужно с самого начала писать гибкий код.   

maxlab, почитайте что-нибудь про экстремальное программирование (XP). Многие идеи будут полезны, при решении вышей задачи.