Как проверить SLA в договоре на разработку мобильного приложения перед оплатой
SLA (Service Level Agreement) в договоре на разработку мобильного приложения — это раздел, который фиксирует конкретные обязательства исполнителя: время реакции на баги, минимальный аптайм серверов, штрафы за срыв
Что такое SLA в контракте на мобильную разработку и зачем его читать
SLA — это часть договора, которая описывает уровень сервиса, который исполнитель обязуется предоставить. В контексте мобильной разработки SLA обычно покрывает три зоны:
1. Разработка и поддержка: сроки устранения критических и некритических ошибок, время отклика на тикеты, обязательства по обновлениям и багфиксам.
2. Инфраструктура: аптайм серверов (обычно 99,5–99,9 %), время восстановления после сбоев (RTO), частота бэкапов.
3. Приёмка и гарантии: критерии готовности продукта к релизу, гарантийный период, порядок фиксации дефектов и передачи артефактов.
Зачем читать? Потому что именно SLA определяет, что произойдёт, если разработчик нарушит сроки или отдаст продукт с багами. Без понимания этого раздела вы рискуете столкнуться с ситуацией, когда формально договор подписан, а реальные обязательства исполнителя размыты или отсутствуют.
> По данным Standish Group, около 66 % IT-проектов завершаются с превышением бюджета или срока. Чёткий SLA — один из инструментов снижения этого риска.
Таблица проверки: ключевые пункты SLA для мобильного приложения
Мы проанализировали более тридцати договоров на разработку мобильных приложений и выделили семь параметров, которые стоит проверить в первую очередь.
| Параметр | Что проверить | Норма / ориентир |
|---|---|---|
| Время реакции на критический баг | Сколько часов даётся исполнителю на первый отклик | 2–4 часа для продакшн-среды |
| Аптайм серверов | Минимальный процент доступности, зафиксированный в SLA | 99,5 % и выше |
| Штрафы за срыв сроков | Размер и условия начисления пени | 0,1–0,5 % от суммы договора за каждый день просрочки |
| Гарантийный период | Срок бесплатного исправления дефектов после приёмки | 3–6 месяцев |
| Исключения из SLA | Какие ситуации снимают ответственность с исполнителя | Форс-мажор, действия заказчика, сбои сторонних API |
| Порядок приёмки | Кто и как подтверждает готовность продукта | Акт приёмки-передачи с перечнем функций |
| Порядок эскалации | Кому жаловаться, если SLA нарушается | Менеджер проекта → технический директор |
Риски: что будет, если SLA не проверить перед оплатой
Если вы подписываете договор без детального изучения SLA, вот что может произойти:
1. Нет штрафов за срыв сроков. Исполнитель задерживает релиз на два месяца, а вы не можете потребовать компенсацию, потому что в договоре нет соответствующего пункта. Потерянный доход от незапущенного приложения при этом никто не компенсирует.
2. Размытые критерии приёмки. Продукт «работает», но не так, как вы ожидали. Без чётких метрик приёмки доказать, что результат не соответствует ТЗ, будет крайне сложно.
3. Отсутствие гарантий на баги. После запуска вы обнаруживаете критические ошибки, а исполнитель ссылается на то, что гарантийный период не предусмотрен договором.
4. Нет порядка передачи кода. Если сотрудничество прекращается, вы можете столкнуться с тем, что исходный код, дизайн-макеты и доступы к серверам не переданы. Убедитесь, что в договоре есть ссылка на акт передачи кода, дизайна и доступов.
5. Слабая отчётность. Без регулярных отчётов вы не контролируете ход работ и не можете вовремя выявить отклонения от графика.
Когда SLA в договоре не защищает заказчика
Даже подробный SLA не всегда работает в пользу заказчика. Вот ситуации, на которые стоит обратить особое внимание:
1. Слишком широкие исключения. Если в перечне исключений указаны «любые действия сторонних сервисов», а ваше приложение интегрировано с десятком внешних API, исполнитель фактически может ссылаться на это при каждом сбое.
2. Нет привязки к конкретным датам. Формулировки вроде «в разумные сроки» не дают юридической базы для претензий. Всегда добивайтесь фиксации сроков в часах или рабочих днях.
3. SLA без измеримых KPI. Если метрики не фиксируются автоматически, доказать нарушение SLA будет сложно. Убедитесь, что в договоре прописаны инструменты мониторинга и периодичность замеров.
4. Отсутствие связи SLA с оплатой. Если оплата не привязана к этапам приёмки, вы рискуете заплатить полную сумму до того, как убедитесь в качестве результата.
Прежде чем подписывать договор, стоит сравнить предложения на разработку по ТЗ и убедиться, что SLA в каждом из них сопоставим по условиям. Также рекомендуем изучить наш материал о том, как проверить поддержку цифрового сервиса после запуска.
Что такое SLA в договоре на мобильную разработку?
SLA (Service Level Agreement) — это соглашение об уровне сервиса, которое фиксирует обязательства исполнителя по времени реакции, аптайму, штрафам и порядку приёмки. В контексте мобильной разработки SLA определяет, как быстро исполнитель исправит баги, какой процент времени приложение будет доступно и что произойдёт при нарушении сроков.
Какой аптайм должен быть зафиксирован в SLA?
Для большинства мобильных приложений нормой считается аптайм 99,5–99,9 %. Это означает, что приложение может быть недоступно не более 4,4 часа в год при показателе 99,9 %. Для финтех-приложений и сервисов с высокой нагрузкой рекомендуется фиксировать аптайм не ниже 99,95 %.
Можно ли изменить SLA после подписания договора?
Да, SLA можно изменить по соглашению сторон через дополнительное соглашение к основному договору. Однако на практике исполнители редко соглашаются на ужесточение условий после подписания, поэтому важно зафиксировать все требования до внесения предоплаты.