ТЗ, постоплата и эффект «бесконечных правок» ⚡️

Завершил интересный кейс на OpenCart: разработал систему проверки серийных номеров для диагностического автооборудования.

Суть задачи:

Сложная логика — в зависимости от статуса номера сайт предлагает разные сценарии: обновить ПО, сменить дилера или связаться с техподдержкой. Полный цикл автоматизации первичной консультации клиента.

Как всё прошло (грабли и опыт):

  1. Проект сдан в срок. Но так как сделка была на «постоплате», процесс приемки затянулся.
  2. Снежный ком правок. После сдачи начались «мелкие доработки», которых не было в ТЗ. Сделал быстро, чтобы закрыть вопрос. Следом — еще два дня ожиданий и новый список хотелок.
  3. Ловушка лояльности. Согласился внести финальные изменения бесплатно, чтобы уже получить расчет. В итоге работа выполнена, переделана, а ощущение такое — будто оплату пришлось «выпрашивать», хотя ТЗ закрыто на 101%.

Вывод для себя и коллег:

Даже если клиент адекватный, отсутствие предоплаты размывает границы ответственности. ТЗ — это не просто документ, это броня. В следующий раз — только четкое разделение: этап по ТЗ принят/оплачен, а новые идеи — в новый тикет.

Как вы боретесь с желанием «быстренько доделать за рамками ТЗ», чтобы скорее получить оплату? 👇