Текст книги "Канбан. Альтернативный путь в Agile"

Глава 5
Культура постоянного совершенствования

В японском языке слово «кайдзен» дословно значит «постоянное совершенствование». Корпоративная культура, в которой все сотрудники сосредоточены на непрерывном повышении качества, производительности и удовлетворенности клиентов, известна как культура кайдзен. На самом деле подобной культуры удалось добиться очень немногим корпорациям. Такие компании, как Toyota, в которых доля участия сотрудников в программе совершенствования приближается к 100 % и где один сотрудник вносит в среднем одно внедряемое предложение по улучшению в год, очень редки.

В мире разработки ПО Институт технологий разработки ПО (SEI) Университета Карнеги – Меллон определяет высший уровень своей интегрированной модели зрелости процессов ПО (CMMI) как оптимизирование. Оптимизирование предполагает, что качество работы и производительность организации подвергаются постоянному совершенствованию. Хотя CMMI мало уделяет внимание корпоративной культуре и ничего об этом не говорит, достижение оптимизирующего поведения в организации более всего возможно в культуре кайдзен.

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

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

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

Многие аспекты культуры кайдзен противоречат общепринятым нормам в современной западной культуре, где нас готовят к конкурентной борьбе. Наша система образования поощряет соперничество и в академической успеваемости, и в спорте. Даже в командных видах спорта часто находят героев, и команды строятся вокруг одного-двух исключительных талантов. Общественная норма сосредоточивается в первую очередь вокруг личности, которая призвана приносить победу или спасать нас от опасности. Неудивительно, что на рабочем месте мы испытываем большие трудности с внедрением корпоративного поведения или системного мышления и сотрудничества.

Канбан-метод призван свести к минимуму первичное влияние перемен и снизить сопротивление им. Переход на Канбан должен изменить культуру компании и помочь ей повзрослеть. Если переход проводится правильно, то организация будет охотно принимать и внедрять изменения, что приведет к совершенствованию процессов. SEI в рамках модели CMMI называет эту способность инновациями и перегруппировкой организации (OID){15}15
  Chrissis, Mary Beth, Mike Konrad, and Sandy Shrum. CMMI: Guildelines for Process Integration and Product Improvement, 2d ed. Boston: Addison Wesley, 2006.


[Закрыть]. Доказано{16}16
  Sutherland, Jeff, Carsten Ruseng Jakobsen, and Kent Johnson. “Scrum and CMMI Level 5: A Magic Potion for Code Warriors.” Proceedings of the Agile Conference, Agile Alliance/IEEE, 2007.
  Jakobsen, Carsten Ruseng and Jeff Sutherland. “Mature Scrum at Systematic.” Methods & Tools, Fall 2009. http://www.methodsandtools.com/archive/archive.php?id=95.


[Закрыть], что организации, достигшие столь высокого уровня в управлении переменами, могут перейти на agile-методы, например Scrum, быстрее и легче, чем менее зрелые компании.

При первом внедрении Канбана вы ищете способы оптимизировать существующие процессы и изменить культуру организации, не собираясь полностью переключаться на другие процессы, которые способны принести существенные экономические выгоды. Это дает повод для критики{17}17
  Larman, Craig and Bas Vodde. Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. Boston: Addison Wesley, 2008.


[Закрыть]: некоторые утверждают, что Канбан занимается оптимизацией того, что нужно попросту изменить. Однако существуют серьезные эмпирические доказательства{18}18
  Willeke, Eric, with David J. Anderson and Eric Landes (editors) Proceedings of the Lean & Kanban 2009 Conference. Bloomington, IN: Wordclay, 2009.


[Закрыть] того, что Канбан ускоряет достижение высокого уровня зрелости и компетентности в отраслях, рассчитанных на зрелые организации, – таких как причинный анализ (CAR), а также инновации и перегруппировка организации.

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

КЕЙС: РАЗРАБОТКА ПРИЛОЖЕНИЙ CORBIS

