Используем модель Белбина для определения силы и слабости команды

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

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

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

О ролевой модели команд Рэймонда Белбина на конференции TeamLead Conf 2020 выступил Максим Цепков — IT-архитектор и бизнес-аналитик, навигатор и эксперт по миру Agile, работающий с самыми разнообразными системами — от бирюзовых организаций до Спиральной динамики. О моделях Белбина Максим рассказывает часто (смотрите семинар, доклад на SPMconf и на COMAQA, а также статью о ролях). Сегодня мы публикуем расшифровку этого доклада, посвященного модели команд по Рэймонду Белбину.

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

Эту модель он встроил в полугодовой курс повышения квалификации менеджеров (английский аналог МВА) в виде игры-имитация по развитию бизнеса в условиях неопределенности в коммуникации с окружением, куда приходили повышать квалификацию реальные менеджеры, развивающие. На входе они проходили тестирование, а Белбин не просто на выходе объяснял успех или неудачу каждого проекта — он предсказывал это перед стартом.

Рэймонд Белбин выявил 9 командных ролей, а так же то, что мы обычно выбираем для себя 1-3 роли. Еще он доказал что между командным духом и успехом команды нет статистической корреляции. Потому что он наблюдал и победившие, и проигравшие команды с сильным командным духом. И такие же оба типа команд, но вдрызг разругавшихся.

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

Читать их стоит именно в таком порядке. Половина контекста там перекрывается, но они про разное: первая больше про историю исследований, вторая — про подбор и формирование команды. Также на официальном сайте belbin.com есть много материалов для тех, кто заинтересуется темой всерьез, включая научные исследования применения модели. Многие из тех, кто практикует эту систему, являются научными сотрудниками и выступают на ежегодных профессиональных конференциях.

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

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

Сегодня я расскажу про проблемы команды, а по мере рассказа покажу роли, которые описал Белбин.

Вроде бы внутри команды все готовы к работе. Но все время что-то мешает, и есть куча недоделанных вещей. Например, все спроектировали и пишут код, но при этом Continuous Integration и контроль версий не работает. То, что из коробки есть — сделали, а то, где надо докрутить — почему-то не доделывается.

Диагноз: в команде нет людей на две роли исполнителя:

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

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

Лечение: фокус на результате. Если такая ситуация возникает, а Работника в команде нет, нужен фокус на результате, особенно в серых зонах ответственности. Лучше всего организовать этот момент отдельно. И конечно, идеальный вариант — найти Работника компании при формировании команды, и тогда этот фокус он организует сам.

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

Диагноз: не хватает ролей, приносящих новые идеи. За них отвечают две роли – Генератор и Исследователь ресурсов, и они совсем разные:

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

Исследователь ресурсов (Resource Investigator) не генерит идеи. Но он много читает, активно общается и приносит новые идеи из внешнего мира: новые технологии, которые хорошо бы применить и т.д. Он загорается ими и видит самореализацию в их адаптации и воплощении.

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

Бывает и противоположная ситуация, когда существуют бесконечные споры между конкурирующими идеями. Например, как сделать общение фронтенда с бэкендом по разным паттернам. Или как использовать промежуточные транспортные Java-объекты: какими способами, какие нужны фреймворки и паттерны, использовать ли отдельно для каждого класса фабрику для порождения объектов или нет, и т.д.

Диагноз: в команде несколько конкурирующих Генераторов или Исследователей ресурсов, конкурирующих за реализацию своих идей. Два Генератора в команде — такая же плохая идея, как и ни одного.

Лечение: развести Генераторов по зонам ответственности, или переключить одного из них в альтернативную роль, если она есть. Например, в одном из проектов я был Генератором и придумывал новые идеи. Но руководитель проекта тоже видел свою реализацию в придумывании новых идей. Я это засек и начал ему оппонировать без выдвижения своих идей, переключившись на роль Аналитика-стратега (которая тоже у меня есть). И это сработало.

