Аутсорсинг в Индии

Аутсорсинг разработки программного обеспечения вызывает все больший интерес. Представив несколько различных моделей аутсорсинга, авторы статьи рассказывают об опыте Tenovis, немецкой телекоммуникационной компании и ее партнера по разработке программного обеспечения из Бангалора (Индия).

В 90-е годы многие организации начали изучать возможность распределенной разработки программного обеспечения в офисах, расположенных в различных странах, объясняя свой интерес к этому стремлением сократить затраты на персонал. Особое внимание привлекли Индия и страны Восточной Европы. Такого рода подход к разработке предполагает самые разные модели сотрудничества — от передачи независимым фирмам и дочерним компаниям субподрядов на реализацию частей проектов по созданию программного обеспечения до организации виртуальных международных групп разработки.

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

Что представляет собой распределенная разработка

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

1. Раздельные команды в независимых компаниях — обычные отношения между подрядчиком и субподрядчиком. Встают юридические вопросы, а также вопросы, касающиеся передачи знаний, управления разработкой и проектом, а также управления качеством. Если одновременно приходится преодолевать еще и культурные границы, то эти трудности становятся еще значительнее, и, вдобавок, к ним присоединяются вопросы языка, временных зон и инфраструктуры.
2. Раздельные команды в родственных компаниях — особого рода отношения подрядчик-субподрядчик между родительской и дочерней фирмами. Данная ситуация аналогична ситуации, предусматриваемой Моделью 1, за тем исключением, что юридические вопросы, а также вопросы передачи знаний, управления проектом и качеством решаются намного проще, поскольку субподрядчик принадлежит родительской корпорации.
3. Одна команда, распределенная между несколькими офисами родственных компаний. В этом случае на первый план выходят вопросы управления разработкой, проектом и качеством продукта. Если офисы находятся в разных странах, особую сложность приобретают вопросы языка, временных зон и инфраструктуры.
4. Одна команда, распределенная между офисами независимых компаний, — наиболее распространенная модель для глобальной корпорации. Команды распределяются по нескольким юридически независимым офисам. Эта модель требует решения всех вопросов, которые характерны для Модели 3; плюс к тому, значительными препятствиями на пути реализации проекта могут стать юридические вопросы.

Зачем нужна глобальная разработка

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

• Есть ли исторические связи, которые могут в определенной степени смягчить трудности, присущие процессу глобализации? Возможно, несколько бывших коллег работает за рубежом или создали свою фирму, или, быть может, две компании уже сотрудничают в какой-то иной области помимо разработки программ. Кроме того, может существовать глубокая историческая общность между теми странами, в которых работают потенциальные партнеры. Например, один язык или иные культурные связи, либо просто наличествует благоприятный политический климат для инвестиций в страну, где планируется начать работать. Исторические связи значительно упростят сотрудничество в любой форме, особенно тесную кооперацию, предусматриваемую Моделями 3 и 4.
• Есть ли культурные различия? Так, специфические для данной страны традиции, верования или религия могут серьезно повлиять на предполагаемое партнерство. К примеру, принято считать, что некоторые азиатские страны традиционно в большей степени ориентированы на коллективную работу, чем западные. В таких странах будет проще наладить сотрудничество в рамках Моделей 3 и 4.
• Можно ли распределить процесс разработки всей программной системы между офисами? Следует ли разделить ответственность в соответствии с системными требованиями (разные офисы разрабатывают разные компоненты, но отвечают за весь их жизненный цикл) или с ролями разработки (один офис выполняет конструкторскую часть работ, в том числе анализ требований, проектирование, тестирование интеграции и работоспособности системы, а другой офис реализует компоненты системы)? Или распределение работы надо вести в соответствии со спецификой квалификации? В зависимости от этого будет выбрана либо Модель 1 или 2, либо 3 или 4, соответственно.

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

Юридические вопросы

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

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

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

Передача знаний

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

