Из чего складывается цена доработки сайта

Поменять телефон в шапке — 15 минут, добавить поле в форму заявки с передачей в CRM — 6 часов. Разбираю, что попадает в оценку кроме написания кода, какие 7 обстоятельств умножают часы, как выглядят сметы на задачи 3 разных масштабов и что можно сделать со своей стороны, чтобы платить меньше.

Поменять телефон в шапке сайта — 15 минут. Добавить в форму заявки одно поле и научить его доезжать до CRM — 6 часов. Обе задачи в письме клиента выглядят одинаково: «мелочь, поправьте, пожалуйста». Разница в 24 раза возникает не от настроения подрядчика.

Цена доработки сайта складывается из 2 множителей: часовая ставка команды и количество часов на задачу. Со ставкой все прозрачно, она публикуется и обсуждается один раз. Все споры и все удивление в счетах живут во втором множителе — в часах. Поэтому дальше речь в основном про них: что попадает внутрь оценки кроме собственно написания кода, какие 7 обстоятельств превращают час в день, как выглядят 3 реальные по структуре сметы, как описать задачу, чтобы оценка не выросла вдвое, и что проверить до оплаты.

Сразу оговорюсь про ориентиры. Все расчеты в статье — модельные: они показывают структуру сметы. Прайс конкретного проекта из них не получить. Реальные цифры зависят от состояния вашего сайта, и как раз про это половина материала.

Почему доработки считают в часах

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

Отсюда 2 модели оплаты. Сколько стоит сам час работы и как ставки различаются у разных исполнителей — в разборе про стоимость часа программиста; здесь речь о том, откуда берется количество этих часов.

Фиксированная цена работает там, где задача полностью описана и предсказуема: подключить онлайн-кассу по типовому сценарию, собрать лендинг по готовому макету, настроить выгрузку в маркетплейс. Подрядчик берет на себя риск и закладывает его в цену — обычно 20–40% сверху. Если задача окажется проще ожидаемого, эта разница остается у него.

Оплата по времени работает там, где объем выясняется в процессе. «Почему-то не приходят письма с формы», «нужен фильтр по 12 параметрам», «сделайте, чтобы остатки подтягивались из 1С» — здесь честная оценка возможна только после того, как кто-то залез внутрь и посмотрел. Риск не перекладывается на цену, зато клиент платит ровно за сделанное. Чтобы итог не стал сюрпризом, заранее договариваются о пороге: при отклонении от оценки больше 15–20% работа останавливается до согласования.

Граница между моделями на практике проходит примерно по 30–40 часам. Задачи меньше этого объема выгоднее делать по времени с предварительной оценкой, крупные и хорошо описанные — по фиксированной смете после короткого проектирования.

Ставка при этом зависит не столько от сложности задачи, сколько от формата сотрудничества. У нас в Design Lab это выглядит так: абонемент от 10 ч. в месяц — 3500 руб./ч., от 50 ч. — 3000 руб./ч., от 100 ч. — 2700 руб./ч. Оценку даем за 1 рабочий день, задачи от 40 ч. считаем как проект с фиксированной стоимостью. Логика простая: в постоянном проекте команда уже знает код, не тратит время на погружение и не перестраивает график ради срочной задачи. Подробный разбор ставок на рынке и того, почему оценки у разных исполнителей расходятся в разы, есть в отдельном материале про стоимость часа программиста Битрикс.

Что на самом деле входит в оценку

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

Возьмем эту задачу и разложим ее целиком.

Итого 6 часов, из которых на программирование ушло 2. Если убрать из сметы тестирование и аккуратную выкладку, получится 3 часа — и примерно 50% вероятности, что форма перестанет отправляться с iPhone, а заявки на сутки уедут в никуда. Экономия в 15 тыс. руб. на фоне суточного простоя формы заявок — плохая сделка.

Есть еще 2 статьи расходов, которые в смете обычно не видны, но в часы попадают: переключение между задачами (разработчику нужно время, чтобы вспомнить чужой код) и ожидание ответов от заказчика. Вторая полностью в ваших руках, и о ней — ниже.

7 обстоятельств, которые умножают часы

Одна и та же формулировка задачи на 2 разных сайтах стоит по-разному, и вот от чего это зависит.

