Канбан. Альтернативный путь в Agile Андерсон Дэвид
Атака на источники вариативности для улучшения предсказуемости
Как последствия вариативности, так и борьба с ней в процессе работы – это сложные понятия. Сокращение вариативности в разработке ПО требует от сотрудников изменений в их рабочем процессе – они должны освоить новые техники и изменить личное поведение. Все это непросто, а потому не подходит для новичков и незрелых организаций.
Вариативность приводит к большому количеству незавершенных задач и увеличению времени выполнения. Подробнее об этом читайте в главе 19. Вариативность порождает необходимость в резервах времени вне бутылочных горлышек, чтобы справиться с неустойчивым объемом работы: вариативность воздействует на объем работы, идущий через цепочку создания ценности. Чтобы глубже разобраться в том, почему так происходит, нужно обладать определенными познаниями в системе статистического контроля процессов и теории массового обслуживания, что выходит за рамки этой книги. Мне, например, нравится работа Дональда Уилера и Дональда Рейнертсена о вариативности и массовом обслуживании, так что, если вы хотите узнать об этом больше, начните с нее.
Пока же примите на веру положение о том, что вариативность в размерах задач, требующих усилий на анализ, дизайн, программирование, тестирование, сборку и выдачу релиза, отрицательно влияет на пропускную способность процесса и накладных расходов цепочки создания ценности в разработке ПО.
Однако ряд источников вариативности непосредственно вшит в производственный процесс вследствие неудачного выбора правил работы. Пример в главе 4 рассказывает о некоторых из них: это ежемесячное перепланирование, соглашение о предоставлении услуг, основанное на оценках, приоритет текстовых, то есть не требующих пересборки продукта, изменений в производстве. Все три приведенных примера – это результат работы по правилам, которые нужно изменить. Простое изменение существующих правил может значительно сократить число источников вариативности, влияющих на предсказуемость.
Рецепт успеха и канбан
Канбан делает возможными все шесть этапов рецепта успеха и обеспечивает его реализацию, а рецепт успеха создает доверие к внедряющему его менеджеру. В свою очередь, рецепт успеха иллюстрирует ценность Канбана.
Выводы
• Канбан делает возможным реализацию всех составляющих рецепта успеха.
• Рецепт успеха объясняет ценность Канбана.
• Плохое качество – это главный источник потерь в разработке ПО.
• Снижение количества незавершенных задач повышает качество продукта.
• Повышение качества порождает доверие у сотрудников ниже по цепочке создания ценности – например, операционных инженеров.
• Частый выход релизов порождает доверие со стороны сотрудников выше по цепочке создания ценности – например, отдела маркетинга.
• Вытягивающая система может сбалансировать нагрузку и пропускную способность.
• Вытягивающие системы выявляют бутылочные горлышки и создают резервы времени и усилий в остальных местах.
• Качественная расстановка приоритетов максимизирует производительность цепочки создания ценности в разработке ПО.
• Расстановка приоритетов сама по себе мало значит без хорошего изначального качества и предсказуемости производственной системы.
• Чтобы внести изменения для сокращения вариативности, требуются резервы.
• Сокращение вариативности снижает потребность в резервах.
• Сокращение вариативности позволяет сбалансировать ресурсы (а в дальнейшем, возможно, и сократить численный состав команды).
• Сокращение вариативности снижает требования к ресурсам.
• Сокращение вариативности позволяет уменьшить количество канбан-жетонов, незавершенных задач и приводит к снижению среднего времени выполнения.
• Появление резервов создает возможности для улучшения.
• Усовершенствование процесса ведет к повышению производительности и предсказуемости.
Глава 4
От худшего к лучшему за пять кварталов
В октябре 2004 года Драгош Думитриу был менеджером программ в Microsoft. Он только что возглавил отдел, который имел репутацию худшего IT-подразделения компании.
Должность «менеджер программ» в Microsoft примерно соответствует тому, что в других местах называют менеджером проектов, но обычно включает также некоторую ответственность за анализ и архитектуру. Менеджер программ назначается на инициативу, проект или продукт и отвечает за часть функционала. Чтобы выполнить работу, он привлекает ресурсы из функциональных областей, например разработки и тестирования. Драгош отвечал за техническое обеспечение ПО для бизнес-подразделения XIT. Эта команда (рис. 4.1), зрелость процессов которой оценивалась как CMMI Model Level 5, располагалась в Индии и состояла из трех разработчиков, трех тестировщиков и менеджеров, занимавшихся разработкой небольших обновлений и устранением ошибок примерно в 80 кроссфункциональных IT-приложениях, используемых сотрудниками Microsoft по всему миру. Сам Драгош находился в кампусе в Редмонде. В то же самое время там работал и я.
Рис. 4.1. Команда в Хайдарабаде (Индия). Драгош – четвертый слева
Проблема
Драгош сам вызвался возглавить команду, которая имела худшую репутацию в Microsoft с точки зрения клиентского обслуживания. В круг его обязанностей как агента изменений входило решение проблем длительного времени выполнения задач и плохо сформулированных, из-за сложившейся в компании конъюнктуры, ожиданий заказчиков. Некоторые из его предшественников на этой должности продолжали работать в компании с другими проектами того же подразделения. Они опасались, что если ему удастся улучшить производительность команды, то они будут выглядеть неудачниками.
Программисты и тестировщики этой организации следовали методологии PSP/TSP (Personal Software Process / Team Software Process). Такие требования компании Microsoft были записаны в контракте. Джон Де Ваан в то время – непосредственный подчиненный Билла Гейтса и большой поклонник Уоттса Хамфри из Института программной инженерии. Как глава Engineering Excellence в Microsoft, он мог требовать от IT-отдела и его поставщиков соблюдения определенных процедур. Поэтому изменение метода жизненного цикла разработки ПО было невозможным.
Драгош понял, что основная причина их проблем не в методе PSP/TSP и не в рейтинге зрелости организации. Более того, команда производила почти все, что от нее требовалось, с высоким качеством. Однако время выполнения запросов на изменения доходило до пяти месяцев и вместе с объемом бэклога продолжало бесконтрольно увеличиваться. Создавалось ощущение плохо организованной и почти неуправляемой команды. Высшее руководство не спешило выделять дополнительные средства на решение этой проблемы. Итак, сдерживающие факторы для изменений были связаны с политикой, финансами и правилами компании. Он обратился ко мне за помощью.
Визуализация рабочего процесса
Я попросил Драгоша сделать изображение рабочего процесса. Он набросал схему, в которой описывался жизненный цикл для запроса изменений, после чего мы обсудили проблему. Рис. 4.2 – это факсимиле того, что он сделал. Фигурка PM (менеджера программ) изображает Драгоша.
Рис. 4.2. Изначальный рабочий процесс технического обеспечения в XIT с указанием времени выполнения Initial
Поступление запросов было бесконтрольным. Четыре менеджера продукта представляли и контролировали бюджеты для ряда клиентов, которые владели приложениями, обслуживаемыми XIT. Они добавляли новые запросы и дефекты, выявленные в процессе промышленной эксплуатации.
Эти ошибки были внесены не командой техподдержки, а проектными командами разработки приложений. Такие команды обычно прекращают свое существование через месяц после выхода новой системы, а исходный код переходит к команде техподдержки.
Факторы, влияющие на производительность
Когда поступал запрос, Драгош отправлял его на оценку в Индию. Согласно регламенту, оценку нужно было произвести и представить владельцам бизнеса в течение 48 часов. Так было легче вычислить ROI (прибыли на инвестицию) и принять решения по запросу. Раз в месяц Драгош встречался с менеджерами продукта и другими заинтересованными лицами: проводилась новая расстановка приоритетов в бэклоге и составлялся план проекта по запросам.
В то время в месяц обрабатывалось около семи запросов. В бэклоге было более 80 записей, и его объем продолжал увеличиваться. Таким образом, ежемесячно подвергались переоценке более 70 запросов, а обработка запроса занимала в среднем четыре месяца. В этом и крылась основная причина неудовлетворительной работы. Сами запросы были небольшими, но постоянное изменение приоритетов означало стабильную неудовлетворенность клиентов.
Запросы фиксировались при помощи инструмента под названием Product Studio. Обновленная версия этой программы была впоследствии выпущена под названием Team Foundation Server Work Item Tracking. Команда техподдержки XIT представляла собой хорошо мне знакомый тип организации, в которой имеется множество данных, но они не используются. Драгош начал анализировать данные и обнаружил, что средний запрос занимал 11 рабочих дней.
Время выполнения при этом составляло от 125 до 155 дней, более 90 % времени тратилось впустую, в том числе на ожидание в очереди.
Оценки поступающей работы отнимали много ресурсов. Мы решили проанализировать процесс оценки, сделав ряд предположений. Хотя аббревиатура ROM расшифровывается как rough order of magnitude (приблизительный порядок величины), клиенты ожидали, что оценка будет очень точной, и члены команды проводили ее с особой тщательностью. У каждого разработчика и тестера одна оценка занимала примерно рабочий день. Мы подсчитали, что на это уходило около 33 % ресурсов команды, а в неудачный месяц – и 40 % рабочего времени, то есть больше, чем на разработку и тестирование. К тому же оценка новых запросов нередко вносила путаницу в планы, составленные на текущий месяц.
Помимо запросов на изменения у команды имелся и второй вид работ – так называемые текстовые изменения на продуктивной среде (Production text changes, PTC), касающиеся интерфейса, редакционных исправлений, изменения данных таблиц или xml-сообщений. Эти изменения не требовали участия разработчиков и часто вносились владельцами бизнеса, менеджерами продукта или программ. Но поскольку они подвергались формальной тестовой приемке, участие тестировщиков было все же необходимо.
PTC традиционно выполнялись прежде всей остальной работы или оценок. PTC поступали неравномерными порциями и тоже нарушали планы на месяц (рис. 4.3).
Рис. 4.3. Рабочий процесс, демонстрирующий оценки ROM и внесение PTC
Установление явных процедурных правил
Команда следовала предписанным процедурам, которые, к сожалению, содержали и неудачные решения, принятые менеджерами на различных уровнях. Важно помнить, что процесс – это набор правил, управляющих поведением, которые находятся под контролем руководства. Например, решение использовать PSP/TSP приняли на уровне вице-президента, то есть всего рангом ниже Билла Гейтса. Такое правило отменить тяжело или невозможно. Но другие правила, например приоритет оценок перед написанием кода и тестированием, были разработаны непосредственными руководителями на местах. Возможно, эти правила имели смысл, когда их внедряли. Но обстоятельства изменились, однако никто не попытался пересмотреть и обновить правила, по которым работала команда.
Оценка была пустой тратой времени
Побеседовав с коллегами и менеджером, Драгош решил внедрить в управление два важных изменения. Во-первых, команда перестала производить оценку. А те усилия, которые прежде тратились на нее, нужно было направить на разработку и тестирование ПО. Исключив этот фактор, вносивший к тому же хаос в рабочее расписание, Драгош надеялся повысить предсказуемость и, как следствие, – удовлетворенность клиентов.
Однако отказ от оценок вызвал целый ряд проблем. Он влиял на подсчет ROI, кроме того, клиенты могли заподозрить возможность неправильной расстановки приоритетов. К тому же оценки облегчали учет затрат и перераспределение бюджета между отделами, использовались для внедрения общих организационных принципов. В команду техподдержки поступали только небольшие запросы. Крупные, разработка или тестирование которых превышали 15 дней, должны были стать частью большого проекта и пройти все формальные процедуры управления портфелем проектного офиса (PMO). Вскоре мы вернемся к этому вопросу.
Ограничение задач в работе (WIP)
Еще одно изменение, задуманное Драгошем, – это ограничение числа задач в работе и вытягивание новых задач из очереди только после завершения старых. Он решил ограничить разработку одним запросом на разработчика, такой же норматив был установлен для тестировщиков.
Добавив очередь для получения PTC, он обеспечил равномерный поток работы между разработкой и тестированием, что показано на рис. 4.4. Этот подход – использование буфера для снижения вариативности размеров и усилий – обсуждается в главе 19.
Примечание. Это установленное правило: одна задача на одного разработчика в любое время. Позже правило может быть изменено. Представление процесса как набора правил – ключевой элемент Канбан-метода.
.
Рис. 4.4. Модель состояний, показывающая желаемый поток работ с ограничением незавершенной работы
Установление каденции пополнения
Примечание. Каденция – это понятие Канбан-метода, которое определяет ритм событий определенного типа. Расстановка приоритетов, поставка, ретроспективы и все повторяющиеся события могут иметь собственную каденцию.
Чтобы облегчить принятие решения об ограничении задач в работе и переходе на вытягивающую систему, Драгош должен был подумать о каденции взаимодействий с менеджерами продукта. Он посчитал, что еженедельное совещание – оптимальный вариант, поскольку его тема – пополнение входящей очереди производственной системы из бэклога. Обычно в течение недели освобождались три места в очереди, поэтому следовало обсуждать вопрос «Какие три элемента бэклога вы бы предпочли отправить сейчас в разработку?». Каденция моделируется на рис. 4.5.
Рис. 4.5. Рабочий процесс с Канбаном: ограничение задач в работе и очереди
Он хотел предложить «гарантированное» время выполнения – 25 дней с момента попадания задачи во входящую очередь. Конечно, 25 больше, чем 11. А на некоторые задачи требовалось до 30 дней. Но Драгош решил, что таких заданий не должно быть много. И, кроме того, 25 – это гораздо меньше, чем 140, а именно столько дней составлял текущий срок выполнения работ. Он рассчитывал добиться цели благодаря регулярности поставок, построению доверительных отношений с менеджерами продукта и их клиентами.
Достижение нового соглашения
Драгош сделал менеджерам продукта предложение – попросил примириться с тем, что они будут встречаться раз в неделю и обсуждать приоритеты, он ограничит количество незавершенной работы, а его команда перестанет заниматься оценкой. В обмен на это он сократит время выполнения до 25 дней и будет в дальнейшем ориентироваться на этот дедлайн.
Клиентам предложили отказаться от вычисления ROI и переводов бюджета между отделами на основе оценки планируемых трудозатрат. В обмен на это им пообещали беспрецедентно короткие сроки выполнения и надежность. Для удобства расчетов время обработки запроса – примерно 11 дней – устанавливалось на основании исторических данных, о чем говорилось выше, в разделе «Факторы, влияющие на производительность». Также их попросили считать затраты фиксированными и игнорировать ту калькуляционную парадигму, на которой ранее основывались переводы бюджета между отделами.
Драгош обосновывал эти перемены так: у организации-поставщика есть годичный контракт, по которому она ежемесячно выставляет счет. В соответствии с контрактом поставщик привлекает людей, получающих зарплату независимо от того, работают они в данный момент или нет. Бюджет, поступающий от четырех менеджеров продукта, – это фиксированная сумма, распределяемая пропорционально. Драгош гарантировал, что каждому менеджеру продукта достанется справедливая доля. Это освободит их от необходимости отслеживать каждый запрос. Если они смогут принять тот факт, что доллары приносят им гарантированный результат, то, возможно, откажутся от предубеждения против приблизительной оценки трудозатрат и переводов бюджета. Чтобы определить, чья очередь подходит, разработали несколько простых правил, поэтому распределение осуществлялось справедливо. Достаточно было простой круговой схемы с весовыми коэффициентами.
Внедрение изменений
Хотя менеджеры продукта и многие коллеги Драгоша по XIT оставались скептиками, они решили дать ему возможность попробовать. В конце концов, дела шли хуже некуда. Нужно было что-то предпринять, и Драгошу поручили внести изменения.
Итак, изменения начались.
И все наладилось! Запросы обрабатывались и выводились в новых релизах. Время выполнения по новым обязательствам укладывалось в обещанный 25-дневный срок. Ежедневные совещания работали как часы, пополнение производственной системы задачами тоже происходило каждую неделю. Менеджеры продукта стали проникаться доверием к команде.
Адаптация правил
Примечание. Это распространенная тема в канбан-методе. Сочетание четких правил, прозрачности и визуализации дает членам команды возможность принимать собственные решения и самостоятельно оценивать риски. Руководство в итоге начинает доверять системе, поскольку понимает, что процесс – это набор правил, которые предназначены для управления рисками и удовлетворения пользовательских ожиданий. Эти правила прописаны, работа открыто визуализируется, а все члены команды понимают правила и принципы их применения.
Но каким образом достигалась расстановка приоритетов, если подсчет ROI больше не проводился? Оказалось, что он и не нужен. Если элемент важен и ценен, то его выбирали из очереди в бэклоге, а если нет, то отодвигали дальше. Позже Драгош понял, что необходимо еще одно правило – безжалостно удалять из бэклога любой элемент более чем шестимесячной давности. Если за полгода о нем ни разу не вспомнили, то наверняка он не имеет никакого значения. А если выяснится, что данный элемент все же важен, то его можно включить заново.
А как насчет правила, согласно которому крупные запросы не поступали в техподдержку, а становились частью большого проекта? В итоге решили, что некоторые из них все же могут туда направляться. Опыт показывал, что таких запросов обычно менее 2 %. Разработчиков просили быть внимательными и, если новый запрос, по их оценкам, требовал на обработку более 15 дней, предупреждать своего менеджера. Риски и затраты в данном случае составляли менее 1 % доступной мощности. Это прекрасно окупалось: отказавшись от оценок, команда обрела более 33 % мощности за счет затрат менее 1 % той же мощности. Это новое правило позволило разработчикам управлять рисками и при необходимости высказывать свое мнение!
На первые два изменения отвели шесть месяцев. В течение этого периода внесли еще кое-какие незначительные улучшения. Как уже упоминалось, появилось правило очищения бэклога, а еженедельное совещание с владельцами продукта исчезло. Процесс протекал так гладко, что Драгош автоматизировал инструмент Product Studio: теперь он получал электронное сообщение каждый раз, когда образовывалось свободное место для нового задания. После этого Драгош предупреждал по электронной почте владельцев продукта, что им необходимо решить, за какое задание браться прежде всего. Производился выбор, и запрос из бэклога работы переводился в очередь через два часа после того, как появлялось свободное место.
Поиск дальнейших улучшений
Драгош начал искать способы для дальнейших улучшений. Изучив данные о продуктивности тестировщиков его команды и сравнив их с показателями других команд XIT от того же подрядчика, он заподозрил, что тестировщики располагают существенными резервами. Между тем звено разработчиков можно было назвать настоящим узким местом. Драгош решил навестить команду в Индии и, возвратившись, посоветовал подрядчику перераспределить ресурсы. Число тестировщиков сократили с трех до двух, но добавили дополнительного разработчика (рис. 4.6). Это привело к практически линейному увеличению производительности: пропускная способность за квартал повысилась с 45 до 56.
Рис. 4.6. Перераспределение ресурсов
Финансовый год Microsoft подходил к концу. Высшее руководство заметило значительный рост производительности и стабильности результатов команды техподдержки XIT.
Руководители наконец-то поверили в Драгоша и его методы. Отделу были выделены средства, чтобы нанять еще двух сотрудников. В июле 2005 года в команде появились новый разработчик и тестировщик. Результаты оказались существенными.
Рис. 4.7. Добавление ресурсов
Результаты
Дополнительная мощность позволила пропускной способности превысить требования. В результате бэклог 22 ноября 2005 года оказался полностью исполнен. К тому времени команда сократила срок выполнения в среднем до 14 дней при сохранении 11-дневного периода разработки. Выполнение 25-дневного дедлайна составляло 98 %. Пропускная способность увеличилась более чем втрое, время выполнения сократилось на 90 % и выше, а надежность программ примерно на столько же выросла. В процессы разработки ПО и тестирования не было внесено никаких изменений. Метод PSP/TSP остался неизменным, все корпоративные нормы, процедуры и контрактные обязательства строго соблюдались. Во второй половине 2005 года команда стала лучшей среди всех инженерных коллективов корпорации. Драгош получил дополнительные полномочия, а текущее руководство команды перешло к региональному менеджеру в Индии, который, впрочем, перебрался в Вашингтон.
Рис. 4.8. Квартальная пропускная способность на единицу производства
Эти улучшения отчасти стали возможны благодаря невероятным управленческим способностям Драгоша Думитриу, но главной причиной успеха послужили типовые элементы – формирование цепочки создания ценности, анализ потока, задание лимита задач в работе и внедрение вытягивающей системы. Без парадигмы потока и канбан-подхода к ограничению задач в работе выигрыш в производительности был бы невозможен. Благодаря Канбану произошли постепенные изменения, притом с низким политическим риском и уровнем сопротивления изменениям.
Пример XIT показывает, как вытягивающую систему с ограничением незавершенной работы можно применить к распределенному проекту с удаленной командой и как в этом помогает электронная система управления задачами.
Никакой визуализации еще не было, и многие более сложные приемы Канбан-метода, описанные в этой книге, в то время не существовали.
Рис. 4.9. Время выполнения командой техподдержки XIT по финансовым годам Microsoft
Но какой менеджер проигнорирует возможность увеличить производительность более чем на 200 %, сократить время выполнения на 90 % и существенно повысить предсказуемость при минимальных политических рисках и сопротивлении изменениям?
Выводы
• Первая канбан-система была внедрена в команде техподдержки XIT в Microsoft в 2004 году.
• Первая канбан-система использовала ПО для отслеживания работы.
• Первая канбан-система была внедрена в удаленной команде подрядчика в Хайдарабаде, которая стояла на пятом уровне в модели зрелости CMMI.
• Рабочий поток требуется описать и визуализировать.
• Процесс следует описывать как явно заданный набор правил.
• Канбан способствует постепенным изменениям.
• Канбан минимизирует политические риски при внесении изменений.
• Канбан минимизирует сопротивление изменениям.
• Канбан предоставляет возможности совершенствования, которые не предполагают сложных изменений в инженерных методах.
• Первая канбан-система показала более чем 200 %-ное увеличение производительности, 90 %-ное снижение времени выполнения и примерно такое же увеличение предсказуемости поставки.
• Значительные изменения становятся возможными благодаря управлению узкими местами, исключению потерь времени и снижению вариативности, которая негативно влияет на ожидания и удовлетворенность клиента.
• Чтобы изменения привели к результату, нужно время. В данном случае понадобилось 15 месяцев.
Глава 5
Культура постоянного совершенствования
В японском языке слово «кайдзен» дословно значит «постоянное совершенствование». Корпоративная культура, в которой все сотрудники сосредоточены на непрерывном повышении качества, производительности и удовлетворенности клиентов, известна как культура кайдзен. На самом деле подобной культуры удалось добиться очень немногим корпорациям. Такие компании, как Toyota, в которых доля участия сотрудников в программе совершенствования приближается к 100 % и где один сотрудник вносит в среднем одно внедряемое предложение по улучшению в год, очень редки.
В мире разработки ПО Институт технологий разработки ПО (SEI) Университета Карнеги – Меллон определяет высший уровень своей интегрированной модели зрелости процессов ПО (CMMI) как оптимизирование. Оптимизирование предполагает, что качество работы и производительность организации подвергаются постоянному совершенствованию. Хотя CMMI мало уделяет внимание корпоративной культуре и ничего об этом не говорит, достижение оптимизирующего поведения в организации более всего возможно в культуре кайдзен.
Культура кайдзен
Чтобы понять, почему так сложно добиться установления кайдзен, нужно разобраться, что это за культура и как она проявляется. Только после этого можно решить, нужна ли она нам и в чем ее преимущества.
В культуре кайдзен каждый сотрудник наделен полномочиями. Люди могут действовать свободно, по своему усмотрению. Они свободно дискутируют о проблемах, вариантах решения, внедряют поправки и улучшения. В культуре кайдзен сотрудники ничего не боятся. Нормой считается толерантность руководства к неудачам, если эксперименты и инновации проводятся во имя совершенствования процессов и общей производительности. В культуре кайдзен сотрудники свободно (с некоторыми ограничениями) самоорганизовываются для решения порученных задач и выполняют их так, как считают нужным. Визуальный контроль и сигналы присутствуют в явном виде, а рабочие задания обычно раздаются желающим, а не по усмотрению руководителя. Культура кайдзен предполагает высокий уровень сотрудничества и атмосферу коллегиальности, когда каждый работник ставит производительность команды и компании в целом выше собственных результатов. Культура кайдзен сосредоточена на системном мышлении даже при внедрении незначительных локальных улучшений, поскольку они повышают общую производительность.
Кайдзен обладает высоким уровнем социального капитала. Это культура высокого доверия, поскольку сотрудники независимо от своего служебного положения уважают друг друга и ценят вклад любого работника. При высокой степени доверия структура обычно менее вертикальная, чем при его низком уровне. А ведь именно уровень наделения полномочиями позволяет горизонтальным структурам работать эффективно. Таким образом, достижение культуры кайдзен может привести к исключению бессмысленных стадий руководства, что в итоге снизит координационные издержки.
Многие аспекты культуры кайдзен противоречат общепринятым нормам в современной западной культуре, где нас готовят к конкурентной борьбе. Наша система образования поощряет соперничество и в академической успеваемости, и в спорте. Даже в командных видах спорта часто находят героев, и команды строятся вокруг одного-двух исключительных талантов. Общественная норма сосредоточивается в первую очередь вокруг личности, которая призвана приносить победу или спасать нас от опасности. Неудивительно, что на рабочем месте мы испытываем большие трудности с внедрением корпоративного поведения или системного мышления и сотрудничества.
Канбан повышает зрелость и возможности организации
Канбан-метод призван свести к минимуму первичное влияние перемен и снизить сопротивление им. Переход на Канбан должен изменить культуру компании и помочь ей повзрослеть. Если переход проводится правильно, то организация будет охотно принимать и внедрять изменения, что приведет к совершенствованию процессов. SEI в рамках модели CMMI называет эту способность инновациями и перегруппировкой организации (OID){15}. Доказано{16}, что организации, достигшие столь высокого уровня в управлении переменами, могут перейти на agile-методы, например Scrum, быстрее и легче, чем менее зрелые компании.
При первом внедрении Канбана вы ищете способы оптимизировать существующие процессы и изменить культуру организации, не собираясь полностью переключаться на другие процессы, которые способны принести существенные экономические выгоды. Это дает повод для критики{17}: некоторые утверждают, что Канбан занимается оптимизацией того, что нужно попросту изменить. Однако существуют серьезные эмпирические доказательства{18} того, что Канбан ускоряет достижение высокого уровня зрелости и компетентности в отраслях, рассчитанных на зрелые организации, – таких как причинный анализ (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. На наших совещаниях сотрудники словно видели замедленную съемку рабочего потока, представленную на доске. Заблокированные рабочие элементы отмечались розовыми стикерами, и команда активнее фокусировалась на разрешении проблем и сопровождении рабочего потока. Производительность существенно выросла.
Теперь, когда поток работы можно было отслеживать на доске, я сосредоточился на самом процессе работы. И отразил на той же доске некоторые изменения. Моя команда менеджеров уяснила мои принципы и к марту сама стала внедрять изменения. В свою очередь, члены их команд – индивидуальные разработчики, тестировщики и аналитики – воочию увидели процесс и поняли, как все работает. В начале лета все почувствовали, что обладают достаточными полномочиями, чтобы предлагать изменения, и мы увидели процесс спонтанного образования групп (состоящих из представителей разных отделов), обсуждавших проблемы и вызовы и вносивших необходимые улучшения. Обычно руководство узнавало обо всем постфактум. Примерно через шесть месяцев в команде разработки возникла настоящая культура кайдзен. Члены команды чувствовали себя уверенно. Страх исчез. Они гордились своим профессионализмом и достижениями, но надеялись, что смогут работать еще лучше.
Социологические изменения
После опыта с Corbis поступали другие аналогичные отчеты из той же отрасли. Роб Хэтэуэй из Indigo Blue первым воспроизвел эти результаты в IT-группе IPC Media в Лондоне. То, что социологический эффект, достигнутый в Corbis, оказался воспроизводимым, убеждает меня, что причина не во мне и не в простом совпадении, а именно в Канбане.
Я много думал о том, чем объясняются эти социологические изменения. Уже лет десять agile-методы предлагают прозрачность применительно к незавершенным задачам, но команды, применяющие Канбан-метод, судя по всему, достигают культуры кайдзен быстрее и эффективнее, чем типичные команды гибкой разработки. Часто команды, добавляющие Канбан к уже взятым на вооружение agile-методологиям, обнаруживают существенное увеличение социального капитала у своих членов. Чем это объяснить?
По-моему, дело в том, что Канбан обеспечивает прозрачность не только самой работы, но и процесса (или потока). Он дает наглядное представление о том, как работа передается от одной группы к другой. Показывает всем заинтересованным лицам, к какому результату приведет их действие или бездействие. Если элемент заблокирован и кто-то способен его разблокировать, это будет видно благодаря Канбану. Допустим, некое требование можно толковать двояко. Обычно в подобных случаях эксперт, способный разрешить противоречие, ждет электронного письма с просьбой о встрече. Наконец, после серии звонков назначается встреча, которая должна быть запланирована в календаре, – это может произойти и через три недели. Но Канбан и наглядность, присущая этому методу, сразу покажут эксперту эффект от его бездействия. Это может заставить его пересмотреть свои планы, чтобы провести встречу в течение ближайшей недели.
Помимо наглядности потока работы, лимиты на число незавершенных задач тоже стимулируют более быстрые и частые взаимодействия по проблеме. Не так-то легко игнорировать заблокированный элемент и продолжить работу над чем-то другим. Этот аспект Канбана, судя по всему, поощряет образование групп по всей цепочке создания ценности. Когда представители разных отраслей, занимающие различные должности, начинают вместе работать над решением проблемы, поддерживая тем самым рабочий поток и улучшая производительность на системном уровне, увеличивается уровень социального капитала и взаимного доверия в команде. Как только в организации благодаря сотрудничеству появляется высокий уровень доверия, страх сделать что-то не так исчезает.
Ограничение на число незавершенных задач наряду с введением классов обслуживания (о них говорится в главе 11) также позволяет сотрудникам принимать собственные решения по планированию, без указаний или надзора руководства. Наделение полномочиями повышает уровень социального капитала, поскольку демонстрирует, что руководители доверяют подчиненным самостоятельно принимать квалифицированные решения. Менеджеры освобождаются от функции контроля работников и могут сосредоточиться на других вещах – например, производственных показателях, управлении рисками, развитии персонала и повышении удовлетворенности клиентов и сотрудников.
Канбан серьезно повышает уровень социального капитала внутри команды. Рост доверия и исключение фактора страха поощряет совместные инновации и решение проблем. В итоге быстро развивается культура кайдзен.
Вирусное распространение сотрудничества
Канбан определенно улучшил атмосферу в отделе разработки Corbis, но наиболее примечательными были результаты его внедрения, проявившиеся за пределами инженерного подразделения. То, как вирусное распространение Канбана пошло на пользу сотрудничеству в масштабах всей компании, достойно отдельного разговора и анализа.
КЕЙС: РАЗРАБОТКА ПРИЛОЖЕНИЙ CORBIS, ПРОДОЛЖЕНИЕКаждый понедельник в 10 утра Диана Коломиец, менеджер проекта, отвечающая за координирование релизов сопровождения ПО IT-систем, проводила совещание группы быстрого реагирования по приоритетам. От бизнес-отдела обычно присутствовали вице-президенты. Они управляли бизнес-подразделением и непосредственно подчинялись либо старшему вице-президенту, либо иному руководителю высшего звена компании. Иными словами, вице-президент подчинялся члену совета директоров. Corbis была все еще достаточно маленькой компанией, поэтому руководителям столь высокого уровня имело смысл присутствовать на еженедельных совещаниях. Можно сказать и по-другому: тактический выбор, который предстояло сделать на этом собрании, был настолько важен, что требовалось присутствие вице-президента и его мнение. Обычно каждый участник совещания в пятницу получал электронное письмо примерно с таким текстом: «Мы предполагаем, что на следующей неделе освободятся два места для новых задач. Пожалуйста, изучите элементы вашего бэклога и выберите варианты для обсуждения на понедельничном совещании».
Торговля
В первые недели после трансформации процесса некоторые участники приходили с намерением поторговаться. Например, кто-то из них мог сказать: «Я знаю, что свободно только одно место, но у меня два маленьких задания, нельзя ли сделать оба?» Такая постановка вопроса редко приводила к успеху. Другие члены совета по приоритетам следили, чтобы правила были одинаковыми для всех. Они отвечали приблизительно так: «Откуда нам знать, действительно ли они маленькие? Поверить тебе на слово?» Или возражали: «У меня тоже два маленьких задания. Почему бы не сделать выбор в их пользу?» Я называл это периодом торговли, потому что именно так проходили переговоры на первых совещаниях по приоритетам.
Демократия
Прошло примерно шесть недель. По стечению обстоятельств примерно в то же время, когда команда разработки начала использовать доску, совет по приоритетам ввел демократическую систему голосования. Это произошло спонтанно, потому что всем надоели постоянные пререкания. Они отнимали много времени. Чтобы усовершенствовать систему голосования, потребовалось несколько итераций, но в итоге установилось положение, при котором у любого участника был один голос на каждое свободное место в очереди на текущей неделе. В начале совещания каждый участник предлагал небольшое количество кандидатов на выбор. Со временем предложение запросов стало оформляться разнообразнее: одни приходили с презентациями в PowerPoint, другие – с таблицами, иллюстрирующими кейсы. Потом мы узнали, что некоторые участники занимались лоббированием, приглашая коллег на ужин. Заключались сделки: «Если я на этой неделе проголосую за твой вариант, то ты поддержишь на следующей неделе мой». Демократической системе расстановки приоритетов способствовал рост сотрудничества между вице-президентами подразделений. Хотя в то время мы этого еще не понимали, рос социальный капитал в масштабах всей компании. Когда руководители подразделений начинают сотрудничать, их примеру, видимо, следуют подчиненные. Ведь все начинается с лидеров! Атмосфера сотрудничества наряду с наглядностью и прозрачностью порождает более тесное сотрудничество: этот период работы я называю периодом демократии.
Конец демократии
Демократия – это прекрасно, но через четыре месяца выяснилось, что она не способствует избранию лучшего кандидата. Были потрачены значительные усилия на реализацию функции для электронной коммерции с адаптацией к восточноевропейскому рынку. Кейс казался великолепным, но его жизнеспособность с самого начала вызывала подозрения, под сомнение было поставлено и качество данных. Далеко не с первой попытки, но функция была выбрана и внедрена. Это крупная функция, которая проходила через группу быстрого реагирования, в ее реализации приняли участие многие, так что она не осталась незамеченной. Через два месяца после запуска директор по интеллектуальному анализу данных обработал данные о выручке. Это была лишь небольшая часть того, что сулил исходный кейс: оказалось, что затраченные усилия окупятся примерно через 19 лет. Благодаря прозрачности, которую предлагает Канбан, результат стал известен многим заинтересованным лицам. Возникла дискуссия о том, для чего на этот вариант затрачивалось столько драгоценных ресурсов, хотя можно было сделать гораздо лучший выбор. Так окончился период демократии.
Сотрудничество
Примечательно то, что пришло на смену. Нужно помнить, что в совет по приоритетам входили в основном сотрудники уровня вице-президента компании. Они хорошо знали такие аспекты бизнеса, о которых многие из нас даже не подозревали. Поэтому в начале совещания они стали спрашивать: «Диана, какое сейчас среднее время выполнения?» Она отвечала, например: «В среднем это сорок четыре дня до релиза». Тогда они задались вопросом: «Какая тактическая деловая инициатива будет самой важной для компании через сорок четыре дня?» Возможно, последовало короткое обсуждение, но в целом соглашение было достигнуто сразу: «О, так это же наша европейская маркетинговая кампания, которую мы запускаем на конференции в Каннах». – «Отлично! Какие элементы бэклога призваны поддержать этот запуск в Каннах?» После быстрого поиска было выявлено шесть элементов. «Итак, сегодня у нас свободно три места. Давайте выберем три из шести, а остальные включим на следующей неделе». Почти никто не спорил, не было никакой торговли. Совещание продолжалось двадцать минут. Этот этап я называю периодом сотрудничества. Он отражает наивысший уровень социального капитала и доверия между подразделениями, который был достигнут, когда я работал старшим директором по разработке в Corbis.
Культурные перемены – едва ли не главное преимущество канбана
Было интересно наблюдать за возникновением культурных изменений и за тем, как они все шире распространяются в компании, после того как сотрудники последовали примеру своих вице-президентов и стали активнее сотрудничать с коллегами из других подразделений. Эти перемены оказались настолько глубокими, что недавно назначенный CEO Гэри Шенк вызвал меня в свой кабинет и спросил, как я это объясняю. Он отметил, что видит новый уровень сотрудничества и командного духа в высшем руководстве компании, и, по его мнению, бизнес-подразделения, между которыми прежде царила конкуренция, теперь работают гораздо лучше. Шенк считал, что все дело в организации группы быстрого реагирования, но хотел услышать и мое мнение. Я постарался убедить его, что именно наша канбан-система существенно повысила уровень сотрудничества и социального капитала у всех, кто имел к ней отношение.
Культурные изменения, опосредованно связанные с тем, что мы сейчас называем Канбаном (с большой буквы), оказались совершенно неожиданными и во многих отношениях противоречили здравому смыслу. Он спросил: «Почему же тогда мы не используем это во всех крупных проектах?» И мы решили внедрить в портфель крупных проектов Канбан, мотивируя это тем, что он создал культуру кайдзен. Эти культурные изменения оказались настолько желательными, что издержки на трансформацию механизмов расстановки приоритетов, планирования, форм отчетности и выполнения, которых требовало внедрение Канбана, не выглядели чрезмерными.
Выводы
• Кайдзен переводится как «непрерывное совершенствование».
• В культуре кайдзен люди чувствуют свои полномочия, действуют без страха, произвольно объединяются в группы, сотрудничают и вводят инновации.
• Для культуры кайдзен характерен высокий уровень социального капитала и доверия между людьми независимо от их места в корпоративной иерархии.
• Канбан обеспечивает прозрачность как самой работы, так и рабочего процесса.
• Прозрачность рабочего процесса позволяет всем заинтересованным лицам видеть результаты своей деятельности или бездействия.
• Люди с большей готовностью инвестируют свое время и выражают готовность к сотрудничеству, если они видят результаты своей деятельности.
• Ограничения на число незавершенных задач в Канбане стимулируют принятие ответственности на себя.
• Ограничения на число незавершенных задач в Канбане стимулируют произвольное образование групп для решения проблем.
• Повышение степени сотрудничества в результате формирования групп для решения проблем и взаимодействия с внешними заинтересованными лицами выводит на новый уровень социальный капитал внутри команды и доверие членов команды друг к другу.
• Ограничения на число незавершенных задач в Канбане и введение классов обслуживания позволяют сотрудникам брать работу и принимать решения по расстановке приоритетов и планированию без надзора или руководства вышестоящих лиц.
• Повышенный уровень полномочий увеличивает социальный капитал и доверие между сотрудниками и менеджерами.
• Коллективистское поведение распространяется вирусным образом.
• Сотрудники могут следовать примеру старших руководителей. Их коллегиальное поведение влияет на поведение всех работников организации.
Часть III
Внедрение канбана
Глава 6
Визуализация цепочки создания ценности
Канбан – это подход, который благоприятствует изменениям, оптимизируя ваши процессы. Главное в начале использования Канбана – внесение минимальных изменений в рабочий процесс. Нужно противостоять искушению полностью перестроить рабочий поток, пересмотреть штатное расписание, роли, ответственность и конкретные рабочие методы. Все, что влияет на самооценку, профессиональную гордость и эго членов команды, сотрудников компании и заинтересованных лиц, должно остаться неизменным. Изменения должны быть направлены на количество незавершенных задач и точки взаимодействия с соседями выше и ниже по цепочке создания ценности. Поэтому вам нужно вместе с командой создать схему существующей цепочки создания ценности. Старайтесь ничего не менять и не изобретать в поисках улучшений.
В некоторых ситуациях официальная процедура не выполняется. При попытке составить схему цепочки создания ценности команда будет настаивать на фиксировании официальной процедуры, а не той, что используется фактически. Вы должны противостоять этому, чтобы описать реальную схему работающего процесса. Без этого невозможно использовать стену карточек как средство визуализации процесса, поскольку члены команды могут полагаться на нее, только если она отражает действительность.
Определение стартовой и финишной контрольных точек
Необходимо определиться со стартовой и финишной точками визуализации процесса, а также с точками взаимодействия с вышестоящими и нижестоящими соседями по цепочке создания ценности. Важно ответственно отнестись к этой начальной стадии внедрения Канбана, поскольку неверный выбор может привести вас к провалу. Успешные команды обычно начинают с перехода на визуализацию при помощи карточек и ограничения числа незавершенных задач в пределах своей сферы контроля и переговоров по поводу новых способов взаимодействия с непосредственными партнерами по цепочке создания ценности. Например, если вы контролируете отдел проектирования или разработки и обладаете контролем (влиянием) над анализом, дизайном, тестированием и написанием кода, то составьте схему этой цепочки создания ценности и начните переговоры по поводу нового стиля взаимодействия с вышестоящими деловыми партнерами, от которых зависят требования, расстановка приоритетов и управление портфелем, а также нижестоящими, занимающимися системными операциями и поддержкой продукта. Очертив тем самым границы, вы предлагаете перейти на ограничение числа незавершенных задач только своей команде. Другие не обязаны менять методы работы, ограничивать число незавершенных задач и внедрять вытягивающую систему. Однако вы просите их по-иному взаимодействовать с вами, чтобы это было совместимо с вытягивающей системой, которую вы внедряете у себя.
Типы работ
Выбрав стартовую точку для рабочего процесса или цепочки создания ценности, определите, какие типы работы относятся к этой точке, а какие существуют в рабочем процессе и должны подвергнуться ограничениям. Например, исправление ошибок, скорее всего, относится к типам работ, существующим в рабочем процессе. Возможно, вы выявите и иные типы деятельности, связанные с разработкой: рефакторинг, поддержку систем, обновление инфраструктуры и другие переделки. Для входящей работы это такие типы, как пользовательские истории, прецеденты, функциональные требования или функции. В некоторых случаях входящие типы работы могут быть иерархическими – например, эпики[6] (собрания пользовательских историй).
Вот основные типы работы в командах, использующих Канбан (это неполный список):
• требование;
• функция;
• пользовательская история;
• пользовательский сценарий;
• запрос изменений;
• дефект продукта;
• поддержка;
• рефакторинг из-за ошибки;
• предложение улучшения;
• блокирующая проблема.
Полезно именовать типы работы по источнику, например: регуляторное требование, запрос продаж на местах, требование стратегического планирования и т. д. Если по оглавлению задачи сразу понятен источник, это создает дополнительный контекст и позволяет системе развиваться в сторону обслуживания нескольких клиентов сразу.
Типы работы обычно определяются их источником, рабочим потоком или размером работы. Например, у производственных текстовых изменений (РТС) в примере с Microsoft из главы 4 рабочий поток иной, хотя источник тот же, что и у запроса изменений. Иметь отдельные канбан-системы для обоих типов бессмысленно: работу выполняет одна и та же команда и несложно визуализировать типы, используя различные цвета карточек или разные ряды («плавательные дорожки») на стене карточек. Порядок величины карточек обычно таков: маленькие (несколько дней), средние (от недели до двух) и большие (месяц и более). Каждый порядок должен соответствовать своему типу.
Создание стены карточек
Стена карточек обычно создается скорее для иллюстрации видов действий, чем для отражения конкретных функций или описаний работы. Часто функция и действие существенно перекрываются: например, аналитики проводят анализы. Однако в программных проектах, выполняемых при помощи Канбана, в последние несколько лет принято моделировать работу, а не работников, функции или передачи функций.
Перед созданием стены карточек для визуализации рабочего потока иногда полезно схематично набросать или смоделировать ее. Рис. 4.4 демонстрирует очень формальную модель желаемого рабочего потока, представленную при помощи диаграммы состояний. В ней добавляются очереди на запросы изменений и производственные текстовые изменения, обрабатываемые командой технической поддержки XIT в Microsoft. Вполне вероятен и менее формальный подход. Рисунка с человечками вроде тех, что фигурировали в главе 4, или схемы-алгоритма либо ее аналога может оказаться достаточно.