• Прикладные знания. В зависимости от типа разрабатываемого программного обеспечения необходимо передать удаленному офису знания, касающиеся прикладной области. Например, если компания в течение ряда лет специализировалась на разработке управляющих программ для конкретной сферы применения, скажем, атомные электростанции или системы стимулирования сердечной деятельности, может потребоваться передача партнерам знаний, накопленных ею о специфических алгоритмах управления. Такая передача знаний обычно не вызывает проблем при организации распределенной разработки в соответствии с Моделями 2 или 3, поскольку офисы принадлежат одной компании. Однако этот вопрос становится критичным для Моделей 1 и 4, когда независимый партнер может также разрабатывать программы и для конкурентов компании. Иногда возникают и юридические вопросы, если, к примеру, политические условия не позволяют свободно передавать определенные технологии (скажем, криптографические средства).
• Знания по управлению качеством. Требования качества иногда означают, что компания должна передать систему качества своему партнеру. В противном случае невозможно будет гарантировать или сертифицировать разработку в соответствии с определенными уровнями CMM или ISO 9000. В силу этого компания должна унифицировать знания о процессах, методиках или методах — например, путем обучения сотрудников или обмена экспертами. Значительно чаще такой вид передачи знаний применяется в условиях распределенной разработки в соответствии с Моделями 2, 3 и 4. В рамках Модели 1 компания должна выбрать партнера, который в состоянии гарантировать следование установленным стандартам качества.
• Знания о стандартах на разработку. Обычно в этом не возникает серьезных проблем, поскольку существуют подробно документированные международные стандарты. Если используются специфические стандарты компании, этот вопрос может вызвать проблемы при ведении разработки в рамках Модели 1 и 4, но не является критичным для разработки в соответствии с Моделями 2 или 3.
• Знания о корпоративной культуре. К ним часто примыкают и вопросы, связанные с преодолением культурных границ. Сюда же относятся и льготы для сотрудников (к примеру, медицинская страховка и отпуска). Передача корпоративной культуры — очень важный момент в рамках Моделей 2, 3 и 4.

Управление разработкой и проектом

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

Также следует упомянуть совместное редактирование, а также моделирование и утверждение процессов [3-5]. Для поддержки этих операций управления проектом существует целый ряд инструментальных средств, в том числе, BSCW, MetaEDIT+, ClearCase MultiSite, а также средства более общего назначения, такие как Corba. Кроме того, существует ряд систем репозиториев, обеспечивающих распределенный и прозрачный доступ к проекту. Однако эти инструменты обычно охватывают лишь небольшую часть возникающих вопросов, и в них часто отсутствует функции, требуемые для адекватной поддержки географически распределенных отделов разработки. Как следствие, компании обычно используют множество различных инструментов. Иногда, поскольку удобные решения еще не созданы или должным образом не апробированы, используется и инструментарий, не предназначенный для поддержки совместной деятельности вне корпоративных рамок [6].

Хотя задачи координации типичны для распределенной разработки, ведущейся в рамках всех четырех моделей, мы остановимся, в первую очередь, на особенностях, присущих Моделям 3 и 4.

Управление качеством

Разработка по Модели 1 позволяет компании свободно выбирать потенциального партнера с нужной репутацией (например, с учетом соответствия стандартов качества ISO 9000 или CMM), однако, это не всегда возможно в рамках других моделей. В этих случаях компании-партнеры должны начать с выработки общего понимания вопросов качества. После этого они могут создать приемлемую модель качества, которая учитывает культурные особенности (такие как традиционная ориентация на коллективную работу или противодействие иностранному менеджменту). В рамках этой деятельности может потребоваться интенсивный тренинг и обмен имеющимися знаниями.

После того как создана общая модель качества, возможны трудности с получением и интерпретацией необходимых данных измерений, а также с их передачей разработчикам в различные офисы. Прозрачный контроль за данными проекта, распространяемыми между офисами по всему миру (в соответствии с Моделями 3 и 4) требует развитой инфраструктуры коммуникаций. Кроме того, лишь немногие инструменты (такие как EPG 7 и WebME 8) обладают необходимыми функциями для поддержки задач управления качеством при совместной разработке с участием физически отдаленных офисов. Те же трудности, что сопутствовали управлению разработкой и проектом, если не в большей степени, возникают и в этом случае, поскольку вопросы обработки данных о качестве и отсутствие адекватной инструментальной поддержки приобретают особый смысл.

Язык и временные зоны

Разработка с участием офисов, расположенных в других странах, как правило, означает, что разработчики говорят на разных языках. В рамках Моделей 1 и 2 языковые различия касаются только обмена контактами, требованиями и продуктами, а также проведения встреч, связанных с проверкой. В рамках Моделей 3 и 4 они затрагивают повседневное общение и техническую документацию. Обычно для глобальных коммуникаций выбирают английский язык. Выбор рабочего языка может оказаться критичным для любой из моделей, если создаваемое программное обеспечение требует подготовки пользовательского интерфейса на определенном языке (например, если все диалоги должны быть на немецком языке или предусматривается использование иероглифов).