• Состояние кода. Типовой компонент с настройками правится за час. Тот же компонент, скопированный в шаблон сайта и переписанный 3 разными подрядчиками, сначала нужно прочитать. Правки в ядре CMS — отдельная история: они всплывают в самый неподходящий момент, обычно при обновлении.
• Есть ли тестовая копия. Без нее любая заметная правка делается либо ночью на рабочем сайте, либо с риском положить его днем. Разворачивание копии — это 2–6 часов один раз, которые потом окупаются на каждой задаче.
• Интеграции. Как только в задаче появляется 1С, CRM, платежный шлюз или служба доставки, время растет кратно: нужны доступы, тестовый контур, разбор чужого формата обмена и ожидание ответа второй стороны.
• Объем и качество данных. Фильтр по характеристикам товара делается за 20 часов, если характеристики заполнены у всех товаров одинаково, и за 60, если у половины каталога они лежат в текстовом описании.
• Количество согласующих. Задача, которую утверждает один человек, и задача, где макет смотрят маркетолог, коммерческий директор и собственник, — это разные задачи. Каждый круг правок стоит часы.
• Срочность. «Нужно сегодня» означает, что кто-то откладывает свою текущую работу. За это берут надбавку, и это обычная практика рынка. Срочными должны быть аварии, а доработки планируются.
• Постановка «как у них». Ссылка на чужой сайт вместо описания — самый дорогой вид технического задания. Подрядчик додумывает недостающее, вы видите результат и говорите «нет, я имел в виду другое», цикл повторяется. Что стоит написать заранее, разобрано в материале про ТЗ на разработку сайта.

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

3 сметы для сравнения

Цифры ниже — собирательные и округленные, для понимания порядка. Считаем по ставке абонемента 3500 руб./ч.

Правка контента и мелочи интерфейса. Поменять текст, добавить фотографию, поправить телефон, скрыть блок на странице. 0,25–1 час, то есть 900–3500 руб. Обычно такие задачи копят и делают пакетом: 10 мелких правок за раз выходят дешевле, чем 10 отдельных обращений, потому что разработчик один раз заходит в проект.

Новая функция средней сложности. Поле в форме с передачей в CRM, калькулятор из 4 параметров, всплывающее окно с условием показа, выгрузка заявок в таблицу. 4–16 часов, то есть 14–56 тыс. руб. Здесь основную роль играет окружение: есть ли CRM, кто дает к ней доступ, на скольких страницах стоит форма.

Крупный блок функциональности. Умный фильтр по каталогу, личный кабинет клиента, новый шаг в оформлении заказа, обмен с 1С. 40–120 часов, то есть от 140 тыс. руб. На этом масштабе задача перестает быть «доработкой» и ведет себя как маленький проект: с этапами, макетами, приемкой и отдельным согласованием сроков.

Полезное наблюдение из практики проектов: разброс внутри каждой категории почти всегда объясняется степенью подготовки. Задача с готовым описанием, одним согласующим и доступами, выданными сразу, уходит в нижнюю границу вилки. Та же задача с формулировкой в 2 строки и доступами через 4 дня — в верхнюю.

Что реально удешевляет доработки

Работающих способов немного, но они дают заметный эффект.

Копить задачи и отдавать пакетом. Каждое отдельное обращение несет накладные расходы: разбор, переключение, выкладка, проверка. Пакет из 8 мелких правок экономит примерно треть времени по сравнению с 8 отдельными заходами. В цифрах: 10 правок по 20 мин., поставленных в разные дни, стоят как 6–7 ч., те же правки одним списком займут 3–4 ч.

Отвечать подрядчику в течение дня. Программист задал вопрос и 4 дня ждет. Потом переключается обратно и тратит час, чтобы вспомнить, на чем остановился. Договоритесь внутри компании, кто отвечает исполнителю по текущей задаче, и этот час не попадет в счет.

Перейти на абонемент, если задачи регулярные. Ставка ниже, команда в контексте, срочные задачи не требуют поиска исполнителя. Деньги здесь не единственный довод: за проектом на абонементе закреплена команда, которая знает его код, задачи идут с приоритетом, а в состав работ входит наблюдение за заказами и формами, которого при разовых работах нет. Разовый формат остается разумным в 2 случаях: сайт меняется редко, 2–3 раза в год, или нужна одна понятная задача вроде подключения нового способа оплаты. Что входит в ежемесячное обслуживание и как считать нужное число часов, разобрано в материале про стоимость обслуживания сайта.

Один раз вложиться в инфраструктуру. Тестовая копия, доступы, репозиторий, описание того, где что лежит. Это разовые часы, которые вычитаются из каждой следующей задачи.

Формулировать «зачем», а не «как». «Нужна кнопка вызова обратного звонка в правом нижнем углу» — это решение, которое вы уже выбрали за подрядчика. «Мы теряем клиентов, которые не хотят писать в форму» — это задача, у которой может оказаться вариант в 3 раза дешевле.

А вот что экономией только притворяется. Исполнитель с самой низкой ставкой: разница в 1000 руб./ч. перестает иметь значение, когда на задачу уходит втрое больше часов, а каждый новый подрядчик начинает с изучения чужого кода, и это честные часы в его смете. Правки сразу на рабочем сайте без проверки: одна упавшая корзина в сезон стоит дороже года тестирования. Отказ от документирования: через полгода никто не помнит, почему этот блок работает именно так, и следующая правка начинается с расследования.

