Гарантийный период и исправления: как это должно работать по‑человечески
Гарантийный период нужен не “для галочки”. Он нужен, чтобы вы запустились спокойно и не боялись, что любой найденный баг будет стоить вам денег и нервов.
Что обычно должно входить в гарантию
По‑простому: исправление того, что сделано неправильно относительно согласованного результата.
Это могут быть:
- ошибки в логике (например, неправильный расчет)
- неработающие сценарии, которые были в согласованном объеме
- сбои, из‑за которых нельзя работать
- проблемы, которые проявляются на реальных данных, но в рамках предусмотренного сценария
Если подрядчик сделал функцию, но она “иногда не работает” — это гарантия.
Что обычно НЕ гарантия (и это нормально)
- новые требования (“а давайте по-другому”)
- расширение функционала
- дополнительные отчеты “раз уж есть данные”
- изменения из‑за того, что вы поменяли процесс в бизнесе
- изменения из‑за новых внешних правил/сервисов, которые не зависели от подрядчика
Это уже развитие, и оно может быть платным.
Как отличить баг от доработки без споров
Самое честное правило:
- если поведение противоречит согласованным требованиям — это баг
- если требований не было или вы хотите иной результат — это доработка
Поэтому так важны список “что делаем” и “что не делаем” и критерии приемки.
Как должны выглядеть “человеческие” правила по срокам
Вам не нужны сложные документы. Достаточно договориться о понятных ожиданиях:
- как быстро подрядчик подтверждает получение проблемы
- как быстро дает план/срок исправления
- какие сроки на исправление критичных проблем
- как вы проверяете исправление и закрываете пункт
Главное — чтобы было не “молчание неделю”, а управляемость.
Как организовать обращения, чтобы их реально исправляли
Каждое обращение должно содержать:
- что делали
- что ожидали
- что получилось
- насколько срочно
Если вы пишете “у нас ничего не работает”, подрядчик будет тратить время на уточнения. Если вы даете сценарий — исправления идут быстрее.
Полезная практика: разделить “гарантия” и “развитие” по потоку задач
Чтобы не смешивать:
- гарантийные баги — отдельный список, приоритет “починить”
- улучшения и хотелки — отдельный список, приоритет “планировать”
Так вы не превращаете гарантию в бесконечное расширение проекта, а подрядчик не превращает баги в продажи.
Гарантия “по‑человечески” — это когда обе стороны понимают правила игры: баги чинятся, развитие планируется, сроки прозрачны, а отношения не превращаются в войну.