Разница часовых поясов может создать дополнительные трудности. На первый взгляд, может показаться, что это не имеет никакого значения, особенно, если временные зоны различаются на один-два часа. Многие американские компании, например, вынуждены ежедневно преодолевать такие трудности, поскольку их филиалы разбросаны по всей стране. Эти вопросы приобретают все более важное значение, когда разница в часовых поясах увеличивается. Офисы попадают в разные временные диапазоны [2]. Проведение видеоконференций между офисом в Нью-Йорке и офисом в Европе в течение обычного рабочего дня, продолжающегося с 9 утра до 5 вечера, к примеру, при типичной разнице во времени, можно проводить лишь в течение двух часов (от 3 до 5 часов вечера по европейскому времени и с 9 до 11 утра по времени Нью-Йорка).

Даже небольшие различия в часовых поясах, как, скажем, в 4,5 часа между Германией и Индией, иногда сказываются на работе команд, ведущих разработку по Моделям 3 или 4. У разных стран в разные дни недели выходные, религиозные и национальные праздники. Индия, к примеру, отмечает День Независимости 15 августа а в США он празднуется 4 июля. Другие индийские праздники — День Республики (26 января), Ганди Джаянти (2 октября) или Холи и Дивали (он отмечается в разные дни по Григорианскому календарю, поскольку день этот выбирается на основе календаря Хинди и лунного цикла) — в Германии и Штатах обычные рабочие дни. Как следствие, при разработках, ведущихся в другой стране, необходимо учитывать возможные временные различия, определяя сроки завершения работ или назначая совещаний. Игнорирование подобных особенностей может породить непонимание и ухудшить моральный климат.

Вместе с тем, разница во времени позволяет вести разработку буквально круглые сутки. Когда в Азии, к примеру, наступает ночь, результаты проделанной за день работы могут быть переданы в Европу, где рабочий день только начинается. Когда в Европе заканчивается рабочий день, документы отправляются в Америку для дальнейшей обработки, а к тому моменту, как они вновь окажутся в Азии, там наступит следующий рабочий день. Такого рода распределенная разработка лучше всего организуется по Моделям 3 и 4. В любом случае, реализация подобного распределенного проекта требует поддержки развитой инфраструктуры.

Инфраструктура

Развитая инфраструктура коммуникаций — основной компонент распределенной разработки, поскольку общение внутри команды становится намного сложнее, когда ее участники разнесены географически (согласно Модели 3 или 4) [9, 10].

• Члены команды должны общаться друг с другом, чтобы обсуждать проблемы и возможные их решения. «Связь по электронной почте помогает, но никакая электронная почта не позволяет разработчикам вести дискуссии, возможные в том случае, если они работают бок о бок» [2]. Необходимы другие формы общения, такие как телеконференции, чаты, видеотелефоны или виртуальные конференции. Ситуацию осложняет разница во времени.
• Разделяемая база данных проекта (информация о разрабатываемом продукте и документация на него, данные о самом процессе и измерения, хранилища повторно используемых компонентов и так далее) должна быть доступна всем членам команды. Разработчики не могут просто получать в виде присоединенных файлов к сообщению электронной почты огромные объемы данных или передавать их, используя обычные аналоговые модемы. Необходимы возможности пересылки больших объемов данных.

В таких проектах особое внимание следует уделять защите. Насколько безопасны выбранные каналы связи? Или необходимо обратиться к заведомо надежным средствам, таким как PGP или X.509 для обеспечения защиты передаваемой информации [11, 12]? Даже в тех случаях, когда защита не является критичным фактором, обычные системы связи просто не в состоянии удовлетворить стоящие требования, особенно в странах с недостаточно развитой инфраструктурой. Все это может вынудить компанию создавать свои собственные дорогостоящие частные каналы коммуникаций.

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

Таблица 1 показывает, каким образом четыре модели сотрудничества удовлетворяют изложенным критериям. Сотрудничество в соответствии с принятой нами Моделью 3, к примеру, позволяет использовать уроки, извлеченные при работе по Модели 2, которые главным образом, относятся к тому, что партнеры были бы родственными компаниями. В случае Модели 1 можно использовать некоторые уроки, полученные при разработке по Модели 2.

Пример сотрудничества

Сотрудничество между компаниями Robert Bosch India (RBIN) и Tenovis (ранее подразделение Private Network корпорации Bosch Telecom) началось в 1997 году.

