Kanban и Lean – эволюция вместо революции

Как я и обещал в своей предыдущей статье «Создание команд и перестройка цепочек создания ценности в Agile-трансформации», семнадцатая статья из серии «Менеджмент цифрового мира» будет посвящена Kanban и Lean. Распространено мнение, что Kanban является сильно упрощенным вариантом «Scrum без спринтов» для ситуации, когда команда должна просто обрабатывать поток задач. Это неверно. Kanban, в отличие от Scrum, вообще не дает какого-либо фиксированного способа организации процесса. Он запускается на основе существующего процесса и набора ролей, визуализирует поток создания ценности, а затем начинает эволюционные изменения для наращивания потока и исключения лишней работы.

Kanban может быть запущен как для одной команды, организуя его работу, с постепенным расширением области применения на смежные команды, так и для компании в целом, соорганизуя и оркеструя работы многих команд. Его естественным развитием является Lean, ориентированный на оптимизацию цепочек создания ценности. Отмечу, что речь тут идет об IT-вариантах Kanban и Lean, а не об их производственных вариантах, разработанных в Toyota. Kanban, насколько я представляю его историю, является оригинальной конструкцией, собранной на основе разных источников. Хотя он и получил свое название от использования Kanban-доски, которая является первым шагом метода и применяется для визуализации потока работ.

А Lean является переосмыслением и адаптацией исходного производственного варианта для систем умственного труда, , описанным Мэри и Томом Поппендик в книге «Бережливая разработка программного обеспечения» (Lean Software Development). Применяются те же механизмы оптимизации потока создания ценности, однако типы лишней работы для задач умственного труда, принципиально отличаются от типов для физического производства. Чтобы убедиться в этом достаточно сравнить лекции специалистов по производственному Lean и Lean в IT. Сейчас можно говорить о том, что объединение Lean и Kanban в IT, по моей оценке, является наиболее интенсивно развивающимся из Agile-методов, и имеет наибольший потенциал применения во всех отраслях, в связи с приходом цифрового мира, вызвавшего интенсивный переходом от физического труда к умственному .

Начну я свой рассказ с того, что порекомендую замечательный доклад про Kanban Алексея Пименова на AgileDays-2019 «Скрытая механика работы Kanban Method» https://youtu.be/DCSPRM4msu4 (мой конспект в отчете с конференции). Алексей является ведущим специалистом по Kanban на всем постсоветском пространстве, включая, естественно, Россию и имеет высокие уровни сертификации от Kanban University и хорошо представляет себе современное развитие метода. Отмечу, что сертификация продвинутых уровней предполагает не просто прохождение курсов и тренингов с проверкой теоретических знаний, а личный опыт практической работы, который проверяется на сертификационном собеседовании – помимо теории ты рассказываешь экспертам-практикам о своих кейсах. Поэтому такой сертификат служит реальным свидетельством квалификации.

Как и большинство Agile-методов, Kanban имеет автора, его придумал Дэвид Андресон и его книга «Kanban – альтернативный путь в Agile» является правильным источником для знакомства с методом, подобно книге книга Джефа Сазерленда «Scrum – революционный метод управления проектами» для знакомства со Scrum. Книги-первоисточники хороши тем, что обычно позволяют проникнуть в замысел автора, показывают логику формирования метода, а не готовый результат. А это очень важно для понимания метода.

Надо заметить, что название «альтернативный путь в Agile» есть только в русском переводе, и, говорят, появилось по настоянию издательства для лучших продаж книги. Оригинал называется «Kanban. Successful Evolutionary Change for Your Technology Business». И в сообществе периодически возникает дискуссия о том, является ли Kanban Agile-методом. С моей точки зрения, безусловно, является. Во-первых, исторически: Андерсон его именно так и позиционировал в своих ранних работах и выступлениях на Agile-конференциях, например, «Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results» (2003). Кстати, она явно показывает один из основных источников – теорию ограничений Голдратта.

