Ограничение задач в работе (WIP)
Еще одно изменение, задуманное Драгошем, – это ограничение числа задач в работе и вытягивание новых задач из очереди только после завершения старых. Он решил ограничить разработку одним запросом на разработчика, такой же норматив был установлен для тестировщиков.
Добавив очередь для получения PTC, он обеспечил равномерный поток работы между разработкой и тестированием, что показано на рис. 4.4. Этот подход – использование буфера для снижения вариативности размеров и усилий – обсуждается в главе 19.
Примечание. Это установленное правило: одна задача на одного разработчика в любое время. Позже правило может быть изменено. Представление процесса как набора правил – ключевой элемент Канбан-метода.
.
Рис. 4.4. Модель состояний, показывающая желаемый поток работ с ограничением незавершенной работы
Установление каденции пополнения
Примечание. Каденция – это понятие Канбан-метода, которое определяет ритм событий определенного типа. Расстановка приоритетов, поставка, ретроспективы и все повторяющиеся события могут иметь собственную каденцию.
Чтобы облегчить принятие решения об ограничении задач в работе и переходе на вытягивающую систему, Драгош должен был подумать о каденции взаимодействий с менеджерами продукта. Он посчитал, что еженедельное совещание – оптимальный вариант, поскольку его тема – пополнение входящей очереди производственной системы из бэклога. Обычно в течение недели освобождались три места в очереди, поэтому следовало обсуждать вопрос «Какие три элемента бэклога вы бы предпочли отправить сейчас в разработку?». Каденция моделируется на рис. 4.5.
Рис. 4.5. Рабочий процесс с Канбаном: ограничение задач в работе и очереди
Он хотел предложить «гарантированное» время выполнения – 25 дней с момента попадания задачи во входящую очередь. Конечно, 25 больше, чем 11. А на некоторые задачи требовалось до 30 дней. Но Драгош решил, что таких заданий не должно быть много. И, кроме того, 25 – это гораздо меньше, чем 140, а именно столько дней составлял текущий срок выполнения работ. Он рассчитывал добиться цели благодаря регулярности поставок, построению доверительных отношений с менеджерами продукта и их клиентами.
Достижение нового соглашения
Драгош сделал менеджерам продукта предложение – попросил примириться с тем, что они будут встречаться раз в неделю и обсуждать приоритеты, он ограничит количество незавершенной работы, а его команда перестанет заниматься оценкой. В обмен на это он сократит время выполнения до 25 дней и будет в дальнейшем ориентироваться на этот дедлайн.
Клиентам предложили отказаться от вычисления ROI и переводов бюджета между отделами на основе оценки планируемых трудозатрат. В обмен на это им пообещали беспрецедентно короткие сроки выполнения и надежность. Для удобства расчетов время обработки запроса – примерно 11 дней – устанавливалось на основании исторических данных, о чем говорилось выше, в разделе «Факторы, влияющие на производительность». Также их попросили считать затраты фиксированными и игнорировать ту калькуляционную парадигму, на которой ранее основывались переводы бюджета между отделами.
Драгош обосновывал эти перемены так: у организации-поставщика есть годичный контракт, по которому она ежемесячно выставляет счет. В соответствии с контрактом поставщик привлекает людей, получающих зарплату независимо от того, работают они в данный момент или нет. Бюджет, поступающий от четырех менеджеров продукта, – это фиксированная сумма, распределяемая пропорционально. Драгош гарантировал, что каждому менеджеру продукта достанется справедливая доля. Это освободит их от необходимости отслеживать каждый запрос. Если они смогут принять тот факт, что доллары приносят им гарантированный результат, то, возможно, откажутся от предубеждения против приблизительной оценки трудозатрат и переводов бюджета. Чтобы определить, чья очередь подходит, разработали несколько простых правил, поэтому распределение осуществлялось справедливо. Достаточно было простой круговой схемы с весовыми коэффициентами.