Дефект требований.

Дефект требований - это самый страшный дефект, который вообще может существовать в мире разработки софта. Дефект требований - это когда проектировщики все правильно спроектировали, программисты все правильно запрограммировали, тестировщики все правильно протестировали. А в результате заказчик говорит что все работает «не так». Такая ситуация уже сама по себе неприятна. А теперь добавьте к этому, что дефект требований вылазит во время эксплуатации, или, в крайнем случае, во время приемки заказчиком (customer acceptance tests). Как учили нас все классики, начиная с дедушки Брукса - это самое неподходящее время для появления дефектов, потому что цена их устранения в это время самая высокая. И вот вместо того, чтобы радостно делить премии и отправляться на очередной team building с пивом по поводу успешного завершения проекта, вы сидите в выходные дни, без оплаты и лихорадочно пытаетесь переделать половину системы не разрушив при этом другую половину.
Хорошо, если ваша команда работает по классической методе. В этом случае вы дружно идете мочить аналитика проекта. А если вы работаете по какому ни будь Agile (XP, Scrum, etc.)? Представитель заказчика - священная корова, его бить нельзя. Даже когда он говорит: «Извините ребята, я вчера поговорил с финансовым директором. Так вот, все эти юзерстори работают неправильно. Все надо переделать». Хоть бить этого парня и нельзя, но надо постараться от него избавиться. В том, что следующую итерацию вам придется переписывать старые юзерстори виноват именно он. А отвечать за это придется скорее всего вам.