Во-вторых, по содержанию: если посмотреть на набор практик, описанный в книге Андерсона, то в целом он хорошо соответствует набору практик Scrum, а также принципам Agile. Что не удивительно, потому что они в целом отражают эффективные методы для IT-разработки. А, в третьих, на уровне культуры: хотя Kanban стартует от существующего процесса и не предъявляет требования какой-либо особой Agile-культуры, прозрачность потока создания ценности, ориентация на его улучшения и сотрудничество со смежниками неизбежно ведет к изменению культуры как раз в том направлении, в котором это сформулировано в Agile-манифесте.

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

Второй уровень значительно важнее первого, потому что именно он показывает логику разворачивания эволюционного процесса улучшений, который и составляет суть Kanban. В книге Андерсон показывает тут путь, который прошли его команды. Следуя духу Kanban, ваши команды пройдут свой путь в той же логике, но стартовав от других начальных условий, и прийдя, естественно, к другому набору используемых практик, потому что этот набор будет зависеть от специфики и условий вашего проекта. И, вероятно, это будут вовсе не простой набор практик, скорее всего, схема процесса будет сложнее, чем фреймворк Scrum, зато она будет отражать вашу специфику. Во всяком случае, то, что получилось у Андерсона и описано в книге – сложнее, поэтому ее и не рисуют ☺

Итак, каким образом работает Kanban? Как уже говорили, все начинается с анализа и визуализации на доске существующего потока работ. Об использовании досок в Agile я писал отдельную статью «Доска – визуализация текущего состояния работы» где как раз достаточно подробно раскрывал их работу на примере Kanban. Я не буду повторяться, однако помещу тут картинку из той статьи с описанием основных элементов и приемов, просто чтобы напомнить.

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

Проектирование доски является частью проектирования Kanban-системы в целом. Он выполняется с помощью STATIK – Systems Thinking Approach to Introducing Kanban, описанном в в книге Майка Барроуза (Mike Burrows) «Kanban from the inside». Описывать его я не буду, потому что краткое описание будет достаточно бесполезно. Желающие могут прочесть книгу, или найти и почитать статьи или сходить на первый тренинг «Kanban System Design». Впрочем, если вы любопытны и решите найти статьи с кратким описанием – найдите несколько и сравните ☺

Самым главным результатом проектирования является вовсе не прояснение потока работ. Главный результат – это ответ на вопрос для кого работает ваше подразделение в компании и какой сервис оно предоставляет тем, для кого работает. Вообще основная идея Kanban – это представить компанию в сервисной структуре. Перейти от представления компании как потока задач, которые выполняются потому что «так надо» и передаются на следующий этап работ соседнему отделу, к представлению компании как предоставляющий сервис конечному клиенту. Это делают подразделения, которые непосредственно с клиентом взаимодействуют, и для этого другие подразделения предоставляют сервис им самим.

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

Самое существенное изменение касается отношения к простоям. Задача сервиса не в том, чтобы все сотрудники были максимально загружены, задача в том, чтобы все внешние запросы обрабатывались в соответствии с соглашением. Типичный пример, который, я думаю, всем будет понятен – кассы в супермаркете. Нет задачи, чтобы кассир все время выбивал чеки, есть задача, чтобы очередь была маленькой: увидев хвост, покупатели просто пойдут в соседний магазин. Для оказания сервиса требуемого уровня в условиях неоднородного потока запросов нужны избыточные мощности. А когда покупателей мало, кассира можно занять чем-нибудь полезным, но при этом основная его задача – сервис на кассе.

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

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

Основными характеристиками сервиса является мощность потока задач, которые он обрабатывает и скорость прохождения отдельных задач через сервис. Как учит теория ограничений Голдратта, для высокой скорости прохождения задач необходимо ограничить количество незавершенной работы. Для этого в Kanban есть механизм WIP-лимитов, которые ограничивают незавершенную работу. При этом используется разные виды лимитов: на человека, на задачу в целом, на классы обслуживания, на этапы работ. Отметим, что в случае обычного производства ограничением является какие-то конкретные этапы обработки. А в IT из-за высокой неопределенности, связанной с исполнением задачи и длинного хвоста распределения вероятности выполнения, мы, как правило, не можем уверенно выделить этапы, являющиеся ограничениями. Поэтому WIP-лимиты устанавливаются для всех этапов.

