И знаете, что самое обидное? Код был нормальный. Подрядчик — адекватный. Никто не воровал, не сливался, не халтурил.
Всё сломалось на одном документе. На ТЗ.
Сейчас разберу по косточкам, как одна бумага сожгла двести тысяч. И как не повторить.
🧨 Что было в том ТЗ
ТЗ занимало полторы страницы. Клиент гордился краткостью.
«Сделать личный кабинет пользователя. Регистрация, профиль, история заказов. Дизайн — как у конкурента, ссылку прикладываю. Сроки — месяц».
Всё. Точка.
Звучит понятно? Для человека — да. Для разработчика — это не ТЗ. Это пожелание на салфетке.
Потому что за каждым словом здесь спрятана пропасть.
«Регистрация» — по почте? По телефону? Через Госуслуги? С подтверждением? С капчей?
«История заказов» — откуда данные? Есть API? Или их надо руками заводить? А фильтры? А экспорт?
«Как у конкурента» — как именно? Вся логика? Или только цвета?
Каждый такой вопрос — это часы работы. А их никто не посчитал заранее.
💸 Как салфетка превратилась в 200 тысяч
Подрядчик оценил проект по тому, что прочитал. Месяц, фикс, поехали.
А дальше начался ад уточнений. В процессе. Когда половина уже написана.
— «А, вам нужна ещё авторизация через телефон? Это отдельный модуль». — «История заказов из вашей 1С? Мы думали, вы данные вручную дадите. Нужна интеграция». — «Как у конкурента, но с вашими фишками? Это переделка».
Каждое «а, ещё вот это» — переработка. Каждая переработка — доплата или конфликт.
Проект растянулся на три месяца. Бюджет вырос вдвое. Отношения испортились. В финале — суд по переписке в мессенджере и обоюдная ненависть.
И вот тут ключевое, что бизнес не понимает.
Проблема была не в коде. Она была в коммуникации. Всегда так.
🎯 Почему ТЗ — это не про технику, а про договор
Люди думают, ТЗ пишут для программиста. Нет.
ТЗ пишут, чтобы две стороны одинаково представляли результат. Это фиксация ожиданий. Юридически и по-человечески.
Я был по обе стороны стола. Нанимал подрядчиков — и сам разгребал чужие ТЗ на горящих проектах.
И вывод один: чем подробнее договорились на берегу, тем меньше крови в процессе.
Что обязано быть в нормальном ТЗ:
— Список функций с конкретикой. Не «регистрация», а «регистрация по email + подтверждение по ссылке». — Источники данных. Откуда приходит информация, в каком формате. — Что НЕ входит в проект. Отдельным блоком. Это спасает нервы больше всего. — Критерии готовности. Как поймём, что сделано. — Кто принимает работу и по каким пунктам.
Звучит занудно. Зато не стоит 200 тысяч.
🛠️ Что надо было сделать клиенту
Перед стартом — заплатить за проектирование. Да, отдельно.
Это пугает бизнес: «Как, платить за документ, который ещё не продукт?».
Объясняю. Час аналитика на этапе ТЗ экономит десятки часов переделок в разработке. Это самая дешёвая страховка в IT.
Если подрядчик сразу называет фикс-цену по салфетке — это красный флаг. Хороший спец скажет: «Давайте сначала распишем, потом оценим».
Тот, кто соглашается на всё сразу, либо не понимает объём, либо заложит риски в цену втридорога.
И ещё. Клиент боялся «грузить деталями». Думал — профи сам догадается.
Профи не телепат. Догадки — это и есть те самые двести тысяч.
📌 Вывод, за который платят
В IT горят не на сложных задачах. Горят на несформулированных.
Самый дорогой баг — это баг в понимании. Он не ловится тестами. Он вылезает в конце, когда деньги уже потрачены.
Хотите сэкономить — вкладывайтесь не в скорость старта, а в ясность на входе.
Я регулярно разбираю такие кейсы вживую. И вот тут разница между Дзеном и соцсетями: здесь я не всегда успеваю ответить в комментариях, а в моём Телеграме мой Телеграм можно кинуть своё ТЗ и я скажу, где в нём дыры на деньги. В ВК сообщество ВК тоже разбираю вопросы подписчиков — заходите, спрашивайте предметно.
Если у вас уже завис проект из-за кривого ТЗ, или нужен аудит перед стартом — работы и контакт для связи тут: портфолио на сайте. Лучше потратить час на разбор, чем двести тысяч на переделку.
А теперь к вам: скиньте в комментариях самую расплывчатую формулировку из ТЗ, которую вам подсовывали. Разберём вместе, где там зарыты деньги.