За что вообще платят в сопровождении
Разговор о цене буксует, потому что стороны считают разное. Заказчик считает правки, исполнитель — готовность. В счёте сопровождения лежат две оплачиваемые вещи и одна, которую заказать забывают, — и их полезно разделить до того, как сравнивать предложения.
- •Плата за готовность: кто-то помнит, как устроен проект, и берёт обращение, когда оно приходит. Эта часть тратится и в месяц, когда не было ни одной правки, — именно она вызывает вопрос «за что мы платим».
- •Плата за работы: конкретные изменения, которые вы заказали и приняли.
- •И то, что вслух не проговаривают: обслуживание того, что стареет само. Версии движка и библиотек, сертификаты, резервные копии, которые никто ни разу не разворачивал.
Последний пункт не заказывают, потому что снаружи его не видно, — а стареет он независимо от того, заказали его или нет. Разбор того, что стареет тихо и когда за этим пора следить, — техническое сопровождение сайта: когда нужно.
Путь первый: обслуживает тот, кто делал
Привычный порядок вещей, и у него есть честное преимущество: вход в задачу уже оплачен. Человек, который писал систему, не тратит дни на то, чтобы понять, что от чего зависит. Мелкая правка остаётся мелкой правкой, а не превращается в исследование.
Платите вы при этом ежемесячно, и часть месяцев уходит вроде бы впустую. Это и есть цена готовности: в аварийный месяц не придётся искать, кому позвонить, и объяснять устройство проекта с нуля. Вопрос не в том, справедливо ли это, а в том, описан ли состав того, что входит.
Путь второй: свой человек или другая команда
Здесь вы платите только за факт работ. Ни один месяц не уходит впустую, но и готовности никакой нет: в день, когда система встала, исполнителя надо ещё найти, и он начнёт с того, что будет разбираться в чужом коде. Эта работа оплачивается заново при каждой смене людей — и в отличие от правок, её результат вам не достаётся: он остаётся в голове того, кто разбирался.
Свой человек в штате снимает поиск, но добавляет зарплату, налоги и отпуск и всё равно остаётся один. Место в штате оплачивается целиком каждый месяц, независимо от того, сколько было правок, и оправдывает себя там, где систем несколько и они меняются постоянно. И разовая работа тоже требует описанных границ: без списка того, что в неё входит, оплата «по факту» превращается в такой же неопределённый счёт, каким бывает абонентская плата.
Два пути по одним и тем же вопросам
| Вопрос | Обслуживает тот, кто делал | Свой человек или другая команда |
|---|---|---|
| За что платите каждый месяц | За готовность взять обращение | Ни за что, если никого не держите в штате |
| За что платите сверх | За работы вне согласованного состава | За каждую задачу и за вход в чужой код |
| Вход в задачу | Уже оплачен: проект в голове у исполнителя | Оплачивается заново при смене людей |
| Что нужно иметь на руках | Формально ничего — и в этом риск | Исходники, среду сборки, документацию, доступы |
| Главный риск | Цену не с чем сравнить: уйти дорого | В аварийный день исполнителя ищете с нуля |
| Когда подходит | Система живая и меняется | Система устоялась, правки редкие |
Условие, без которого второго пути просто нет
Сравнение выше имеет смысл только тогда, когда оба пути вам доступны. Если при сдаче вы получили работающую систему и ничего больше, второго столбца не существует: обслуживать её сможет только автор, на его условиях. Поэтому вопрос «кто обслуживает и почём» решается не после сдачи, а при ней. На руках должно остаться:
- •Права на результат — закреплённые в договоре, а не подразумеваемые,
- •Исходники и среда сборки: не срез файлов, а то, из чего проект собирается повторно,
- •Документация на то, что вы будете эксплуатировать, написанная для инженера, который придёт после,
- •Ваши данные с выгрузкой в открытом формате, без участия исполнителя,
- •Доступы к домену, хостингу, репозиторию и учётным записям сервисов.
Проверять этот список надо на приёмке, а не в день, когда захотелось уйти: после сдачи договориться о границе «готово» уже нельзя. Как выстроить такую проверку, не читая код, — как принять работу, если вы не инженер. Что из комплекта возвращается без прежнего подрядчика, а что отдаёт только он, разобрано в статье передача сайта другому разработчику. Список того, что мы отдаём на руки, и десять вопросов, которые стоит задать любому подрядчику, — на странице что мы делаем и что остаётся у вас.
Как сравнивать цену, а не ценники
Два предложения с одинаковой суммой могут означать совершенно разный объём. Прежде чем сравнивать числа, стоит выяснить пять вещей:
- •Что входит в ежемесячную плату списком, а что считается работами сверх,
- •Кто платит за исправление ошибки, допущенной самим исполнителем,
- •Входят ли обновления движка и библиотек, продление сертификатов и проверка резервных копий,
- •Что происходит с ценой, когда система вырастет или добавится новый модуль,
- •Что вы получаете в конце месяца: список сделанного или строку «работы выполнены».
Ежемесячная плата без описанного состава — это плата за доступность, а не за объём. Это не обман, но и сравнивать её по одному числу с предложением другой команды нельзя: вы сравниваете разные вещи.
Эти же вопросы задайте и нам. Сразу оговоримся, чтобы список не выглядел проверкой, написанной под себя: ни прайса на сопровождение, ни расписанного состава абонентской платы у нас на сайте нет. И то и другое мы называем после разбора конкретного проекта — по одному адресу сайта видно симптомы, а не состояние кода.
Кому какой путь
Живая система, в которой что-то меняется каждый месяц, дешевле обходится на сопровождении у того, кто её знает: вход в задачу там не оплачивается по второму разу. Устоявшаяся система с правками пару раз в год — наоборот: держать за неё ежемесячную плату дороже, чем позвать исполнителя по факту. Пограничный случай — система живая, но подрядчик единственный возможный; тогда сначала возвращают себе комплект передачи, а разговор о деньгах ведут уже после.
Мы работаем и так, и так. Начинать имеет смысл с одной разовой задачи: после неё обе стороны видят, в каком состоянии код, и о деньгах за месяц говорят от фактов, а не от ощущений. Как мы разбираем чужой код и где проводим границу между «чинится» и «упирается в архитектуру» — доработка существующих систем.
Частые вопросы
Сколько стоит сопровождение после сдачи проекта?
Цена собирается из двух частей: ежемесячной платы за то, что кто-то держит проект в голове и принимает обращения, и оплаты самих работ. Назвать сумму до разбора того, что уже написано, нельзя — пока не видно, что внутри, любое число будет догадкой. Поэтому порядок цены мы называем после разбора, а не в переписке.
Можно ли обойтись без сопровождения вообще?
Можно там, где система ничего не принимает и её остановка не стоит денег. Если через неё идут заявки, заказы или данные клиентов — обслуживать её кто-то будет в любом случае: либо по плану, либо в аварийном режиме и дороже. Ломается не только то, что правят, но и то, что стареет само: версии, сертификаты, резервные копии.
Прежний подрядчик не отдаёт исходники. Что делать?
Разделить то, что возвращается без него, и то, что не возвращается. Домен, хостинг и почта оформлены на вас или на человека, до которого можно дойти, — доступ к ним восстанавливается через регистратора и хостера. Репозиторий с историей и учётные записи сервисов отдаёт только он; если не отдаёт, остаётся восстанавливать по тому, что работает на сервере, и это отдельная оплаченная работа.
Дешевле нанять своего человека в штат?
Считать надо не ставку, а место целиком: к зарплате добавляются налоги, отпуск и больничный, а оплачивается оно каждый месяц независимо от того, сколько было правок. Держать проект в голове он всё равно будет один, и его уход возвращает вас к началу. Свой человек оправдан, когда систем несколько и они меняются постоянно.
Как проверить, что ежемесячная плата не уходит впустую?
Просить в конце месяца список сделанного, а не строку «работы выполнены». И раз в квартал проверять, что исходники, среда сборки и доступы по-прежнему у вас: сопровождение — не повод, чтобы управление проектом постепенно переехало к исполнителю.