Как поставить задачу, чтобы оценка не поплыла

Половина разброса в оценках появляется еще до того, как программист открыл код. «Сделайте, чтобы доставка считалась правильно» — подрядчик читает эту строку и не знает, о чем речь: об 1 службе доставки или о 4, о весе или о габаритах, о Москве или о всей стране. Он закладывает запас и называет 30 ч. Заказчик удивляется цене, уходит к тому, кто назвал 8 ч., и через месяц платит за те же 30, только по частям.

Хорошее описание задачи отвечает на 5 вопросов: что происходит сейчас, что должно происходить, для кого, как проверить и что трогать нельзя. Полноценное техническое задание для большинства доработок не нужно, хватает страницы текста. Вот шаблон, который я прошу заполнять клиентов. Пример условный, интернет-магазин сантехники.

Что сейчас:
  стоимость доставки покупатель узнает от менеджера после заказа

Что нужно:
  стоимость и срок видны в корзине до оформления

Для кого:
  розничные покупатели, Москва и область, СДЭК и свой курьер

Как проверить:
  1. смеситель 2 кг, Москва, курьер: цена совпадает с тарифом
  2. ванна 45 кг, Тверь: показан только СДЭК до терминала
  3. заказ ушел в 1С с доставкой отдельной строкой

Что не трогаем:
  оформление заказа для юрлиц, оно согласовано с бухгалтерией

Материалы:
  тарифы курьера (файл), договор со СДЭК есть, вес товаров в 1С заполнен на 80%

Самая ценная строка в шаблоне последняя. «Вес заполнен на 80%» означает, что для каждого пятого товара доставка не посчитается, и это надо решать до программирования: дозаполнить вес или показать таким товарам «уточнит менеджер». Без этой строки проблема всплыла бы на приемке.

Блок «Как проверить» одновременно служит списком приемки. По нему подрядчик тестирует работу сам, по нему же ее принимаете вы. А если 2 подрядчика оценили задачу в 10 и в 40 ч., они почти наверняка поняли ее по-разному: покажите обоим этот шаблон, и оценки сойдутся ближе.

Чего в описании быть не должно, так это готового технического решения. «Выведите поле из 1С в шаблон корзины» звучит точно, но лишает программиста выбора. Возможно, у службы доставки есть готовый модуль, и задача решается за 3 ч. вместо 15.

Отдельная история — интернет-магазины. Здесь доработки почти всегда касаются мест, через которые идут деньги, и у подрядчика в первый же день появляются вопросы, без которых оценка невозможна. Если ответы пришли вместе с задачей, оценка готова за день. Если их приходится собирать по одному, до старта проходит неделя.

На заполнение шаблона уходит 20 минут, и это не бюрократия: такая постановка обычно срезает от четверти до трети часов на разбор и переписку, а заодно защищает вас от результата, который формально соответствует заявке, но решает не ту проблему.

Как читать смету

Нормальная смета на доработку отвечает на 5 вопросов, и если хотя бы 2 ответа отсутствуют, стоит спросить.

1. Что входит в объем. Не «доработка формы», а перечень: какие поля, на каких страницах, куда уходят данные, что с письмами.
2. Что не входит. Хороший подрядчик пишет это явно: настройка CRM на стороне клиента, дизайн, наполнение контентом, покупка модуля.
3. Как распределены часы. Хотя бы 3–4 строки вместо одной цифры. По распределению видно, думал ли исполнитель о тестировании и выкладке. Если прислали одну строку «Расчет доставки в корзине — 20 ч.», попросите расшифровку: отказ ее дать говорит о подрядчике больше, чем ставка.
4. Что происходит при выходе за оценку. Кто предупреждает, на каком пороге, продолжаются ли работы без нового согласования. Сюда же относятся риски: устаревшая версия системы управления, чужие правки в ядре, отсутствие данных — хороший исполнитель называет их заранее.
5. Что вы получаете на выходе и когда. Работающая функция на рабочем сайте, доступ к коду, короткое описание изменений, срок в календарных днях: 20 ч. работы могут занять и 3 дня, и 3 недели.

Сравнивать предложения стоит по этому списку. Смета на 12 ч. без тестирования и выкладки дешевле сметы на 20 ч. только на бумаге.

Признаки, при которых счет стоит обсудить до начала работ: цена названа без вопросов о сайте, в смете нет ни одного часа на проверку, оценка дана «примерно» без вилки и без условий, сроки обещаны без учета согласований с вашей стороны. И зеркальный признак: оценка, которая выглядит подозрительно низкой. За ней редко стоит эффективность; обычно это недопонятая задача, которая всплывет счетом на доработку доработки.

Приемка доработки: что проверить до оплаты