WIP-лимит служит ограничением не только числа задач, находящихся в работе на конкретной фазе, но и для тех, которые уже готовы для передачи на следующий этап. В этом и состоит суть вытягивания: задача закреплена за фазой исполнения до тех пор, пока на следующей фазе не освободиться для нее место. Таким образом, возможна ситуация, когда завершив очередную задачу сотрудник не может взять следующую, потому что сработало ограничение лимита. И в этот момент возникает вопрос: а что ему делать? Ответы могут быть разными: «отдохнуть и выспаться», «помочь другим», «посмотреть, что можно сделать в других этапах», «почитать книгу». Важно не брать задачу сверх лимита, увеличивая этим незавершенную работу и нарушая, таким образом, производительность Kanban-системы. Теория ограничений говорит: простои сотрудников не ведут к деградации сервиса.

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

Переход к вытягивающей системе выполняется не сразу. WIP-лимиты вводят постепенно, анализируя изменения, к которым их изменение привело для обработки потока задач. И не существует никакой формулы, которая бы позволила вычислить «правильные лимиты» в зависимости от команды: многое зависит именно от конкретного потока задач, а он индивидуален.

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

Если такие ситуации регулярно возникают и являются типичными, то команда превращается в «отдел ждунов», и это сигнал ситуации, когда никакие внутренние реорганизации не смогут принципиально изменить ситуации. Стоит задуматься о перестройке работы, например, исключении лишних согласований со смежниками или руководством. Сила Kanban-системы в том, что она позволяет увидеть такие ситуации и оценить потери от лишних согласований, а также реальные риски их отсутствия: сколь часто возникают ситуации, когда на согласовании задача была изменена. Алексей Пименов в упомянутом выше докладе рассказывал, что у него было много кейсов, когда согласование занимает 30-50% от времени реализации, и отделу принимать решения без согласования получалось ускорить процесс в полтора раза.

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

Начинать здесь стоит со срочных задач, и не только в буфере, а в целом на обработке, потому что практика показывает, что большое количество срочных задач, которых никто не учитывает, является основной причиной нарушения регулярной работы. Может показаться, что ограничение на срочные задачи – не реалистичное, потому что они часто выполняются по прямому поручениями руководства. Однако, если контролировать их и объяснять, что реально такое количество задач срочно выполнено точно не будет, и надо поставить реальные приоритеты, то получается конструктивный диалог. Практика показывает, что достаточно часто срочность оказывается ситуативной и теряет актуальность, а руководство забывает ее отменить. При этом выполнение в «пожарном режиме» того, что оказалось не нужным является очень сильным демотиватором. Отметим, что выполнение задач, которая стала не актуальной – один из примеров лишней работы, muda в lean.

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

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

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

Во-первых, реальное понимание способов работы встречается редко. Распространены примитивные рецепты, которые хорошо показывает анекдот про консультанта:

– Как сделать, чтобы моя ферма давала больше молока, а расходы на корма уменьшились?
– Очень просто, коров надо чаще доить и реже кормить!

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

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

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

Приведем пример работы с интересной метрикой «дни касания». Мы берем общий срок, когда задача была в работе, и считаем, какой процент из этих дней задачи реально касались, для чего анализируем следы: записи в таск-трекере или изменения в коде, связанные с этой задачей. Естественно ожидать, что в хорошей ситуации над задачей работают ежедневно пока не сделают. Однако, при расчете реальных метрик часто оказывается, что задача очень долго ожидает выполнения в различных внутренних очередях, и коэффициент касания может составлять 50, 30 или даже 10%.

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

Отметим, что часть из перечисленных выше проблем представляют собой примеры тех или иных потерь (waste в Lean) в рабочем процессе, то есть работ, не несущих ценности: согласовать без необходимости, сделать оказавшееся ненужным, переделывать ранее сделанное и так далее. В IT-разработке и в любой другой интеллектуальной работе потери тоже присутствуют, как и в физическом производстве, просто они носят другой характер, поэтому производственный lean напрямую не применим. А задача метрик – наблюдать за ходом процесса и потерями, и служить сигналом, что какие-то из них превысили допустимый объем и требуют устранения.

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

