В ноябре 2013 года сообщество Канбан-коучей выработало 3 ключевых повестки, которые адресованы имплементации Канбана: повестка устойчивости, повестка сервис-ориентации, повестка выживаемости. Первая из этой троицы разделяется гибкими подходами, вторая и третья — являются совершенно уникальными и сосредоточены на улучшении качества предоставляемого сервиса и эволюционных изменениях. Гибкие методологии разработки программного обеспечения имеют чёткую повестку работы кросс-функциональными командами, которую Канбан не разделяет и в которой он не нуждается, чтобы получать серьёзные результаты улучшения рабочих процессов. Канбан — это про визуализацию, повышение прозрачности и понимание того, как вы работаете и уменьшения координационных издержек за счёт использования досок. Визуализируйте, а не реорганизуйте!
Консультанты по гибким методологиям любят много говорить о командах. Я тоже очень много говорил о командах в моей книге о Канбане, и это было моей ошибкой. Я использовал слово «команда» для обозначения «группы людей, работающих совместно, для достижения общей цели». А в гибких подходах команда — это уже организационная единица, которая построена так, чтобы иметь общую цель или предназначение, например разработку программного обеспечения. Консультанты по гибким методологиям обычно реорганизуют вас в «команды», и когда у работы есть вариативность и разнообразие, которые требуют людей с разными навыками, тогда эти команды называют кросс-функциональными командами — командами, содержащими людей, являющихся специалистами разной функциональной направленности. Цель дальнейшего командообразования состоит в том, чтобы в конечном итоге переквалифицировать людей состоящих в команде, чтобы они были универсальными специалистами, которые могут выполнять всё, или чтобы оны были Т-shaped специалистами, т. е. специалистами, которые обладают широким набором навыков на слабом уровне компетентности и высоким уровнем компетенции в своей специализации.
Трюк такого Agile-преобразования заключается в том, что боль реорганизации окупится при старте работ этих новых кросс-функциональных команд, что они достигнут высокой эффективности, устранив задержки в коммуникациях между функциональными подразделениями, и устранив накладные расходы на координацию межфункциональной деятельности. Если в одной организационной единице содержится всё, что вам нужно для производства продукта, вам не придётся беспокоиться о внешних зависимостях. Если эти организационные единицы могут быть небольшими, скажем, по 6 человек, тогда накладные расходы на координацию должны быть минимальными или не существовать вовсе.
И давайте просто скажем, что это работает. Давайте не будем даже оспаривать эту теорию с любыми метриками производительности или наблюдениями о том, что Agile-организации, на самом деле тратят много времени на координацию, определение зависимостей, выявление недостающих навыков и доступности общих ресурсов. Давайте проигнорируем частую нехватку квалифицированных людей, споры, борьбу за идеи и влияние на Agile-собраниях. Давайте проигнорируем всё это и просто предположим, что это работает.
Что я хотел бы, чтобы вы обдумали читая этот пост, так это то, насколько дорого во времени, деньгах, стрессе и тревоге проходит реорганизация в эти кросс-функциональные команды. Я бы хотел сказать, что большая часть боли в Agile-реорганизации и большое количество часов коучинга, необходимых для новых Agile-команд, вызваны стрессом реорганизации в кросс-функциональные команды. Другими словами, одна из причин, по которой Agile стоит так дорого, связана с кросс-функциональной повесткой.