Портал №1 по управлению цифровыми
и информационными технологиями

Один за всех: когда гиперактивность вредна

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

Обычно остальным членам команды это нравится. Да, есть немножко хаоса, зато часть работы делают за них – приятно же!

Но не всегда. Бывает, что пользы от “бегунка” меньше, чем вреда. В каких случаях это происходит?

Приведу в качестве иллюстрации мою любимую спортивную игру – волейбол. Недавно мне посчастливилось играть в неё дважды в день по два часа почти две недели подряд (отпуск): как вы понимаете, наблюдения свежие, и их много.

Вот собралась команда, ранее не игравшая вместе. Уровень у всех разный: у большинства игроков весьма средненький, у пары человек, скажем так, приличный. Один из “приличных” начинает принимать все мячи, сам себе передаёт пасы, сам атакует, сам ставит блок – активничает изо всех сил. Проигрывать-то нельзя, а остальные не тянут! Приходится выручать. Через несколько игр становится понятно, что такой стиль игры команду к победе приближает не сильно. Поле чуть больше, чем возможности одного, даже очень сильного игрока. Остальные не только не помогают, но и совершенно не понимают что от них требуется, а потому по большей части стоят и ждут, когда “передовик” набегается.

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

Второй пример приведу также из волейбола, но уже не пляжно-отпускного, а нашего, в который мы играем в Cleverics. Мы делаем это каждую неделю, и первые разы несколько месяцев назад были особенно весёлыми: многие из нас не то что играть не могли, а иногда и мяча боялись. Он же летит. Может задеть. Вдруг не увернусь? Что тогда делать? Руки жалко, ногами бить не разрешают. Естественным образом появилась задача: подтянуть уровень тех, кто с игрой не очень знаком, чтобы им было интересно и полезно. Если кто-то из опытных будет делать работу за новичков, то новички никогда ничему не научатся.

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

Третий пример мне подсказала игра “2020 – организационные изменения“, в которой я принимал участие в прошлую пятницу. Игра построена на довольно сложных механиках и взаимодействиях. Исполнителю каждой роли нужно разобраться с собственной предметной областью, чтобы выполнять свою работу хорошо; я же был на роли одного из руководителей. Мне важно было понимать в целом что как устроено, но было не обязательно вникать в тонкости каждой роли. Таких руководителей было трое, и нам повезло, что никто из них не вмешивался в оперативную работу остальных участников – хаоса и замедления тогда было бы не избежать. Более того, нам действительно повезло с командой: мы все были из разных компаний (Росбанк, СберТех, КРОК, SAP, ОМК-ИТ…), мы не работали ранее вместе, но в игре как-то вполне естественно каждый стал заниматься своим делом. Это позволило добиться неплохих результатов, и даже модель Джона Коттера рассмотреть и обсудить. Можете мне поверить, я провёл не один десяток деловых игр – такое бывает довольно редко. Намного чаще встречается обратная проблема, когда в команде есть один очень болеющий за дело участник, готовый любому объяснить что и как нужно делать.

Выделим третью ситуацию про вред гиперактивности – когда работа участников довольно сложна/специфична/своеобразна, и неподготовленный “передовик” только замедлит/ухудшит/разрушит её.

Вот те три ситуации, которые я могу выделить. Наверняка в вашей практике встречались и другие – какие? Насколько они вредны? Всегда ли?

И как со всем этим бороться?

 

Профессиональные деловые игры
для ИТ-департаментов и ИТ-компаний

Комментариев: 3

  • Rafhat Osmonov

    У нас на 1 линии поддержки есть внутренний рейтинг, регулярно подводятся итоги по количеству обработанных и т.д. запросов. Так вот в рейтинге явным образом лидировали 1-2 сотрудника, причем с явным отрывом от остальных. Это стало сказываться на скорости и качестве обработки запросов в моменты отсутствия лидеров.

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

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

    • Интересная практика, спасибо.

      У меня был похожий случай, но с другой концовкой – один из инженеров поддержки явно выбивался в лидеры по числу выполненных заявок, с сильным отрывом. Посмотрели внимательно что за заявки он себе берёт (у нас можно было самому забирать работу из общего пула), и выяснили, что это сплошь простые и быстрые обращения. Обсудили, пожурили, объяснили остальным, немного поправили KPI. Продолжили работать.

  • Мне кажется, очень часто бывает смесь этих ситуаций.

    А вообще забавно. Я по рекомендации Романа читаю вот эту книжку (кстати, она очень интересная). И вот недавно добрался до момента, когда главному герою предложено справиться с ситуацией, которая напоминает №1 и №2.


Добавить комментарий для Олег СкрынникОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM