Виртуальные команды разработки

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

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

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

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

Глобально рассредоточенные команды

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

Обычно на виртуальные команды смотрят как на команды вообще (с точки зрения социологии) или команды в контексте информационных систем, состоящие из специалистов по маркетингу, пользователей и хозяев проекта, менеджеров, ответственных за составление требований, специалистов по техническому обслуживанию и разработчиков ПО. В 2004 году исследовательская группа Энн Пауэлл опубликовала исчерпывающий обзор положения дел с виртуальными командами, опирающимися на информационные системы. Авторы отмечают, что обычно в исследованиях не определяются типы проектов, подходящих для виртуальных команд; не устанавливается оптимальная численность и круг навыков участников виртуальных команд, занимающихся проектами различных типов; не конкретизируются типичные характеристики виртуальных команд и оптимальная структура коллективов (самоорганизующихся и управляемых), а также роль руководства. Более того, отмечается, что больше 90% исследовательских публикаций основывались на студенческих проектах, заведомо осуществляемых в контролируемых средах. Десять лет спустя все эти вопросы остались актуальны, особенно по отношению к виртуальным командам разработки ПО.

Экспертные мнения

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

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

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

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

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

— Самир Динс, ThoughtWorks

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

Реальна ли польза от виртуальных команд?

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

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

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

— Ларс-Ола Дамм, Ericsson

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

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

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

Условность преимущества виртуальных команд

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

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

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

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

— Марко Нок, Knorr-Bremse Systeme

***

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

Литература

R. Sangwan, N. Mullick, and D.J. Paulish. Global Software Development Handbook, Auerbach Publishers, 2006.
D. Parnas. Agile Methods and GSD: The Wrong Solution to an Old but Real Problem. Comm. ACM, vol. 49, no. 10, 2006, P. 26–34.
O Conchuir et al. Global Software Development: Where Are the Benefits? Comm. ACM, vol. 52, no. 8, 2009, P. 127–131.

Дарья Шмите (darja.smite@bth.se) — доцент, Политехнический институт Блекинге (Швеция); Марко Курманн (kuhrmann@mmmi.sdu.dk) — доцент, Университет Южной Дании; Патрик Кейль (patrick.keil@keil-ktm.com) — управляющий директор, компания Keil KTM (Германия).