Развитие команды по Модели Такмана: что нужно знать менеджеру проекта​

Руслан Шапиев, куратор курса по P3.express, рассказал, как команда проекта ведёт себя на разных этапах роста — и как проджекту на каждом этапе распределять ответственность, решать конфликты и не допускать выгорания сотрудников.

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

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

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

Расскажу о модели Такмана, которую я регулярно использую в работе.

Психолог Брюс Такман в 1965 году в статье «Последовательность развития в малых группах» предложил модель развития команды.

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

На каждой из этих стадий — свои уникальные вызовы и задачи, которые нужно преодолеть. Рассмотрим особенности каждой.

Задача 1. Прописать инструкции

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

Я готовлю чек-лист на два случая: для адаптации нового человека в команде и для работы над новым продуктом. Вот один из примеров:

Для онбординга прописываю гайд с первичными договорённостями. Если мы работаем над новым продуктом, то я указываю критерии готовности (definition of ready) и критерии завершённости (definition of done) задач.

А также обсуждаю видение и описываю бизнес-кейс (резюме проекта), составляю карту результатов в рамках предпроектного обследования по методологии P3.express.

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

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

Задача 2. Проводить 1-on-1 встречи

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

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

А уже после — через месяц/полтора — проводим 1-on-1.

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

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

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

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

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

Поэтому в процессе работы вы должны обсуждать зоны ответственности участников и фиксировать договорённости, например с помощью матриц RACI и DACI.

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

Чтобы определить, в чём суть столкновений, желательно привлечь третью сторону, например лида, и провести совместную встречу. Важно, чтобы проблемы обсуждались открыто.

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

Люди в команде начинают активно взаимодействовать и сотрудничать по выработанным правилам.

Проджект-менеджер видит эти процессы, и если что-то идёт не так, корректирует их через обсуждение и голосование.

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

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

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

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

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

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

Проджект-менеджеру на этом этапе важно измерять уровень удовлетворённости у всей команды на ретроспективах.

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

Важно: После встреч 1-on-1 и performance review (оценки удовлетворённости на ретро) я записываю ценные для команды поинты в Notion. Так я не упускаю тревожные сигналы в рабочих процессах и могу потом поделиться с участником конструктивной обратной связью. Например, если подмечаю, что он систематически не готовится к дейли, не показывает результаты или заваливает сроки в третий раз. Записи можно использовать и для того, чтобы не забыть похвалить участника команды за его успехи.

Кстати, на тему performance review советую хорошую книгу “High Output Management” Эндрю Грува. Отличное руководство для новичков в менеджменте.

Главное на стадии функционирования — не допускать выгорания, когда люди устают от проекта или продукта. Для этого:

Завершающая стадия: проект подходит к концу, а продукт передаётся другой команде на поддержку.

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

Поэтому я провожу заключительные встречи, где эмоционально поддерживаю команду. А также:

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

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

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

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

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

PMCLUB — онлайн-школа для менеджеров проектов и продуктов. Мы учим грамотно управлять и не срывать дедлайны, оценивать сроки и бюджет и работать с рисками. Подписывайтесь на нас на vc.ru и в Telegram.

#команда #управлениепроектами #projectmanagement