Канбан. Альтернативный путь в Agile

Клиентам предложили отказаться от вычисления ROI и переводов бюджета между отделами на основе оценки планируемых трудозатрат. В обмен на это им пообещали беспрецедентно короткие сроки выполнения и надежность. Для удобства расчетов время обработки запроса – примерно 11 дней – устанавливалось на основании исторических данных, о чем говорилось выше, в разделе «Факторы, влияющие на производительность». Также их попросили считать затраты фиксированными и игнорировать ту калькуляционную парадигму, на которой ранее основывались переводы бюджета между отделами.

Драгош обосновывал эти перемены так: у организации-поставщика есть годичный контракт, по которому она ежемесячно выставляет счет. В соответствии с контрактом поставщик привлекает людей, получающих зарплату независимо от того, работают они в данный момент или нет. Бюджет, поступающий от четырех менеджеров продукта, – это фиксированная сумма, распределяемая пропорционально. Драгош гарантировал, что каждому менеджеру продукта достанется справедливая доля. Это освободит их от необходимости отслеживать каждый запрос. Если они смогут принять тот факт, что доллары приносят им гарантированный результат, то, возможно, откажутся от предубеждения против приблизительной оценки трудозатрат и переводов бюджета. Чтобы определить, чья очередь подходит, разработали несколько простых правил, поэтому распределение осуществлялось справедливо. Достаточно было простой круговой схемы с весовыми коэффициентами.

Внедрение изменений

Хотя менеджеры продукта и многие коллеги Драгоша по XIT оставались скептиками, они решили дать ему возможность попробовать. В конце концов, дела шли хуже некуда. Нужно было что-то предпринять, и Драгошу поручили внести изменения.

Итак, изменения начались.

И все наладилось! Запросы обрабатывались и выводились в новых релизах. Время выполнения по новым обязательствам укладывалось в обещанный 25-дневный срок. Ежедневные совещания работали как часы, пополнение производственной системы задачами тоже происходило каждую неделю. Менеджеры продукта стали проникаться доверием к команде.

Адаптация правил

Примечание. Это распространенная тема в канбан-методе. Сочетание четких правил, прозрачности и визуализации дает членам команды возможность принимать собственные решения и самостоятельно оценивать риски. Руководство в итоге начинает доверять системе, поскольку понимает, что процесс – это набор правил, которые предназначены для управления рисками и удовлетворения пользовательских ожиданий. Эти правила прописаны, работа открыто визуализируется, а все члены команды понимают правила и принципы их применения.

Но каким образом достигалась расстановка приоритетов, если подсчет ROI больше не проводился? Оказалось, что он и не нужен. Если элемент важен и ценен, то его выбирали из очереди в бэклоге, а если нет, то отодвигали дальше. Позже Драгош понял, что необходимо еще одно правило – безжалостно удалять из бэклога любой элемент более чем шестимесячной давности. Если за полгода о нем ни разу не вспомнили, то наверняка он не имеет никакого значения. А если выяснится, что данный элемент все же важен, то его можно включить заново.

А как насчет правила, согласно которому крупные запросы не поступали в техподдержку, а становились частью большого проекта? В итоге решили, что некоторые из них все же могут туда направляться. Опыт показывал, что таких запросов обычно менее 2 %. Разработчиков просили быть внимательными и, если новый запрос, по их оценкам, требовал на обработку более 15 дней, предупреждать своего менеджера. Риски и затраты в данном случае составляли менее 1 % доступной мощности. Это прекрасно окупалось: отказавшись от оценок, команда обрела более 33 % мощности за счет затрат менее 1 % той же мощности. Это новое правило позволило разработчикам управлять рисками и при необходимости высказывать свое мнение!