Когда возникает дубликат won't do?

Когда возникает дупликат воркфлоу "Won't Do" в процессе разработки программного обеспечения

В контексте управления требованиями и задачами в системах отслеживания ошибок (например, Jira, Azure DevOps, Redmine) дубликат статуса "Won't Do" возникает в нескольких типичных ситуациях, которые отражают процесс принятия решений и приоритизации в разработке ПО. Этот статус означает, что задача, багрепорт или фича не будут реализованы или исправлены в текущем или планируемых релизах, и его дублирование может быть как корректной практикой, так и следствием ошибок процесса.

Основные причины возникновения дубликатов "Won't Do":

• Повторяющиеся или массовые репорты от пользователей: Например, при выходе нового релиза несколько пользователей независимо сообщают об одном и том же неочевидном, но намеренном изменении функционала, которое воспринимается ими как ошибка. QA или менеджер закрывает каждый такой репорт как Won't Do с комментарием о том, что это запланированное изменение.

  Заголовок: Кнопка "Сохранить" перемещена в правый верхний угол — это неудобно!
  Статус: Won't Do
  Комментарий: Это изменение UI/UX согласно дизайн-макету версии 2.1. Функциональность сохранения не нарушена.
  Ссылка на требование: UX-123
  

• Отклонение низкоприоритетных или edge-case багов: Несколько задач, описывающих редкие сценарии, требующие непропорционально больших усилий для исправления, могут быть массово отклонены перед релизом для концентрации на критичных проблемах.

• Дублирование задач в backlog: В large-командах два человека могут создать две одинаковые пользовательские истории. На этапе grooming или prioritization обе могут быть помечены как Won't Do, если продукт-менеджер решил полностью отказаться от этой функциональности.

• Проблемы в процессах коммуникации и triage:

    *   **Отсутствие синхронизации:** Один инженер уже обработал и отклонил баг, но не успел добавить **соответствующие теги** (например, `duplicate`) или связать его с исходным отчетом. Второй инженер, встречая похожий репорт, также закрывает его как `Won't Do`.
    *   **Ошибочное применение:** Новички в команде могут путать статусы `Won't Do` и `Duplicate`. Вместо того чтобы линковать дубликат к исходной задаче (которая, в свою очередь, может быть закрыта как `Won't Do`), они напрямую выставляют статус `Won't Do`.

# Пример логики обработки баг-репорта в системе
def process_bug_report(bug, existing_issues):
    # Проверка на дубликат
    duplicate = find_duplicate(bug, existing_issues)
    if duplicate:
        if duplicate.status == "WON'T_DO":
            # Решение: связать текущий баг с существующим как дубликат
            bug.link_to(duplicate)
            bug.set_status("DUPLICATE")
            bug.set_resolution("Duplicate of issue with 'Won't Do' status")
        else:
            bug.set_status("DUPLICATE")
    else:
        # Если дубликатов нет, принимать решение по существу
        if is_feature_by_design(bug) or is_out_of_scope(bug):
            bug.set_status("WON'T_DO")
            bug.set_resolution("Working as designed / Out of scope")
        else:
            bug.set_status("OPEN")

Как минимизировать нежелательное дублирование статуса "Won't Do":

1. Четкое определение workflow: В процессе triage (разбора входящих issues) должно быть правило: сначала искать потенциальный дубликат, и только если его нет — принимать решение (Open, Won't Do, Defer).
2. Обучение команды: Все участники (QA, разработчики, менеджеры) должны понимать разницу между Duplicate и Won't Do. Won't Do — решение по сути, а Duplicate — техническая связь.
3. Использование возможностей трекера: Обязательное использование поля "Связанные issues" или функции "Связать как дубликат". Это позволяет поддерживать историю и прозрачность.
4. Качественные комментарии: Любое закрытие как Won't Do требует развернутого обоснования (например, "Отклонено в связи с изменением бизнес-требований", "Low priority, не соответствует текущей product vision", "Работает в соответствии с техническим дизайном").
5. Регулярный аудит: Периодический просмотр задач, закрытых как Won't Do, особенно если их число резко возросло, помогает выявить системные проблемы в процессе коммуникации или в продукте.

Заключение: Сам по себе факт наличия нескольких задач со статусом Won't Do не является проблемой — он отражает активный процесс фильтрации входящего потока требований. Проблемой становится неконтролируемое дублирование, вызванное сбоями в процессе triage, которое ведет к потере истории, размыванию статистики и недовольству пользователей, чьи репорты "исчезают" без должной связи. Ключ к управлению этим — четкие процедуры, обучение и эффективное использование инструментов.