Что делать, если от программиста возвращается тикет, что это не баг

Стратегия работы с возвращенным тикетом «Не баг»

Когда разработчик возвращает тикет с пометкой «Не баг», это не обязательно тупик, а часто — начало важного диалога о требованиях, поведении системы и качестве продукта. Моя стратегия, отработанная за годы практики, строится на принципе коллаборации, а не конфронтации. Вот пошаговый план действий, который я применяю.

1. Спокойный анализ и проверка своей позиции

Первое и главное — не действовать эмоционально. Я сразу же провожу повторную проверку.

• Изучаю комментарий разработчика: Внимательно читаю, какую именно причину он указал. Это «работает согласно спецификации», «особенность среды», «ошибка на стороне данных» или что-то иное?
• Повторяю воспроизведение: Еще раз прохожу все шаги, описанные в тикете, чтобы убедиться в точности и неизменности воспроизведения. Иногда на этом этапе обнаруживается ошибка в шагах или тестовых данных.
• Сверяюсь с документацией: Открываю требования (PRD, user stories), спецификации или дизайн-макеты. Я ищу формальное обоснование того, почему текущее поведение я считаю ошибочным. Без опоры на документацию мой аргумент слабеет.

2. Углубленное исследование и сбор доказательств

Если после первичного анализа я по-прежнему уверен, что это дефект, перехожу к детальному расследованию.

• Расширяю контекст: Проверяю, как аналогичная функция работает в других частях приложения (принцип консистентности UX). Если везде иначе — это сильный аргумент.
• Смотрю на проблему глазами пользователя: Формулирую, какой бизнес-ущерб или неудобство причиняет данное поведение. Пример: «Если кнопка не подсвечивается при наведении, пользователь может не понять, что она кликабельна, что увеличит количество отказов».
• Собираю «улики»: Делаю скриншоты, записи экрана, логирую сетевые запросы (через DevTools) или данные в БД. Особенно весомо выглядит сравнение с поведением конкурентов или общепринятых стандартов (например, гайдлайны iOS/Android).

3. Конструктивный диалог с разработчиком

Здесь ключ — перевести разговор из режима «ты неправ» в режим «давай разберемся вместе».

• Задаю уточняющие вопросы: Вместо «Почему ты это закрыл?» я спрашиваю: «Помоги мне понять твою точку зрения. На каком основании это признано ожидаемым поведением?» или «Какой частью кода или конфигурации это поведение регулируется?».
• Демонстрирую доказательства и бизнес-логику: Спокойно показываю собранные материалы и объясняю, почему с точки зрения пользователя это проблема. Часто программист сфокусирован на технической реализации и может упускать UX-составляющую.
• Предлагаю решение: Иногда полезно не просто указать на проблему, а предложить вариант исправления или области для поиска. Например: «Мне кажется, это может быть связано с кэшированием виджета. Мы можем проверить это?»

4. Эскалация и привлечение третьей стороны

Если диалог зашел в тупик и мы не можем прийти к консенсусу, необходим арбитр. Это не признак слабости, а стандартная рабочая практика.

• Обращаюсь к аналитику или продакт-менеджеру: Они являются владельцами требований. Их вердикт о том, является ли текущее поведение корректным с бизнес-точки зрения, — решающий. Тикет переоткрывается с их комментарием.
• Обращаюсь к тимлиду или руководителю направления: Если вопрос технический (например, связано ли это с архитектурным ограничением), его мнение поможет расставить приоритеты.
• Использую процедуру «Bug Triage»: На регулярных митингах по оценке багов спорные кейсы выносятся на общее обсуждение командой (QA, Dev, PM). Коллективное решение是最公平的.

5. Документирование и извлечение уроков

Финал истории — не просто переоткрытие или закрытие тикета.

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

Пример диалога в тикете:

Комментарий QA (после возврата):
@Разработчик, спасибо за фидбэк. Я перепроверил. Поведение действительно соответствует текущей логике компонента X. Однако, согласно макету в Figma (ссылка) и аналогичному виджету на странице профиля, здесь ожидается поведение Y. Это нужно для консистентности интерфейса. 
@Продакт-менеджер, пожалуйста, уточни, какое поведение (текущее или из макета) является верным с точки зрения продукта? От этого зависит, будет ли это тикет багом или задачей на доработку.

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