Группа из шести индийских разработчиков программного обеспечения в Бангалоре, своеобразной индийской Кремниевой долине, начала свою деятельность под руководством своего французского коллеги, остававшегося в Индии полтора года. Поскольку RBIN принадлежала корпорации Robert Bosch, это сотрудничество с самого начала развивалось в соответствии с Моделью 2. Когда Tenovis в начале 2000 года стала независимой компанией, формально модель изменилась на Модель 1. Однако вследствие длительного периода предыдущего сотрудничества по Модели 2, удалось избежать некоторых наиболее серьезных трудностей, свойственных Модели 1.

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

Была создана инфраструктура — канал на 256 кбит/с для коммуникаций и передачи программ. В 1998 году стали разрабатываться и другие интерактивные средства обслуживания, терминальное оборудование и серверные приложения. Рост ответственности и важности разработок в RBIN привел к необходимости создать лабораторию в RIBN. Группа в Бангалоре получила возможность тестировать свои разработки прежде, чем передать их группе в Германии, которая занималась окончательной интеграцией.

Сейчас 72 индийца работают по заданиям Tenovis над созданием программного обеспечения УАТС.

Юридические вопросы

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

Передача знаний

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

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

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

Управление проектом и разработкой

Как уже упоминалось, все задания, переданные RBIN, сопровождались описанием рабочих проектов и первоначальной оценкой трудозатрат. Чтобы разработка велась должным образом, руководитель проекта в Tenovis должен знать, кто за какой рабочий пакет отвечает и какова планируемая дата завершения этого пакета. И аппаратная, и программная среда разработки должны быть созданы прежде, чем начнется сама разработка. За время совместного проекта мы создали множество программ, проводя контроль версий. Для решения этой задачи и во Франкфурте, и в Бангалоре используются инструментальные средства контроля, рассчитанные на разработку в различных офисах. Магистралью общей разработки стал канал связи на 256 кбит/с, который гарантирует бесконфликтную передачу данных и голоса. Этот канал поддерживает независимый от Tenovis оператор, специализирующийся на вопросах межконтинентальной связи.

Управление качеством

RIBN прошла сертификацию в соответствии с требованиями стандарта ISO 9000. Мы провели интенсивное обучение использованию инструментальных средств поддержки качества, процедур, спецификаций, методов, контроля и измерений — в обоих офисах, чтобы добиться приемлемого уровня качества.

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

Язык и время

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

Инфраструктура

Инфраструктура в Индии весьма ненадежна. Чтобы гарантировать стабильное функционирование, офис RBIN должен быть технически самодостаточным. Этого удалось добиться с помощью установки генератора на 100 КВт, который полностью удовлетворял потребности в электроэнергии для RBIN и гарантировал необходимую избыточность, а также благодаря независимому каналу связи, который поддерживался посредством Robert Bosch Corporate Network (RBN). Канал RBN для связи с Германией состоит из одной линии на 256 кбит/с и одной линии на 384 кбит/с, по которым передаются данные, голос, факсы, а также проводятся видеоконференции.

Уроки

Описанные здесь уроки относятся, главным образом, к сотрудничеству, которое было организовано в соответствии с Моделью 2 (прежде, чем Tenovis стала независимой в начале 2000 года, после чего мы перешли на Модель 1). Хотя эти уроки касаются взаимодействия Tenovis и RBIN, они могут оказаться весьма полезными многим организациям. Действительно, многие крупные компании (к примеру, Lucent Technologies, Siemens и Nokia) пользуются услугами по разработке своих индийских филиалов, юридически связанные с их собственной компанией (Модель 2). Если они действуют в соответствии с одной из других моделей, схема классификации для моделей сотрудничества позволяет четко выявить различия между ситуацией Tenovis-RBIN и какой-либо иной. Благодаря этому определенные уроки могут быть для конкретных компаний более актуальны, чем другие. Например, компания, действующая в соответствии с Моделью 3, может использовать эти уроки, полученные при сотрудничестве по Модели 2, которые касаются главным образом юридических отношений между компаниями-участниками. С другой стороны, при сотрудничестве по Модели 1 могут оказаться полезными некоторые из уроков Модели 2, касающиеся того факта, что для организации группы разработки были выбраны отдельные команды.

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

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

Юридические проблемы, проблемы языка и временных зон в нашем случае никогда не возникали. Выбор английского в качестве общего языка в этом случае оказался естественным. Кроме того, согласно Модели 1 и 2, у нас были четкие описанные контрактом процедуры.

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

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

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

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

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

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

Разработке программ для родительских иностранных компаний грозит та же опасность. Как только в других странах появится более квалифицированный персонал или более эффективные методы разработки, позволяющие решить проблему нехватки кадров, Индия как ведущий игрок рынка глобального программирования может оказаться не у дел. Таким образом, Индия должна (так оно и происходит) стремится к разработке продуктов и готовых систем, сочетающих в себе знание программного обеспечения и прикладной области. Такая разработка гарантирует, что Индия надолго останется ведущим глобальным поставщиком программного обеспечения, но при этом окажется в условиях более жесткой конкуренции со странами — традиционными производителями программного обеспечения, такими как США и государства Европы.

Литература

[1] J. Grundy, «Distributed Component Engineering Using a Decentralized, Internet-Based Environment», Proc. Third Int?l Conf. Software Eng., Workshop Software Eng. over the Internet, 2000

[2] S.E. Dossick and G.E. Kaiser, «Distributed Software Development with CHIME», Proc. Third Int?l Conf. Software Eng., Workshop Software Eng. over the Internet, 1999

[3] J.C. Grundy, «Interaction Issues for User-Configurable Collaborative Editing Systems», Proc. Asian Pacific Computer & Human Interaction Conf. (APCHI), IEEE CS Press, Los Alamitos, Calif., 1998

[4] R. Conradi et al., «EPOS: Object-Oriented Cooperative Process Modeling», Software Process Modeling & Technology, A. Finkelstein, J. Kramer, and B. Nuseibeh, eds., Research Studies Press, Hertfordshire, UK, 1994

[5] F. Bendeck et al., «Coordinating Management Activities in Distributed Software Development Projects», Proc. IEEE Workshop Enabling Technologies: Infrastructures for Collaborative Enterprises (WETICE ?98), IEEE CS Press, Los Alamitos, Calif., 1998

[6] Z. Haag, R. Foley, and J. Newman, «Software Process Improvement in Geographically Distributed Software Engineering: An Initial Evaluation», Proc. 23rd Euromicro Conf., IEEE Press, Piscataway, N.J., 1997

[7] M.I. Kellner et al., «Process Guides: Effective Guidance for Process Participants», Proc. Fifth Int?l Conf. Software Process (ICSP), IEEE CS Press, Los Alamitos, Calif., 1998

[8] R. Tesoriero and M. Zelkowitz, «A Web-Based Tool for Data Analysis and Presentation», IEEE Internet Computing, vol. 2, no. 5, Sept./Oct. 1998

[9] J. Suzuki and Y. Yamamoto, «Leveraging Distributed Software Development», Computer, vol. 32, no. 9, Sept. 1999

[10] S.F. Li and A. Hopper, «A Framework to Integrate Synchronous and Asynchronous Collaboration», Proc. IEEE Workshop Enabling Technologies: Infrastructures for Collaborative Enterprises (WETICE ?98), IEEE CS Press, Los Alamitos, Calif., 1998

[11] P. Zimmermann, The Official PGP User?s Guide, MIT Press, Cambridge, Mass., 1995

[12] ISO-IEC Standard 9594:1993-8, 1993, www.iso.ch

Werner Kobitzsch, Dieter Rombach, Raimund L. Feldmann. Outsourcing in India. IEEE Software, March/April 2001. All rights reserved. IEEE CD, 2001. Reprinted with permission.

Tenovis в Германии

Компания Tenovis (www.tenovis.com) создана в апреле 2000 года в результате отделения от корпорации Bosch Telecom ее подразделения Private Network. Клиентами Tenovis являются более 200 тыс. компаний по всей Европе, от небольших и средних до таких гигантов, как Bertelsmannn, Hypo-Vereinsbank, BMW и Volkswagen. В 82 офисах Tenovis в Европе работает около 8 тыс. человек.

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

Индийская компания-разработчик

Robert Bosch India (RBIN), расположенная в Бангалоре (Индия), была основана в 1998 году как дочерняя компания немецкой корпорации Robert Bosch. Эта компания предоставляла программные услуги для подразделений Robert Bosch по всему миру, в том числе в Европе, Северной Америке, Азии и Австралии. В настоящее время она принимает заказы на разработку программного обеспечения и для фирм, не являющихся клиентами Bosch. В RBIN около 650 сотрудников, из которых почти 600 — в отделе разработки программного обеспечения. Компания прошла сертификацию в соответствии с ISO 9001 и CMM Level 3.

Основные направления деятельности RBIN:

• разработка программных приложений для автомобильных систем;
• разработка ПО для систем связи;
• бизнес-приложения;
• промышленная автоматизация.

Более подробную информацию можно найти по адресу www.boschindia.com/rbin.