Как управлять гибридными командами: семь инструментов из практики

Фото: Robert Schlesinger / Global Look Press

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

Формулируем задачи

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

• Сделать из сотрудников разных компаний единую сборную. Люди должны чувствовать, что работают в одной команде, и понимать общую цель, к которой они идут.
• Синхронизировать работу — процессы, коммуникации, работу над задачами. Важно наладить горизонтальные связи внутри команды — должно быть беспрепятственное общение людей друг с другом.
• Выйти на максимально возможный уровень производительности команды. Это уже как результат двух предыдущих задач.

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

Выбираем инструменты и грамотно их используем

Задачи ясны. Остается продумать оптимальные пути их решения. Расскажу о семи инструментах, которые вы можете применять в зависимости от ситуации.

1. Доверить управление тимлиду.

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

2. Выстроить внутренние процессы

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

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

3. Сделать все мероприятия общими

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

Для одного из проектов, в котором участвовали наши разработчики, заказчик собрал команду, включающую больше 20 человек. Управлять таким числом людей трудно, поэтому их разделили по функциональным задачам на две группы, работающие в тесном контакте друг с другом. На всех обсуждениях, организуемых одной группой, как правило, присутствовала и вторая. Таким образом все узнавали о новом функционале еще до того, как он появлялся. Более того, некоторые технические решения принимались исходя из пожеланий соседней группы, которые, к слову, всегда звучали по-дружески: «Вы можете сделать так или так, но нам будет проще интегрироваться через такое вот решение».

4. Объединить всех сотрудников общей целью

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

Если вы достигаете 100% своих целей, вы поставили их неправильно

Образование

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

5. Привлекать сторонних экспертов в случае нехватки компетенций

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

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

6. Собирать обратную связь

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

7. Контролировать соблюдение комплаенса

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

Как инструменты работают на практике

В заключение приведу пример того, как мы применяли все описанные выше инструменты на проекте, в котором участвовали в качестве подрядчиков. Банк запускал масштабный проект по реорганизации кредитных процедур. Бэклог проекта (список всех требований, задач, функций, которые могут быть необходимы для разработки продукта) был огромный, а сроки амбициозные. Требовалось усилить команды специалистами подрядчиков и максимально быстро выстроить их работу внутри. Со стороны банка были только представители бизнес-подразделений (методологи, бизнес-аналитики, владельцы продуктов), концептуальные архитекторы и IТ-лидеры департаментов.

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

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

Следующим шагом стала формулировка общих целей — глобальных (на год и квартал) и локальных (на две и четыре недели). Фиксация задач и сроков помогли ребятам в режиме открытого диалога договариваться о том, как удобнее работать — на какие этапы оптимальнее разделить разработку каждой функциональности, чтобы максимально быстро и качественно выйти в продакшен. Участники команды также договорились, что перед тем, как брать в разработку новую функциональность, станут встречаться с методологом, который будет простыми словами объяснять, что она даст конечному пользователю. Эти обсуждения стали регулярными и позволили сблизить IТ и бизнес: технические специалисты понимали суть продукта.

Инструкция по Scrum: правила, события, команда

Образование

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

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

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