Баг или доработка: как различать

Фундаментальное правило простое: если система работает не так, как было описано в техническом задании или утвержденных сценариях — это баг. Ошибкой считается любое отклонение от логики, о которой договорились «на берегу».

• Пример бага: В ТЗ указано, что заявка с сайта должна падать в вашу CRM, но она туда не доходит. Это поломка, которую подрядчик устраняет без лишних разговоров.
• Пример доработки: Вы протестировали форму и поняли, что хотите добавить туда еще одно поле для выбора филиала, хотя изначально этого не планировали. Это новая задача, требующая времени дизайнера и программиста.

Почему «мне не нравится» — это не баг.

Иногда при приемке включается субъективный фактор: «Я думал, это будет работать иначе» или «Эта кнопка здесь неудобна». Если в документации не было зафиксировано конкретное расположение или цвет, то любые изменения после реализации — это доработка. Чтобы минимизировать такие ситуации, бизнес-логику нужно прописывать максимально подробно до начала кодинга.

Управление изменениями без конфликтов.

Важно понимать: в сложных системах автоматизации невозможно предусмотреть 100% нюансов на старте. Если в ходе приемки вы осознали, что системе нужны дополнительные фильтры, поля или интеграции — это нормальный процесс эволюции продукта. Чтобы не стопорить запуск всей платформы, такие задачи выносятся в отдельный этап развития системы. Это позволяет запустить основной функционал в эксплуатацию вовремя, постепенно наращивая мощность продукта.