Внешние источники вариативности

 

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

 

Двойственность требований

 

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

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

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

В 2007 году в Corbis это достигалось постепенно. Сначала внедрили канбан‑систему – визуальную доску и электронное средство отслеживания. Вместе с этим пришла прозрачность. Бизнес оказался сильнее вовлечен в процесс разработки ПО и в наблюдение за производительностью этого подразделения. Создавались отчеты, демонстрирующие количество нерешенных проблем и заблокированных единиц работы, а также среднее время разрешения этих задач. (Рис. 12.6. Отчет о проблемах и заблокированных единицах работы)

Когда требование проделало путь до приемочного тестирования, но было отвергнуто, поскольку оказалось ненужным бизнесу, команда ответила на это, выделив на доске мусорную корзину и прикрепив к ней талон, как показано на рис. 19.1. После этого руководство попросило создать несколько электронных отчетов о работе, которая поступила в систему, но не смогла проделать весь путь по ней (рис. 19.2).

 

Рис. 19.1. Доска с мусорной корзиной

 

Рис. 19.2. Отчет о непринятой и отмененной работе, демонстрирующий незавершенные рабочие единицы за прошлый месяц

 

Сочетание прозрачности, отчетности и сознания ответственности за отрицательное влияние (в том числе экономическое) неудачных требований привело к тому, что бизнес сознательно изменил поведение. Изначально отчет о потерях, который демонстрировал эффект от неудачных требований, содержал от пяти до десяти единиц в месяц. К пятому месяцу он опустел. Бизнес понял: если относиться к созданию требований внимательнее, то можно будет не разбрасываться мощностью. Они добровольно согласились сотрудничать, чтобы добиться лучших системных результатов. В итоге удалось исключить первопричины выявляемых вариаций из‑за плохо написанных требований или неудачно определенной контекстуальной информации.

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

Это один из примеров того, как локально предпринятые меры косвенно влияют на вариации с выявляемой причиной.

 

Ускоренные запросы

 

Ускоренные запросы – результат внешних событий, таких как неожиданный заказ клиента, или неполадок во внутренних процессах компании, например коммуникативной ошибки, которая приводит к слишком позднему обнаружению какого‑то важного требования. Ускоренные запросы – это вариации с выявляемыми причинами, поскольку причина запроса всегда известна, а следовательно, «выявляема».

В промышленном производстве ускорение считается отрицательным фактором. Оно влияет на предсказуемость других запросов, увеличивает среднее время выполнения и разброс вариативности, а также сокращает пропускную способность. Данные, полученные за 2007 год в Corbis, показали, что это верно и для процессов разработки ПО: ускорение нежелательно, даже если проводится с целью создания ценности.

Необходимость в ускорении можно сократить. Увеличение резервной мощности благодаря усовершенствованию пропускной способности, автоматизации или увеличению ресурсов повысит способность к реагированию. Более короткое время выполнения, высокая прозрачность и организационная зрелость – все это снизит необходимость в ускорении. Хорошие команды, усвоившие Канбан‑подход, обычно не злоупотребляют ускоренными запросами. Например, в Corbis за весь 2007 год их было всего пять.

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

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

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

 

Нерегулярный поток

 

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

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

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

Первый восстанавливает поток за счет времени выполнения и даже качества. Вы можете восстановить поток, увеличив общий WIP‑лимит – либо установив буфер напрямую, либо задав менее жесткие правила ограничения незавершенных задач: например, 3, а не 1,2 элемента в среднем на человека. Больший WIP‑лимит подразумевает, что, пока одна задача блокирована, члены команды могут работать над остальными. Такой подход рекомендуется недостаточно зрелым организациям. Эффект от него прост и лишен драматизма. Время выполнения будет больше, но во многих отраслях это не составляет проблемы. Сильнее может оказаться и разброс вариативности, так что время выполнения окажется менее предсказуемым. Однако благодаря использованию канбан‑системы оно все равно будет более предсказуемым, чем раньше. Главный недостаток использования б о льших WIP‑лимитов в том, что так почти (или совсем) не создается внутренней напряженности, которая вызвала бы обсуждения и внедрение улучшений. Нет стимула к совершенствованию, эффект канбана как катализатора утрачивается.

Второй подход связан с неукоснительным проведением политики управления проблемами и их разрешения и, по достижении зрелости команды, с переходом к анализу и устранению первопричин, а также внесению улучшений, направленных на предотвращение вариаций с выявляемыми причинами в будущем. При таком подходе WIP‑лимиты, размеры буфера и действующие правила остаются достаточно жесткими, и если задача блокируется, то это останавливает всю работу. Простой сотрудников, назначенных на блокированную задачу, повышает ответственность за блокирующую проблему. После этого может начаться массовая атака на проблему, что, как было установлено, стимулирует простаивающих членов команды думать о первопричинах и возможных изменениях в процессе, которые смогут сократить или исключить возможность новой подобной проблемы. Как показывает практика, сохранение жестких WIP‑лимитов и проведение мероприятий по управлению проблемами и их разрешению позволяет создать культуру непрерывного совершенствования. Впервые я столкнулся с этим в Corbis в 2007 году, но есть и другие данные, полученные в 2009 году в таких компаниях, как Software Engineering Professionals (Индианаполис), IPC Media и BBC Worldwide (обе из Лондона). Сейчас уже достаточно информации, позволяющей предположить, что Канбан действительно способствует появлению культуры, сосредоточенной на непрерывном совершенствовании. Среди постоянно появляющихся элементов процесса, которые можно привести в пример, – готовность устанавливать жесткие правила WIP, маркировать работу как заблокированную, позволять потоку останавливаться, вызывая простой, и заниматься управлением проблемами и их решением в качестве устоявшейся организационной практики. Результат – сосредоточение на анализе и устранении первопричин и постепенное внедрение усовершенствований, которые снижают вариации с выявляемыми причинами и помогают распространению культуры непрерывного совершенствования.

 