Agile-методы предъявляют к метрикам и их визуализации особые требования: работа с ними перестает быть уделом избранных, а становится предметом заботы всех членов команды. А это означает наглядное представление, позволяющее быстро провести анализ ситуации по графикам, с тем, чтобы возникла эмпатия к графикам, подобная эмпатии к доске. Scrum решил такую задачу в частном случае, там придумали burndown chart.

В Kanban тоже есть несколько хороших визуальных представлений. Одно из них – кумулятивная диаграмма потока, на которой каждый день по вертикали откладывают число задач, находящихся на каждой стадии, как показано на рисунке. В результате по горизонтали мы можем увидеть, сколько времени в среднем занимает каждая фаза и, в том числе выделить непропорционально большие фазы, как это показано на приведенном примере диаграммы, на котором видно, что задачи очень долго отлеживаются на согласовании у CEO. Пример взят из уже упоминавшегося выше доклада Алексея Пименова на AgileDays-2019 «Скрытая механика работы Kanban Method».

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

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

Как известно, в Scrum со спринтом связан ряд встреч: daily scrum, планирование, демо, ретро, а помимо них есть и другие встречи, такие как story mapping для планирования релизов. Все они обеспечивают синхронизацию процесса и взаимодействие со стейкхолдерами. Как легко догадаться, эти функции являются необходимыми для организации потока создания ценности и должны быть выполнены при любом способе организации процесса. В Kanban для выполнения этих функций используются каденции – регулярные встречи, каждая из которых посвящена определенному вопросу и имеет свой собственный ритм, зависящий от соответствующего потока работы.

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

1. Статус-митинг, как правило, ежедневный для обсуждения текущих задач и решений по заблокированным задачам.
2. Пополнение списка задач – обсуждение, какие именно задачи сейчас являются наиболее приоритетны и должны быть включены в работу. Обычно раз в 1-2 недели.
3. Планирование поставки – представление сделанного и передача результата клиентам.
4. Обзор качества сервиса и способов его улучшения.
5. Операционная встреча по качеству взаимодействия со смежниками.
6. Обзор рисков, связанных с блокировками выполнения задач и их влиянием на работу сервиса.
7. Обзор и обновление стратегии.
   

Заметим, что все они в том или ином виде есть в Sсrum, только привязаны к спринту, за исключением последней.

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

Таким образом, к описанному выше списку стоит относиться, скорее, как к списку важных фокусов, которые, как показывает опыт, стоит держать под контролем тем или иным образом. При этом, что важно, каждый из фокусов надо держать отдельно, и потому смешивать их на одной встрече не слишком желательно, даже если состав участников совпадает. Дэвид Андерсон в своей книге показывает, как эти механизмы возникали в его командах по мере эволюционного развития процесса, и как менялась их форма. Делать это в форме отдельных серий встреч – самый простой способ, но вовсе не обязательный. И в любом случае, встречи появляются постепенно, при чем порядок тоже может быть различен. Подробнее об этом узнать в докладе Алексея Пименова на AgileDays-2018 «Канбан! Что новенького?» В отличие от его доклада на AgileDays-2019, на который я ссылался в начале статьи, этот дает обзор новых техник и рассчитан на более глубокий уровень слушателя.

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

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

Отметим, что при масштабировании Kanban-системы на компанию в целом или на автономные бизнес-единицы помимо метрик, показывающих прохождение потока задач становятся актуальными метрики, показывающие финансовые результаты деятельности. Естественным желанием является взять готовую систему стандартных финансовых метрик. Засада в том, что не всякая система метрик является совместимой с теорией ограничений, которая лежит в основе Kanban. Это подробно разобрано в книге Томаса Корбета «Учёт прохода. Управленческий учет по теории ограничений» (оригинал «Throughput accounting», есть конспект). И может получиться, что оптимизация потока оценивается метриками и KPI негативно. Эту опасность необходимо представлять, и выбирать метрики правильно.

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

На этом я заканчиваю свой рассказ про Kanban. Он получился очень длинным, и, возможно, стоило поделить эту статью на две, как вы думаете?

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