Никаких сюрпризов! Про развитие сотрудничества в команде

Сотрудничество — одна из базовых ценностей канбан метода*, позволяющая стимулировать изменения и указывающая на то, что ситуация улучшается. О том, как развить и углублять эту ценность в команде, в своей книге «Канбан метод. Улучшение в системе управления» («Альпина Паблишер») рассказывает Майк Барроуз. Делимся отрывком в тему.

*Канбан — метод управления процессами, реализующий принцип «точно в срок» и способствующий равномерному распределению нагрузки между сотрудниками


На мой взгляд, очень полезно думать о сотрудничестве, как о чем-то четко определенном, вспоминая широко известные примеры. Джон Леннон и Пол Маккартни, Фрэнсис Крик и Джеймс Уотсон, Мари и Пьер Кюри — их сотрудничество оставило глубокий след не только в областях их деятельности, но и в памяти поколений. Это не просто приятные люди, сотрудничавшие друг с другом в общем смысле.

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

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


Улучшайтесь совместно

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

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

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

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


Поощрение сотрудничества

Я неоднократно был свидетелем того, как проводимые в разной форме экспертные проверки работы коллег приносили сильное разочарование. В банке UBS мы очень гордились качеством программирования, и ревью кода (своего рода экспертная оценка) проводился с двумя целями: «повышение» качества и распространение опыта. С этой точки зрения подобная практика оказалась очень успешной.

Тем не менее мы столкнулись с проблемой. Ревью могло застопориться на несколько дней (иногда даже дольше) в ожидании, пока назначенный старший разработчик найдет время для проведения этого ревью. Такие эксперты могут проводить по несколько ревью одновременно, «поскольку это более эффективно». Иногда в результате ревью приходилось вносить в программу большие изменения, что приводило к дополнительным затратам и дальнейшим задержкам. Многочисленные задержки и переделки — вот что вызывает настоящую головную боль!

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

Возможно, это звучит банально, но психологический сдвиг был огромным. Прежде бремя получения оценки программы у эксперта лежало на разработчиках. Другими словами, экспертная оценка являлась для них препятствием. Теперь, с появлением неофициального руководящего принципа «никаких сюрпризов», выполняющего роль политики открытости, обе стороны почувствовали взаимную ответственность за обеспечение непрерывности потока работы. <…>


Сосредоточьтесь на сотрудничестве

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

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

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

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

Другие хорошие статьи