Содержание
- Что входит в техподдержку на самом деле
- Сколько стоит: почасовка и пакеты часов
- Сколько часов нужно вашему сайту
- Пять причин, почему меняют подрядчика
- Сделали сайт, но не умеют его развивать
- Подрядчик перестал справляться
- Непрозрачность
- Инертность
- ИИ поменял экономику
- Как сменить подрядчика и не получить «подарок»
- Что все делают неправильно
- С чего начать
Техподдержка сайта — это регулярные работы, которые не дают сайту сломаться, устареть и остаться без хозяина: обновления, бэкапы, мониторинг и текущие доработки. У нас в Редстаре оплата почасовая: час работ стоит 3500 ₽, а типовому сайту хватает 3–10 часов в месяц — то есть поддержка обходится от десяти тысяч рублей. Эта статья — для владельца бизнеса, который хочет понять, за что он платит и как не попасть на подрядчика, после которого сайт придётся спасать. Я занимаюсь этим с 2007 года, за плечами больше 800 проектов, так что примеры будут не из учебника.
Что входит в техподдержку на самом деле
Универсального списка нет: каждый подрядчик наполняет «поддержку» по-своему, и это первое, что стоит проверить в договоре. Но здоровый минимум выглядит так.
- Обновления платформы и модулей — сначала на тестовой копии, потом на боевом сайте.
- Резервные копии и проверка, что из них реально можно восстановиться.
- Мониторинг: доступность, скорость, ошибки. О падении сайта вы должны узнать от подрядчика, а не от клиентов.
- Текущие правки и доработки: контент, баннеры, новые блоки, мелкий функционал.
Первые три пункта — это регулярные технические работы: их делают по календарю, а не по заявке, и именно их чаще всего пропускают. Когда к поддержке добавляется постоянное развитие сайта, услугу нередко называют сопровождением — разница больше в акценте, чем в сути.
Что поддержкой не считается: редизайн, новый раздел «под ключ», интеграция с 1С — это отдельные проекты со своей оценкой. Когда подрядчик обещает «всё включено за фиксированную сумму», обычно «всё» заканчивается на третьей задаче, а дальше начинается торг. Развёрнутый список работ и что в них не входит — в отдельной статье.
Сколько стоит: почасовка и пакеты часов
Расскажу на нашем примере — не потому, что мы эталон, а потому, что за эти цифры я могу ответить. У нас почасовка: час работ стоит 3500 ₽, оплата по факту выполненного за месяц. Есть пакеты с предоплаченными часами — 3, 5, 10 и 20 часов в месяц; чем больше пакет, тем дешевле час, на самом большом — 2500 ₽.
Две вещи, которые я советую требовать от любого подрядчика, а не только от нас. Первая: предоплаченные часы не должны сгорать. У нас, если в этом месяце задач не набралось, часы переходят на следующий. Если случилось превышение — менеджер предлагает выбор: доплатить и сделать приоритетные задачи сейчас или перенести их на следующий месяц. Вторая: оценка в часах на каждую задачу до её старта. Это главный инструмент прозрачности: вы всегда понимаете, сколько стоит конкретная задача, а не абстрактная «абонентская плата за воздух». Подробнее о том, из чего складывается сумма в счёте, — в статье о цене поддержки сайта.
Сколько часов нужно вашему сайту
По нашей практике объём предсказуем. Если на сайте небольшие правки и точечные доработки — в среднем выходит 3–5 часов в месяц. Доработки в спокойном постоянном темпе — около 10 часов. Активное развитие с созданием нового функционала — от 20 часов ежемесячно. Темп при этом не приговор: если задачи пришли волной, месяц работаем интенсивнее; в затишье пакет копится.
Отдельная история — влияние ИИ на эти цифры. Когда мы два года назад начали внедрять нейросети в работу, прирост был скромный, по нашим замерам 10–15 %. Сейчас некоторые задачи мы делаем с помощью ИИ в десять раз быстрее. Для клиента это значит одно из двух: либо тот же объём работ заметно дешевле, либо за те же деньги — в разы больше сделанного. Поэтому если ваш подрядчик работает как в 2023-м, вы уже переплачиваете.
Пять причин, почему меняют подрядчика
Переход от одного подрядчика к другому — явление настолько частое, что у нас это отдельный отработанный процесс. Причины я бы разложил на пять типовых сценариев.
Сделали сайт, но не умеют его развивать
Разработка и поддержка — разные профессии. Свежий пример: к нам пришла компания Феникс Упак, производитель металлической тары. Сайт им сделали в целом неплохой, но явно недоделанный: каталог требовал переработки, калькулятор расчёта так и не дописали. А самый прикол в том, что раздел «Доставка» начинался словами «мы не осуществляем доставку». Дочитать до продолжения — «…курьерскими службами, а только до транспортных компаний» — у покупателей уже не хватало нервов. За три-четыре месяца мы доработали сайт, разместили 200 товаров в каталоге и сделали первичную SEO-оптимизацию.
Подрядчик перестал справляться
Тормозит, срывает сроки, делает некачественно. Худший вариант этого сценария — у подрядчика сменился менеджер проекта: по моему опыту при этом теряется 80–90 % информации о проекте. Кто, что и зачем настраивал — уходит вместе с человеком. Мы страхуемся так: на каждом проекте поддержки работают двое — менеджер проекта и руководитель отдела техподдержки, который курирует проект и дублирует знание. Плюс вся история задач и переписки живёт в таск-трекере и клиентском чате, а не в голове сотрудника.
Непрозрачность
Абонентская плата списывается, а за что — непонятно. Лечится той самой оценкой в часах до старта каждой задачи, о которой я писал выше. Если подрядчик отказывается оценивать задачи заранее — это не «у нас гибкий процесс», это «мы не хотим, чтобы вы считали».
Инертность
Когда годами делаешь одно и то же на одном проекте, глаз замыливается — критически оценить функционал уже невозможно, причём с обеих сторон: у заказчика происходит то же самое. Иногда смена подрядчика — просто способ взбодрить проект и придать ему новый импульс. Как ни странно, я готов это признавать, хотя сам подрядчик.
ИИ поменял экономику
Заказчики ищут самых эффективных исполнителей, и это нормально. Разница в производительности между командой, которая внедрила ИИ в процессы, и командой, которая «пока присматривается», уже кратная — выше я приводил наши замеры.
Как сменить подрядчика и не получить «подарок»
Здесь у меня есть железное правило: мы не начинаем работу, пока на проекте есть действующий подрядчик. Сначала клиент завершает отношения со старым исполнителем, потом начинает с нами. Иначе размывается ответственность: что-то сломалось — одни говорят «это не мы» и кивают на вторых, вторые оправдываются и тыкают пальцем в первых. Результата в этой конструкции не бывает.
Чем кончается нарушение этого правила, покажу на реальном факапе. Компания переходила к нам на поддержку: со старым подрядчиком закончили в воскресенье, наш договор начался с понедельника. Утром понедельника нам посыпались сообщения: половина страниц не открывается, формы заказа не работают, а рекламный бюджет продолжает литься на неработающий сайт. Оказалось, программист старого подрядчика напоследок решил сделать нам «подарок» — обновил Битрикс прямо на боевом сервере, не сделав резервную копию. Как правильно обновлять Битрикс — разобрал отдельно, там же процесс, который спасает от таких сюрпризов.
Критические вещи мы починили за четыре часа, но мелкие косяки всплывали ещё неделю. А отдельная неделя ушла на расследование: договор-то только начался, и первое подозрение пало на нас — «вы зашли и что-то сломали». Пришлось восстанавливать не только сайт, но и честное имя.
Чтобы переход прошёл без таких приключений, заберите у старого подрядчика всё своё:
- Доступы — все: хостинг, домен, админка, базы, почта, счётчики.
- Документы и лицензии.
- Свежие резервные копии.
- Закрытые хвосты: повисшие задачи либо доделаны, либо оформлены в бэклог.
И самый забываемый пункт — по-человечески разойтись с предыдущим подрядчиком: предупредить о расторжении так, как написано в договоре. Про это забывают чаще, чем про доступы. А потом появляются «подарки» вроде описанного выше — или дело вовсе доходит до суда, где время и деньги теряет прежде всего сам клиент. Пошаговый разбор перехода — в статье как сменить подрядчика по сайту.
Что все делают неправильно
За годы работы я вывел одну недооценённую вещь. У каждого подрядчика своя механика: как ставить задачи, как считаются часы, как устроены приоритеты. Мы, подрядчики, забываем об этом рассказать — а клиенты забывают спросить. В итоге первые месяцы сотрудничества уходят на притирку, которой могло не быть.
Два года назад мы ввели у себя обязательный этап онбординга: после подписания договора, но до начала реальных работ мы рассказываем клиенту, как с нами работать, как лучше ставить задачи и что происходит с его часами. Одна такая встреча снимает большую часть будущей притирки. Спросите у своего подрядчика, есть ли у него такой этап. Если в ответ пауза — вы уже знаете, как пройдут первые месяцы.
Самое главное, что забывают при смене подрядчика, — по-человечески разойтись с предыдущим. Доступы вспоминают почти все, а предупредить о расторжении по договору — почти никто.
С чего начать
Если вы читаете это, потому что с текущей поддержкой что-то не так, — вот короткая самопроверка.
- Откройте договор: что конкретно входит в вашу «абонентку» и есть ли регламент, как ставить задачи.
- Спросите подрядчика, где хранятся ваши доступы и когда делался последний бэкап, из которого реально восстанавливались.
- Попросите оценку в часах на следующую задачу до её старта. Реакция скажет больше любых отзывов.
- Посмотрите на историю: задачи и переписка лежат в трекере или размазаны по почте и мессенджерам?
А если хотите, чтобы сайт посмотрели свежим взглядом, — мы в Редстаре делаем технический аудит, обычно он стоит 20 000 ₽. Читателям этого блога проведём бесплатно по промокоду «olegrodin»: скажите его менеджеру при обращении.
Услуга по темеТехподдержка сайтов на 1С-БитриксСайт на Битриксе работает, обновляется и не тормозит — без вашего участия. Мониторинг, обновления, правки и дежурство при сбоях.Статьи по теме
