• Новости
• Блоги
• Аналитика
• Новости компаний
• В СНГ и в мире
• Анонсы

Вы не любите виртуальные команды? Вы просто не умеете их готовить!

Разработка программных продуктов виртуальными командами – это веление времени, от которого никуда не деться. И пусть работа таких команд сопряжена с множеством специфических проблем, их вполне можно и нужно научиться разрешать.

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

Во-первых, это простая неизбежность. Типичные ее примеры:

• заказная разработка для внешнего заказчика: ведь заказчик – это тоже часть команды, создающей продукт;

• физическая невозможность собрать в одном месте необходимое количество специалистов-разработчиков – что типично для нынешней ситуации «кадрового голода»;

• необходимость включить в команду уникального эксперта, проживающего «где-то там»;

• необходимость организовать работу команды в режиме 24x7, что особенно актуально для проектов поддержки;

• необходимость для кого-то из команды на некоторое время «оторваться от коллег» и поработать в офисе заказчика или партнера.

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

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

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

Что такое «виртуальная команда»

Прежде всего определимся с терминологией. Понятие «команда» многими людьми воспринимается скорее как эмоциональное, нежели рациональное. Ассоциативный ряд тут длинный: «слаженная команда», «сплоченная команда», «команда единомышленников», «комфортная социальная группа», «люди, которые всегда поддержат»… Будем считать, что команда – это группа индивидуумов, совместно работающих для достижения общей цели (например, проекта), причем таким образом, что команда в целом достигает большего, чем достиг бы каждый из входящих в нее людей, работая вне ее. Таким образом, ключевой чертой, отличающей команду от рабочей группы и прочих подобных ей «несильных» форм объединения людей, является синергический эффект. По большому счету, именно ради этого эффекта любой грамотный руководитель столько времени и сил тратит на командообразование. А сплоченность, слаженность и тому подобное являются необходимыми, но, увы, отнюдь не достаточными условиями возникновения синергии.

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

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

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

Инфраструктурные проблемы

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

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

Модель централизованного хранилища

У такого хранилища довольно много достоинств. Прежде всего это централизованное управление из одного места, что позволяет достаточно просто решать вопросы безопасности и поддержки работоспособности и при этом не требует наличия на других площадках высококвалифицированного ИТ-персонала. Далее, удается минимизировать затраты на создание и обслуживание проектной инфраструктуры. И наконец, конфликты, возникающие при одновременном изменении одних и тех же данных (например, одного фрагмента исходного кода разрабатываемого продукта) разрешаются по мере выполнения работ, а не откладываются до момента синхронизации. А ведь возникновение таких проблем – не редкость при активной разработке с участием большого количества программистов, и вообще чуть ли не норма жизни в период интенсивного тестирования и исправления обнаруженных ошибок.

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

Интересная вариация на тему централизованного хранилища – работа сотрудников из дома или регионального офиса на виртуальных машинах, т.е. с удаленным доступом к рабочим компьютерам, находящимся в (центральном) офисе. В этом случае локальный компьютер фактически используется как простой терминал (и может иметь весьма умеренные аппаратные характеристики, а из программного обеспечения – только VPN-клиент, ибо программа доступа к удаленному рабочему столу встроена в Windows). Реальную же работу выполняет офисный компьютер или сервер необходимой производительности и нужным образом сконфигурированный. Что же касается централизованного хранилища, то оно располагается тут же, рядом с рабочими компьютерами, в пределах локальной сети с ее практически неограниченной пропускной способностью. Помимо экономии на региональном ИТ-персонале (для нормальной работы необходимо фактически только устойчивое интернет-соединение), сильной стороной этого варианта является очень высокий уровень безопасности. В частности, это относится к нераспространению конфиденциальной информации, поскольку она не выходит за рамки компьютеров, на которых проводится ее обработка. Правда, многие разработчики

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

Модель репликации

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

и наконец, модель репликации, очевидно, неприменима при работе сотрудников из дома.

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

Проблемы коммуникации и рабочего взаимодействия

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

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

Сложность сплочения команды

«Виртуальный тим-билдинг» – известный оксюморон, связанный с виртуальными командами. Пока еще не зарегистрировано ни одного действительно успешного мероприятия такого плана. А естественным путем (чисто в повседневном рабочем взаимодействии) сплоченность команды возникает ох как медленно, особенно на расстоянии!

У виртуальных команд низкая скорость групповой динамики. Общеизвестно, что прежде чем выйти на пик продуктивности (и стать командой в рассмотренном выше смысле), проектная группа должна пройти этапы формирования, притирки и стабилизации. Это непросто и небыстро даже в условиях непосредственного личного взаимодействия членов команды, а что уж говорить о команде виртуальной! Многие из них так и застревают на самом сложном и болезненном этапе притирки, становясь «террариумом единомышленников» (или – другая крайность – кучкой разобщенных и изолированных индивидуалистов).

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

Потеря контекста

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

Возникает ощущение «потерянности и ненужности». Особенно ярко оно проявляется в ситуации «один человек на площадке» (аналогично – при работе из дома), но склонность к этому испытывает большинство малочисленных (1–3 человека) «удаленных» групп.

Замедление реакции

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

Запаздывает обратная связь «через расстояние». Сказывается разница во времени, и неизбежно происходит смещение приоритетов: более приоритетным становится не самое важное для судьбы проекта, а самое близкое, оно же более настойчивое и чреватое – в случае игнорирования – более серьезными проблемами.

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

Изоляция и конкуренция

Задача координации работ и обмена опытом между площадками достаточно сложна. Частым следствием этого является дублирование усилий (выполнение одной проектной работы на нескольких площадках) и появление в системе идентичных по сути, но разных по оформлению и функционированию частей («проще сделать самим, чем выяснять – причем непонятно у кого, – не сделал ли это уже кто-то до нас»). Как результат – изменения в этом функционале придется вносить в каждый вариант реализации, что увеличит трудозатраты на программирование и тестирование и сделает внесение изменений более сложным, длительным и рискованным процессом.

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

Снижение уровня управляемости

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

Удаленное управление развитием сотрудников (наш вариант перевода англоязычного термина people management) не работает. Планирование и мониторинг профессионального и карьерного развития, решение проблем межличностного взаимодействия и в целом измерение «индивидуальной температуры сотрудника при нахождении в рабочей среде» требует плотного личного контакта, к тому же еще и достаточно высокого уровня доверия. И если ради десятка-двух ежегодных аттестаций руководитель может организовать себе командировку в далекий офис, то решать оперативные вопросы в этой сфере приходится издалека, что чрезвычайно сложно.

Все сказанное выше применимо и для проблем передачи обратной связи сотрудникам и приема ее от них.

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

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

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

О том, как «правильно приготовить виртуальную команду» и как разрешать проблемы, если они возникнут, – читайте в следующем номере «ИКС».