Когда я вводил в 2006 году канбан-систему в Corbis, я имел в виду множество механических выгод, которые были продемонстрированы в Microsoft XIT в 2004 году (описано в главе 4). Изначально применение предполагалось таким же – техподдержка IT-приложений. Я не рассчитывал на значительные культурные изменения или сдвиг в организационной зрелости. И уж тем более я не ожидал, что итогом этой работы станет то, что мы теперь называем Канбан-метод.

В 2010 году, когда я пишу эту книгу, общепринято, что Канбан создан для техподдержки IT. Но в 2006-м мало кто это осознавал, хотя казалось, что канбан-система способна справиться с функциональными проблемами техподдержки. Я пришел в Corbis не для того, чтобы обязательно «вводить Канбан». Моей задачей было повысить удовлетворенность клиентов командой разработки ПО. Так сложилось, что первой проблемой оказалась недостаточная предсказуемость работы техподдержки IT-программ.

История и культура

В 2006 году Corbis была частной компанией и насчитывала 1300 сотрудников по всему миру. Corbis контролировала цифровые права на многие потрясающие произведения искусства, а также представляла интересы примерно 3000 профессиональных фотографов, выдавая лицензии на их работы для использования в издательском деле и рекламе. Это был второй по величине фотобанк в мире. В бизнесе были и другие направления, например отдел авторских прав, который от имени семей, предприятий и управляющих фирм контролировал права на изображения и имена знаменитостей. IT-отдел насчитывал примерно 110 человек, часть из них занималась разработкой, а другие – техподдержкой сетевых операций и систем. Для участия в крупных проектах подписывались контракты с дополнительными сотрудниками. В 2007 году в отделе числилось 105 человек, 35 штатных сотрудников находились в Сиэтле, а еще 30 – у индийского поставщика в Ченнаи, где в основном и проводилось тестирование. Подход к управлению проектами оставался традиционным. Все планировалось в соответствии с деревом зависимости задач и утверждалось в офисе руководства программами. Эта компания с консервативной культурой действовала в сравнительно консервативной и медленно продвигающейся вперед отрасли. Она использовала традиционные подходы к управлению проектами и жизненному циклу разработки ПО.

IT-отдел оказывал поддержку примерно 30 разнообразным системам. Некоторые из них представляли собой типичные системы учета и управления персоналом, другие же выглядели как экзотические, а порой даже эзотерические приложения для индустрии управления цифровыми правами. Поддерживалось множество технологий, программных платформ и языков. Работники сохраняли завидную лояльность: многие сотрудники IT-отдела трудились в нем от 8 до 15 лет. Неплохо для компании, существовавшей около 17 лет. Отдел придерживался традиционного, применявшегося многие годы водопадного жизненного цикла разработки ПО (SDLC). В компании существовали отделы бизнес-анализа, системного анализа, разработки и офшорного тестирования. В них сидели узкие специалисты – например, аналитики, ранее занимавшиеся бухгалтерией, а теперь – финансами. Некоторые разработчики также были узкими специалистами – в частности, программисты систем J.D. Edwards, которые поддерживали бухгалтерские программы J.D. Edwards.

Все это было далеко от идеала, но шло своим чередом. Когда я появился в компании, люди ждали, что я начну внедрять agile-методы и заставлю сотрудников менять поведение. Хотя такой подход казался перспективным, он предполагал определенную долю жестокости, и итог мог получиться не слишком удачным. Я опасался, что все проекты остановятся, пока работники будут обучаться новым методам и адаптироваться к непривычным принципам работы. Не хотелось также терять ключевых специалистов компании, многие из которых оказались очень уязвимыми из-за чрезмерно развитой специализации. Я предпочел ввести канбан-систему, вернуть работы по поддержке систем в первоначальное состояние и посмотреть, что из этого получится.

Необходимость функции сопровождения ПО

Команда сопровождения ПО (или RRT, то есть Rapid Response Team – группа быстрого реагирования, как мы их называли) была учреждена советом директоров на дополнительные 10 % бюджета, выделенные для отдела разработки. В 2006 году на эти деньги наняли еще пять человек. Они пришли незадолго до меня. Из-за разнообразия систем, которые требовалось поддерживать, и высокого уровня специализации было решено, что создавать отдельную команду из пяти человек исключительно для сопровождения нецелесообразно. Эту пятерку добавили к общему пулу сотрудников. Среди них были менеджер проектов, аналитик, разработчик, а также два тестировщика. Появились дополнительные сложности: необходимо было доказать руководству, что эти пятеро действительно занимаются сопровождением, а не просто влились в портфель крупного проекта. Однако в тот или иной день этими пятерыми могли оказаться кто угодно из 55 членов команды.

