Модель Белбина для IT: сила и слабость разных команд

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

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

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

Сегодня мы публикуем расшифровку доклада, посвященного модели команд по Белбину, с которым Максим выступил на конференции TeamLead Conf 2020.

Что предлагает Рэймонд Мередит Белбин

Исследование Белбина

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

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

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

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



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

Содержание модели Белбина

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

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



Реймонд протестировал людей на эти роли, после чего смог описать:

• Конфигурации ролей для сильных и слабых команд;
• Рекомендации по формированию сильной команды;
• Способы компенсировать конкретные слабости команды.

Позднее Rob Thomsett, американский исследователь, адаптировал модель Белбина для IT — на него ссылается Эдвард Йордан в своей книге «Смертельный марш». В книге, кстати, есть список из 20 причин провальных IT-проектов.

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

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

Проблемы команды

Много идей и разговоров, но работа движется слабо

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

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

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

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

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

Нет идей, ступор при проблемах и затруднениях

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

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

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

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

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

Бесконечные споры между конкурирующими идеями

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

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

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

Реализация сложных идей не продвигает к результату

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

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

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

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

Паралич принятия решений

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

Примеры:

• Способ реализации непонятной задачи: «Давайте еще поисследуем». Мы посмотрели три фреймворка и нужно делать выбор. Но у каждого есть свои плюсы и минусы. Что же делать? Давайте еще поисследуем.
• Определение исполнителя для задачи с неясными перспективами решения. Есть противная задача: написать сложную алгоритмику системы скидок или комиссий, которую придумали маркетологи. Но никому не хочется этим заниматься.
• Релиз с дефектами. При выпуске релиза определили список дефектов. И дальше релиз либо нужно выпускать в таком виде, считая, что дефекты не так страшны (ведь пользователи ждут функционал), либо отсрочить выпуск релиза. Лучше всего сразу принять решение. Но бывают ситуации, в которых наступает паралич — кажется, что дефекты магическим образом исправятся за последние два дня, оставшиеся до даты выхода

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

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

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

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

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

Слишком уверенный лидер

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

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

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

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

Непродуктивная команда звезд

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

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

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

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

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

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

Некому завершать работу

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

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

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

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

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

Нет сотрудничества

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

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

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

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

Одинаковые слабости у всех членов команды

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

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

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

Человек и команда

Человек в команде

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

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

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

Достоинства и недостатки

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

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

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

Зрелость команды

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

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

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

• Те, кто не осознавал и/или не признавал недостатков. Например, опытные и сложившиеся менеджеры, которые пришли повышать свою квалификацию, не понимали про какие-то роли и их недостатки. О каких недостатках речь? Мы такими компаниями и командами руководили! Уж как-нибудь без этих особо умных обойдемся!
• Фаталисты, которые не стремились исправиться. Они узнали о ролях и решили для себя — о, мы слабая команда, мы идем к проигрышу. И не предпринимали ничего, чтобы это исправить.
• Зрелость в осознании себя внутри команды и знание роли, а также когда ваша самооценка, имидж и факты совпадают, приводят к зрелости как себя, так и команды.

Формирование команды

Пригодность и приемлемость

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

• Пригодные и приемлемые — им работа скучна, это просто ступенька карьеры.
• Приемлемые и непригодные развиваются, и им интересно работать в команде.
• Неприемлемые, но пригодные — проблемные. Работу делают, но в команде из-за них возникают трения.

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



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

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

• Нужны идеи, исполнители и организаторы.
• Нужен хотя бы один (а лучше несколько) Работников компании и желателен один Педант.
• На несколько ключевых ролей (ядро команды) выбирайте профессионалов (пригодных по знаниям и навыкам) и у которых нет резких конфликтов по ролям. Они обеспечат выполнение работы.
• Дополняйте команду пусть и не столь выдающимися специалистами, но приемлемыми по командному профилю. Даже если они имеют формально недостаточный уровень по знаниям и навыкам, они будут расти и эффективно работать.
• При включении новых людей в сложившуюся команду приемлемость критичнее, чем знания и навыки. Если новый сотрудник подходит по своей роли, это снизит шторминг после его появления в команде.
• Командный дух не обеспечивает успеха, а конфликт между Шейперами и Генераторами не стоит решать при помощи их примирения — его надо делать конструктивным.
• Однородные команды слабы и часто выбирают себе подобных.
• Обязанности следует делить с учетом профессионализма и (обязательно!) ролей участников команды.

Состав сбалансированной команды:

• Руководитель – Координатор, умеющий работать с талантливыми, но зачастую трудными участниками;
• Один сильный Генератор;

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

• умный Генератор;
• еще один умный не-Генератор, который ему оппонирует;
• умный Координатор;
• остальные – чуть ниже среднего уровня.

Размер команды

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

• Ни 5, ни 7 человек не проигрывают и не выигрывают;
• 8 человек могут быть успешны, но возрастает нагрузка на руководителя, а также требования к нему;
• 4 человека могут быть успешны, если представлены все роли. Но в этом случае у команды нет резерва;
• В команде от 10 человек неизбежно появляется ядро из 2-4 человек, принимающих решения и люди без включения в него.

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

Команды-победительницы:

• Смешанные сбалансированные команды, где представлены все роли.
• Однородные команды из стабильных экстравертов. В IT это редкость, но все же такие встречаются. Эти команды хорошо работают за счет сотрудничества, так как им нравится трудиться вместе. Роли в таких командах могут быть не выделены, но сотрудничество помогает преодолеть проблемы. Правда, они так же весело могут пойти на дно.
• Команды, во главе которых суперзвезда: если стратегия лидера верна, команда движется к победе, если нет — к поражению. И то, и другое будет стремительным.
• Команды типа «Аполлон» (команды звезд): острый ум, ресурсы и таланты, но и большие сложности в их применении. Ключ к успеху — хороший Координатор. Для сложных проектов такие команды особенно хороши, но нужно внимательно выбирать руководителя проекта.

Заключение

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

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

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

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

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

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

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