Поддержка и сопровождение ПО: модели и стоимость
Практика3 минРедакция Innovialabs
Коротко
Абонентская поддержка подходит для продуктов, от которых зависит бизнес, почасовая — для нерегулярных доработок, потикетная — для редких мелких обращений. Объём выбирают по частоте изменений и цене простоя.
Какую модель поддержки выбрать
Есть три основные модели: абонентская (retainer), почасовая и потикетная. Короткий ответ:
- продукт приносит деньги каждый день и простой обходится дорого — берите абонентскую поддержку с SLA;
- доработки случаются волнами, а в остальное время система стабильна — подойдёт почасовая;
- обращений мало и они однотипные — достаточно оплаты за тикет.
Многие компании комбинируют: небольшой абонемент на мониторинг и аварии плюс почасовая оплата крупных доработок.
Что такое поддержка и что такое сопровождение
Эти слова часто путают, а от этого зависит договор.
- Поддержка — реакция на проблемы: ошибки, сбои, вопросы пользователей, восстановление после аварий.
- Сопровождение — плановая работа: обновление зависимостей и серверов, патчи безопасности, резервные копии, мониторинг, небольшие улучшения.
Если в договоре есть только поддержка, система постепенно устаревает: библиотеки не обновляются, сертификаты истекают, уязвимости накапливаются.
Сравнение моделей
| Модель | Как оплачивается | Плюсы | Минусы |
|---|---|---|---|
| Абонентская | Фиксированная сумма в месяц за пакет часов или зону ответственности | Гарантированное время реакции, команда знает систему | Платите и в спокойные месяцы |
| Почасовая | По фактически отработанным часам | Платите только за работу | Нет гарантий скорости, подрядчик может быть занят |
| Потикетная | Фиксированная цена за обращение определённого типа | Предсказуемая цена задачи | Сложно классифицировать нестандартные задачи |
От чего зависит стоимость
Вместо готовых цифр смотрите на факторы, которые двигают цену:
- Время реакции и часы работы. Реакция в течение часа круглосуточно стоит заметно дороже, чем в рабочее время.
- Сложность и возраст системы. Старый код без документации и тестов требует больше времени на каждую правку.
- Количество интеграций. Платёжные системы, 1С, CRM, внешние API — каждая интеграция может сломаться независимо от вас.
- Требования к безопасности и данным. Персональные и платёжные данные повышают требования к процессам.
- Кто владеет инфраструктурой. Если подрядчик отвечает и за серверы, объём работ растёт.
Как определить нужный объём
- Посчитайте историю. Сколько обращений и доработок было за последние месяцы? Какие из них срочные?
- Оцените цену простоя. Что вы теряете за час, если сайт или CRM не работает? Это определяет требуемый SLA.
- Разделите срочное и плановое. Аварии — в абонемент, развитие — отдельным бюджетом.
- Начните с пробного периода. Через два-три месяца станет понятно, хватает ли пакета.
- Пересматривайте объём. Неиспользованные часы и постоянные переработки — сигнал скорректировать договор.
Что прописать в договоре
- SLA: время реакции и время решения для разных уровней критичности.
- Классификацию инцидентов: что считается критичным, а что — плановой задачей.
- Что входит и что не входит в абонемент, как оплачиваются задачи сверх пакета.
- Судьбу неиспользованных часов: сгорают или переносятся.
- Доступы и передачу дел: все пароли, репозитории и документация должны оставаться у вас.
- Отчётность: ежемесячный список выполненных работ и потраченных часов.
Частые ошибки
- Не заключать договор вообще и искать разработчика в момент аварии.
- Покупать круглосуточный SLA для внутренней системы, которой пользуются только днём.
- Смешивать поддержку и развитие в одном бюджете, из-за чего новые функции съедают время на аварии.
- Не требовать отчётов и не понимать, за что вы платите.
Частые вопросы
Да, но нужен этап передачи: аудит кода, документация, доступы и инфраструктура. Чем лучше задокументирован проект, тем быстрее новая команда начнёт работать эффективно.