Запуск продукта — не финишная черта, а смена режима. Первые недели на реальных пользователях всегда приносят находки: сценарий, который никто не проверил, устройство с необычным экраном, данные, которых не было в тестовой базе. Гарантия нужна именно для этого периода.
Но слово «гарантия» заказчик и подрядчик нередко понимают по-разному. Ниже — где обычно проходит граница и о чём стоит договориться до запуска.
Что такое гарантия
Гарантия — обязательство подрядчика бесплатно исправить ошибки в той работе, которую он сделал и сдал. Если функция, описанная в требованиях и принятая на приёмке, перестала работать или работает не так, как описано, — это гарантийный случай.
На нашу работу действует гарантия 6 месяцев после запуска. Этого срока обычно хватает, чтобы продукт прошёл через все типичные сценарии: ежедневные, ежемесячные, отчётные периоды.
Что входит в гарантию
Типичные гарантийные случаи:
- функция работает не так, как описано в требованиях или техническом задании;
- ошибка в логике — неверный расчёт, неправильный статус, потерянное уведомление;
- сбой на сценарии, который был в требованиях, но проявился только на реальных данных;
- проблема производительности в пределах нагрузки, о которой договорились заранее.
Главный критерий — было ли поведение описано и принято. Поэтому чем подробнее требования и сценарии приёмки, тем проще потом отличить ошибку от новой задачи.
Что обычно не входит
Здесь чаще всего возникают недоразумения. Как правило, гарантия не покрывает:
- новые функции и доработки. «Добавить фильтр в отчёт» — это не ошибка, а развитие продукта, даже если идея появилась в первую неделю после запуска;
- изменения в требованиях. Если процесс в компании поменялся, система должна меняться вместе с ним, но это новая работа;
- изменения чужих систем. Внешний сервис выпустил новую версию API или поменял правила — интеграцию нужно обновить, и это сопровождение;
- обновления под новые версии iOS и Android и новые требования магазинов приложений;
- проблемы инфраструктуры — сбои серверов или облака, если они не вызваны ошибкой в коде;
- последствия изменений, внесённых другими — например, вашей командой или другим подрядчиком.
Точные условия фиксируются в договоре. Хорошо, если там же описано, как подаётся обращение и как быстро на него реагируют.
Как сообщить об ошибке, чтобы её быстро исправили
Скорость исправления во многом зависит от того, насколько понятно описана проблема. «Ничего не работает» требует нескольких дней переписки. Хорошее обращение содержит:
- что делали — шаги, которые привели к ошибке, по порядку;
- что ожидали увидеть и что произошло на самом деле;
- где это случилось — веб или приложение, браузер, модель телефона, версия приложения;
- когда — дату и примерное время: по ним команда найдёт запись в журналах;
- под каким пользователем — у разных ролей разные права и данные;
- скриншот или запись экрана, если ошибку видно.
Если ошибка мешает работать многим людям — например, не проходит оплата или не открывается главный экран, — об этом стоит сказать сразу, в первой строке. Такие обращения разбираются в первую очередь.
Поддержка и развитие после гарантии
Продукт после запуска не замирает. Даже если в нём нет ошибок, ему нужно:
- следить за стабильностью и реагировать на сбои;
- обновлять зависимости и библиотеки, в том числе ради безопасности;
- обновлять интеграции, когда меняются внешние системы;
- выпускать версии под новые iOS и Android;
- добавлять функции по данным аналитики и отзывам пользователей.
Это техническая поддержка и развитие продукта. Их удобно планировать так же, как разработку: итерациями, с понятным списком задач и демо. Оплачиваются они отдельно — по плану или по мере задач.
Передача проекта
Хороший проект можно передать — вашей команде или другому подрядчику — без многомесячного погружения. Для этого после запуска у вас должны быть:
- исходный код и доступ к репозиторию;
- доступы к серверам, облаку, внешним сервисам и магазинам приложений, оформленные на вашу компанию;
- документация — архитектура, API, порядок развёртывания;
- описание интеграций — с какими системами связан продукт и как устроен обмен;
- список известных ограничений и планов, которые не вошли в текущую версию.
Мы готовим документацию по архитектуре, API и развёртыванию так, чтобы систему могла развивать и ваша команда, и любой другой подрядчик. Даже если вы планируете работать с одной командой долго, такая готовность к передаче — признак здорового проекта.
Что обсудить до запуска
Чтобы гарантия и поддержка не стали поводом для споров, договоритесь заранее:
- Сколько длится гарантия и с какого момента она отсчитывается.
- Что считается ошибкой, а что — доработкой: опирайтесь на требования и сценарии приёмки.
- Как подаётся обращение и как быстро на него реагируют.
- Что будет после гарантии: поддержка по плану, по мере задач или своими силами.
- Что передаётся вам — код, доступы, документация — и в какой момент.
Коротко
Гарантия покрывает ошибки в сделанной работе. Развитие продукта, изменения внешних систем и новые требования — это поддержка. Граница между ними проходит по требованиям и приёмке, поэтому их ясность важна не только на старте, но и после запуска.
Подробнее о том, что входит в нашу работу, — на странице услуг и в описании разработки ПО на заказ.
Гарантия — это не страховка от всего. Это обещание, что сделанное работает так, как договорились. Остальное продукт получает уже в своей следующей версии.