Одно из возможных решений выглядело так: обязать всех сотрудников заполнять сложные табели учета рабочего времени. Это наложило бы дополнительное административное бремя, но продемонстрировало бы, что 10 % деятельности команды действительно приходится на сопровождение ПО. Довольно неприятная, но типичная реакция менеджеров среднего звена на подобные проблемы. Другой вариант – это введение канбан-системы.

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

Итак, релизы сопровождения ПО были единственной отраслью в IT-подразделении Corbis, где канбан мог обеспечить некоторую степень бизнес-гибкости.

Небольшие проекты сопровождения ПО неэффективны

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

Внедрение изменений

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

Мы разработали канбан-систему, в которой каждые две недели по средам в час дня были запланированы релизы, а каждый понедельник в 10 утра – совещания по расстановке приоритетов с бизнес-отделом. То есть каденция расстановки приоритетов была недельной, а каденция релизов – двухнедельной. Выбор такой каденции определился в ходе обсуждений с партнерами выше и ниже по цепочке создания ценности с учетом операционных и координационных издержек. Произошел и ряд других изменений. Мы установили очередь на выполнение с лимитом незавершенных задач, равным 5, добавили лимиты по всему жизненному циклу – на анализ, разработку, конфигурацию и системный тест. Тестовая приемка, обкатка и подготовка к запуску в производство остались без ограничений, поскольку мы считали, что они не служат ограничителями общей мощности и при этом находятся вне зоны нашего непосредственного контроля.

Первичные результаты изменений

Эффекты введения канбан-системы были, с одной стороны, неудивительными, а с другой – довольно примечательными. Мы начали выпускать релизы каждые две недели. После примерно трех итераций все пошло гладко, без инцидентов. Качество было хорошим, почти не возникало необходимости вносить срочные правки после выхода нового кода. Затраты на планирование релизов существенно сократились, а недопонимание между командой разработчиков и менеджерами программ практически исчезло. Итак, канбан сдержал свое основное обещание. Мы регулярно выпускали высококачественные релизы с минимальным вмешательством руководства. Операционные и координационные издержки существенно сократились. Команда стала выполнять больше работы, и клиент начал получать ее результаты значительно чаще.

Но еще примечательнее оказались вторичные эффекты.

Непредвиденные эффекты перехода на канбан

В команде разработки в январе 2007 года мы использовали реальные канбан-карточки – клеили стикеры к доске. Каждое утро в 9:30 мы собирались возле этой доски, чтобы провести 15-минутное совещание. С точки зрения психологии реальная доска имела значительно больший эффект, чем все использовавшиеся нами электронные системы управления задачами, применявшиеся в Microsoft. На наших совещаниях сотрудники словно видели замедленную съемку рабочего потока, представленную на доске. Заблокированные рабочие элементы отмечались розовыми стикерами, и команда активнее фокусировалась на разрешении проблем и сопровождении рабочего потока. Производительность существенно выросла.

Теперь, когда поток работы можно было отслеживать на доске, я сосредоточился на самом процессе работы. И отразил на той же доске некоторые изменения. Моя команда менеджеров уяснила мои принципы и к марту сама стала внедрять изменения. В свою очередь, члены их команд – индивидуальные разработчики, тестировщики и аналитики – воочию увидели процесс и поняли, как все работает. В начале лета все почувствовали, что обладают достаточными полномочиями, чтобы предлагать изменения, и мы увидели процесс спонтанного образования групп (состоящих из представителей разных отделов), обсуждавших проблемы и вызовы и вносивших необходимые улучшения. Обычно руководство узнавало обо всем постфактум. Примерно через шесть месяцев в команде разработки возникла настоящая культура кайдзен. Члены команды чувствовали себя уверенно. Страх исчез. Они гордились своим профессионализмом и достижениями, но надеялись, что смогут работать еще лучше.