Из чего на самом деле складывается стоимость поддержки
Итак, представим обычный понедельник.
У интернет-магазина перестала работать кнопка «Купить» — нужно разобраться. Параллельно менеджер просит добавить новое поле в заказ, маркетолог хочет запустить акцию со своими специфичными условиями, а из 1С внезапно перестали приходить остатки.
И где-то между этими задачами кто-то ещё должен обновить сервер, так как опубликовались новые уязвимости, проверить резервные копии и убедиться, что после последнего обновления ничего не отвалилось.
Всё это — поддержка.
Поэтому когда говорят: «Нам нужно 20 часов программиста в месяц», возникает простой вопрос: а что именно вы заложили в эти 20 часов?
Если разработчик только пишет код, цифра будет одной. Если команда отвечает за работающий интернет-магазин целиком — совсем другой.
Обычно в сопровождении есть несколько разных типов работ.
Разработка.
Исправление ошибок, разработка нового функционала, доработки каталога, личного кабинета, корзины, оформления заказа и всего остального, что бизнесу хочется изменить в магазине.
Тестирование.
После изменения кода нужно убедиться, что вместе с новой функцией случайно не сломались старые. Особенно это важно там, где одна доработка затрагивает заказ, оплату или интеграцию с 1С.
DevOps.
Серверы, резервные копии, сертификаты, логи, мониторинг, деплой. Пользователь этого обычно не видит — ровно до того момента, пока что-нибудь не перестанет работать.
Аналитика и постановка задач.
«Добавьте возможность автоматически разбивать доставку по складам наличия» звучит как одна задача. А потом выясняется, что нужно изменить правила расчёта, обмен с 1С и службами доставки, личный кабинет и ещё несколько мест, которые на первый взгляд вообще не были связаны с доставкой.
Контроль и коммуникация.
Кто-то должен расставить приоритеты, уточнить требования, собрать результаты от разработчиков и объяснить заказчику, почему задача, которая казалась двухчасовой, внезапно стала восьмичасовой.
И есть ещё одна категория, которую особенно сложно заложить в план.
Срочные работы.
Упал обмен с 1С перед началом рабочего дня. Не проходит оплата. После обновления перестал открываться каталог.
В такие моменты уже не очень важно, сколько часов было запланировано на этот месяц. Магазин должен снова заработать.
Поэтому мы обычно смотрим на поддержку не как на покупку определённого количества часов программиста, а как на объём ответственности за работающий проект.
Сколько часов поддержки нужно интернет-магазину
Здесь обычно хочется услышать конкретную цифру.
Например: «Небольшому магазину достаточно 20 часов, среднему нужно 40, крупному — 80».
Но с реальными проектами всё интереснее.
Один магазин может месяцами работать практически без изменений. Другой — иметь небольшую посещаемость, но постоянно требовать доработок из-за сложной интеграции с 1С. Третий может вообще не иметь серьёзных проблем, пока внезапно не понадобится срочно переделать половину оформления заказа.
Поэтому размер каталога или количество заказов сами по себе мало что говорят о трудозатратах.
Гораздо полезнее посмотреть, что происходит внутри проекта.
Небольшой магазин
Допустим, у нас относительно простой интернет-магазин: несколько тысяч товаров, стандартное оформление заказа, одна интеграция с 1С, привычная доставка и без большого количества индивидуальных доработок.
В таком проекте поддержка действительно может занимать условные 10–20 часов в месяц.
Часть времени уйдёт на небольшие доработки, часть — на исправление возникающих проблем, остальное можно оставить на технические задачи и профилактику.
При этом бывают месяцы, когда почти ничего не происходит, а бывают те, в которых внезапно появляется большой релиз или проблема с интеграцией.
Магазин среднего размера
С ростом бизнеса обычно растёт не только количество товаров и оборот.
Появляются несколько складов, разные цены, акции, CRM, дополнительные способы доставки, личный кабинет, обмен с 1С и другие системы. У маркетинга появляются свои задачи, у отдела продаж — свои, у руководства — третьи.
Здесь уже вполне реалистичен объём порядка 30–60 часов в месяц.
Причём часть этих часов может уходить вовсе не на новые функции. Иногда значительная доля времени нужна просто для того, чтобы существующая система продолжала нормально работать.
Сложный или крупный проект
Здесь начинаются совсем другие цифры.
Большой каталог, несколько складов, сложный обмен с 1С, CRM, собственные модули, интеграции с доставкой и оплатой, нестандартная логика цен и заказов.
Здесь 60–100 часов в месяц и больше уже не выглядят чем-то необычным.
Особенно если магазин активно развивается и команда не только поддерживает существующий функционал, но и постоянно его расширяет.
И здесь есть важный момент.
100 часов поддержки не означают, что сайт плохой.
Иногда всё ровно наоборот: бизнес активно развивается, а сайт просто должен успевать за ним.
Добавили новый склад — нужна доработка.
Изменили схему работы с дилерами — нужна доработка.
Запустили новую доставку — нужна интеграция.
Поменяли правила ценообразования — снова изменения в системе.
Хороший интернет-магазин — это не статичный сайт, который однажды сделали и забыли.
Он постепенно превращается в часть бизнес-инфраструктуры компании.
И чем больше бизнес-процессов проходит через него, тем больше задач появляется вокруг него.
Поэтому мы бы скорее ориентировались не на вопрос «сколько часов нам положено?», а на другой:
«Какой объём изменений и ответственности нужен нашему бизнесу каждый месяц?»
Вот здесь уже можно переходить к деньгам.
Сколько это стоит в месяц
Сама по себе стоимость часа мало о чём говорит. Можно найти разработчика за условные 1 500 рублей в час и потратить на одну проблему десять часов. А можно заплатить 3 500 и решить её за три.
В первом случае счёт будет 15 тысяч. Во втором — 10 500.
Поэтому правильнее считать не «сколько стоит час», а «сколько стоит решить задачу».
Если всё-таки попробовать разложить бюджет по типовым сценариям, получится примерно такая картина.
|
Тип проекта |
Поддержка в месяц |
Что обычно происходит |
|---|---|---|
|
Небольшой магазин |
10–20 часов |
Небольшие доработки, ошибки, обновления |
|
Средний магазин |
30–60 часов |
Доработки + интеграции + регулярные технические задачи |
|
Сложный проект |
60–100+ часов |
Активное развитие, несколько систем, сложная инфраструктура |
Это не тарифная сетка и не универсальная норма. Скорее способ понять порядок цифр.
Допустим, команда работает по ставке 3 000 ₽ в час. Тогда 20 часов в месяц — это около 60 000 ₽, 40 часов — 120 000 ₽, а 80 часов — уже 240 000 ₽.
На этом месте часто возникает естественная реакция:
«Двести тысяч за поддержку сайта? Серьёзно?»
Иногда — да.
Но здесь важно понимать, что за этими 80 часами может скрываться вовсе не «сидение программиста на сайте».
Это может быть разработка новых функций, тестирование, работа с 1С, исправление ошибок, контроль интеграций, серверные задачи, анализ проблем и планирование следующих изменений.
По сути, компания покупает не восемьдесят часов кода. Она покупает восемьдесят часов работы команды над своей цифровой инфраструктурой.
И есть ещё одна причина, почему сравнивать предложения только по ставке опасно.
Представим двух подрядчиков.
Первый предлагает 1 800 ₽ в час. Второй — 2 800 ₽.
На первый взгляд разница очевидна: второй дороже больше чем на половину. Но у первого подрядчика на задачу регулярно уходит 10 часов, а у второго — 6.
Получаем:
1 800 × 10 = 18 000 ₽
против
2 800 × 6 = 16 800 ₽.
Более дорогой час в итоге оказался дешевле.
Конечно, в реальной жизни всё не настолько математически чисто. Есть сложные задачи, исследования, технический долг и ситуации, которые невозможно заранее оценить с точностью до часа.
Но сам принцип остаётся.
Цена часа — это только одна переменная.
Гораздо важнее, сколько часов действительно требуется проекту, насколько предсказуемо подрядчик работает и сколько из этих часов уходит на развитие, а сколько — на бесконечное исправление последствий старых решений.
И вот последний пункт может очень сильно изменить весь бюджет. Потому что иногда дорогой становится не поддержка.
Дорогим становится сам сайт.
Почему один магазин обходится дороже другого
Иногда мы смотрим на два проекта и понимаем: внешне они почти одинаковые.
Оба на одной CMS. В обоих интернет-магазин. В обоих несколько тысяч товаров. А потом открываем техническую часть — и становится понятно, почему один проект требует десять часов поддержки в месяц, а второй пятьдесят.
1. Интеграция с 1С
Сам по себе обмен с 1С уже добавляет проекту сложности.
А если есть несколько складов, разные типы цен, остатки, резервирование, статусы заказов, обмен в обе стороны и какие-нибудь исторически сложившиеся правила или кастомизации базовых механизмов обмена — количество возможных сценариев быстро растёт.
И чем больше систем должны договориться между собой, тем больше нужно времени не только на разработку, но и на диагностику проблем.
2. Большой каталог
10 000 товаров и 100 000 товаров — это уже не одно и то же.
Начинают играть роль скорость поиска, фильтрация, индексация, обновление остатков, импорт, кеширование и нагрузка на базу данных.
Пока каталог маленький, некоторые архитектурные решения могут оставаться незаметными.
А потом бизнес добавляет ещё 50 тысяч товаров — и сайт внезапно начинает думать над каждым запросом чуть дольше, чем хотелось бы.
3. Количество интеграций
Сайт редко живёт один.
Он разговаривает с 1С, CRM, службами доставки, платёжными системами, маркетинговыми сервисами, иногда с ERP и другими внутренними системами компании.
Каждая такая связь — потенциальная точка отказа.
Причём проблема может находиться вообще не на сайте. Упал внешний API, изменился формат ответа, закончился сертификат, зависла очередь — а первым об этом узнаёт пользователь, который просто не смог оформить заказ.
4. Собственные доработки
Битрикс позволяет очень многое сделать поверх стандартного функционала.
И это прекрасно, пока через несколько лет не появляется вопрос:
«А почему здесь заказ создаётся именно так?»
Иногда ответ можно найти в документации.
Иногда — в коде.
А иногда документации нет, автора давно нет в компании, а разобраться нужно прямо сейчас.
Так появляется ещё одна статья расходов — понимание того, как вообще работает существующая система.
5. Технический долг
Есть проекты, где разработчики постоянно что-то чинят, но проблема возвращается снова. Сегодня исправили одно. Через месяц — похожее место. Ещё через месяц — другое. Можно годами жить в таком режиме.
Но тогда часть бюджета на поддержку фактически превращается в плату за прошлые решения. В какой-то момент оказывается, что команда тратит 30 часов не на развитие магазина, а на то, чтобы он просто продолжал работать.
6. Требования к скорости реакции
И наконец — насколько быстро бизнесу нужна помощь. Если ошибка может спокойно подождать до завтра, это одна история. Если из-за неё перестают проходить заказы или не работает оплата в пятницу вечером — совсем другая.
Срочность всегда стоит дороже, потому что подрядчику приходится менять планы, подключать дополнительных специалистов и решать задачу не тогда, когда удобно команде, а тогда, когда это нужно бизнесу.
Поэтому два магазина с одинаковым количеством товаров могут иметь совершенно разную стоимость сопровождения.
Количество товаров — это только верхушка айсберга.
Настоящая сложность находится в том, сколько процессов завязано на сайт и насколько хорошо эти процессы между собой связаны.
И именно поэтому перед тем, как назвать клиенту количество часов на поддержку, мы обычно сначала пытаемся понять сам проект.
Почему фиксированный пакет часов не всегда лучший вариант
Самое простое решение кажется очевидным:
«Давайте просто купим 40 часов в месяц».
Для стабильного проекта это действительно удобно. Есть понятный бюджет, команда знает объём работы, задачи можно планировать заранее.
Но интернет-магазин не всегда умеет соблюдать план.
В одном месяце всё спокойно — несколько доработок, обновление, пара ошибок. В следующем меняется что-то в 1С, перестаёт работать доставка или появляется срочная задача от маркетинга. И вот запланированные на месяц часы заканчиваются гораздо раньше.
Поэтому пакет часов — это прежде всего способ планировать бюджет, а не гарантия того, что каждый месяц потребуется одинаковый объём работы.
Если задачи достаточно предсказуемы, пакет на 30–40 часов может быть удобным вариантом.
Если же проект активно развивается и каждый месяц появляются новые вводные, иногда логичнее работать по T&M: оценивать задачи, согласовывать их и оплачивать фактическое время.
При этом T&M не означает отсутствие контроля. Хороший процесс — это когда понятно, что именно делает команда, сколько это примерно займёт и на что фактически ушли часы.
Поэтому вопрос не столько в том, что лучше — пакет или T&M.
Важнее понять:
Насколько предсказуем ваш проект?
Если магазин стабилен — пакет может быть удобнее.
Если постоянно меняется — гибкая модель часто оказывается честнее.
А если сайт регулярно требует срочного вмешательства, стоит сначала разобраться, почему на него вообще уходит столько времени. Возможно, проблема уже не в модели оплаты, а в техническом состоянии проекта.
Как понять, сколько поддержки нужно именно вашему магазину
Универсальной формулы здесь нет. Количество товаров или заказов сами по себе почти ничего не говорят о трудозатратах. Чтобы примерно оценить объём поддержки, достаточно посмотреть на несколько вещей.
Что происходит с сайтом каждый месяц?
Если магазин почти не меняется, постоянный большой объём разработки ему, скорее всего, не нужен. Если регулярно запускаются акции, меняется логика цен, появляются новые функции — потребность в поддержке будет выше.
Сколько систем связано с магазином?
1С, CRM, доставка, оплата, ERP, складские системы — каждая интеграция добавляет сценариев, которые нужно поддерживать и контролировать.
Насколько сложны бизнес-правила?
Разные цены, склады, скидки, дилерские условия, минимальные партии, согласование заказов — всё это постепенно превращается в дополнительную логику сайта.
В каком состоянии существующий проект?
Документация, качество кода, история доработок и технический долг напрямую влияют на скорость работы команды.
Насколько критичны сбои?
Если магазин может спокойно пережить несколько часов простоя — требования к поддержке одни. Если остановка сайта означает потерю заказов и денег — совсем другие.
В итоге при оценке мы смотрим не столько на размер магазина, сколько на его сложность, динамику и цену ошибки.
Поэтому правильный вопрос звучит не «сколько часов положено интернет-магазину», а:
Какой объём работы нужен, чтобы сайт стабильно работал и успевал за бизнесом?
Считаем на реальном примере
Чтобы разговор не оставался слишком абстрактным, возьмём вполне типичный проект.
Интернет-магазин на 1С-Битрикс, около 40 000 товаров. Есть обмен с 1С, несколько складов, CRM, онлайн-оплата и доставка. Магазин работает каждый день, а отдел маркетинга регулярно запускает новые акции и небольшие изменения на сайте.
То есть это уже не тот случай, когда разработчика можно вспоминать раз в месяц.
Допустим, за месяц появляются такие задачи:
|
Работа |
Примерный объём |
|---|---|
|
Небольшие доработки магазина |
12 ч |
|
Работа с интеграциями |
8 ч |
|
Исправление ошибок |
6 ч |
|
Тестирование |
5 ч |
|
Технические задачи и обновления |
4 ч |
|
Аналитика и постановка задач |
5 ч |
|
Итого |
40 ч |
Получается примерно 40 часов.
Если ставка команды составляет 2 500 ₽ в час, месячный бюджет составит около 100 000 ₽.
На бумаге всё просто.
Но здесь есть важная оговорка: эти 40 часов — не какой-то магический норматив для магазина с 40 тысячами товаров. В следующем месяце их может оказаться 25. А потом — 70.
Например, компания решила подключить новую службу доставки. Само подключение может выглядеть как небольшая задача. Но за ним появляются тестирование, изменения в оформлении заказа, обмен статусами, обработка ошибок и проверка разных сценариев.
И вот вместо пяти часов получается пятнадцать, тридцать, пятьдесят.
А иногда появляется задача, которую вообще нельзя было запланировать.
Упал обмен с 1С.
Не проходит оплата.
После обновления перестал работать какой-то модуль.
На такие вещи обычно не существует красивого месячного плана.
Поэтому хороший бюджет на поддержку — это не попытка угадать точное количество часов до единицы.
Это понимание обычного объёма работ плюс готовность к отклонениям.
Если каждый месяц мы видим примерно одинаковые 40 часов, это нормальная ситуация.
Но если магазин регулярно требует 70–80 часов только для того, чтобы устранить ошибки и восстановить работоспособность, а на развитие почти ничего не остаётся, стоит остановиться и задать другой вопрос:
а не слишком ли дорого обходится сам способ поддержки этого проекта?
Потому что одно дело — тратить деньги на развитие магазина.
И совсем другое — каждый месяц платить за исправление одних и тех же проблем.
Как не переплачивать за поддержку
Есть довольно неприятный парадокс.
Иногда компания пытается сэкономить на поддержке и в итоге тратит на неё больше.
Например, выбирает самого дешёвого подрядчика, откладывает обновления, не хочет платить за тестирование и просит «сделать пока как-нибудь».
В ближайшем месяце это действительно может выглядеть как экономия.
А потом приходит счёт.
Только уже не от подрядчика.
Неудачное обновление — несколько часов простоя.
Ошибка в обмене с 1С — неактуальные остатки.
Сломавшаяся оплата — потерянные заказы.
Срочная работа вечером или в выходной — повышенная стоимость и сорванные планы команды.
В итоге сэкономленные несколько тысяч превращаются в гораздо более дорогую проблему.
Поэтому экономить на поддержке лучше немного другим способом.
Не чинить одно и то же бесконечно
Если одна и та же ошибка возникает третий раз, возможно, проблема уже не в ошибке.
Возможно, стоит потратить время и разобраться с причиной.
Иногда десять часов на нормальное исправление сегодня экономят десятки часов в течение следующего года.
Планировать технический долг
У любого живого проекта постепенно появляется технический долг. Если его постоянно откладывать, часть бюджета на поддержку будет уходить на обслуживание старых проблем. Поэтому имеет смысл регулярно выделять время на устранение самых проблемных мест.
Автоматизировать то, что повторяется
Если разработчик каждый месяц вручную проверяет одно и то же, это хороший кандидат на автоматизацию.
Мониторинг, резервные копии, проверки интеграций, уведомления об ошибках, часть рутинных операций — всё это можно постепенно переводить из ручной работы в автоматическую.
Следить не только за ошибками, но и за состоянием проекта
Это, пожалуй, одна из самых недооценённых вещей.
Если команда узнаёт о проблеме только после звонка клиента, это уже не совсем поддержка.
Хороший мониторинг позволяет узнать, что что-то пошло не так, раньше пользователя.
Например, обмен с 1С перестал выполняться ночью — утром команда уже может знать об этом и начать разбираться, не дожидаясь первого звонка из отдела продаж.
И главное — не экономить на понимании
Иногда самый дешёвый час оказывается самым дорогим.
Если разработчик потратил три часа на поиск причины, а другой специалист с опытом конкретного проекта решил бы задачу за один — экономия на ставке уже не выглядит такой очевидной.
Поэтому хорошая поддержка — это не когда подрядчик постоянно занят. И даже не когда подрядчик работает максимально дёшево.
Хорошая поддержка — это когда с каждым месяцем проект становится понятнее, стабильнее и требует меньше бессмысленной работы.
И тогда деньги уходят не только на то, чтобы сайт продолжал работать.
Они начинают работать на его развитие.
Так сколько же стоит поддержка?
Если мы дошли до этого места, то, наверное, уже понятно, почему на этот вопрос сложно ответить одной цифрой.
Можно назвать ставку за час. Можно предложить пакет на 20, 40 или 80 часов. Можно сравнить несколько коммерческих предложений и выбрать самое дешёвое.
Но всё это будет только частью картины.
На практике стоимость поддержки определяется не размером сайта и не количеством товаров.
Она определяется тем, сколько бизнес-процессов завязано на интернет-магазин, насколько сложна его техническая часть и какой уровень ответственности нужен компании.
Если вы каждый месяц платите за поддержку, но сайт продолжает работать нестабильно, одни и те же ошибки возвращаются, а большая часть часов уходит на тушение пожаров — проблема, скорее всего, не в количестве часов.
Если же магазин стабильно работает, интеграции находятся под контролем, технический долг постепенно уменьшается, а часть бюджета можно направлять на новые функции — это уже совсем другая история.
