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 и хорошо представляет себе современное развитие метода. Отмечу, что сертификация продвинутых уровней предполагает не просто прохождение курсов и тренингов с проверкой теоретических знаний, а личный опыт практической работы, который проверяется на сертификационном собеседовании – помимо теории ты рассказываешь экспертам-практикам о своих кейсах. Поэтому такой сертификат служит реальным свидетельством квалификации.

Дэвид Андресон. Kanban – альтернативный путь в Agile

Как и большинство 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-системы

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

Kanban-доска. ​Из моих презентаций

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

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

От функций к сервисам

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

Основная идея Kanban – представить компанию в сервисной структуре

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

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

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

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

WIP-лимиты и вытягивание – ограничиваем незавершенную работу

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

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

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

​Из доклада Алексея Пименова «Скрытая механика работы 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-системы компании представляет собой не единственный способ для этого. Продолжение следует...

{ "author_name": "Максим Цепков", "author_type": "self", "tags": [], "comments": 52, "likes": 32, "favorites": 476, "is_advertisement": false, "subsite_label": "hr", "id": 100096, "is_wide": false, "is_ugc": true, "date": "Sun, 05 Jan 2020 11:55:49 +0300", "is_special": false }
0
52 комментария
Популярные
По порядку
Написать комментарий...
1

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

Советую начать с истории Toyota Production System,  ибо основатель Канбана - Таиичи Оно, и система WIP, JIT и т.д. принадлежат его светлому разуму. Создание системы началось в 1959 году и вся компания перешла полностью на Канбан в 1962.

Литература для обучения: "Кайзен" Масааки Има. Ну или википедию русскую почитать.

Ответить
6

Это вы не шарите в теме или невнимательно читаете. Речь идет про Kanban в IT, и это явно оговорено в статье раньше, чем написана фраза про Андерсона. И он является оригинальной конструкцией. Естественно, разработанной не с нуля, а с использованием накопленного человечеством опыта, включая Toyota Production System, которая была одним из источников. Но все это не просто заимствовано, а переосмыслено применительно к IT-разработке, или, если шире - к организации умственного труда, которая принципиально отличается от организации труда физического, которую решает система Тойоты. Об отличиях можно почитать того же Друкера "Менеджмент. Вызовы XXI века", или мою статью "Цифровой мир: от физического труда – к умственному" https://vc.ru/future/94043-cifrovoy-mir-ot-fizicheskogo-truda-k-umstvennomu  И, собственно, поскольку современный мир - эпоха как раз умственного труда, то Kanban и Lean в IT-варианте сейчас представляют гораздо больший интерес, чем система Тойоты.

Ответить

Комментарий удален

0

Я думал, танцы с бунами вокруг канбана и аджайла уже ушли в прошлое, ан нет! Есть еще маньяки. С трудом поднимающие голову из новогоднего оливье - и го на VC, бубнить про кумулятивные каденции масштабирования.

Ответить
0

Что, единственный способ защиты картины мира, в котором Agile нет места - это объявить автора "с трудом поднимающим голову от оливье?" Других аргументов - нет, что ли? А, нет, еще чужие ролики добавлять. Ну, это понятно легко, не то, что свои мысли.

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

Ответить
–1

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

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

Ответить
2

Agile распространяется с каждым годом все шире и принимается как метод управления серьезными компаниями - с его помощью разрабатывают новые материалы (Северсталь) и оружие (концерн Калашникова), работают над проектами атомных станций (Росатом) и коллекциями новой одежды (12Storeez), организуют производство на литейных заводах (Литмашдеталь) и обучают в школах (уже более сотни школ только в Москве), и есть много других кейсов. Для тех, кого это заинтересует - детали можно прочесть в моих отчетах с конференций http://mtsepkov.org/AgileDays-2019 и http://mtsepkov.org/AgileBusiness-2018 и найти записи выступлений.

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

Ответить
–1

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

Ответить
2

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

Ответить
–3

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

И да, высказаться здесь каждый имеет право, по теме топика. Для того и комментарии.

Ответить
1

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

Александр, а что предложить он ничего не может - это понятно. Для предложений надо мыслить. Поэтому и занимается метанием г... В этом он - мастер, опытный г... мет. Скучный и однообразный. 

Ответить
–1

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

