Поток
Когда наша команда была сформирована, то оказалось, что мало кто в ней имел опыт работы с такими процессами, как аджайл. Половина моих подчиненных были новичками в части применяемых нами технологий — они не были знакомы даже с языком программирования и никогда прежде не сталкивались с такими методами, как непрерывная интеграция и управление версиями. Но даже в таких условиях они продолжали разрабатывать приложения высокого уровня сложности, используя простые и надежные процессы, способные давать заказчикам новые функции определенного качества в течение часов или дней.
Как стала возможна такая трансформация? Наш подход заключался не в обучении членов команды новым процессам или в предложении взять на себя новую роль. Мы просто перешли к применению Канбан Метода, с которым вы знакомитесь сейчас. Короче, мы визуализировали свою работу, продолжая выискивать самые серьезные препятствия, встречающиеся на пути потока задач и стараясь устранять их.
Основная практика 3: управляйте потоком (еще раз)
Я опять обращаю внимание на мою собственную расширенную версию третьей основной практики канбана:
ОП3 (расширенная): управляйте потоком, добивайтесь плавности, своевременности и хороших экономических результатов, предугадывая потребности клиента.
О том, как управлять потоком для обеспечения своевременности, мы поговорим ближе к концу этой главы. Большая ее часть будет посвящена плавности.
Плавность
Канбан не уникален в своей приверженности принципу плавности. В некоторых кругах эта приверженность намного сильнее — она просто перерастает в одержимость! Подготовка менеджеров в компании Toyota включает в себя многочасовое наблюдение за поточными линиями в поисках мельчайшего отклонения от идеальной плавности. Главная идея здесь заключается в том, что не существует настолько плавного производственного процесса, что дальнейшее улучшение не является возможным и целесообразным.
Идея начать с наблюдения за производственной линией не очень хорошо подходит для творческой интеллектуальной работы, даже если мы практикуем канбан. Но, как бы то ни было, мы начинаем чувствовать настоящий дискомфорт, когда видим прерванную, заблокированную, незавершенную или возвращенную для переделки работу. Это происходит даже в тех случаях, когда сложившиеся в данный момент в бизнесе обстоятельства, казалось бы, служат удовлетворительным оправданием. Если эта прискорбная ситуация вызывает вопрос «Что это за процесс, который так легко позволяет такому случиться?», то мы уже сделали важный шаг вперед.
В книге «Вопрос культуры» Даниэль Мезик напоминает, что мы можем одновременно уделять внимание только ограниченному количеству вещей и событий. Независимо от осознания этого факта при создании своих систем управления производством мы выбираем то, чему будем осознанно уделять внимание. Привнося прозрачность в поток нашей работы, мы делаем именно такой выбор. Как заметил Мезик: «Канбан уделяет явное внимание потоку».
Как выглядит поток?
Вот несколько признаков того, что работа приобретает характер потока:
- Вы видите, что между стендап митингами выполняется все больше рабочих задач. Их точное число и частота появления зависят от размера задач, количества людей в команде и интервалов между стендап митингами, однако в большинстве из них ежедневно отмечается некоторый прогресс. Разбивайте крупномасштабные рабочие задачи на более мелкие части (но по-прежнему ценные), если прогресс не очень заметен.
- С учетом численности сотрудников значительное количество рабочих задач выполняется без помех, что дает уверенность в обеспечении прогресса.
- Вы чувствуете (и даже можете подтвердить количественно), что рабочие задачи решаются быстрее и более предсказуемо. У рабочих задач сходного типа и размера производственные циклы становятся короче и вписываются в более узкий временной диапазон.
Если этого не происходит, то у вас есть к чему стремиться. Если же происходит, то задайте себе вопрос, можно ли еще улучшить поток с помощью этих широких мер. Но ни на секунду не сомневайтесь, что такая возможность существует.
Хорошо, когда есть возможность наблюдать признаки потока и даже оценивать его количественно, но не стоит недооценивать ощущения. Очень приятно ощущать, что рабочие задачи выполняются, что рабочая нагрузка не отягощена проблемами, что можно с достаточной долей уверенности делать прогнозы. Это придает уверенность всем — клиентам, организации и тем, кто выполняет работу.
Обзор доски (еще раз)
В предыдущей главе предлагалось анализировать рабочий процесс с точки зрения клиентоориентированности. Анализ начинался с удовлетворенности клиента и шел в обратном направлении к его исходным потребностям с изучением каждого этапа через линзу получения знаний. Попробуем применить тот же подход к изучению потока, но уже с другой линзой.
Зачем идти в обратном направлении? Это заставляет сосредоточиться на том, что действительно нужно, чтобы работа шла потоком, а не на выискивании возможных способов выполнения задач в каждой точке рабочего процесса. В переносном смысле (и возможно даже физически) мы стоим на правом краю канбан-доски и размышляем о том, что мешает плавно довести работу до завершения, вместо того чтобы стоять на левом краю и придумывать способы быстрого выталкивания работы в растущую кучу в центре системы. Протокол канбан-летучек — это своего рода инструмент мышления!
Какой будет наша новая линза? Когда мы уделяем более пристальное внимание потоку, то задаем применительно к каждому столбцу примерно такие вопросы:
- Как рабочие задачи покидают эту стадию процесса? По каким критериям мы определяем их готовность? Как выражены эти критерии? Каким образом мы получаем сигнал о готовности рабочей задачи к перемещению далее по потоку?
- Как долго рабочие задачи обычно находятся в данной стадии? Какую часть этого срока они находятся в активной работе по сравнению с ожиданием?
- Каковы самые важные причины непредсказуемости — они связаны с рабочим процессом или с ожиданием? Рабочие задачи обычно ждут высвобождения внутренних ресурсов или их выполнение зависит от внешних факторов?
- Какая часть ресурсов на этой стадии ушла на переделку? Или это всего лишь жалоба на то, что выполненная работа не полностью удовлетворяет потребности клиента?
- Как рабочие задачи добираются до этой стадии процесса? По каким признакам мы узнаем, что они готовы к началу работы над ними?
Внимание: подобные вопросы позволяют сделать следующие предположения:
- Процесс имеет разумные цели — удовлетворение правильных потребностей клиента.
- Рабочий процесс имеет разумные ограничения — он начинается с правильных вопросов и заканчивается правильными результатами.
- Рабочий процесс разумно организован — он выстроен таким образом, чтобы как можно быстрее служить источником высококачественного обучения.
Я видел достаточно примеров обратного, чтобы понимать потенциальную опасность подобных предположений. Ниже я привожу два из них.
- Однажды я помогал оптимизировать процесс, цель которого заключалась в принятии предложений по изменению дизайна или отказе от них. Было очевидно, что этот так называемый процесс управления изменениями полностью оторван от фактического процесса реализации изменений — его цели и содержание были либо неправильно выбраны, либо рассогласованы. Излишне говорить, что клиента очень недолго удовлетворяли его результаты.
- Процессы разработки программного обеспечения часто осуществляются в предположении, что думать о приемо-сдаточных испытаниях нужно ближе к окончанию проекта. Это сдвигает возможность ценного обучения к самой последней стадии процесса работы над проектом.
Всегда есть более широкий контекст
Мы уже видели, как клиентоориентированность создает для команд стимулы думать о более широком контексте, чем их непосредственная работа. Поток делает то же самое по многим измерениям.
Размышляя о потоке, нам часто приходится думать о том, как то, от чего мы зависим — материал, информация, идеи и даже люди, — оказывается в нашей части системы. Ведь они не попадают туда в нужное время случайно. Точно так же мы не можем ожидать, что работа всегда будет выходить от нас в подходящий момент, если не подумаем о том, что происходит за нашими стенами, и не убедимся, что маршрут выхода свободен.
Вы, наверное, к настоящему моменту поняли, что на самом деле канбан не нацелен на повышение персональной или коллективной продуктивности. Да, мы часто работаем над улучшением системы в пределах своей зоны ответственности, но не ограничиваемся только теми проблемами, которые можем решить исключительно своими силами. Зачастую мы выходим за ее пределы, работаем с другими людьми над более крупными, комплексными проблемами. В данном случае сотрудничество не просто помогает получить результат, оно способствует концентрации коллективных усилий там, где они больше всего необходимы.
Несколько простых примеров
Ниже я привожу фрагменты списка усовершенствований, осуществленных нами в 2009–2010 гг. Некоторые из них могут показаться чересчур специфическими из-за привязанности к разработке программного обеспечения, но большая часть содержит идеи, которые можно перенести в другие сферы деятельности. Фрагменты расположены в порядке «справа налево», т.е. в обратном порядке относительно процесса поставки готового продукта клиенту.
- Как было рассказано в предыдущей главе, в конце процесса мы добавили стадию верификации со стороны клиента. Наша первоначальная цель заключалась в ускорении перехода от «просто передано» к «фактически внедрено». Оглядываясь назад, можно сказать, что это изменение стало катализатором конкретного сотрудничества с клиентом, которое, в свою очередь, позволило гарантировать хорошие результаты работы. Кроме того, нам удалось значительно сократить общее время, переделки, жалобы и объем прекращенной работы.
- Автоматический выпуск релизов. То, что изначально требовало нескольких часов интенсивной ручной работы, сопряженной с высоким риском ошибки, теперь можно сделать за несколько минут с высокой надежностью, кроме того, у нас появилась возможность быстрого отката назад в случае, если что-то пошло не так.
- Автоматическое тестирование. Мы начали с покомпонентного тестирования низкого уровня, однако постепенно автоматизировали бо́льшую часть приемо-сдаточных испытаний. Мы научились анализировать результаты тестирования до того, как перейти к анализу кода прикладной программы, и с учетом этого внесли ряд существенных усовершенствований в кодовую базу. Это, в свою очередь, не просто повысило качество тестов, которые мы написали, но и дало возможность существенно упростить тестирование изменений, которые мы вносили в будущем.
- Внедрение в практику правила «демонстрируй!». Оно требует, чтобы разработчик каждой вновь написанной программы демонстрировал ее всей команде, а не только аналитику. Только после этого работа перемещается из раздела «Разработка» в раздел «Тестирование». Это предотвращает преждевременное перемещение работы из раздела в раздел и создает хорошие возможности для обмена знаниями и генерирования идей.
- В том, что касалось анализа кода, мы придерживались принципа «никаких сюрпризов», но на современный манер. Мы считали, что в анализе кода нет необходимости, когда он написан методом парного программирования (разработка программного продукта с участием двух программистов, совместно работающих за одним компьютером).
- «Правило пяти дней». Мы совместно постановили, что на выполнение рабочей задачи, как правило, не должно уходить более пяти дней. Со временем это правило превратилось в «правило двух дней». Мы доработали это правило c исключением (его следует задействовать с осторожностью), которое касается рабочих задач, которые не так легко разбить на составные части.
- Введение ежедневных перемещений рабочих задач с целью получения поддержки вместо еженедельных. При старой системе (еженедельные перемещения) случались регулярные и длительные задержки разработки, что сказывалось на предсказуемости наших результатов. С внедрением системы ежедневной ротации у нас появилось правило, в соответствии с которым запросы на получение поддержки передавались по утрам. Такая практика давала возможность гарантированно получать необходимую помощь даже в том случае, если ее объем был велик (мы находили баланс между потоком работы, связанной с поддержкой, и потоком работы, связанной с разработкой программных продуктов).
- Мы тщательно следили за тем, откуда чаще всего исходят запросы на поддержку, и предлагали разработать и внедрить там локальные правила. По мере решения общих проблем и с организацией совместного обучения в смежных отделах количество обращений за помощью пошло на убыль.
Поток в крупной организации
Чем больше становится организация, тем больше сервисов требуют ее потоки. Обычно какие-то сервисы задействованы в одном потоке, а остальные используются в нескольких и, возможно, являются аутсорсинговыми. Некоторые сервисы являются частью «главного потока», а другие используются только по запросу.
На рис. 5.1 показаны некоторые проблемы масштаба.
При значительных масштабах возникает масса возможностей для задержек и срывов.
- Группа, ответственная за получение запросов на выполнение работ, и группа, ответственная за выполнение работы, — это две разные группы. Использование средств коммуникации, основанных на принципе «выстрелил и забыл» (особенно электронной почты), приводит к тому, что работа остается незамеченной.
- Возникают нестыковки представлений о «Сделанном» и «Готовом» у сотрудников или команд. Эти качественные проблемы могут быть вызваны ошибками при следовании правилам или неудачным сотрудничеством, а зачастую тем и другим вместе.
- Производственная деятельность осуществляется не на той стороне границы организации в отрыве от наиболее необходимых навыков или источников информации.
- Процесс включает в себя ненужные шаги, которые можно было бы без проблем встроить в другие этапы, а также шаги, которые можно разложить на компоненты и перенести на более ранний срок, чтобы быстрее получить важную обратную связь.
- Неадекватное внимание уделяется общекорпоративным сервисам, от которых зависит главный поток. Эта проблема играет двоякую роль: проблема зависимости от одного сервиса представляет собой первичную проблему другого сервиса, а последняя, в свою очередь, является проблемой как видимости (запросы поступают слишком поздно от людей, которые необязательно понимают, о чем просят), так и управления возможностями (запросы делаются без учета общей рабочей загрузки).
Работа выполняется порциями, которые слишком велики и представляют собой, например, многомесячные или многолетние проекты, не приносящие клиентам никакой пользы на промежуточных этапах. Проблема катастрофически усугубляется тем, что выполнение больших порций новой работы начинается без учета их воздействия на уже выполняемую работу (другие большие порции).
Одновременное существование обеих проблем не такое уж редкое явление. В итоге мы получаем не только очень плохую организацию производства, но и реальные страдания людей. Кому хочется быть постоянно перегруженным и при этом не видеть значимого результата?
Некоторые говорят, что, если ситуация так плоха, нужно все бросить и начать работу заново. Это несерьезно: с чего это те, кто выступает за постепенный и эволюционный подход к разработке программного продукта, будут рекомендовать разрушительные и революционные перемены в работе систем, основой которых является человек, где результаты намного менее предсказуемы?
К счастью, редко процесс является настолько сложным, что названные проблемы нельзя идентифицировать и последовательно решить. Перечисленные ниже тактические приемы их решения удивительно просты и имеют очевидную связь с практикой канбана:
- Сквозное отслеживание работы при правильной степени детализации рабочей задачи, часто многоуровневой.
- Контроль размеров порций с помощью ограничения объемов незавершенной работы и правил определения размеров рабочих задач — официальное уменьшение аппетита к принятию обязательств по поставкам в далеком будущем.
- Управление объемами незавершенных работ через функциональные границы.
- Получение согласия на совместное соблюдение правил за пределами функциональных границ.
- Визуальное управление зависимостью от общекорпоративных сервисов; и наоборот, управление спросом до вступления в действие этих сервисов.
- Изменение детализации видов деятельности или структур, с помощью которых происходит управление рабочими задачами (при необходимости на нескольких уровнях).
- Поэтапная реорганизация процесса с последующими функциональными изменениями при необходимости.
- Количественная оценка и передача информации о результатах удобным для клиентов способом (во многих случаях речь идет о количественной оценке потока).
Зачастую организации усугубляют свои проблемы из-за уверенности людей в том, что лучший выход — это «поднажать». Они думают, что эффективное управление проектом устранит проблему управления возможностями (превращение менеджеров проекта в козлов отпущения), что более сильное функциональное руководство повысит комплексную эффективность (хотя оно легко может ухудшить ее) или что люди должны просто стараться работать лучше (хотя система ненадежна на принципиальном уровне).
Предлагаемое Канбан Методом необычное решение этой проблемы не связано с «лобовой атакой» на роли менеджмента проекта и функционального руководства и уж тем более не предусматривает немедленную их замену на что-то другое. Напротив, канбан предоставляет менеджерам (и, конечно, другим сотрудникам) инструменты и возможности по-новому увидеть работу и ее потоки, а также инструменты контроля незавершенной работы, которая является причиной задержек и непредсказуемости. Если сфера применения канбана выбрана верно, то улучшение ситуации и переход на новый тип мышления идут рука об руку. А если потребуется изменить роли менеджмента проекта и функционального руководства, то это прекрасно!
Но сферу применения канбана не следует воспринимать как нечто само собой разумеющееся. Обычно (что неудивительно) нас приглашают как консультантов, которые должны дать рекомендации или обучить сотрудников соответствующего функционального подразделения, которое испытывает перенапряжение, зачастую являясь самым перегруженным элементом системы. Нам приходится напомнить новым спонсорам о том, что улучшения и усовершенствования, ориентированные внутрь, имеют ограничения, даже если они базируются на Канбан Методе.
Откровенно говоря, ориентированная внутрь программа канбана не совсем полноценна. В частности, в ней отсутствуют такие внешнеориентированные ценности, как клиентоориентированность и поток (наряду с лидерством, о котором пойдет речь в следующей главе). Она указывает направление на внутренние ценности и практики, о которых говорилось в предыдущих главах. Напоследок хочется задать вопрос: если предложенная вам программа перемен (независимо от того, основана она на принципах канбана или нет) исчерпала себя, то может ли внимание на правильном организационном уровне к одной или нескольким ценностям помочь сдвинуть дело с мертвой точки?
Управление потоком ради своевременности
Было бы ошибкой считать, что управление потоком имеет значение только с точки зрения устранения помех по мере их появления. Обычно при интеллектуальной работе мы видим, что рабочие задачи очень сильно различаются по контенту и смыслу, а общая рабочая нагрузка сильно меняется с течением времени. Сказанное означает, что всегда будет место для активного управления работой:
- Необходимо как можно раньше идентифицировать необычные риски и зависимости и эффективно на них реагировать.
- При среднесрочных задачах ожидаемая рабочая нагрузка должна соответствовать производственным возможностям.
- При более долгосрочных задачах могут потребоваться совершенно новые производственные возможности.
Приверженность к самоорганизации вовсе не означает, что вы должны всегда воздерживаться от активного управления наиболее важными рабочими задачами. Не все они похожи друг на друга, некоторые из них заслуживают значительно большего внимания с вашей стороны. Сроки — по меньшей мере, разумные — должны соблюдаться. И если это оправдано с деловой точки зрения, то можно и нужно принести в жертву предсказуемость и позволить особо ценным рабочим задачам обойти очередь.
В то же время признаком хорошо развитой и отлаженной вытягивающей системы является то, что в ее рамках легко принимать повседневные решения, связанные с планированием. Можно сделать так, что это будет происходить естественно при одновременном развитии умения понимать, выполнение какой задачи следует ускорить и когда. Формализация этого поможет системе развиваться дальше. По мере становления системы необходимость вашего вмешательства будет уменьшаться.
