Модель Такмана: четыре стадии развития команды простыми словами

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

Что это

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

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

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

Третья стадия — Norming, нормирование. Конфликты постепенно находят разрешение, команда вырабатывает общие правила игры: как принимаются решения, кто за что отвечает, как договариваются при разногласиях. Люди начинают признавать сильные стороны друг друга, чаще предлагают помощь без просьбы, а споры из личных переходят в рабочие — обсуждается не «кто виноват», а «как сделать лучше». Появляется доверие, и общение внутри команды становится более прямым и менее осторожным, чем на стадии формирования.

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

Зачем это нужно

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

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

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

Как применить

Практическая ценность модели Такмана — в том, что стиль управления стоит менять вместе со стадией, а не держать один и тот же подход весь проект.

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

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

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

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

Частые ошибки

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

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

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

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

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

Частые вопросы

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

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

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

Работает ли модель для удалённых команд? Да, но признаки стадий там менее очевидны: часть сигналов теряется при общении через экран. Шторм в такой команде чаще проявляется не спором на созвоне, а молчанием в чатах и падением вовлечённости, поэтому стоит внимательнее следить за косвенными признаками и чаще инициировать разговоры один на один.

Коротко о главном

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