Ознакомительная версия.
Другие рыночные факторы
В октябре 2008 года вслед за крахом Lehman Brothers и ряда других драматических событий в финансовом секторе банки и инвестиционные компании таких ведущих финансовых центров, как Лондон и Нью-Йорк, стали отменять или видоизменять IT-проекты, находившиеся в разработке. Причина была в том, что их мир рушился и они боролись за выживание как могли. Внезапно выяснилось, что нужно лучше понять собственную – и общерыночную – ликвидность. Оказалось, что предлагать новейшие или экзотичные товары и услуги неактуально. Рынок больше не интересовался инвестициями. Осенью 2008 года финансовые предприятия беспокоились исключительно о собственной платежеспособности или ее отсутствии.
Это конкретный пример того, насколько серьезно могут измениться проектные портфели и требования к проекту в процессе работы. Необходимость реагировать на подобные изменения обычно отвлекает команды, что приводит к существенным потерям в пропускной способности, значительному увеличению времени выполнения, а нередко и к потере качества, отсутствию предсказуемости, поскольку команде нужно справиться с хаосом, который рыночные колебания вносят в проект.
Разумеется, эти события относятся к вариациям с выявляемыми причинами. Их требуется нейтрализовать при помощи стратегии и тактики управления рисками. Существуют достаточно серьезные наработки по вариациям с выявляемыми причинами, или событийному риску. Наличие опыта в управлении рисками как часть общей цели повышения зрелости организации улучшит предсказуемость разработки как при использовании Канбана, так и без него. Однако канбан-системы демонстрируют большую предсказуемость при хорошем управлении рисками. Это порождает внутрисистемное доверие.
В канбан-системах есть и другие элементы, которые помогают при управлении рисками. Так, WIP-лимит снижает риск, поскольку в любое время в работе находится лишь небольшое число задач. Назначение WIP-лимитов для отдельных типов рабочих единиц и классов обслуживания позволяет управлять рисками и нейтрализовать вариации с выявляемыми причинами. Появляются и другие стратегии. Судя по всему, выйдут в свет и новые книги, где будут подробно описаны передовые методы внедрения Канбана и современные тактики управления рисками.
Некоторые материалы по управлению рисками в канбан-системах, появившиеся в результате использования Канбана, я представлял на конференциях в 2009 году. Они доступны в интернете.
Еще один распространенный источник вариаций с выявляемой причиной, который блокирует работу и лишает поток равномерности, – это координация с внешними командами, заинтересованными лицами и ресурсами. Обычная реакция на проблемы координации – планирование совещаний с регулярной каденцией. В определенных случаях это очень эффективное решение, но оно не всегда возможно.
Поток может быть прерван ограничениями, которые установлены правительственными органами или нормативными документами, требующими проведения аудита или утверждения документа. Люди, которые должны выполнять эту функцию, часто недоступны или не располагают свободным временем.
Сначала вариации с выявляемыми причинами такого рода нужно нейтрализовать, повысив осведомленность сотрудников и обратив общее внимание на этот фактор при помощи наглядности и прозрачности. Маркировав элементы как заблокированные и наглядно продемонстрировав источник блокировки, руководство, команда и другие участники цепочки создания ценности осознают воздействие этих координационных проблем.
Такое осознание должно привести к поведенческим изменениям, улучшающим ситуацию.
Одна из возможных тактик – изучение правительственных и регуляторных норм с целью определить, что именно должно подвергнуться оценке, одобрению, аудиту и изучению. Если предположить, что существуют разные профили риска, которые дают возможность распределить задания на две категории – «необходимо согласовать» и «необязательно согласовывать», – то для разбивки задач можно использовать типы рабочих единиц либо классы обслуживания. После этого стоит задать отдельные WIP-лимиты как для типов, так и для классов для обеспечения равномерности потока.
• Изучение вариативности в промышленных процессах началось в 1920-е годы с Уолтера Шухарта. В середине и конце XX века его дело продолжили и развили Эдвардс Деминг, Джозеф Джуран и Дэвид Чемберс.
• Изучение вариативности и связанный с ним метод статистического анализа лежит в основе производственной системы Toyota (а следовательно, и бережливого управления) и метода «шести сигм» для совершенствования процесса.
• Работы Эдвардса Деминга и Джозефа Джурана – главный источник вдохновения для Института технологий разработки ПО Университета Карнеги – Меллон и модели зрелости возможностей (современное название – «интегрированная модель зрелости», или CMMI).
• Шухарт разделил источники вариативности на две категории: внутренние для процесса или системы и внешние для процесса или системы.
• Внутренние вариации называются вариациями со случайными причинами.
• Внешние вариации называются вариациями с выявляемыми причинами.
• В цепочке создания ценности жизненного цикла разработки ПО может быть много источников вариаций со случайными причинами. Типичные примеры – размер рабочей единицы, тип, класс обслуживания, нерегулярный поток и переработка.
• Список источников вариаций с выявляемыми причинами, возможно, бесконечен. Типичные примеры – двусмысленные требования, ускоренные запросы, доступность среды, нерегулярный поток, рыночные факторы, факторы персонала и проблемы с координационной деятельностью.
• Вариации со случайными причинами можно контролировать, задав правила, определяющие жизненный цикл разработки ПО и используемые процессы управления проектами.
• Вариациями с выявляемыми причинами можно управлять, развив способности к управлению проблемами и их разрешению, а также способности к управлению рисками. Такие вариации можно сократить или ликвидировать благодаря анализу и устранению первопричин.
• Канбан-системы приводят к более благоприятным экономическим результатам, если с ними сочетается умелое управление событийными рисками.
• Канбан также предлагает дополнительные способы управления рисками – например, назначение WIP-лимитов для классов обслуживания и типов рабочих единиц, использование профилей риска для разбивки задач на типы или классы и действия в соответствии с ними.
• Предстоит еще много работать над передовыми стратегиями и тактиками управления рисками в Канбане – это станет темой следующей книги.
Глава 20
Управление проблемами и правила эскалации
Когда работа в нашей канбан-системе оказывается заблокированной, обычно на стене к карточке, содержащей причины блокировки, прикрепляется розовый стикер. В электронных системах могут существовать и другие способы визуализации факта блокировки: например, карточки обводят красной рамкой. Предпочтительно, чтобы функции электронной системы позволяли отдельно указывать причины блокировки или связывать проблему с пользовательскими запросами, которые зависят от решения этой проблемы.
Я заметил, что некоторые новички в использовании Канбана считают заблокированные задачи бутылочными горлышками. Это неверно. Заблокированная задача действительно образует затор, ограничивающий поток. Но он не относится к бутылочным горлышкам, описанным в главе 17, так как это не ресурс ограниченной мощности и не ресурс с ожиданием доступа. Точно так же пробка – это вовсе не бутылочное горлышко. Чтобы возобновить поток жидкости из бутылки, надо попросту вынуть пробку.
Считать заблокированные задачи бутылочными горлышками даже опасно, поскольку это ведет к неправильному подходу к решению проблемы. Блокированные задачи – это вариации с особой причиной. Их единственное сходство с бутылочными горлышками – желаемый результат. В обоих случаях нам нужно решить определенную проблему, чтобы снова сделать поток равномерным.
Заблокированные задачи требуют от организации умелого управления проблемами и способности решать их, чтобы быстрее возобновить поток, а также осуществлять анализ первопричин и устранять их, чтобы те же проблемы не возникали вновь. О последнем навыке говорилось в главе 19 (устранение вариаций с особыми причинами). А управление проблемами обсудим в этой главе.
Недостаточно просто отметить задачи как заблокированные. Однако многие первые инструменты гибкой разработки ПО давали лишь эту возможность. Знать, что задача, пользовательская история, функция или сценарий заблокированы, полезно. Но наблюдая за командами программистов со всего мира, я пришел к следующему выводу: понимать, что нечто заблокировано, – это еще не значит уметь разблокировать.
Ознакомительная версия.
