Вы нашли разработчика, обсудили доработку сайта, договорились на 50 тысяч рублей. Через неделю слышите: «А вот эта кнопка — это отдельная задача, ещё 15 тысяч». Ещё через пару дней: «Адаптивная вёрстка под мобильные — мы это не обсуждали, плюс 20 тысяч». В итоге вместо 50 тысяч платите 150, а в голове один вопрос: «Где я ошибся?»
Если узнали себя — вы не одиноки. По моим наблюдениям, в 7 из 10 случаев конфликты между заказчиком и разработчиком возникают именно из-за «плавающей» сметы. Давайте разберёмся, почему это происходит и как обезопасить себя от неожиданных расходов.
Почему смета растёт как на дрожжах
Главная причина — отсутствие детального технического задания. Вы с разработчиком обсудили задачу на словах: «нужно добавить фильтр товаров». Звучит просто и понятно. Но дьявол кроется в деталях.
Для вас «фильтр товаров» — это возможность выбрать цвет и размер. Для разработчика в базовую смету входит только вывод чекбоксов. А вот:
- Фильтрация по нескольким параметрам одновременно — отдельная задача
- Сохранение выбранных фильтров при переходе на другую страницу — ещё одна доработка
- Красивая анимация и адаптация под смартфоны — тоже не входит в базу
- Счётчик товаров рядом с фильтром — дополнительные 5 часов работы
Вторая причина — вы сами не знаете, чего хотите. В процессе работы приходят новые идеи: «А давайте ещё вот тут добавим!» Каждая «мелочь» — это время разработчика, а значит, деньги.
Третья причина — недобросовестность исполнителя. Некоторые специально занижают первоначальную смету, чтобы получить заказ, а потом «вспоминают» про дополнительные работы. Но таких меньшинство. Чаще проблема в банальном непонимании между сторонами.
Чем грозит размытая смета
Помимо очевидного удара по бюджету, вы получаете букет неприятностей:
Сорванные сроки. Когда в процессе выясняется, что нужно больше работы, разработчик пересматривает график. Запуск, который планировали через две недели, откладывается на месяц или больше.
Конфликты и стресс. Постоянные споры «это входило в смету или нет» выматывают обе стороны. Вместо конструктивной работы — взаимные претензии и испорченные нервы.
Недоделанный результат. Когда бюджет исчерпан, а работы ещё много, приходится выбирать: либо доплачивать, либо получить сайт с урезанным функционалом. Оба варианта не радуют.
Потеря прибыли. Пока вы разбираетесь со сметой, ваши конкуренты уже запустили новые фичи и забирают клиентов. Каждый день задержки — это упущенная выручка.
Как составить смету, которая не взлетит в космос
Шаг 1: Составьте подробное ТЗ — на бумаге
Не поленитесь потратить время на детальное описание задачи. Используйте скриншоты, схемы, примеры с других сайтов. Чем подробнее опишете — тем меньше недопониманий.
Пропишите каждый элемент:
- Что должно происходить при клике на кнопку
- Как должна выглядеть страница на телефоне
- Какие уведомления получает пользователь
- Что видит администратор в панели управления
Да, это долго. Но это инвестиция, которая окупится сторицей.
Шаг 2: Разбейте проект на этапы с фиксированной ценой
Не делайте одну большую смету на весь проект. Разделите работу на логические части: «Разработка каталога — 30 тысяч», «Интеграция оплаты — 25 тысяч», «Личный кабинет — 40 тысяч».
Так вы:
- Контролируете расходы на каждом этапе
- Можете остановиться или скорректировать план после любого этапа
- Видите прогресс работы наглядно
Шаг 3: Требуйте детализацию от разработчика
Попросите расписать смету по часам: сколько времени на вёрстку, на программирование, на тестирование. Если разработчик отказывается или называет только общую сумму — это красный флаг.
Нормальная смета выглядит так:
- Вёрстка страницы каталога — 4 часа — 6 000 рублей
- Программирование фильтров — 8 часов — 12 000 рублей
- Адаптация под мобильные — 3 часа — 4 500 рублей
- Тестирование — 2 часа — 3 000 рублей
Итого с запасом понятно, за что платите.
Шаг 4: Пропишите в договоре порядок изменений
Обязательно включите пункт: все изменения сметы — только в письменном виде, с обоснованием и согласованием. Никаких устных договорённостей в мессенджерах.
Установите правило: если в процессе выяснилось, что нужна дополнительная работа, разработчик составляет дополнительную смету, вы её изучаете и либо соглашаетесь, либо отказываетесь от этой части.
Шаг 5: Заложите резерв 15-20%
Даже при идеальном ТЗ могут всплыть нюансы. Если договорились на 100 тысяч, держите в запасе ещё 15-20 тысяч на непредвиденные расходы. Это нормальная практика в разработке.
Практические советы из окопов
Используйте таск-трекеры. Заведите проект в Trello, Asana или Jira. Каждая задача — отдельная карточка с описанием, сроком и стоимостью. Это дисциплинирует обе стороны.
Проводите еженедельные созвоны. Даже 15-минутный разговор раз в неделю помогает держать руку на пульсе и вовремя ловить расхождения в понимании задач.
Требуйте промежуточные демо. Не ждите конца всей работы. Пусть разработчик показывает результат каждые 3-5 дней. Так вы вовремя скорректируете направление и не переплатите за переделки.
Просите обоснование каждого «это не входит». Когда слышите фразу про дополнительную работу, спрашивайте: «Почему? Покажи в нашей переписке, где мы это исключили». Если разработчик прав — заплатите. Если пытается накрутить — у вас есть аргументы.
Изучите базовые термины. Не нужно становиться программистом, но понимать разницу между версткой и программированием, фронтендом и бэкендом стоит. Это защитит от манипуляций.
Чёткое ТЗ — спокойный сон
Размытая смета — это не злой умысел разработчика и не ваша глупость. Это следствие неправильно выстроенной коммуникации. Инвестируйте время в подготовку, требуйте прозрачности, фиксируйте договорённости — и сможете избежать 90% конфликтов.
Помните: хороший разработчик заинтересован в чётком ТЗ не меньше вашего. Ему тоже не хочется спорить и переделывать работу. Если специалист уклоняется от детализации — это повод задуматься о смене исполнителя.
Если нужна разработка или доработка сайта с прозрачной сметой, чётким планом и без скрытых доплат — обратите внимание на Разработчика Дениса Бунакова. Работа с детальным ТЗ, поэтапной оплатой и понятным распределением ответственности — это основа комфортного сотрудничества, когда обе стороны знают, чего ожидать.
