Часто ли вам приходится переделывать задачи из-за неверного тех. задания

Вам хорошо, вам пишут ТЗ )))

Отталкиваемся от того, что ТЗ пишет тот, то умеет его писать (например, Аналитик)
А вот пользователь или руководитель вряд ли что-то понимают в этом...

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

очень часто аппетит приходит во время еды
изначально имеем одну задачу, после ее реализации хотим еще в итоге после 2-х, 3-х изменений то с чего начали вообще не нужно )

Чуть реже, чем всегда. Даже если ТЗ ставлю себе сам.

Задачи ставятся пользователем, не всегда понимающем, как работает 1С. Иногда сделаешь по описанию, отдашь.... Оказывается нужно было делать вообще другое. Поэтому сейчас перед тем как делать всегда общаюсь с непосредственным инициатором, обговариваем вместе всё до кнопок на форме включительно.

Уже давно, поняв, что в будущем поставленная задача может иметь расширение и развитие функционала, если позволяет время, делаю решение более универсальным и более тонкими в настройках, в 80% случаев хватает за глаза. Но есть иное! Когда говорят пожелания, ты их реализовываешь, иной раз достаточно объемная работа, при реализации все довольны, кайфую пару месяцев над тем как удобно, как круто, а потом оказывается, что данная разработка более не нужна по каким-то причинам.

Да бывает и что напишут ТЗ(набор хотелок), потом по нему делаешь, говорят неправильно, показываешь ТЗ, пишем дополнение к ТЗ, в итоге первоначальный замысел обрастает костылями, а потом пользователь смотрит на все это и понимает что хотел совершенно не этого. Вот тогда все это откатывается на начало, пишется новое вменяемое ТЗ и делается то, что было изначально нужно за 10% времени затраченного на первое ТЗ. Но тут уж, кто платит...

На фикси. В большинстве случаев самостоятельно расставляю приоритет задачам.

Если всплывают косяки, из-за ошибок в ТЗ, то такие заявки живут в конце очереди с минимальным приоритетом. И на то есть 3 причины:
1. Другие заказчики не должны страдать из-за чужих ошибок и ждать пока кто-то брутфорсит программиста до получения желаемого результата.
2. Таким образом я не даю себя брутфорсить. Заказчик пару раз подождав по несколько дней/недель, обычно соображает, что так каши не сварить и начинает более ответственно подходить к постановке задачи.
3. Жаловаться на разработчика в этом случае никто не побежит - нет смысла, просто будет поднят тикет с первоначальной задачей и передан руководству.

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

Ну, а для особо непонятливых всегда в запасе есть анекдот:

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