Бывает и так, что идеи есть, но они сложные. В этом случае команда либо не движется к результату, либо останавливается где-то на полпути. Это случается, когда есть мощный генератор, придумывающий новые сложные фреймворки и идеи, и которые сразу идут в реализацию. Но потом выясняется, например, что декларативное описание форм, которое он придумал, 100% проблем не решает, и даже 50% решает с трудом. Он его усложняет, но все кейсы и особые случаи все равно не натягиваются, и начинается ступор.

Диагноз: идеи от Генератора принимаются без критики, потому что у него нет достойного оппонента или не получается обсуждение.

Лечение: организовать обсуждение и защиту идей до их реализации, а лучше заранее найти Аналитика-стратега для оппонирования. Здорово, если есть человек, который будет оппонировать идеям в самом начале. Но для этого он должен иметь вес в глазах Генератора.

Основная задача Аналитика-стратега (Monitor Evaluator) — оценивать идеи и варианты, искать истину и синтезировать сложное решение с учетом всех нюансов. Если его в команде нет, ревью постановок и обсуждения нужно специально фасилитировать, потому что Генераторы харизматичны, но обидчивы.

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

Примеры:

Диагноз: нет руководителей — Координатора или Шейпера.

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

Координатор (Coordinator) организует совместную работу, используя сильные стороны сотрудников и давая им возможность проявиться, но при этом принимает взвешенные ключевые решения. Координатор и работает на команду, и руководит. Он старается, чтобы люди проявляли свои способности. Выслушивает других, но при этом умеет принять адекватное решение: «Я вас услышал и решил, что здесь так… потому что сроки».

Шейпер (Shaper) — это более традиционный харизматичный руководитель, который активно и жестко ведет команду к принятым целям по выбранному им пути: «Идем туда!»

Лечение: внешнее руководство в точках принятия решений. Когда этот процесс налажен, неожиданностей почти не бывает. И команда может работать без этих двух ролей, если будет фокус внимания извне. Но такой прием работает, если в работе команды мало точек неопределенности, и принимать решения нужно редко, а не каждый день.

Противоположная ситуация.

Диагноз: у руководителя-Шейпера нет уважаемого им оппонента (Координатора или Аналитика-стратега) для обсуждения решений. Это обратная сторона Шейпера — без оппонента он ведет команду к поражению, а не к победе, но при этом уверен в правильности своих действий. Как и Генератору, оппонент нужен ему для обсуждения решений.

Может показаться, что если Шейпер часто ведет команду не туда, было бы лучше доверить руководство Координатору — с точки зрения демократичного mindset и с учетом самореализации всех членов команды это более привлекательная конструкция. Но исследования Белбина показали, что команды, руководимые Шейперами, столь же успешны, как те, во главе которых стоит Координатор — энергия Шейпера заряжает и позволяет жестче двигаться к цели.

Лечение: создать внешние механизмы обратной связи для проверки курса движения команд, если нельзя найти оппонента в команде — чтобы у Шейпера были оппоненты для проверки курса движения. Если вы знаете, что у команды харизматичный лидер и есть опасность, что он заведет не туда, то периодически его решения нужно проверять. Причем у Шейпера в этом месте слепая зона — он не может сам оценить выбранный им курс. Хотя со временем он может прокачаться и оценивать свою работу адекватно.

Симптомы: выдающиеся члены команды с высокой самооценкой не могут работать вместе и каждый тянет в свою сторону.

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

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

Лечение: Команде звезд нужен опытный руководитель-координатор, принимающий решения, потому что «кто-то должен быть арбитром». Успешность команды звезд была одной из первых гипотез Белбина, которую он проверил. Когда Белбин собрал лучших людей в команду, все сказали: «О, мы знаем, кто выиграет в этом соревновании!». А команда неожиданно пришла к финишу последней, раздираемая внутренними противоречиями.

