Плохая работа команды не лучшим образом отражается на любом ее члене. О том как выяснить, в чем дело, и постараться решить проблемы, на портале The New Stack рассказывает Чарльз Хамбл, бывший инженер-программист, архитектор и технический директор, немало поработавший в качестве старшего руководителя как технологических, так и контентных групп.

Недавно я провел серию бесплатных онлайн-консультаций по наставничеству, и несколько раз прозвучал вопрос: «Что вы делаете как технический директор, когда считаете, что команда не справляется со своими обязанностями?»

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

И эти проблемы с производительностью касаются не только разработчиков. «Мы так часто сталкивались с этим в операционных командах, что создали регулярный процесс для борьбы с этим», — говорит Крис Свон, инженер Atsign и бывший технический директор по доставке DXC Technology.

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

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

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

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

Вот пять практических шагов, которые помогут выяснить, почему команда испытывает трудности.

1. Проверьте данные в поисках подсказок

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

Фурнье рекомендует начинать с гипотезы, как при отладке системы: «Делайте это как можно менее инвазивным способом, чтобы ваше вмешательство не заслонило проблемы».

Мой собственный подход, хотя и схожий с тем, что описан в книге Фурнье, заключается в том, чтобы начать с поиска сигналов в данных и использовать их для выработки первоначальной гипотезы. Я также стараюсь не забывать изречение поэта Уолта Уитмена: «Будь любопытен, но не суди».

Хорошо проверить текучесть кадров — много ли людей уходит из этой конкретной команды по сравнению с остальными ИТ-специалистами? Можете ли вы получить статистику по больничным дням? Если да, то не болеют ли люди чаще, чем в других частях ИТ-отдела?

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

Следующее, что я обычно делаю, — смотрю на календарь. Проводит ли руководитель регулярные встречи один на один? Не тратит ли команда слишком много часов в неделю на совещания?

Затем, что также предложила Фурнье, посмотрите на другие системы учета — журналы чатов, электронные письма, тикеты, обзоры кода и контрольные проверки — и посмотрите, что они вам скажут.

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

2. Определите, почему команда не чувствует себя сильной

Для операционной команды основное внимание будет сосредоточено на журналах управления сервисами. Но, опираясь на теорию ограничений эксперта по управлению бизнесом Элияху М. Голдратта из книги «Цель: процесс непрерывного совершенствования», вышеупомянутый процесс в DXC включает в себя получение всех журналов обслуживания, а затем применение науки о данных для выявления ограничений.

Такая работа «позволяет нам сосредоточиться на том, что наиболее важно в данный момент», — говорит Свон. Устранение ограничений в итоге превращается в итерационный процесс, когда вы устраняете проблему на высшем уровне, а затем проводите повторное измерение: «Мы каждый раз проводим повторные измерения, потому что мы изменяем рабочие характеристики динамичной, адаптивной системы».

По его словам, определенные ограничения возникают регулярно: «Одно из них мы наблюдаем часто — это „пинг-понг“, когда никто не берет на себя ответственность за устранение проблемы, а вместо этого перекладывает ее на кого-то другого».

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

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

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

Решение этой проблемы требует «очень вдумчивого подхода к управлению рисками, который может быть поддержан более совершенными системами, — говорит Свон. — Например, если вы можете предоставить людям возможность „разбить стекло“ при управлении привилегированным доступом, то вы не окажетесь в ситуации, когда сотрудники постоянно имеют доступ к „богоподобным“ учетным данным, но не могут получить их, когда им это нужно».

Еще один распространенный источник проблем — передача полномочий. Всегда полезно максимально сократить количество передаваемых функций и обеспечить их полноту, когда это происходит.

Эта проблема часто возникает в контексте аутсорсинга. Например, если команда системных администраторов работает в компании, а сетевая функция передана на аутсорсинг, «команда системных администраторов будет говорить: „Мы поднимаем тикеты, но ничего не происходит“, а внешняя сетевая команда будет говорить: „Каждый тикет, который мы получаем, не завершен, и поэтому мы не можем принять по нему меры“», — отмечает Свон.

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

3. Ходите, разговаривайте и не смешивайте критику с похвалой

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

Если вы еще не сделали этого и руководитель команды не обратился к вам, поговорите с ним. Если вы работаете в одном месте, может быть, выпейте вместе кофе.

Я регулярно провожу подобные встречи во время прогулок (в том числе удаленно, когда мы оба идем и разговариваем по телефону) и обнаружил, что смена обстановки может быть полезной. Есть данные, что прогулка раскрывает творческий потенциал, но я также считаю ее полезной в ситуациях, когда обсуждение может вызвать стресс.

Будьте прямолинейны и откровенны в этот момент, и, пожалуйста, избегайте смеси критики с похвалой («У вас красивая прическа. Ваша команда не справляется с работой, и я думаю, что это может быть вашей ошибкой. Хорошие туфли»). Это никому не поможет.

Дайте понять, что вы слышали предположения о том, что команда может быть недостаточно эффективной, и что если это так, то вы готовы помочь. Что думают сами менеджеры? И что вы можете сделать, чтобы поддержать их?

4. Используйте встречи один на один с умом

Если вы регулярно проводите встречи один на один «через голову» (а если нет, то я настоятельно рекомендую начать эту практику), это может стать хорошим моментом для проведения такой встречи с одним из членов команды. Попробуйте узнать побольше: может быть, что-то не так?

Чаще всего я сталкиваюсь с тем, что менеджеры не приходят на встречи один на один — как вариант, в последнюю минуту они отправляют прямое сообщение, чтобы отменить встречу. Или не отвечают на сообщения в мессенджере.

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

Другая тактика — посетить собрание команды, но не забывайте, что благодаря вашему присутствию динамика команды изменится. Здесь стоит подумать о том, какова энергетика в комнате? Кажется, что люди вовлечены или апатичны? Кто говорит бóльшую часть времени? Скучно ли сотрудникам? Скучно ли вам?

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

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

Классическим симптомом этого является ситуация, когда говорит только руководитель команды.

Фурнье также предлагает в своей книге спросить у членов команды, какие цели они ставят перед собой: «Что они могут сказать вам об этом? Понимают ли они, почему именно эти цели? Если они не понимают целей своей работы, значит, их лидеры (менеджер, техлид, менеджер продукта) плохо работают над тем, чтобы увлечь команду целью работы».

5. Выясните, чувствуют ли члены команды себя в безопасности

И последнее, на что следует обратить внимание, — это психологическая безопасность команды. «Один из главных вопросов, который я задаю себе, глядя на команду, испытывающую трудности, — „Работают ли эти люди в безопасной среде?“, — говорит Свон. — Это связано с психологической безопасностью — если они совершат ошибку, их будут винить или это станет поводом для обучения?».

Есть и более практический аспект — допустимости совершать ошибки, которые имеют пагубные последствия, но которые можно было бы предотвратить, говорит Свон. В качестве примера он рассказал об использовании магистральной разработки (trunk-based development) без защиты веток (branch protection): «Защита веток — это фундаментальная часть безопасности, но она не применяется по умолчанию. Без нее часы тикают, пока кто-то принудительно не вытолкнет в магистраль то, что не должен».

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