Доступ к среде

 

Доступ к среде – типичный вид проблемы с выявляемой причиной, которая может оказать существенное влияние на поток, пропускную способность и предсказуемость. Отказ среды часто останавливает весь рабочий поток. С помощью канбан‑системы эта проблема и ее воздействие становятся нагляднее. Простой, вызванный заданием WIP‑лимита, стимулирует совместные действия по ее решению. Когда коллеги выше по цепочке, например разработчики и тестировщики, помогают операторам системы восстановить среду, такое поведение часто называется роением. Роение – это ситуация, когда вся команда собирается вместе и работает над единственной проблемой до полного ее разрешения. Природа Канбана позволяет командам сосредоточиться на времени выполнения, пропускной способности и потоке на протяжении всей цепочки создания ценности. Соединив усилия всех групп на разных отрезках цепочки создания ценности для достижения общей цели, мы порождаем стимул, чтобы наброситься на проблему со всех сторон, целым «роем». Все выигрывают от того, что простаивающие сотрудники добровольно помогают решить проблему, которая воздействует на них, даже если это выходит за рамки их должностных обязанностей.

 

Другие рыночные факторы

 

В октябре 2008 года вслед за крахом Lehman Brothers и ряда других драматических событий в финансовом секторе банки и инвестиционные компании таких ведущих финансовых центров, как Лондон и Нью‑Йорк, стали отменять или видоизменять IT‑проекты, находившиеся в разработке. Причина была в том, что их мир рушился и они боролись за выживание как могли. Внезапно выяснилось, что нужно лучше понять собственную – и общерыночную – ликвидность. Оказалось, что предлагать новейшие или экзотичные товары и услуги неактуально. Рынок больше не интересовался инвестициями. Осенью 2008 года финансовые предприятия беспокоились исключительно о собственной платежеспособности или ее отсутствии.

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

Разумеется, эти события относятся к вариациям с выявляемыми причинами. Их требуется нейтрализовать при помощи стратегии и тактики управления рисками. Существуют достаточно серьезные наработки по вариациям с выявляемыми причинами, или событийному риску. Наличие опыта в управлении рисками как часть общей цели повышения зрелости организации улучшит предсказуемость разработки как при использовании Канбана, так и без него. Однако канбан‑системы демонстрируют б о льшую предсказуемость при хорошем управлении рисками. Это порождает внутрисистемное доверие.

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

Некоторые материалы по управлению рисками в канбан‑системах, появившиеся в результате использования Канбана, я представлял на конференциях в 2009 году. Они доступны в интернете.

 

Трудности с координацией

 

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

Поток может быть прерван ограничениями, которые установлены правительственными органами или нормативными документами, требующими проведения аудита или утверждения документа. Люди, которые должны выполнять эту функцию, часто недоступны или не располагают свободным временем.

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

Такое осознание должно привести к поведенческим изменениям, улучшающим ситуацию.

Одна из возможных тактик – изучение правительственных и регуляторных норм с целью определить, что именно должно подвергнуться оценке, одобрению, аудиту и изучению. Если предположить, что существуют разные профили риска, которые дают возможность распределить задания на две категории – «необходимо согласовать» и «необязательно согласовывать», – то для разбивки задач можно использовать типы рабочих единиц либо классы обслуживания. После этого стоит задать отдельные WIP‑лимиты как для типов, так и для классов для обеспечения равномерности потока.

 

 

Выводы

 

• Изучение вариативности в промышленных процессах началось в 1920‑е годы с Уолтера Шухарта. В середине и конце XX века его дело продолжили и развили Эдвардс Деминг, Джозеф Джуран и Дэвид Чемберс.

• Изучение вариативности и связанный с ним метод статистического анализа лежит в основе производственной системы Toyota (а следовательно, и бережливого управления) и метода «шести сигм» для совершенствования процесса.

• Работы Эдвардса Деминга и Джозефа Джурана – главный источник вдохновения для Института технологий разработки ПО Университета Карнеги – Меллон и модели зрелости возможностей (современное название – «интегрированная модель зрелости», или CMMI).

• Шухарт разделил источники вариативности на две категории: внутренние для процесса или системы и внешние для процесса или системы.

• Внутренние вариации называются вариациями со случайными причинами.

• Внешние вариации называются вариациями с выявляемыми причинами.

• В цепочке создания ценности жизненного цикла разработки ПО может быть много источников вариаций со случайными причинами. Типичные примеры – размер рабочей единицы, тип, класс обслуживания, нерегулярный поток и переработка.

• Список источников вариаций с выявляемыми причинами, возможно, бесконечен. Типичные примеры – двусмысленные требования, ускоренные запросы, доступность среды, нерегулярный поток, рыночные факторы, факторы персонала и проблемы с координационной деятельностью.

• Вариации со случайными причинами можно контролировать, задав правила, определяющие жизненный цикл разработки ПО и используемые процессы управления проектами.

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

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

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

• Предстоит еще много работать над передовыми стратегиями и тактиками управления рисками в Канбане – это станет темой следующей книги.

 

 

Глава 20