Повторюсь, КТЗ не решает проблему непонятных требований, он помогает ее увидеть системно. Когда разработчик перекидывает задачу аналитику, это разовое решение. Но если задачи от одного источника стабильно набирают 4-5, это уже сигнал не про конкретную задачу, а про системный процесс на стороне заказчика. Вот тут КТЗ дает фактуру для разговора на уровень выше.
Нет, проработка требований - обязанность аналитика. В статье имелось в виду что заказчик не проходил этап совместной проработки с аналитиком перед постановкой задачи - просто ставил задачи напрямую. Причем это происходит часто потому, что в системе заказчика так настроен процесс.
КТЗ не перекладывает работу аналитика на разработчика - он помогает аналитику и руководителю остановить задачу до того как она ушла в разработку. Это инструмент для фильтрации на входе, но не замена ролям.
Аналитик в спринте есть. Но в крупных организациях, с которыми мы работаем, задачи часто прилетают уже с дедлайном, аналитик физически не успевает проработать их до планирования. КТЗ как раз помогает быстро отсечь то, что в текущем виде брать не стоит. Дальше уже переговоры с заказчиком на основе фактуры, а не ощущений.
Про рынок труда - справедливое замечание, фактор есть и его нельзя игнорировать. Но у нас изменения начались раньше чем рынок просел, так что списать только на это не получается.
Про то что «эта задача так себе» - интуитивно да, было понятно и раньше. Но когда задач много и сроки сжатые, не всегда есть время остановиться и оценить каждую. КТЗ делает это быстро и дает язык для разговора с заказчиком - конкретные цифры и вопросы.
Принцип "вы сделайте, мы посмотрим" который вы описываете - это туманность требований и конфликт владельцев в одном флаконе, КТЗ = 3 минимум. Очень узнаваемо.
Согласен, хороший аналитик снимает эти проблемы до старта. КТЗ не замена качественной аналитике, это страховка там где процесс не идеален. В крупных организациях аналитик часто есть, но полномочий у него недостаточно. Или задачи прилетают мимо него напрямую от стейкхолдеров высокого уровня.
Верно подмечено. КТЗ намеренно не учитывает исполнителя, это сделано чтобы метрика работала на уровне процесса. Но ваше замечание про разное выгорание справедливое. КТЗ говорит, что задача токсична, но не говорит насколько токсична для конкретного исполнителя. Это следующий уровень, но я над этим еще не работал.
Средняя численность команды по внедрению систем - 15 человек. Раньше текучка составляла 4-5 человек за полгода, сейчас 1-2. Черновик готовился с помощью ИИ, ситуации и цифры из реального опыта.
По сути КТЗ это и показывает - когда задачи от одного источника стабильно набирают 4-5, это уже его коэффициент. Просто считается через задачи от него, а не отдельно.
Не совсем так. DoR говорит да или нет, прошла ли задача чеклист. КТЗ дает число, с которым можно работать - сравнивать задачи между собой, считать среднее по спринту, находить паттерны по источникам. Когда у тебя есть данные, которые показывают что задачи от одного заказчика стабильно набирают 4-5 - разговор с ним строится на цифрах, а не на ощущениях.
Да, знакомый термин. Но КТЗ смотрит на задачу до старта, шрамы это уже другой слой. Возможно, есть повод для внедрения отдельного коэффициента - токсичности унаследованного кода.
Да, принцип можно использовать везде где есть неопределенность на входе.
Повторюсь, КТЗ не решает проблему непонятных требований, он помогает ее увидеть системно. Когда разработчик перекидывает задачу аналитику, это разовое решение. Но если задачи от одного источника стабильно набирают 4-5, это уже сигнал не про конкретную задачу, а про системный процесс на стороне заказчика. Вот тут КТЗ дает фактуру для разговора на уровень выше.
Нет, проработка требований - обязанность аналитика. В статье имелось в виду что заказчик не проходил этап совместной проработки с аналитиком перед постановкой задачи - просто ставил задачи напрямую. Причем это происходит часто потому, что в системе заказчика так настроен процесс.
КТЗ не перекладывает работу аналитика на разработчика - он помогает аналитику и руководителю остановить задачу до того как она ушла в разработку. Это инструмент для фильтрации на входе, но не замена ролям.
Аналитик в спринте есть. Но в крупных организациях, с которыми мы работаем, задачи часто прилетают уже с дедлайном, аналитик физически не успевает проработать их до планирования. КТЗ как раз помогает быстро отсечь то, что в текущем виде брать не стоит. Дальше уже переговоры с заказчиком на основе фактуры, а не ощущений.
Удачи с прогоном - пишите что получилось.
Про рынок труда - справедливое замечание, фактор есть и его нельзя игнорировать. Но у нас изменения начались раньше чем рынок просел, так что списать только на это не получается.
Про то что «эта задача так себе» - интуитивно да, было понятно и раньше. Но когда задач много и сроки сжатые, не всегда есть время остановиться и оценить каждую. КТЗ делает это быстро и дает язык для разговора с заказчиком - конкретные цифры и вопросы.
Принцип "вы сделайте, мы посмотрим" который вы описываете - это туманность требований и конфликт владельцев в одном флаконе, КТЗ = 3 минимум. Очень узнаваемо.
Согласен, хороший аналитик снимает эти проблемы до старта. КТЗ не замена качественной аналитике, это страховка там где процесс не идеален. В крупных организациях аналитик часто есть, но полномочий у него недостаточно. Или задачи прилетают мимо него напрямую от стейкхолдеров высокого уровня.
Рад что сразу в дело. Удачи с задачами
Попробуйте на реальном бэклоге, первые результаты обычно удивляют.
Верно подмечено. КТЗ намеренно не учитывает исполнителя, это сделано чтобы метрика работала на уровне процесса. Но ваше замечание про разное выгорание справедливое. КТЗ говорит, что задача токсична, но не говорит насколько токсична для конкретного исполнителя. Это следующий уровень, но я над этим еще не работал.
Средняя численность команды по внедрению систем - 15 человек. Раньше текучка составляла 4-5 человек за полгода, сейчас 1-2. Черновик готовился с помощью ИИ, ситуации и цифры из реального опыта.
По сути КТЗ это и показывает - когда задачи от одного источника стабильно набирают 4-5, это уже его коэффициент. Просто считается через задачи от него, а не отдельно.
Не совсем так. DoR говорит да или нет, прошла ли задача чеклист. КТЗ дает число, с которым можно работать - сравнивать задачи между собой, считать среднее по спринту, находить паттерны по источникам. Когда у тебя есть данные, которые показывают что задачи от одного заказчика стабильно набирают 4-5 - разговор с ним строится на цифрах, а не на ощущениях.
Да, знакомый термин. Но КТЗ смотрит на задачу до старта, шрамы это уже другой слой. Возможно, есть повод для внедрения отдельного коэффициента - токсичности унаследованного кода.