PsolaoЧтобы бы вы посоветовали, чтобы такого избежать?
Во-первых, подумать, в чём именно моя проблема в этой ситуации и чего именно избежать. Я бы избегал таких вещей как "пришлось переделывать бесплатно" или там "пришлось вкалывать быстро-быстро-быстро", а в самой по себе ситуации "заказчик дал непродуманное и по факту неверное ТЗ" - больше его проблема. Это не значит, что её не надо решать мне. Это значит, что пока заказчик считает это моей проблемой и моей виной - решить её не удастся. Вот когда заказчику, конкретным людям, станет выгодно этого избегать - тогда можно научить их, как это делать.

Во-вторых, среди представителей заказчика критично найти кандидатуры на две роли:

а) Человек, который хорошо знает, как на самом деле всё сейчас работает (подсказка: директора чаще всего этого не знают)

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

Если найдётся человек, совмещающий то и другое - это просто идеально. Но обычно первого стоит искать среди подчинённых второго.

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

В-третьих, с некоторых пор я принял для себя железное правило - идти небольшими итерациями, не ломающими уже сделанного. Самая гадкая ситуация, в которую только может попасть разработчик - это когда один отдел заказчика кричит "новая версия мне всё сломала, я не могу работать с ней", а другой - "в новой версии то, что мне позарез нужно, я не могу работать без неё". Двигаясь такими итерациями, разработчик решает две задачи: во-первых, если с новым функционалом возникли проблемы, можно просто остановиться, не пользуясь им и работая по-старому, во-вторых, проблемы если возникают, то аналогично "небольшими порциями по итерациям", а не одной горой сразу.