Дэвид Андерсон - Канбан. Альтернативный путь в Agile

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

Также из предыдущих данных известно, что в среднем инженерная работа занимала 11 дней, а при самом высоком качестве работ – 15. Поэтому мы решили предложить 25-дневное время выполнения, считая с момента выбора элемента из входящей очереди. Больше никаких научных данных не потребовалось. А теперь представьте психологический эффект от этого: в бизнесе привыкли, что работа занимает четыре-пять месяцев, а мы предлагали 25 дней. Разница в том, что мы говорили о 25 днях как о времени выполнения, не учитывая ожидание в очереди, а 155 дней включали и его. Тем не менее это выглядело фантастическим улучшением. Неудивительно, что представители бизнеса согласились.

Есть и другие варианты. Можно взять предыдущие данные по инженерной работе и разместить их на графике статистического контроля процессов. Это даст вам верхний контрольный лимит (или 3-Sigma). Возможно, вы захотите немного буферизовать этот верхний лимит, чтобы нейтрализовать внешнюю вариативность. Но если вы так поступаете, нужно честно признаться в этом партнерам и показать, что вы провели соответствующие вычисления.

Еще одна альтернатива – спросить, в каком уровне ответной реакции нуждается бизнес. Лучше всего это сделать в контексте задания классов обслуживания. Например, если вам говорят: «Нам нужен релиз через три дня», спросите: «Все ли элементы нужно реализовать за три дня?» Чаще всего ответ будет отрицательным. Это даст возможность запросить определение типов запросов, которые должны быть реализованы в течение трех дней. После этого можно создать класс обслуживания для данного типа заданий. Повторите процесс для оставшихся заданий.

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

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

Выходные критерии для обсуждений с партнерами таковы: вы добились консенсуса по WIP-лимитам по всей цепочке создания ценности, достигнуто соглашение о координации расстановки приоритетов и используемом для нее методе и такое же соглашение о координации и методах сдачи работы, имеется определение набора соглашений об уровне обслуживания, включающее целевое время выполнения для каждого класса обслуживания.

• Можно выделить как минимум восемь целей внедрения Канбана в вашей организации.

• Улучшайте производительность, внося в процесс усовершенствования, которые будут встречены с минимальным сопротивлением.

• Сдавайте высококачественную работу.

• Время выполнения должно оставаться предсказуемым благодаря контролю числа незавершенных заданий.

• Создайте оптимальные условия для членов команды, улучшив их баланс работы и жизни.

• Внесите в систему резервы, сбалансировав нагрузку и пропускную способность.

• Обеспечьте простой механизм расстановки приоритетов, при котором обязательства откладываются, а варианты долго остаются возможными.

• Обеспечьте прозрачную схему, чтобы были видны возможности для роста. Тогда будут возможными сдвиги в сторону культуры большего сотрудничества, которые приведут к непрерывному совершенствованию.

• Боритесь за процесс, дающий предсказуемые результаты, деловую гибкость, хорошее управление и переход к тому, что Институт по разработке программного обеспечения называет организацией высокой зрелости.