Никаких сюрпризов! Про развитие сотрудничества в команде
Сотрудничество — одна из базовых ценностей канбан метода*, позволяющая стимулировать изменения и указывающая на то, что ситуация улучшается. О том, как развить и углублять эту ценность в команде, в своей книге «Канбан метод. Улучшение в системе управления» («Альпина Паблишер») рассказывает Майк Барроуз. Делимся отрывком в тему.
*Канбан — метод управления процессами, реализующий принцип «точно в срок» и способствующий равномерному распределению нагрузки между сотрудниками
На мой взгляд, очень полезно думать о сотрудничестве, как о чем-то четко определенном, вспоминая широко известные примеры. Джон Леннон и Пол Маккартни, Фрэнсис Крик и Джеймс Уотсон, Мари и Пьер Кюри — их сотрудничество оставило глубокий след не только в областях их деятельности, но и в памяти поколений. Это не просто приятные люди, сотрудничавшие друг с другом в общем смысле.
Здесь мы видим отношения, в которых целое значительно больше, чем сумма отдельных частей, где творческая энергия бьет ключом не только в творческом союзе, но и в каждом участнике процесса.
Мы не можем ожидать, что сотрудничество работников будет таким же поразительно плодотворным, как в приведенных примерах. Но если наши интеллектуальные организации не могут генерировать больше идей по сравнению с обычными людьми, то для чего они существуют?
Улучшайтесь совместно
Точно так же, как любая эффективная организация предполагает сотрудничество при создании товаров и услуг, наше правило «улучшайтесь совместно» подразумевает направление части творческой энергии сотрудничества на усовершенствование базовой системы исполнения заказов.
Это позволяет по-новому взглянуть на некоторые аспекты прозрачности, о которой мы говорили в главе 1. В циклах обратной связи должно участвовать множество людей. Когда команды самоорганизуются, усовершенствования и нововведения появляются в результате сотрудничества, которое, по большей части, возникает вполне естественно и вовлекает соответствующие группы людей.
В том, что мы говорим о необходимости работы над развитием и углублением сотрудничества, нет никакого противоречия. Создание атмосферы непрерывного самоорганизующегося совершенствования обычно требует времени. Иногда руководители надеются, что добиться цели можно простым объявлением о введении неких мер. Почти всегда их ждет разочарование. Возможно, вы уже видели это: пара совещаний, несколько усовершенствований, а затем все сходит на нет, как только становится ясно, что это не считается «настоящей работой». Когда просьба раздается в следующий раз, у циничных сотрудников она вряд ли вызывает интерес.
В главе 6 мы поговорим о роли лидерства в развитии таких организационных возможностей. А сейчас давайте рассмотрим конкретный пример процесса изменения, в основе которого лежит сотрудничество.
Поощрение сотрудничества
Я неоднократно был свидетелем того, как проводимые в разной форме экспертные проверки работы коллег приносили сильное разочарование. В банке UBS мы очень гордились качеством программирования, и ревью кода (своего рода экспертная оценка) проводился с двумя целями: «повышение» качества и распространение опыта. С этой точки зрения подобная практика оказалась очень успешной.
Тем не менее мы столкнулись с проблемой. Ревью могло застопориться на несколько дней (иногда даже дольше) в ожидании, пока назначенный старший разработчик найдет время для проведения этого ревью. Такие эксперты могут проводить по несколько ревью одновременно, «поскольку это более эффективно». Иногда в результате ревью приходилось вносить в программу большие изменения, что приводило к дополнительным затратам и дальнейшим задержкам. Многочисленные задержки и переделки — вот что вызывает настоящую головную боль!
В чем мы видим решение? В сотрудничестве! В данном случае процесс, который поддерживали наши инструментальные средства, не требовал существенных изменений. Было достаточно нашего согласия с тем, что задержки и переделки будут расцениваться как свидетельство отсутствия эффективного сотрудничества разработчиков и экспертов в процессе работы над программой.
Возможно, это звучит банально, но психологический сдвиг был огромным. Прежде бремя получения оценки программы у эксперта лежало на разработчиках. Другими словами, экспертная оценка являлась для них препятствием. Теперь, с появлением неофициального руководящего принципа «никаких сюрпризов», выполняющего роль политики открытости, обе стороны почувствовали взаимную ответственность за обеспечение непрерывности потока работы.
Сосредоточьтесь на сотрудничестве
Урок, который можно вынести из последнего примера, достаточно прост. Он состоит в том, что проведение ревью кода может быть проблематичным, — я сталкивался с этим достаточно и могу сказать, что это общая тенденция. Однако есть и более глубокий урок — полезно пристальнее взглянуть на качество взаимодействий в процессе, а не только на их количество и последовательность.
Это не просто метод, который надо применять в контексте конкретной возможности добиться того или иного улучшения, а самостоятельная стратегия. Посмотрите на качество взаимодействий, происходящих вокруг вас. Видите ли вы основные процессы, которые замедляются из-за низкокачественных взаимодействий, задержек, пустых перепалок, доработок, переделок и разочарований? Если с ними все более или менее в порядке, то видите ли вы людей и команды, у которых, на ваш взгляд, редко появляется возможность начать настоящее сотрудничество? Найдите их, и, возможно, это послужит импульсом для нового, особенного процесса.
Не жалейте времени и сил на приобретение навыков и изучения методов сотрудничества. Приверженцы аджайл-подходов заслуживают глубокой благодарности за то, что сделали сотрудничество приоритетом.
Таким образом, когда вы в следующий раз столкнетесь с ошибкой сотрудника или сбоем процесса, задайтесь вопросом, можно ли это объяснить неэффективным сотрудничеством. Превратите лозунг «Руководители не любят сюрпризы!» во что-нибудь позитивное, научившись задавать этот вопрос автоматически.