В шапке
Создание команды проекта – больше искусство, чем наука

Создание команды проекта – больше искусство, чем наука

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

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

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

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

Скажу вам, что все последние 10 лет, которые я руководил проектами (а их было 19), я мечтал создать команду, которой я мог бы гордиться. В последние 4 года я руководил программой проектов по внедрению ERP-системы в транспортно-экспедиторской компании. В рамках этой программы были проекты по разработке модулей системы, внедрению этих модулей и разворачиванию процессов поддержки внедренных модулей ERP.

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

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

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

Первого программиста в команду мне порекомендовал ИТ-директор компании, в которой делалась программа проектов. Так как оценить технический бэкграунд программиста я не мог, мне пришлось просто поверить его рекомендациям. Но для принятия окончательного решения мне хотелось узнать его психологические особенности, чтобы понять, насколько комфортно нам будет работать вместе. Состоялось интервью, мы присмотрелись друг к другу, я задал тогда еще не структурированные вопросы и понял, что шансы сработаться у нас велики. Я понимаю, что это было скорее интуитивное решение, чем основанное на фактах. Но мне повезло. Программист он оказался очень даже квалифицированный, и выстроить доверительные отношения с ним удалось. Второго программиста мы уже подбирали вместе. Теперь мне было легче – технический бэкграунд мог проверить мой технический лидер, а «прокачать» на личностные качества мог я. Опять же мне повезло, потому что второго программиста пригласил технический лидер, который работал с ним в проекте и хорошо знал его. Я доверился его экспертному мнению и даже не стал устраивать интервью с глазу на глаз – хватило пары бесед по телефону. Надо сказать, что подбор первых двух людей был чистым везением, но в проектах без удачи – никак.

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

За 4 года команда выросла до восьми человек. За это время нас покинуло три человека, вместо которых мы подбирали других людей. Один из ушедших был тем первым программистом, который стал моим техническим лидером. Это был первый серьезный стресс, связанный с командой проекта. Я принял решение быстро – предложил его место самому структурированному человеку из программистов и начал выстраивать с ним доверительные отношения. Одно из правил, которому я следовал: быть искренним и честным с каждым членом команды. Через полгода после смены технического лидера я понял, что новый технический лидер – это моя опора и правая рука. Вместе с ним мы подбирали новых программистов, специалиста по базам данных, специалистов поддержки. Он отвечал за проверку технического бэкграунда, а я – за проверку личностных качеств, хотя он всегда присутствовал при интервью и высказывал свое мнение по кандидату. Решение о найме мы принимали коллективно.

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

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

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

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

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

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

Вместе с этой командой мы внедрили у себя scrum, а оценку производительности делали по командному фокус-фактору. Интересные наблюдения: при появлении нового члена команды его личный фокус-фактор первые 3-4 месяца «плавал» на уровне 40-50%, а потом, благодаря формированию навыков оценки объемов работ и использованию коллективной оценки (да-да, через покерное планирование), он поднимался до 100%. 

Естественно, обсуждение фокус-фактора и способов его улучшения входило в повестку большинства наших совещаний по улучшению процессов (ретроспектив). 

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

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

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

Спасибо вам, ребята, за столь приятные воспоминания и великолепный опыт! Я надеюсь, если вы прочтете эту заметку, вы себя в ней узнаете)

До связи в эфире, коллеги!

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

 

Комментарии (0)
Войти как