Всего лишь десять лет назад число организаций, вовлеченных в глобальную разработку программного обеспечения, было весьма невелико, но ситуация меняется очень быстро. Сейчас уже более 200 компаний из списка Fortune 500 пользуются услугами офшорного аутсорсинга [1]. Судя по результатам недавнего опроса представителей крупнейших американских корпораций, в среднем объем работ, связанных с ИТ и выполняемых в рамках аутсорсинга, но проводимых на территории США, составляет 6,5% [2]. В то же время в Голландии около 250 фирм самого разного размера прибегают к тому или иному виду офшорной деятельности [3].

Рис. 1. Партнеры, расположенные в различных временных зонах

Свыше 50 стран уже принимают участие в международной разработке программного обеспечения. В Индии 800 фирм предлагают свои услуги на международном рынке [3]. Многие американские компании радикальным образом меняют свою стратегию разработки ПО, передавая основные операции в офшорные зоны. Крупнейшие центры разработки начинают появляться не только в традиционных регионах, но и в Ирландии, Сингапуре, Финляндии и многих других странах. Рынок реагирует на рост спроса на ИТ-специалистов, появляются новые бизнес-механизмы. Организации наподобие ITsquare.com и IT-radar.com служат своего рода посредниками между поставщиками услуг в области ИТ, с одной стороны, и небольшими и средними предприятиями, которым требуются такие услуги, с другой.

Существует две важнейшие, стратегические причины перехода на офшорную разработку ПО: экономическая выгода и наличие кадров. Более того, радикальное переосмысление самого понятия предприятия предполагает глобализацию разработки. Экономика, основанная на снижении операционных расходов, исходит из того, что если дешевле осуществлять операции внутри организации, то организация эта должна стать крупнее [4]. Теперь, когда есть возможность более эффективно координировать работу даже на больших расстояниях, организации либо остаются небольшими по размеру, либо становятся специализированными и часть операций переносят вовне (в частности, это касается продаж, распространения, производства, управления информационными системами, юридических вопросов, оплаты и т.д.). Рост объемов контрактного производства — еще одно проявление этой тенденции [5]. Если 25 лет назад 20% американцев работали в компаниях из списка Fortune 500, сейчас этот показатель составляет всего 10%, продолжая снижаться.

Проблемы расстояния

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

Координация — это действия, направленные на интеграцию каждой задачи с каждым подразделением организации с тем, чтобы подразделение могло вносить свой вклад в достижение общей цели. Эти действия обычно требуют интенсивного и непрерывного общения. Контроль — процесс, обеспечивающий выполнение задач, правил и стандартов или поддержку уровня качества. Контроль может быть формальным (например, обеспечение выполнения бюджета или сроков) или неформальным (давление со стороны коллег). Очевидно, что координация и контроль практически неотделимы друг от друга. Коммуникации — фактор, затрагивающий и координацию, и контроль, который предусматривает обмен полной и недвусмысленной информацией, т. е. таким образом, чтобы отправитель и получатель смогли найти взаимопонимание [6].

Рис. 2. Влияние расстояния

Расстояние усугубляет возникающие при координации и контроле проблемы напрямую или косвенно, за счет ограничений, которые оно накладывает на коммуникации. Жирными стрелками на рис. 2 показаны основные трудности глобальной разработки.

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

Тактика 1: сокращение интенсивности совместной работы

Известна так называемая функция зрелости глобальной разработки ПО, которая отражает рост с течением времени от низких к более высоким уровням квалифицированной работы. На рис. 3 показана типичная функция зрелости [7]. При описании передачи задач между двумя фирмами, обычно вовлеченными в глобальную разработку, мы используем термины «Центр» и «Иностранный партнер». Центр — это, обычно, (хотя и не всегда) организация в Северной Америке, в Западной Европе или в Японии. Иностранный партнер может находиться также в одном их этих регионов или в развивающемся государстве. Иного рода сотрудничество, главным образом в области исследований и разработок, может охватывать сеть национальных офисов.

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

Рис. 3. Усложнение задач разработки ПО

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

Верхняя часть рис. 4 характеризуется очень плотной координацией, которая необходима для передачи знаний и совместной работы над задачами. В такой среде два или более подразделений совместно выполняют один и тот же проект. В предельном случае это реализуется при подходе, получившем название «вслед-за-солнцем» (follow-the-sun), при котором работа передается из офиса в офис в течение суток. Например, когда разработчики в Калифорнии заканчивают решение задачи, определенной им на день, они передают результаты (например, код) коллегам в Индии, которые вскоре должны появиться в офисе. В свою очередь, в конце рабочего дня индийские разработчики передают результаты обратно в Калифорнию. Сложность координации высока, потому что ежедневно каждая из сторон должна оформить свои результаты таким образом, чтобы другая сторона могла сразу продолжить работу, причем без дополнительных пояснений. В некоторой окрестности этого экстремума сложности координации расположено все многообразие видов деятельности по исследованиям и разработке, поскольку такие проекты, как правило, не структурированы [8].

Рис. 4. Альтернативные способы сокращения интенсивности совместной работы

Стремясь снизить сложность координации, многие организации движутся в одном из двух направлений (на рис. 4 они показаны стрелками) — вдоль графика либо налево, либо направо. В обоих случаях сложность координации остается относительно низкой. Ключевое различие связано с тем, какой объем задач в течение жизненного цикла продуктов выполняет Иностранный партнер. Следование левой стрелке (такая тактика характерна для крупной корпорации) часто выражается в передаче партнерам работ по сопровождению, службы Help Desk и центров обработки данных.

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

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

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

Тактика 2: сокращение культурных различий

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

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

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

Рис. 5. Систематика структурных связей при разработке программного обеспечения

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

Основных типов организационной структуры при работе с Иностранными партнером пять, однако зачастую многонациональные корпорации используют их комбинацию. Для компании, чье положение отражает верхний правый квадрант рис. 4, возможны три структуры. Во-первых, подразделение за рубежом — типично для внутреннего ИТ-отдела многонациональной корпорации. Во-вторых, купленная иностранная фирма — типично для технологической или программной компании. Например, в 1999 году европейские компании приобрели 229 американских технологических фирм, а американские — 405 европейских [9]. Разработчики в этих фирмах затем были вынуждены налаживать совместную работу. В-третьих, центр офшорной разработки — как правило, создается «с нуля».

В правом нижнем квадранте представлены две распространенные структуры. Иностранная фирма, выполняющая аутсорсинг или работу по контракту, может быть индийской Tata Consultancy Services, мексиканской Dextra Technologies или пакистанской Askari Information Systems — мы упомянули только три из нескольких тысяч таких фирм. Совместное предприятие или альянс с иностранной фирмой — вот структура, в рамках которой участники команды разработчиков из Центра и Иностранного партнера работают совместно. Это типичная организация работы в технологических компаниях, создающих кардинально новый продукт или расширения для уже существующей системы.

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

Культурный буфер

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

Многие из крупнейших индийских компаний (например, Tata Consultancy Services) теперь широко представлены в американских корпорациях, еще больше увеличивая культурный буфер и сокращая культурные различия. При использовании концептуально аналогичного подхода крупные американские компании, предлагающие ИТ-услуги, такие как EDS, выделяют специалистов для ИТ-аутсорсинга в офисах заказчиков, где те выступают в роли своеобразного связующего звена между американским заказчиком и группой специалистов, работающих в офшоре.

Интернационализация

Некоторые американские и европейские компании, главным образом технологические, открывают за рубежом собственные центры разработки программ. Это можно наблюдать как на примере крупных международных корпораций, так и небольших компаний. Например, в тех случаях, когда Internet-компании приобретают небольшие индийские фирмы для поддержки своих внутренних нужд. Некоторые подразделения создаются «с нуля», а другие — за счет покупки компании или переориентации уже имеющихся отделов, ранее выполнявших иные функции. Благодаря интернационализации глобальной разработки программного обеспечения и развитию сотрудничества с внешними Иностранными партнерами (фирмы, специализирующиеся на аутсорсинге, подрядчики или СП), компании сокращают культурные различия. Это отражено стрелкой «Внутреннее подразделение за рубежом» на рис. 5, предполагающей сокращение различий в организационной культуре. Когда сотрудники работают внутри фирмы, организационные различия, проявляющиеся в сложности координации и диссонансе между культурами, уменьшаются. В этом случае ИТ-специалисты находятся в корпоративной сети, с внутренней стороны межсетевого экрана, получая доступ ко всем базам данных, календарям, Web-страницам и т.д., изучая корпоративную методологию, правила и системы.

Менеджер по объединению культур

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

репатрианты или много путешествовавшие специалисты, поддерживающие идею глобальной разработки. Например, ирландец по рождению, проживающий в США, может выступать в роли посредника в офшорной фирме в Ирландии. По данным [9], 47% международных программных команд имеют в своем составе человека, выполняющего функции посредника между культурами.

Язык

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

Тактика 3: сокращение различий во времени

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

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

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

Работа в различных часовых поясах требует эффективных синхронных коммуникаций. Цель состоит в том, чтобы минимизировать различие временных зон, в лучшем случае до нуля (иногда рабочее время в двух офисах различается часов на восемь, а то и больше). Рис. 1 показывает типичные случаи работы партнеров в различных часовых поясах. Для фирм, расположенных на восточном побережье США, в область «минимальной временной дистанции» попадают Канада, Мексика и страны Карибского бассейна. Фактически, мексиканские и карибские провайдеры сами рекламируют себя как near shore, т. е. «ближнее зарубежье» (в противоположность офшору). Возможности синхронной работы с Латинской Америкой тоже достаточно велики. Что же касается Европы, то «минимальная временная дистанция» предполагает сотрудничество либо внутри Евросоюза, либо с африканскими государствами, либо с такими странами, как Румыния, Венгрия, Россия и Украина. Японские фирмы могут работать «синхронно» с Сингапуром, Китаем, Филиппинами и Индией. Еще один пример — Израиль, который, наравне с наиболее развитыми странами, испытывает нехватку квалифицированных программистских кадров. Одна из крупнейших местных программных компаний — Amdocs, открыла центр офшорной разработки на Кипре, находящемся в том же часовом поясе. Здесь теперь работает 400 специалистов.

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

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

Смешанные схемы

Далеко не все компании практикуют один или хотя бы часть из этих подходов. Во-первых (и это самое важное), существуют другие подходы к решению проблемы расстояния; самый перспективный из них — технологический. Во-вторых, критерии выбора тактики частично зависят от задачи и типа организации. Организации, поддерживающие собственные разработки, скорее всего, будут заинтересованы в реализации Тактики 1 или 2. В-третьих, эти тактики могут выбираться с учетом важности получаемых преимуществ. Например, фирма, которая сокращает интенсивность совместной работы (Тактика 1) за счет передачи иностранному партнеру хорошо структурированных задач, вряд ли будет инвестировать большие средства в сокращение культурных различий (Тактика 2). Наконец, вполне резонно использовать лишь определенное подмножество этих тактик. Например, типичные отношения в рамках сотрудничества американских и индийских фирм не удовлетворяют временному критерию (рабочий день в Индии и Кремниевой долине отличается на 10,5 часов), но прекрасно соответствует другим тактическим подходам (Тактика 1 и 2). Точно так же, если фирма вкладывает значительные средства в стратегический альянс с иностранной компанией (Тактика 2), которая расположена в том же самом часовом поясе (Тактика 3), может потребоваться интенсивная совместная работа (в противоположность Тактике 1), с тем чтобы эффективно использовать преимущества, которые дает незначительная разница во времени.

Иногда, вместо сокращения интенсивности совместной работы, как предполагает Тактика 1, абсолютно необходимо, несмотря на сложности координации, интенсифицировать ее с целью создания нового приложения или инновационных исследований. В массе ситуаций географически рассредоточенная команда может оказаться единственной возможностью собрать талантливых специалистов со всего мира. Это необходимо, если компания может использовать разницу в часовых поясах для ускорения выпуска продукта на рынок (например, дизайнерский центр корпорации Ford или разработка IBM программных компонентов VisualAge JavaBeans), хотя очень немногим удается добиться при этом успеха.

Как ни парадоксально, не сокращение культурных и организационных различий, как предусматривает Тактика 2, а увеличение культурной дистанции от Центра может стать преимуществом, поскольку позволяет получить множество новых идей и ноу-хау. Эрик вон Хиппел пришел к выводу, что успешные компании аккумулируют инновации, которые исходят от наиболее важных для них заказчиков [10]. Например, японские фирмы, доминирующие на рынке компьютерных игр, часть своих игровых программ разрабатывают в США, стремясь быть как можно ближе к сообществу игроков и дизайнеров.

Тактика 3 предполагает сокращение временных различий за счет синхронных коммуникаций, но это не панацея, поскольку синхронные коммуникации имеют свои ограничения. Многие отказываются от видеоконференций, в частности, из-за неудобств, вызванных прерываниями связи или из-за невозможности видеть участников. Более того, следует подчеркнуть, что современные синхронные инструменты совместного использования приложений неестественным образом ограничивают сотрудничество информационным пространством одного приложения [11]. И даже незначительная разница часовых поясов может оказаться губительной. При англо-германском сотрудничестве (при том что разница во времени составляет всего лишь один час) после вычета времени на ланч и из-за различной продолжительности рабочего дня, общего (синхронизованного) времени остается очень немного [12]. Синхронные коммуникации могут даже оказаться менее удобными, чем асинхронные. В конце концов, телефонные переговоры не позволяют доказательно ссылаться на сообщенную ранее информацию, в то время как электронная почта и факсы автоматически оставляют записи всех сеансов связи.

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

Литература

[1] «Offshore?s New Horizons», Global Technology Business, vol. 3, no 3 Mar. 2000

[2] E. Carmel and R. Agarwal, Offshore Sourcing of Information Technology Work by America?s Largest Firms, tech. report, Kogod School of Business, American Univ., Washington D.C., 2000

[3] GPI consultancy and P. Tjia, Computer Software and IT Services: A Survey of the Netherlands and Other Major Markets in the European Union, The Center for the Promotion of Imports from Developing Countries, Netherlands, 1999

[4] T.W. Malone and R.J. Laubacher, «The Dawn of the E-Lance Economy», Harvard Business Rev., vol. 76, no 5, Sept./Oct. 1998

[5] «Have Factory, Will Travel», The Economist, vol. 354, no. 8157, 12 Feb. 2000

[6] G. Anthes, «Software Development Goes Global», Computerworld, 26 June 2000

[7] E. Carmel, Global Software Teams: Collaborating Across Borders and Time Zones, Prentice Hall, Upper Saddle River, N.J., 1999

[8] R.E. Grinter, J.D. Herbsleb, and D.E. Perry, «The Geography of Coordination: Dealing with Distance in R&D Work», Proc. Int?l ACM SIGGROUP Conf. Supporting Group Work (GROUP ?99), ACM Press, New York, 1999

[9] Broadview Technology M&A Report, 1999; www.broadview.com

[10] E. von Hippel, The Sources of Innovation, 2nd edition, Oxford Univ. Press, New York, 1994

[11] C. Geisler and E.H. Rogers, «Technological Mediation for Design Collaboration», Rensselaer Polytechnic Inst., New York, June 2000

[12] J. D. Herbsleb and R. E. Grinter, «Splitting the Organization and Integrating the Code: Conway?s Law Revisited», Proc. 21st Int?l Conf. Software Engineering (ICSE ?99), ACM Press, New York, 1999

Эрран Кармел (ecarmel@american.edu) — адьюнкт-профессор школы бизнеса Когода Американского университета (Вашингтон). Написал книгу «Глобальные группы разработчиков программного обеспечения» (Global Software Teams, 1999). Риту Агарвал (ragarwal@rhsmith.umd.edu) — адьюнкт-профессор школы бизнеса Роберта Смита университета штата Мериленд.Один из авторов книги «Решения проблемы нехватки кадров в ИТ» (Labor Scarcity in Information Technology, 1999).

Erran Carmel, Ritu Agarwal, Tactical Approaches for Alleviating Distance in Global Software Development. IEEE Software, March/April 2001. IEEE CS, 2001, All rights reserved. Reprinted with permission.

Другие решения проблемы расстояния

Литература, посвященная виртуальным группам, описывает множество различных подходов к решению проблемы расстояния при глобальной разработке программного обеспечения. Эрран Кармел сформулировал [1] (а позже и развил [2]) шесть факторов, которые в состоянии оказать внутреннее давление на команду разработки и заставить ее действовать эффективнее: технология совместной работы, создание команды, лидерство, архитектура продукта и распределение задач, методология разработки программного обеспечения и телекоммуникационная инфраструктура.

Из них, пожалуй, самыми очевидными являются технологические решения. Например, распределенное управление конфигурацией программного обеспечения (Software Configuration Management), используемое для контроля версий системных компонентов, позволяет в значительной степени избежать возможного непонимания, поскольку оно поддерживает единый рабочий процесс и общее представление о проекте [1, 3]. Другое использование технологий — Web-сайт команды разработки, который отражает все аспекты, касающиеся как людей, так и задач, от фотографий программистов до тестовой документации [4]. Нетехнологические подходы менее формализованы. Марта Мазневски и Кэтти Чудоба пришли к выводу, что эффективная виртуальная команда имеет «глубинный ритм» регулярных совещаний, как очных, так и удаленных [5]. Конечно, главное не сама встреча, а формализм коммуникаций. Потребность в коммуникациях не всегда возникает внутри формальной, иерархической конфигурации. Когда глобальная команда разработчиков трудится над действительно новаторскими проектами, неформальные каналы координации критически важны. Они, как сказано в [6], «помогают разработчикам проникать в суть задачи, замечать исключения, исправлять ошибки».

Литература

[1] E. Carmel, Global Software Teams: Collaborating across Borders and Time Zones, Prentice Hall, Upper Saddle River, N.J., 1999

[2] E. Carmel, «Global Software Teams: A Framework for Managerial Problems and Solutions», Global Information Technology and Electronic Commerce: Issues for the New Millennium, Ivy League Publishing, Marietta, GA, 2001

[3] R.E. Grinter, «Doing Software Development: Occasions for Automation and Formalisation», Proc. Fifth European Conf. Computer Supported Cooperative Work (ECSCW ?97), Kluwer Academic Publishers, Dortrecht, The Netherlands, 1997

[4] S. McConnell, Software Project Survival Guide, Microsoft Press, Redmond, Wash., 1998

[5] M.L. Maznevski and K. Chudoba, «Bridging Space Over Time: Global Virtual Team Dynamics and Effectiveness», Organization Science, vol. 11, no 5, Sept./Oct. 2000

[6] J. D. Herbsleb and R. E. Grinter, «Splitting the Organization and Integrating the Code: Conway?s Law Revisited», Proc. 21st Int?l Conf. Software Engineering (ICSE ?99), ACM Press, New York, 1999