Дубли задач между командами возникают не из-за хаоса, а из-за слабого разграничения ответственности

Дубли задач между командами возникают не из-за хаоса, а из-за слабого разграничения ответственности

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

Рабочая схема простая:
• один intake-канал для всех запросов;
• шаблон задачи с полями «цель», «срок», «ответственный», «зависимости»;
• запрещён прямой старт работы без назначения владельца;
• если задача пересекает команды — у неё один главный, остальные только исполнители.

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

Если дубль уже случился, не ищите виноватого — зафиксируйте, на каком шаге система дала второй вход. После пары таких разборов обычно становится видно, где именно ломается процесс: в постановке, маршрутизации или праве на запуск.