Перевод статьи Kanban Does Not Share Your Agile Cross-Functional Team Agenda от David J Anderson
В ноябре 2013 года сообщество Канбан-коучей выработало 3 ключевых повестки, которые адресованы имплементации Канбана: повестка устойчивости, повестка сервис-ориентации, повестка выживаемости. Первая из этой троицы разделяется гибкими подходами, вторая и третья — являются совершенно уникальными и сосредоточены на улучшении качества предоставляемого сервиса и эволюционных изменениях. Гибкие методологии разработки программного обеспечения имеют чёткую повестку работы кросс-функциональными командами, которую Канбан не разделяет и в которой он не нуждается, чтобы получать серьёзные результаты улучшения рабочих процессов. Канбан — это про визуализацию, повышение прозрачности и понимание того, как вы работаете и уменьшения координационных издержек за счёт использования досок. Визуализируйте, а не реорганизуйте!
Консультанты по гибким методологиям любят много говорить о командах. Я тоже очень много говорил о командах в моей книге о Канбане, и это было моей ошибкой. Я использовал слово «команда» для обозначения «группы людей, работающих совместно, для достижения общей цели». А в гибких подходах команда — это уже организационная единица, которая построена так, чтобы иметь общую цель или предназначение, например разработку программного обеспечения. Консультанты по гибким методологиям обычно реорганизуют вас в «команды», и когда у работы есть вариативность и разнообразие, которые требуют людей с разными навыками, тогда эти команды называют кросс-функциональными командами — командами, содержащими людей, являющихся специалистами разной функциональной направленности. Цель дальнейшего командообразования состоит в том, чтобы в конечном итоге переквалифицировать людей состоящих в команде, чтобы они были универсальными специалистами, которые могут выполнять всё, или чтобы оны были Т-shaped специалистами, т. е. специалистами, которые обладают широким набором навыков на слабом уровне компетентности и высоким уровнем компетенции в своей специализации.
Трюк такого Agile-преобразования заключается в том, что боль реорганизации окупится при старте работ этих новых кросс-функциональных команд, что они достигнут высокой эффективности, устранив задержки в коммуникациях между функциональными подразделениями, и устранив накладные расходы на координацию межфункциональной деятельности. Если в одной организационной единице содержится всё, что вам нужно для производства продукта, вам не придётся беспокоиться о внешних зависимостях. Если эти организационные единицы могут быть небольшими, скажем, по 6 человек, тогда накладные расходы на координацию должны быть минимальными или не существовать вовсе.
И давайте просто скажем, что это работает. Давайте не будем даже оспаривать эту теорию с любыми метриками производительности или наблюдениями о том, что Agile-организации, на самом деле тратят много времени на координацию, определение зависимостей, выявление недостающих навыков и доступности общих ресурсов. Давайте проигнорируем частую нехватку квалифицированных людей, споры, борьбу за идеи и влияние на Agile-собраниях. Давайте проигнорируем всё это и просто предположим, что это работает.
Что я хотел бы, чтобы вы обдумали читая этот пост, так это то, насколько дорого во времени, деньгах, стрессе и тревоге проходит реорганизация в эти кросс-функциональные команды. Я бы хотел сказать, что большая часть боли в Agile-реорганизации и большое количество часов коучинга, необходимых для новых Agile-команд, вызваны стрессом реорганизации в кросс-функциональные команды. Другими словами, одна из причин, по которой Agile стоит так дорого, связана с кросс-функциональной повесткой.
Канбан не разделяет повестку кросс-функциональных команд. Вместо этого Канбан решает эту проблему по-другому. И размещённый выше рисунок объясняет как. Верхняя половина рисунка показывает упрощенную функциональную организационную структуру, разделенную на 8 функциональных подразделений с названиями от A до H. Каждое из этих функциональных подразделений представляет собой группу специалистов с определённым навыком или профессией.
Клиент делает запрос, который предусматривает привлечение 7 из этих подразделений. При Agile-подходе нам надо было бы реорганизовать эти подразделения в команды с представителями всех 7 навыков. Канбан использует другой подход. Канбан — это «начнем с того, что вы делаете сейчас», и это означает, что вы начинаете с организационной структуры, которая у вас сейчас есть. Вместо реорганизации Канбан просит вас смоделировать рабочий процесс для обработки запросов клиентов. Мы будем делать это с использованием инструмента STATIK (системный подход к представлению Канбана), который преподается на двухдневных тренингах Дизайнер Канбан Систем (Kanban Systems Design) аккредитованных Lean Kanban University. Применение STATIK даст нам Канбан-доску, изображенную в нижней части рисунка. Канбан-доска будет «сервис-ориентированной», поскольку на ней моделируется требуемый сервис с точки зрения клиента. Доска позволяет членам из всех 7 команд взаимодействовать для обработки запросов клиента.
Эта доска упрощена для целей демонстрации. В реальной жизни дизайн доски может не иметь соответствия один к одному от функциональной команды к колонке на доске. Некоторые этапы работ могут выполняться параллельно или в неопределённой последовательности. Мы можем спроектировать доску и тикеты (элементы идущие по доске) так, что этапы работ отражались не колонками на доске, а чекбоксами на тикетах. Существует много тонкостей, и большинство этих тонкостей охвачены обучающими программами. Квалифицированный Канбан-коуч может помочь с дизайном и моделированием содержимого доски и тикета.
В Канбане мы тоже пользуемся термином «команда» и я в своей книге дал ей определение: «группа людей, работающая совместно, чтобы достичь общей цели». Общая цель — удовлетворить запрос клиента. Это цель ориентированная на сервис. Дизайн доски и дизайн тикета обеспечивают визуализацию и понимание цели. У нас есть много примеров, которые показывают, что этот подход работает. Многие Канбан-практики сообщают о повышении уровня сотрудничества (коллаборации) в своих компаниях и что это было достигнуто без болезненной реорганизации или выделения какой-либо новой роли, ответственности или должности. Канбан улучшает сотрудничество посредством визуализации, ориентированной на клиента, и создает общие цели для динамически сформированных групп людей, привлечённых из разных функциональных подразделений. При правильном дизайне доски он работает для разделяемых ресурсов, разделяемых служб, групп разделенных по функциональному признаку и, конечно же, всегда будет работать для существующих кросс-функциональных команд.
Результаты от использования Канбана впечатляют с самого начала. В 2005 году первая Канбан-система охватывала три функциональных подразделения и обеспечила рост производительности на 230%, на 90% сократилось время выполнения запросов, с 0% до 98% улучшилась предсказуемость. И эти цифры теперь являются обыденностью. Чаще сообщается о 400%. Были даже цифры в 800%. Сокращение времени производства в 50% — 90% — это обыденность. Все это достигается без болезненной реорганизации в кросс-функциональные команды; без болезненных Agile-преобразований; без затрат на Agile-преобразования и затрат на Agile-коучинг.
Таким образом, даже если кросс-функциональные команды действительно значительно сокращают накладные расходы на управление, и даже если это делает их «потрясающими» и «гиперпродуктивными», и, откровенно говоря это ещё вопрос для обсуждения и исследования, но давайте представим, что всё это правда. Учитывая всё это, вам не кажется, что быстрее, проще, дешевле и лучше сделать прирост производительности на 200−800% и сократить на 50−90% время производства начав с того, что есть у вас сейчас и выполнив канбанизацию? Визуализируйте, а не реорганизуйте!
