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