Как создать команду проекта – личный опыт Максима Якубовича

Создание команды – это, пожалуй, самый сложный навык руководителя проекта. Он формируется годами, и предела совершенству здесь точно нет. К сожалению, даже изучение и использование подходов из психологии не позволяет руководителю быть на 100% уверенным, что из группы специалистов получится сделать команду. В этом и сложность – нет четкого алгоритма, ведущего к желаемому результату. Если сетевой график – это математика, довольно точная и логичная, то формирование команды – больше искусство, чем наука, пишет наш эксперт Максим Якубович.

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

1. Доверие друг другу

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

2. Постоянное изучение производительности и размышление над тем, как еще ее можно улучшить

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

3. Осознание общей ответственности за результат

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

Скажу вам, что все годы, которые я руководил проектами, я мечтал создать команду, которой мог бы гордиться. Предыдущие 4 года я руководил программой проектов по внедрению ERP-системы. Мне повезло в этой программе: я мог самостоятельно подбирать людей в команду, выстраивать процессы разработки, использовать любые инструменты автоматизации этих процессов и поддержки ERP. Это был прекрасный опыт, и я очень ценю его.

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

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

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

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

За 4 года через интервью со мной и техническим лидером прошли десятка четыре человек. Мы подбирали новых программистов, специалиста по базам данных, специалистов поддержки. Я постепенно совершенствовал вопросы интервью, делал их открытыми (не предполагающими ответов «да» или «нет»), чтобы человек рассказывал мне истории, которые бы позволяли больше узнать о его ценностях и мотивации. Скоро я понял, что мои вопросы на интервью должны быть такими, чтобы через ответы на них я мог «прокачать» те компетенции, которые для меня важны на этой позиции. Например, если мне важно, чтобы человек умел работать в команде, я просил его рассказать мне историю о его опыте работы в команде, о том, с какими сложностями он столкнулся, какие вещи его раздражали в командной работе и т.п. Всего в опроснике для интервью было около 20 вопросов, а само интервью с кандидатом занимало около часа.

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

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

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

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

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

Благодаря коллективным KPI в команде удалось добиться ситуации, когда те члены команды, кто успевал сделать свои задачи раньше срока, «перехватывали» задачи у тех, кто не успевал. Это было воистину прекрасно услышать что-то типа: «Коллеги, у меня есть возможность перехватить чью-нибудь задачу трудоемкостью часа на три. У кого что есть?».

Последние несколько месяцев моей работы с этой командой были удивительными: фокус-фактор – 100%, отсутствие ошибок в работающих релизах, максимально возможные премиальные у членов команды.

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

Компания, в которой происходило становление этой команды, называется TELS.

Спасибо вам, ребята, за столь приятные воспоминания и великолепный опыт!