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

Я не сразу понял, что дело не в зарплате и не в карьерном росте. Люди уходили от конкретных задач — просто никто это так не формулировал. 36% увольнений в IT в 2025 году — это выгорание. Мы умеем измерять скорость команды до миллиметра. Эмоциональную стоимость задачи — никто не считал.

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

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

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

Я начал искать инструмент, который это считает. И обнаружил кое‑что интересное.

Что уже существует и почему не подходит

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

Есть RICE и ICE — фреймворки приоритизации. Они отвечают на вопрос — какую фичу делать первой? Это про ценность и усилие, но не про готовность и стоимость человеческих затрат.

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

Получается, что инструменты для приоритизации есть. Чеклисты готовности — тоже. Диагностика нагрузки постфактум есть. А вот числового фильтра на входе нет.

Что такое КТЗ

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

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

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

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

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

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

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

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

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

Почему это важнее story points

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

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

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

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

Как это работает на груминге

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

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

• Кто принимает финальное решение по требованиям?

• Какой критерий приемки фиксируем письменно прямо сейчас?

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

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

Что вскрылось за полгода

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

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

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

После введения обязательного этапа проработки средний КТЗ упал с 4.2 до 1.8. Возвраты задач почти пропали — раньше за итерацию было четыре‑пять, теперь один в лучшем случае. Но цифра, которая удивила больше всего — текучесть. С 30% до 10% за полгода. Если задуматься — это логично. Люди уходят не от сложных задач, а от задач, в которых нельзя победить.

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

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

Вот промпт, который использую:

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

Контекст: в команде действует КТЗ (Коэффициент токсичности задачи) с порогом готовности < 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 | Название | Группа | Обоснование |

После таблицы — готовый текст в Slack для команды: что закрываем и почему.

Список задач:

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

КТЗ — это симптом, а не причина

Первые месяцы я работал с метрикой как с инструментом фильтрации: высокий КТЗ — задача не идет в работу, низкий — идет. Это работало, но не объясняло, почему токсичные задачи вообще появляются.

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

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

Вопрос, который хорошо работает на разборе полетов: «Где хранится история изменений требований?» Если команда не может ответить быстро — вот корневая проблема.

Итог

КТЗ не заменяет нормальный процесс проработки требований и внятные технические задания.

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

Если хотите попробовать на своем списке задач — есть бот, который задает пять вопросов и считает КТЗ за 30 секунд: @KTZ_ToksikomerBot. Даёт не просто цифру, а готовый промпт под ваш уровень риска.

Про метрики нагрузки и инструменты для BA и PM — в канале Async Mind.