Время выполнения и классы обслуживания

 

Когда разговор заходит о времени выполнения, полезно привести накопленные данные по предыдущей производительности. В идеале хорошо иметь данные по времени выполнения и инженерному времени. В примере с Microsoft (глава 4) было известно, что время выполнения составляет примерно 125 дней на устранение ошибок первой степени срочности и 155 дней – на ошибки остальных степеней. Главное, что мы можем отсюда почерпнуть, – это наличие двух классов обслуживания. Ошибки первой степени в какой‑то форме обрабатывались раньше. Возможно, формальных правил не было, но так уж выходило, что ошибки первой степени устранялись быстрее.

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

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

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

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

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

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

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

 

 

Выводы

 

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

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

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

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

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

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

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

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

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

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

• Следуйте пошаговому 12‑этапному руководству по введению Канбан‑процесса.

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

• Привлечение внешних заинтересованных лиц к договору о базовых элементах канбан‑системы позволяет заручиться их сотрудничеством.

• Основные правила, касающиеся WIP‑лимитов, целевого времени выполнения, классов обслуживания, расстановки приоритетов и релизов, – это правила совместной игры по разработке программного обеспечения.

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

 

Часть IV

Совершенствование

 

Глава 16