Что меняется в компании, когда она начинает использовать Kanban? А может, Scrum подойдет больше? Об отличиях этих инструментов в интервью Николаю Борисову , руководителю направления Дирекции по процессам Альфа-Банка в специальной серии про Agile рассказал Алексей Пименов , управляющий партнер ScrumTrek.

Что такое Kanban? Часть 3

Текстовая версия видеоматериала:

Николай Борисов, руководитель направления Дирекции по процессам Альфа-Банк:

- Как Kanban с уровня какой-то команды масштабируется на организацию? Как это происходит и что при этом меняется внутри компании?

Алексей Пименов, управляющий партнер ScrumTrek:

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

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

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

- Набор досок каких-то, получается?

- Не столько набор досок – набор сервисов и уровней управления, можно так сказать. То есть, допустим, у нас может быть Kanban-система, на которой портфель проектов. То есть у нас у каждого проекта есть определенный жизненный цикл, он движется по нему. Жизненный цикл может не существовать, быть запутанным, логистика его непонятна. Но мы это визуализируем, и каждый проект – это, соответственно, листочек на доске программы проектов. А на уровне исполнителей, на уровне команд (не важно, команда эта была какая-то монофункциональная – программисты или бухгалтеры, либо кросс-функциональная, как в Scrum) этот листочек распадается на кучу-кучу разных заданий. Что нужно сделать для того, чтобы успешно выполнить этот проект? То есть каждый листочек описывается.

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

- Алексей, что выбрать, как понять, какой инструмент использовать – Scrum или Kanban?

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

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

- Scrum внутри Kanban.

- Да, такой Scrum внутри Kanban. То есть он вообще возможен, подобная деятельность возможна. Чаще всего Kanban – это все-таки на уровень выше, то есть как этим всем управлять. Scrum – это больше про инновационные проекты. Но, если помните, у нас есть так называемая Run-активность, и есть Change-активность. Run – это когда мы занимаемся операционной деятельностью, Change-активность – это когда мы что-то пытаемся менять, и причем форму мы можем не знать. Если применительно какой-нибудь HR-активности, активности, которая связана с персоналом у нас, у нас есть какие-то процессы, которые очевидны, понятны и прописаны – допустим, кадровый учет.

- Подбор, адаптация?

- Подбор, адаптация – я бы еще подумал. Но вот кадровый учет, то есть оформление всяких ДМС, ОМС и тому подобное. Допустим, подбор, адаптация тоже может быть прописанным процессом, но здесь может возникать определенный ряд инициатив. Допустим, мы хотим сделать какой-то внутренний электронный продукт для улучшения внутреннего HR-бренда. Или мы захотим этот процесс подбора, адаптации поменять… Вот сейчас он у нас занимает в среднем два месяца, а мы хотим подбирать кадры за полторы недели.

- Так. И тогда что?

- Вот для этого чаще всего используется Scrum. А вот для управления этим используется Kanban.

Еще такая штука. Ты помнишь, что в Scrum мы чаще всего выбираем людей на стопроцентную занятость. Там есть такая идеология, как метафора «куриц и свиней». Мы берем в команду «свиней».

Так вот, а что же делать, если нам, допустим, для реализации нашего проекта нужен юрист, а он у нас в организации один? Мы его не можем в Scrum-команду в одну или, тем более, в две разделить. Получается такая штука, что у нас есть юридическая служба – внутренний сервис, к которой каждая из Scrum-команд предъявляет свои требования, как и когда им нужен юрист на определенную деятельность. И мы можем как бы вот эту юридическую службу описать Kanban-системой и сделать ее такой, чтобы она соответствовала потребностям этих Scrum-команд.

- Сделать ее эффективной, чтобы она более эффективно оказывала некий сервис?

- Да, да.

- Когда мы начинаем использовать Kanban, что внутри компании меняется с точки зрения сервиса – того, что мы делаем внутри компании?

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

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

Допустим, мы сейчас не рассматриваем, что Scrum-команда у нас будет на всю цепочку создания ценности. Просто захотел кто-то внедрить Scrum в команде маркетологов. Насколько это надо? А дальше надо смотреть, а кто после маркетологов и с чем из маркетинговых продуктов работает? Работают там какие-то люди, которые создают потом что-то, что на рынке продается? Либо это был рекламный маркетинг, а там дальше реализаторы, кто делает видеоролики, организуют мероприятия? Сколько они могут этих видеороликов сделать, сколько мероприятий? Из этого у нас предъявляются определенные требования: «Коллеги, а не надо нам столько генерить замечательных идей» или «Давайте вы будете генерить эти идеи, но мы придумаем механизм, как мы будем из этих идей – 200 идей, 300 идей в месяц – отбирать золото, которое может принести нам большинство денег». Весь Kanban – это про нахождение, про балансировку этого всего дела внутри, про то, как это дело должно улучшаться в организации в рамках идеологии Fitness For Purpose.

- Первое, что он повышает – это предсказуемость, как ты сказал. И дальше уже, в связи с тем, что мы понимаем, что улучшить, мы уже сами находим, на скорость мы работаем, на качество мы работаем либо на увеличение дохода?

- Да, какие требования к нам предъявляются.

- Если предположим, что нас заинтересовал Kanban, мы его «купили», выбрали для себя, с чего начать? Куда двигаться для того, чтобы использовать этот инструмент?

- Самый первый вопрос. Давайте немножко расскажу. Если мы вдруг хотим в организации сделать какую-то новую Kanban-систему управляемую, то для этого есть четкий алгоритм, как это создается. Это некоторое ноу-хау Lean Kanban University – он называется STATIK. Расшифровывается это как подход к системному мышлению для того, чтобы представить в вашей организации Kanban – System Thinking Approach To Introducing Kanban.

У него есть ряд шагов, и первым из этих шагов является «А что ты хочешь от этой системы?» То есть что для тебя будет являться предназначением системы, и кем ты сейчас являешься? Это выясняется в ходе этих шагов. То есть что ты хочешь, почему тебе это надо, что сейчас является источником неудовлетворенности, какие есть проблемы, какая на этот твой создаваемый сервис есть нагрузка? То есть сколько заявок сейчас ссыпается на бедных юристов? Какая текущая пропускная способность? Какие там могут быть скрытые классы обслуживания?

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

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

- Хорошо.

- Спасибо большое!

- Спасибо!

При использовании материала гиперссылка на соответствующую страницу портала HR-tv.ru обязательна

0


Похожие видео

Рекомендуемые материалы