КТЗ: коэффициент токсичности задачи — как одна метрика снизила текучку до 10%

24 мая 2026 5 min read

Два года назад из моего отдела ушел ключевой специалист. Спокойно, без скандала. Унес с собой три года контекста. Я долго не понимал, в чем дело, пока не начал считать то, что никто не считает: эмоциональную стоимость задачи.

Для кого: BA, PM, тимлиды и все, кто ведет бэклог и сталкивается с задачами, которые «вроде понятны», но итерацию ломают.

Проблема, которую не видит Jira

Две задачи, обе по 5 story points. Первая: чистое техническое задание, один заказчик, понятный критерий готовности. Восемь часов — закрыл — доволен. Вторая: требования размыты, два конфликтующих заказчика, дедлайн поставлен до того, как кто-то вообще понял объем. Неделя согласований, три возврата, ощущение что работал впустую.

В отчете обе задачи выглядят одинаково. Но одну исполнитель вспоминает с удовлетворением, вторую — с желанием сменить работу.

36% увольнений в IT в 2025 году — это выгорание. При этом скорость команды мы умеем измерять до миллиметра. Эмоциональную стоимость задачи не считает никто.

Я начал искать инструмент, который это считает. Оказалось, что его нет.

Что есть и почему не подходит:

Ближайший аналог в Agile — Definition of Ready. Набор условий перед итерацией: есть критерий приемки, нет неразрешенных зависимостей, понятен объем. Полезная вещь, но бинарная: прошло или не прошло. Числа нет — значит, нельзя сравнивать задачи между собой, считать среднее по итерации, находить паттерны по заказчикам.

RICE и ICE отвечают на другой вопрос: какую фичу делать первой. Это про ценность и усилие, не про готовность задачи к старту.

Методологически ближе всего — NASA Task Load Index, шкала когнитивной нагрузки 1988 года. Шесть субшкал, включая разочарование и ощущение результата. Я ее изучил отдельно. Проблема одна: NASA-TLX оценивает нагрузку постфактум, после выполнения задачи. Как вскрытие — точно, но поздно.

Числового фильтра на входе нет. Я сделал его сам.

Что такое КТЗ

КТЗ — коэффициент токсичности задачи. Число от 0 до 5, которого нет ни в одном таск-трекере.

Пять факторов, каждый — либо есть (1), либо нет (0):

Туманность требований. Нет четкого образа результата, критерии приемки не зафиксированы. Команда берет задачу с ощущением «разберемся по ходу». Самый частый фактор в моей практике: на старте всем кажется, что все понятно.

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

Внешние зависимости. Прогресс блокируют люди или системы вне нашего контроля.

Цикл правок. Задача возвращалась больше двух раз без существенного изменения требований. Не потому что плохо сделали, а потому что заказчик сам не знает, чего хочет.

Нереальный срок. Дедлайн поставлен до старта анализа. Команда берет задачу с пониманием, что не успеет, и это знание живет внутри весь спринт.

Сумма этих пяти факторов — КТЗ.

КТЗ Что это означает
0 Задача с четким ТЗ, одним владельцем, реальным сроком. Редкость, но бывает.
1–2 Рабочий диапазон. Один разговор с заказчиком закрывает риск.
3–5 Задача не готова к исполнению. Она готова к обсуждению.

Пример из практики

Внедряем информационно-управляющую систему для Департамента. В списке задач висит карточка: «Реализовать экспорт данных в формате заказчика». Звучит просто. По факту — формат нигде не задокументирован, у дочернего общества свои требования, у головной структуры другие, дедлайн поставил куратор из московских коллег, который уже три недели недоступен.

КТЗ этой задачи: 4. Туманность требований, конфликт владельцев, нереальный срок и внешняя зависимость.

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

Задача с КТЗ = 4 стоит как две-три задачи с КТЗ = 1. Планирование этого не видит.

Как использовать КТЗ на груминге

Задача с КТЗ >= 3 не идет в работу в текущем виде. Либо разбиваем на части прямо на груминге, либо возвращаем заказчику с конкретными вопросами.

Не «доработай» — а:

  • Кто принимает финальное решение по требованиям?
  • Какой критерий приемки фиксируем письменно прямо сейчас?
  • Есть ли зависимость от смежников, которую надо включить в планирование?

Пять вопросов, по минуте каждый. Каждое «не знаю» — плюс 1 к КТЗ. Это меняет сам характер встречи по уточнению задач. Вместо оценки сложности — оценка готовности.

Промпт для анализа бэклога

Считать КТЗ вручную на каждой встрече — не вариант для большого списка. Я делегировал первичный анализ ИИ.

Роль: ты — опытный скрам-мастер с жестким фокусом на качество входных требований.

