Баг или доработка: как различать и что писать в акте/переписке
Когда проект подходит к приемке, почти всегда появляется спор: “это ошибка, исправляйте”, “нет, это доработка, оплачивайте”. Чтобы не тратить недели на эмоции, нужна простая логика, на которую можно опираться.
Как отличать баг от доработки (рабочее правило)
Баг — это когда реализовано не так, как было согласовано, или не работает заявленный сценарий.
Доработка — это когда вы хотите новое поведение, новый сценарий, новое правило или расширение объема.
Ключевой критерий: было ли это зафиксировано в требованиях/сценариях/критериях приемки, либо это новая идея, которая появилась по ходу.
Пограничные случаи (где чаще всего спорят)
- “Мы думали, что оно само…” — если не было описано, это чаще доработка.
- “Это же очевидно” — в разработке “очевидное” не считается требованием.
- “Там всего одна кнопка” — объем не важен, важно: было ли это согласовано.
Что писать в переписке (чтобы было однозначно)
Хорошая формулировка дефекта включает 5 элементов:
- где проблема (раздел/экран/роль),
- шаги воспроизведения,
- фактический результат,
- ожидаемый результат,
- ссылка на согласованное требование/сценарий (если есть).
Пример: “Роль: менеджер. Экран: Заявки. Шаги: открыть заявку → нажать ‘Сохранить’. Факт: статус меняется на ‘Закрыта’. Ожидание: статус не меняется, остается текущим. Основание: сценарий №3 ‘Редактирование заявки’”.
Если основания нет, можно честно писать как запрос на изменение: “Просим изменить поведение: … Оцените срок/стоимость”.
Что фиксировать в акте приемки
Чтобы не платить “за воздух”, акт должен содержать:
- что принято (перечень функционала/этапа);
- перечень дефектов, которые не мешают приемке (если вы готовы принять с оговорками);
- сроки устранения дефектов и критерий “как проверяем”;
- что переносится в следующий этап как развитие (отдельным списком).
Так приемка перестает быть войной: есть факты, есть критерии, есть понятный процесс.