Вот например, вместо того чтобы аргументированно доказать силу и полезность своего канбана, ты ввязался в пустые препирательства с оскорблениями. Не стыдно?

Ответить
0

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

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

Ответить
0

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

Ответить
–1

Может предложить что-то сможешь на замену agilе?  Хотя ты кроме ГУЛАГа нечего предложить не сможешь. 

Ответить
0

Ты так и не понял, канадец. Объясняю еще раз, специально для канадцев: я ничего не собираюсь тут предлагать, тем более для управленческого учета, тем более в нерабочие праздничные дни.

Ответить
1

Поэтому я прав. Ты тролль. Люди здесь делятся знаниями и опытом а ты пришёл и всё обосрал, причём совсем не зная темы. 

Ответить
1

Уж кто бы говорил? Не ты ли бегаешь по всем топикам с целью обосрать все российское, не зная темы.

Ответить
0

Не обращайте внимания. Это тролль. Он в любой статье обсирает всё западное.

Ответить
0

Не обращайте внимания. Это тролль. Он в любой статье обсирает все российское.

Ответить
0

Я обсираю аккуратненько царя и его банду. Ну или убогие попытки этого криминального режима выдавать какие-нибудь древние достижения СССР за свои. 

Ответить
0

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

Ответить
1

Наверное более худшая ситуация с коррупцией в России. 

Ответить
1

Канада и ее проблемы меня не будет беспокоить при любом уровне коррупции в России это точно. Вы бы отдохнули  от своей круглосуточной  войны с Россией на VC, мир не идеален (не только на  1/6 части суши) . В Канаде рыбалка должна быть неплохая рекомендую

Ответить
1

А мне не пох. когда русские пенсионеры в нищете живут а больным детям на операцию деньги собирают. А в то же время друзья царя своим любовницам самолёты дарят. 

Трюдо от меня тоже достаётся,  не беспокойтесь. 
Этот тролль сам эту тему поднял. Я на vc больше люблю про технологии спорить а не про убогого царишку возомнившего себя пупом земли. 

Ответить
–1

Сильно комментарии на  VC  помогают пенсионерам, больным детям и  пугают любовниц друзей царя? Вы посмотрите внимательно на ветку к чему там вообще про ГУЛАГ было? 

Ответить
0

Статья была про использование Канбана в IT. Но пришёл тролль и обосрал труд автора и вообще все современные методики. 

Причём обвинил меня в обсирании России только потому что я против криминала. 

Ответить
0

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

Ответить
0

Они в основном чужих диктаторов грабят а не свой народ. 

Ответить
0

Это они-то свой народ не грабят? )) Это ты рассказываешь про страну, где КАЖДЫЙ гражданин обязан жить исключительно в кредит и выплачивать проценты по нему? Банкиры доят американцев по полной программе, хотят они этого или нет. И не упускают случая ограбить своего соседа по Шарику, для этого достаточно объявить его диктатором и сфальсифицировать компромат на него.

Ответить
0

Ключевое слово ЖИТЬ. Да, лучше платить ипотеку и жить в огромном доме с бассейном чем пол жизни ютиться в маленькой съёмной квартирке или жить у родителей копя деньги на покупку своей квартиры. 

Типо Садам был не диктатором а демократом 

Ответить
0

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

 Да в любом случае, не ваше собачье дело, демократ Саддам или не демократ. Лезть со своими пушками в чужую страну никто вам права не давал, даже если там полно нефти, на которую вам вздумалось наложить лапу. Грабеж чистой воды

Ответить
–1

А как же Крым?  Тоже чужая страна была. 

Ответить
0

Что - Крым? Он был изъят без единого выстрела и без капли крови, исключительно цивилизованно, с одобрением большинства жителей полуострова. Исторически это российская территория, Украине его дали подержать временно, так что хватит. Займитесь лучше искуплением своей исторической вины перед американскими индейцами, у которых забрали территории без какого-либо согласия, ценой тысяч трупов - ну, как обычно янки делают.

Ответить
0

Примерно как бандюки телефоны ночью отжимают. Подходят три амбала к дрищу студенту и просят телефон позвонить. Студент "добровольно" отдаёт. 

Ответить
0