Заметную доработку делают на копии сайта и переносят на рабочий сайт только после вашей приемки. Правки сразу на рабочем сайте экономят 1–2 ч. и регулярно заканчиваются корзиной или формой, которая не работает в разгар дня.

Для интернет-магазина копия особенно важна: сайт связан с 1С, платежным сервисом и службами доставки, и изменение в одном месте отзывается в другом. У копии магазина есть 3 особенности, о которых стоит спросить подрядчика:

• платежный сервис на копии переключен в тестовый режим, чтобы проверочные заказы не списывали деньги;
• обмен с 1С отключен или направлен в тестовую базу, иначе проверочные заказы попадут в учет;
• письма и СМС покупателям с копии не уходят.

Сама приемка проходит в 2 приема: сначала по сценариям на копии, затем по цифрам через 2–4 недели после выкладки. Первая отвечает на вопрос «работает ли», вторая на вопрос «стало ли лучше».

На копии я прошу пройти сценарии из блока «Как проверить» в описании задачи. Для интернет-магазина к ним добавляется обязательный набор для любого изменения:

1. Заказ с телефона без регистрации, оплата картой.
2. Заказ юридического лица с оплатой по счету.
3. Заказ с промокодом и самой дорогой доставкой.
4. Товар без веса, без фотографии, с нулевым остатком.
5. Заказ дошел до 1С, статус вернулся на сайт.
6. Покупателю пришло письмо, менеджеру пришло уведомление.

Пункт 4 находит больше всего ошибок. Программист проверяет на аккуратных товарах, а в реальном каталоге всегда есть позиции с пустыми полями.

Выкладку планируют на утро буднего дня. Перед ней делается резервная копия, после нее подрядчик проходит контрольный сценарий уже на рабочем сайте. Крупные доработки не выкладывают перед распродажей и в сезон: если что-то пойдет не так, цена ошибки будет максимальной. Как устроены обновления без остановки продаж, мы показывали на примере обновления 1С-Битрикс без простоя, принцип тот же.

Вторая приемка идет по цифрам. Если доработка касалась корзины или оформления заказа, до выкладки стоит записать, какая доля посетителей доходит до каждого шага, и сравнить через месяц. В Яндекс Метрике для этого есть отчет «Ecommerce-воронка»: он строится по данным электронной коммерции и показывает, сколько посетителей дошли до корзины, оформления и покупки.

Отчет работает, только если на сайте настроена передача данных электронной коммерции. Нет ее — начните доработки с этого: без цифр вы не узнаете, окупилась ли следующая задача. Как убедиться, что цели и заказы считаются верно, описано в инструкции по настройке целей в Метрике.

Спросите у подрядчика и про гарантию. Ошибки в сделанной работе, найденные после выкладки, должны исправляться без оплаты в течение оговоренного срока. У нас в Design Lab он равен 1 мес.

Частые вопросы

Можно ли получить фиксированную цену на доработку?

Да, если задача описана достаточно подробно, чтобы риск был посчитан. Практичный компромисс — платный аудит на 2–4 часа, по результатам которого подрядчик дает фиксированную цену на саму работу. Вы платите за понимание объема, зато дальше цена не плавает.

Почему оценка выросла уже в процессе?

Обычные причины: при разборе обнаружились правки предыдущего подрядчика в тех же файлах, задача затронула смежные страницы, изменились требования после первой демонстрации. В договоре стоит заранее закрепить порог, обычно 15–20% от оценки, при превышении которого исполнитель обязан остановиться и согласовать продолжение.

Сколько часов в месяц нужно среднему сайту?

Корпоративный сайт без активного развития обычно укладывается в 5–10 ч.: обновления, мониторинг, мелкие правки. Интернет-магазин с регулярными акциями и интеграциями — от 20 ч. Если сайт развивается по плану, счет идет на десятки часов, и разумнее считать это не поддержкой, а продолжением разработки.

Дешевле нанять программиста в штат?

Штатный разработчик выгоден при постоянной загрузке от 100 ч. в месяц и при наличии внутри компании человека, который умеет ставить ему задачи и проверять результат. При нерегулярном потоке задач штатная единица простаивает, а один человек все равно не закрывает сразу верстку, backend, тестирование и администрирование сервера.

Можно ли платить за результат, а не за часы?

Для доработок — редко. Результат вида «увеличить конверсию» зависит от трафика, цен и конкурентов, код здесь лишь одно из слагаемых, поэтому привязывать к нему оплату работ некорректно с обеих сторон. Для конкретной функции результат и так проверяется приемкой: работает — принято.

Если доработка у вас на подходе, начните с малого: заполните шаблон из раздела о постановке задачи и отправьте его 2–3 подрядчикам. По вопросам, которые они зададут в ответ, будет видно, кто из них разобрался в задаче, а кто назвал цифру не глядя.