ТЗ, постоплата и эффект «бесконечных правок» ⚡️
Завершил интересный кейс на OpenCart: разработал систему проверки серийных номеров для диагностического автооборудования.
Суть задачи:
Сложная логика — в зависимости от статуса номера сайт предлагает разные сценарии: обновить ПО, сменить дилера или связаться с техподдержкой. Полный цикл автоматизации первичной консультации клиента.
Как всё прошло (грабли и опыт):
- Проект сдан в срок. Но так как сделка была на «постоплате», процесс приемки затянулся.
- Снежный ком правок. После сдачи начались «мелкие доработки», которых не было в ТЗ. Сделал быстро, чтобы закрыть вопрос. Следом — еще два дня ожиданий и новый список хотелок.
- Ловушка лояльности. Согласился внести финальные изменения бесплатно, чтобы уже получить расчет. В итоге работа выполнена, переделана, а ощущение такое — будто оплату пришлось «выпрашивать», хотя ТЗ закрыто на 101%.
Вывод для себя и коллег:
Даже если клиент адекватный, отсутствие предоплаты размывает границы ответственности. ТЗ — это не просто документ, это броня. В следующий раз — только четкое разделение: этап по ТЗ принят/оплачен, а новые идеи — в новый тикет.
Как вы боретесь с желанием «быстренько доделать за рамками ТЗ», чтобы скорее получить оплату? 👇