Владимир Бычко об управлении проектами

пиэм разъясняет, предостерегает, рекомендует

Тег: психология

Пять стадий жизненного цикла команды

forming, storming, norming, performing  

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

Изначально модель содержала forming, storming, norming, performing. Через 12 лет её дополнили (при участии Мэри Энн Дженсен) пятой стадией, adjourning. Первая стадия начинается с момента формирования команды, последняя заканчивается успешным завершением проекта и расформированием команды. На мой взгляд, мини-версию этой модели команда также проходит при назначении нового менеджера. 

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

Forming

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

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

Также на постановочных встречах надо проговорить основные пункты регламента работы, структуру управления (если предполагается несколько начальников) и какая нужна отчётность. 

Storming

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

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

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

Norming

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

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

Performing

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

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

Adjourning

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

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

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

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

О профессиональном выгорании

Профессиональное выгорание

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

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

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

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

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

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

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

(далее…)

О том, как не превратить сбор требований в соревнование

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

Вот вы здесь говорите, что должна быть голосовая почта. То есть, в приложении должен быть контакт, позвонив на который вы можете прослушать голосовые сообщения, я правильно понимаю? Ну а здесь по всем канонам юзабилити мы будем размещать кнопку управления группами контактов, не так ли? Здорово, что мы с вами понимаем друг друга. Мне однажды доводилось курировать разработку подобного приложения, там был случай…

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

Как не настроить заказчика против себя при сборе требований? Вести диалог так:

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

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