Вы отправили подрядчику задачу: добавить в каталоге фильтр по бренду. Выглядит на полдня, договор с ежемесячной оплатой подписан, часы в нём есть. Через два дня приходит ответ: это доработка, оценка отдельная, сорок часов. Дальше с этой оценкой идти к руководителю и объяснять, почему сайт, за который компания платит каждый месяц, требует ещё денег.
Разговор этот повторяется в каждом втором проекте, и почти всегда не потому, что подрядчик хитрит. Просто «поддержка» и «доработка» — две разные работы, которые в счёте стоят рядом и оттого кажутся одной.
За что уходит ежемесячная оплата
Ежемесячные деньги платятся за то, чтобы сайт оставался в том состоянии, в каком его приняли. Это обновления программ, на которых он работает, — без них через год-полтора в нём находят дыры, и через них попадают внутрь. Это резервные копии, причём с проверкой, что из них удаётся восстановиться: копия, которую ни разу не разворачивали, — это не копия, а надежда. Это слежение за тем, что сайт отвечает и оплата проходит, чтобы о поломке узнать раньше, чем позвонит клиент. Плюс мелкие правки: телефон в шапке, новая позиция в меню, картинка на баннере.
Объём такой работы заранее неизвестен — в спокойный месяц её почти нет, в неудачный она съедает всё. Поэтому продают её пакетом часов, а не по факту. И поэтому неизрасходованные часы обычно не переносятся на следующий месяц: платят не за отработанное время, а за готовность — за то, что в среду вечером кто-то возьмёт трубку и полезет разбираться.
Отсюда же первая честная развилка. Если у вас сайт-визитка, который меняется раз в год, ежемесячная оплата вам не нужна: разовые обращения обойдутся дешевле, даже с наценкой за срочность. Смысл в постоянном сопровождении появляется там, где остановка сайта начинает стоить заказов за каждый час — в интернет-магазине, на портале для дилеров, в сервисе с оплатой.
Что превращает задачу в доработку
Граница проходит не по размеру задачи и не по количеству часов. Признак один: меняется ли после правки поведение сайта.
Заменить в шапке телефон — поддержка. Изменить правило, по которому оптовик получает скидку, — доработка, хотя изменений в программе может быть на десять строк. Разница в том, что после первого проверять нечего, а после второго нужно проверить корзину, документы, выгрузку заказов в 1С и то, что уже оформленные заказы не пересчитались задним числом.
Несколько случаев с границы, которые чаще всего вызывают спор:
- «Поменять текст на странице» — поддержка, пока текст лежит в админке. Если он зашит в программу, это уже правка программы, и стоит она иначе.
- «Добавить поле в форму заявки» — полчаса, если поле нужно только менеджеру. Если оно должно попасть в CRM и в письмо клиенту, править придётся в трёх местах, и каждое надо проверить.
- «Поставить баннер акции» — поддержка. «Поставить баннер, который сам исчезнет в полночь и не покажется тем, кто уже купил» — доработка.
- «Ускорить каталог» — почти всегда доработка, хотя звучит как починка. Медленный каталог не сломался, он таким и был; чтобы стал быстрым, его надо переделать.
Последний пункт стоит запомнить: слова «почините» и «доработайте» в переписке значат одно, а в смете разное. Починка возвращает то, что работало вчера. Всё остальное — новое, даже если оно кажется мелочью.
Почему маленькая доработка стоит как большая
Цена доработки складывается не из самого изменения. Изменение — это верхушка, под ней четыре части, и каждая стоит времени.
- Разобраться, как устроено то, что уже есть. Если сайт писала другая команда, а документации нет, программист несколько часов просто читает чужую программу: где считается цена, откуда берётся остаток, что произойдёт, если он тронет вот эту строчку. На унаследованном проекте эта часть регулярно занимает больше времени, чем сама правка.
- Пройти по связкам с другими программами. Пример из живого проекта: каталог на 400 000 позиций, и заказчик просит добавить у товара одно новое свойство. Само по себе — час работы. Но свойство приходит из 1С, значит его надо провести через обмен, который идёт по расписанию; довезти до витрины; добавить в файлы, которые уходят на Wildberries, Ozon и Яндекс Маркет; и не сломать те выгрузки, что уже работают. Час превращается в неделю, и ни одного лишнего действия в ней нет.
- Проверить, что ничего не задето. Не «посмотрели, открывается», а прогон всего, до чего правка могла дотянуться: оформление заказа, оплата, скидки, письма. Чем крупнее каталог, тем дороже убедиться, что не поехали остальные 399 999 карточек.
- Выложить обновление на работающий сайт так, чтобы покупатели этого не заметили. Там, где выкладка настроена и делается сама, это минуты. Там, где файлы копируют руками по вечерам, это отдельная операция с риском положить магазин.
Цена вопроса при этом чаще складывается не там, где её ищут. Дорого обходится не доработка, а месяц ожидания: пока задача висит без оценки, менеджеры правят цены руками, ошибаются, а клиент видит на сайте не то, что ему обещали по телефону.
Как поставить задачу, чтобы оценка не выросла вдвое
Самое дорогое в постановке — когда заказчик приносит не задачу, а придуманное решение. «Добавьте в карточку поле „цена 2“» — исполнитель добавит, и через месяц выяснится, что нужно было другое. Формулируйте результат: «оптовик после входа должен видеть свою цену, а розничный покупатель — обычную». Как это сделать, пусть придумывает тот, кто знает программу.
Дальше — четыре вещи, которые сокращают оценку просто потому, что снимают неизвестность. Скажите, кто и где должен увидеть изменение: только менеджер в админке или все посетители. Приложите пример — конкретный товар, номер заказа, скриншот с пометкой. Назовите срок и причину срока: «к 1 октября, стартует акция» оценивается иначе, чем «побыстрее». И спросите заранее, что из этого попадёт в ежемесячные часы, а что будет считаться отдельно, — до начала работ, а не в конце месяца, когда придёт счёт.
Ещё полезно раз в квартал смотреть список задач целиком, а не по одной. Пять мелких правок в одном разделе, сделанные вместе, стоят заметно дешевле, чем те же пять по очереди с интервалом в месяц: разбираться в этом разделе придётся один раз.
Когда пора разделять бюджеты
Если доработок стабильно больше, чем часов в пакете, спор о границе будет повторяться каждый месяц — и он не решается формулировками в договоре. Решается разделением: сопровождение остаётся абонентским, а развитие идёт отдельным бюджетом со своим списком задач и сроками. У такого разделения есть минус, и мы его видим на своих проектах: согласований становится больше, каждая задача проходит через оценку и утверждение. Взамен исчезают счета-сюрпризы, а вместе с ними и разговоры «мы же вам и так платим».
Обратный случай встречается не реже. Если пакет часов не выбирается третий месяц подряд, вы платите за готовность, а не за работу — пакет стоит уменьшить, честный подрядчик сам это предложит. А если каждая мелочь вроде новости или баннера требует программиста, проблема не в тарифе: значит, админкой пользоваться невозможно и её стоит один раз довести до состояния, когда с ней справляется контент-менеджер. Это разовая доработка, которая окупается за несколько месяцев сэкономленных часов.
Кому вообще эти часы отдавать — своему разработчику или внешней команде — вопрос отдельный, мы разбирали его в другой статье.
На что смотреть в первую очередь
Граница между поддержкой и доработкой не в договоре — она в том, меняет ли задача поведение сайта. Всё, что возвращает работу в прежнее состояние, входит в месяц. Всё, что добавляет новое, оценивается отдельно, и чем плотнее сайт связан с 1С, CRM и маркетплейсами, тем дороже обходятся изменения, которые на словах звучат как мелочь.
Поэтому до подписания стоит задать подрядчику три вопроса и записать ответы.
- Что именно входит в ежемесячную оплату — перечнем работ, а не словом «поддержка».
- Как оценивается то, что не входит, и в какой срок приходит оценка.
- Что происходит с неизрасходованными часами и что считается перерасходом.
Три ответа занимают полстраницы и снимают почти все будущие споры о счетах.