Ой, ну не надо )) Щас помру со смеху.  По-твоему, Сочинская олимпиада, космодром Восточный, Керченский мост, ГЛОНАСС, гиперзвуковые ракеты Циркон - древние достижения СССР? 

Ответить
–1

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

Олимпиаду можно было бы в успех записать если бы она не стоила 50 лярдов из которых 40 украли. И если бы не допинговый скандал из-за которого до сих пор русских спортсменов не пускают на другие олимпиады. 
Циркон скорее всего такое же достижение как и истребитель пятого поколения или армата. Сделают в трёх экземплярах чтобы на параде показывать и на телеканале Звезда. А потом всякие лошки будут вестись что Россия вооружена современным оружием.

Ответить
0

Свергун, ты еще будешь отрицать, что бегаешь тут и обсираешь все русское? Ну ты попался с поличным, и далеко не в первый раз.

Керченский мост - вполне уникальный проект, учитывая территориальные особенности, из-за которых даже в СССР не смогли его построить. ГЛОНАСС - тоже достаточно уникален, далеко не каждая старна может себе позволить. Космодром - дикредитирован, верно, но он построен и работает (опять же, не в каждой стране есть). Олимпиада - дорогостоящая, верно, но не сильно дороже аналогичных проектов в других странах, и уж точно не рекордсмен, тем более уже не раз окупилась за счет турпотока и мероприятий типа Формулы-1. Я там отдыхал прошлым летом, понастроили десятки пятизвездочных отелей и сотни 3+ звезд, рестораны, концертные площадки, толпы народа и спортсменов, - отличный ресорт.
В общем Свергун, в твоей канадской глубинке на окраине США никогда таких грандиозных проектов не было и не будет, расслабься и завидуй молча.

Ответить
0

Боже мой.

Керченский мост - вполне уникальный проект.

Ну ну. Я в курсе какой у вас пиар с этим мостом устроили. Даже говно фильм забацали и чуть ли не силой заставляли людей смотреть.
У нас в прошлом году тоже мост построили за 5 лярдов. Один день по новостям показали что открыли, вот и весь пиар. Потому что построить мост это не достижение это рутина для такой огромной страны. 
Олимпиада самая дорогостоящая за всю историю. 50 лярдов. В Канаде зимняя стоила 10. Мало что при строительстве украли кучу денег, так и инфраструктуру построили за бюджетные деньги для своих курортов. И теперь друзья пути рубять бабло а пенсионеры последний х. без соли доедают.
Мне смешно что ты Крым и Сочи ставишь в какие эталоны курортов. У нас вокруг Монреаля (где гор нету, а только холмы) горнолыжных баз под два десятка. С любыми гостиницами, шале и т.д. на любой бюджет. Это не достижения это просто нормальная экономика. 

Ответить
0

Смешной

Ответить
0

А как мне смешно из Канады смотреть на пиар Керченского моста. 

Ответить
0

Во-первых, Житомир это не Канада, Вас обманули

Во-вторых, посмейтесь, смех жизнь продлевает

Ответить
0

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

Ответить
1

у отдела появляется SLA, Service Layer Agreement

Кажется, здесь ошибка. Service-level agreement. 

Ответить
1

Да, увы ошибка, и исправить уже нельзя - прошло время с публикации, когда разрешены исправления. Спасибо, что рассказали.

Ответить
1

Спасибо за статью! Действительно, очень интересно.

Ответить
0

Спасибо!

Ответить

Комментарий удален

0

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

Ответить
1

Пять копеек насчет отличий умственного труда от физического. Есть ещё один способ отличать один труд от другого. Один труд - это труд в Системе основного процесса. Это труд создает ценность для клиента, поэтому процесс - Основной. Этот труд был часто физическим - поднять, принести, отпилить, покрасить. Другой труд - это труд в Управляющей системе, или в Создающей системе. Он является умственным, и раньше был умственным. Таким образом, по форме труд разный (физический и умственный), и по сути тоже разный (Основного процесса, и Управляющий).

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

Ответить
0

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

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

Но спасибо за этот акцент в разделении видов труда, это существенно для рассказа. Я в своей статье "Цифровой мир: от физического труда — к умственному"  https://vc.ru/future/94043 об этом не написал, а зря. 

Ответить
1

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

Ответить
0

Рад оказаться полезным!

Ответить

Комментарии

null