Контекст: в команде действует КТЗ (Коэффициент токсичности задачи) с порогом готовности < 3. Пять бинарных факторов: туманность требований, конфликт владельцев, цикл правок, внешние зависимости, нереальный срок (каждый оценивается 0 или 1).

Я дам описание задачи. Выполни три шага:

Шаг 1 — Диагностика: оцени каждый из 5 факторов (0/1), посчитай КТЗ. Каждую оценку обоснуй одним конкретным предложением со ссылкой на текст задачи.

Шаг 2 — Решение по уровню КТЗ:
— КТЗ 0–2: задача готова. Укажи, что можно усилить для снижения риска.
— КТЗ 3–4: предложи минимальный набор действий для снижения КТЗ < 3. Для каждого фактора — конкретный вопрос владельцу или критерий приемки.
— КТЗ 5: задача возвращается. Сформулируй список того, что должно быть сделано до следующего уточнения задач.

Шаг 3 — Сообщение заказчику: 3–4 строки. Указать КТЗ, конкретные вопросы или действия. Без воды, без извинений.

Задача: [описание, заказчик, дедлайн]

Промпт для очистки мертвого бэклога

Отдельная история — задачи, которые накопились месяцами. «Изучить возможность...», «Подумать над...». Я называю их фантомными. Каждый раз, открывая список на 200 задач, мозг пытается оценить приоритет каждой, включая мертвые. Это как держать 200 вкладок в браузере.

Роль: ты — опытный владелец продукта, который умеет говорить «нет» задачам без ценности.

Задача: проанализируй каждую задачу из списка и определи её судьбу:
— Kill: закрыть без сожалений
— Merge: объединить с другой задачей
— Rewrite: переформулировать — есть потенциал, но непонятно что делать

Критерии мертвой задачи (хотя бы 2 из 4):
— Создана более 3 месяцев назад без единого обновления
— Нет конкретного результата в формулировке
— Не отвечает на вопрос «зачем это бизнесу прямо сейчас?»
— Нет владельца или заказчик покинул проект

Формат: таблица | ID | Название | Группа | Обоснование |
После таблицы — готовый текст для команды: что закрываем и почему.

Список задач: [экспорт из таск-трекера: ID, название, дата создания, статус]

Результаты за полгода

Через месяц после того, как начали считать КТЗ, нашли паттерн, который объяснил половину возвратов за последний год.

Задачи от одного конкретного заказчика стабильно набирали 4–5. Не потому что он плохой, а потому что у него не было этапа проработки требований. Поручения формулировались на ходу и сразу падали в разработку. Это звучит очевидно. Но у нас было не принято говорить об этом вслух.

КТЗ дал фактуру для разговора без обвинений. Не «твои задачи всегда непонятные» — а «средний КТЗ задач от вас — 4.1, от остальных — 1.6. Вот три последних примера, вот конкретные вопросы, которых не хватает до старта».

После введения обязательного этапа проработки:

  • Средний КТЗ упал с 4.2 до 1.8
  • Возвраты задач за итерацию: с четырех-пяти до одного
  • Текучесть персонала: с 30% до 10% за полгода

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

Раньше на вопрос «почему итерация провалилась?» у меня был один ответ: «Задачи были сырые». Попробуй объясни это замдиректора. Теперь есть цифра: «КТЗ итерации 4.2, норма до 2.5, вот три конкретных источника, вот что меняем».

Часто задаваемые вопросы

Чем КТЗ отличается от Definition of Ready?

Definition of Ready — бинарный: задача либо прошла, либо нет. КТЗ дает число, с которым можно работать: сравнивать задачи между собой, считать среднее по итерации, отслеживать динамику по заказчикам. Это разница между «светофором» и «спидометром».

Нужно ли считать КТЗ для каждой задачи?

На практике — нет. Для знакомых типовых задач достаточно беглой проверки по пяти факторам. Полный расчет имеет смысл для крупных задач, задач от новых заказчиков и всего, что вызывает интуитивное беспокойство команды.

Что делать, если задача с КТЗ = 5 все равно нужна срочно?

Срочность не снижает КТЗ, она его маскирует. Если задачу нельзя отложить — фиксируйте риски письменно до старта. Это не спасет итерацию, но сделает разбор полетов предметным, а не эмоциональным.

Можно ли автоматизировать расчет КТЗ?

Да. Я использую промпт-шаблон с ИИ для первичного анализа бэклога — он в статье выше. Также есть бот @KTZ_ToksikomerBot: задает пять вопросов и выдает КТЗ с готовым промптом под ваш уровень риска.

Как убедить команду начать считать КТЗ?

Не убеждать — показывать. Возьмите последние три итерации, которые пошли не так. Посчитайте КТЗ задач постфактум. Разрыв между тем, что видел таск-трекер, и тем, что вскроет КТЗ, говорит сам за себя.