В такой команде существует парадокс: обычно руководитель команды умнее среднего участника, но не обязательно самый-самый (а вообще лучший вариант, если умнее других будет Генератор — его задача подавать классные идеи, и пусть он не отвлекается на повседневное руководство). Но для команды звезд нужно, чтобы руководитель был глупее среднего уровня. Тогда звезды объединяются и сотрудничают между собой, чтобы донести до этого глупого руководителя свои гениальные идеи.

Реймонд Белбин это проиллюстрировал историей про американский атомный проект, где командой ученых руководил генерал. Все ученые его дружно ненавидели за невысокие, по их меркам, умственные способности. Но при этом он уверенно и успешно руководил проектом.

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

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

Педант (Completer Finisher) доводит дело до конца. Перфекционист, для которого главное — качество и детали, а сроки могут подождать. Но без него оставшиеся 20% проекта никому не интересны.

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

Лечение: чек-листы и административный контроль за реальным завершением задач не нужны, когда педант есть в команде. Увы, в IT педантов мало.

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

Диагноз: нет человека, который бы заботился о взаимоотношениях и сглаживал острые углы, это «слепая зона» у руководителя. Оказывается, это отдельная роль. Это не Координатор, и тем более не Шейпер, то есть роль не должна быть руководящей.

Душа команды (Team Worker) ненавязчиво налаживает отношения в команде, сглаживает углы и не участвует явно в управлении.

Лечение: найти человека с эмпатией, который будет заботиться о взаимоотношениях. Руководителю объяснить, что важно не только производство, но и эмоциональные отношения. Необходимо показать ему на примерах, почему это важно, а не бесполезная трата времени. К тому же люди обычно оценивают коллег из своей роли — если роль несвойственна и непонятна, они искренне не видят, чем занят другой.

Симптомы: команда повторяет ошибки, а в некоторых ситуациях даже «впадает в ступор» и не может двигаться.

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

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

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

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

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

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

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

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

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

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

Проигравшие команды же разделились на две категории:

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

При составлении команд имеют значение как профессиональные знания и навыки (Белбин это называет пригодность), так и приемлемость по командному профилю (роли):

Непригодных и неприемлемых надо уволить из команды — в другой команде они могут подойти по профилю и проявить свои сильные стороны.

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

Ключевые моменты при формировании команды:

При этом хорошим будем следующее распределение умственных способностей:

Эксперименты Белбина показали, что оптимальный размер команды — 5-7 человек. Целевым было шесть, но выяснилось:

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

Вы познакомились с теорией. Как ее можно применить в повседневной жизни? Во-первых, вы можете проверить свои роли в команде (пройдя тест) и осознать свои сильные и старые стороны. И далее можете использовать это для собственной работы, выборе своего места или проекта.

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

В-третьих, полезно учитывать личные качества людей, их командные роли при формировании новых команд. Конечно, при нынешнем дефиците IT-специалистов формирование идеальных сбалансированных команд — недопустимая роскошь. Но и формирование заведомо слабых команд, которые провалят проект, потому что там нет ни одного способного породить новые идеи (а для проекта это критически важно), или нет человека, ориентированного на завершение проекта, а не на вечное продолжение — тоже не очень хорошая идея. В любом случае, эта теория поможет компенсировать недостатки. Так же как в случае, если команда получается конфликтной — знать об этом заранее лучше, чем выяснить в процессе.

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

А тем временем конференция TeamLead 2020 переносится на 25-26 февраля 2021 года. Наш опыт в онлайне показал, что это лучше чем ничего, но этого недостаточно. Мы приходим на конференции за общением, решениями, знакомствами, новыми идеями и обсуждениями. А работа с людьми, управление, софт-скиллы тем более очень сильно зависит от нюансов, поэтому личное общение здесь крайне важно.

Из-за ситуации с Covid cо всей болью, разочарованием и грустью мы приняли решение о переносе конференции. Но сформированная программа конференции не меняется, билеты автоматически будут перенесены, проживание в гостинице (если бронировали через нас) будет автоматически перенесено на новые даты.

По любым вопросам пишите на organization@ontico.ru, всё разрулим и всё решим.