Доверяй и структурируй: 5 принципов управления смешанной командой

Разработка сложных ИТ-продуктов часто не обходится без привлечения подрядчиков и временных сотрудников. Как при этом отслеживать все процессы и сохранять ощущение единой команды — рассказывает руководитель проектов компании Rubytech  Дмитрий Денисов.

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

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

#1. Единая цель

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

Такой подход поможет легко справляться с классическими конфликтами, а точнее — не допускать их. Например, во многих командах существует некоторое недоверие  программистов к тестировщикам (и наоборот). Иногда по итогам тестирования новых функций разработчики выражают недовольство тем, что тестировщик недостаточно хорошо понял замысел «фичи», а значит, не слишком качественно проверил её и не  отловил все «баги».

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

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

Видение конечного результата придает смысл каждому действию. В коллективе, объединенном общей целью, нет понятия «моя» и «не моя» зона ответственности. Если мы побеждаем, то всей командой. Если лажаем, то тоже всей командой.

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

#2. Доверие

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

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

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

#3. Безопасность

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

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

#4. Общие ценности

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

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

Наши ключевые ценности

Мы — команда

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

Мы поддерживаем открытость и сотрудничество

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

Мы отвечаем за результат или «пацан сказал (пообещал) — пацан сделал».

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

Мы проактивны

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

Мы стремимся к большему и лучшему

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

#5. Структурность

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

Что касается инструментов для коммуникации и постановки задач, мы для себя сформировали набор из Slack, Jira, Confluence, Gitlab, TestRail и других знакомых многим сервисов и ресурсов. Какую именно систему для постановки задач вы выберете — не так уж важно. Главное, чтобы процессы были прозрачными для всех участников команды.

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