Глобальная разработка и поставка ПО: Тенденции и проблемы. Часть 2

Фактически, глобальная разработка может быть отягощена рядом проблем и болевых точек:

• непонимание или несовпадение процессов в рабочих группах могут привести к ошибкам при передаче работы, росту объема переделок и снижению производительности. По некоторым оценкам, производительность в проекте GDD может снизиться до 50%, при этом объем переделок может быть в 2-5 раз больше, чем для проектов, сосредоточенных в одном подразделении;
• коммуникационные проблемы могут привести к непониманию, упущениям, ошибкам и переделкам уже сделанного;
• культурологические проблемы, например языковой барьер и различия в привычных стилях общения или работы, могут вызвать задержки в работе и оказать негативное влияние на отношения в коллективе;
• координация трудовой деятельности в нескольких локальных подразделениях и часовых поясах требует больше временных и финансовых затрат;
• обеспечение обзора и контроля деятельности разработчиков во всех локальных подразделениях может оказаться проблематичным, особенно при совместной работе с другими компаниями или с рабочими группами, расположенными в другом часовом поясе;
• показатели проектов могут оказаться несогласованными или трудными для получения из неоднородных инфраструктур, различных процессов или политик безопасности компаний, что усложняет выполнение количественной оценки успеха;
• политические проблемы как внутри компании (организации, которые боятся потерять работу или сетуют на непроизводительные издержки на удаленные локальные подразделения), так и за ее пределами в стране или регионе могут привести к возникновению скрытых планов и конфликту целей;
• организации могут не разделять одни и те же цели, особенно при сдаче отчетов через различные цепочки управления или в разных компаниях;
• заботы о безопасности и защите IP-коммуникаций, особенно в ситуациях, связанных с аутсорсингом в странах, где законы о защите IP-коммуникаций менее жесткие, могут ограничить возможности принятия решений в отношении инфраструктуры и организации;
• в результате слияний, приобретения и аутсорсинга инструменты разработки и инфраструктуры могут варьироваться в широких пределах. Даже внутри одного локального подразделения менее крупные рабочие группы могут использовать облегченные инструменты, часто из категории программ с открытым исходным кодом, и часто для поддержки новых процессов, например, agile-разработки.

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

Критические факторы успеха GDD

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

Рисунок 3. Факторы успеха GDD

1. Обеспечение координации и контроля во всех локальных подразделениях.
   
   Важно с самого начала "мыслить глобально" и планировать, каким образом организация будет обеспечивать желаемую модель поставки. Определите, как именно роли и ответственности будут распределены по различным локальным подразделениям, включая руководство и лиц, ответственных за принятие решений. Подберите инструменты, которые будут использовать рабочие группы в каждом локальном подразделении, и определите, какие инфраструктуры необходимы для обеспечения их использования и интеграции с инструментами в других локальных подразделениях
   
   Контроль над удаленными рабочими группами, особенно аутсорсинговыми, может стать особой проблемой - как можно гарантировать уверенность в актуальности текущего состояния работы и целостное представление обо всем проекте, включая все промежуточные продукты? Каким образом можно обеспечить надежность оценки и сопоставлений между компонентами или проектами? Сравнивайте одинаковые величины, используйте согласованные критерии (по мере возможности) во всех рабочих группах. Заранее определите, какие критерии вы будете использовать для мониторинга хода выполнения и состояния работы, и поработайте с рабочими группами, чтобы убедиться, что они могут собирать необходимые показатели.
   
   Для объективной оценки выбирайте дискретные единицы. Например, старайтесь избегать количественной оценки артефактов типа "готов на 50%"; указывайте просто, готов данный артефакт или не готов. По возможности собирайте данные непосредственно из инструментов разработки, так можно избежать ошибок в результате человеческого фактора и предвзятости. (Некоторые сотрудники рабочих групп, воспитанные в определенных культурных традициях, могут уклоняться от сообщения плохих новостей.)
   
   
2. Внедрение хорошо продуманных и согласованных рабочих потоков.
   
   Чтобы избежать непонимания в отношении того, как необходимо выполнять работу, определите и документируйте согласованные процессы, которые должны выполняться во всех локальных подразделениях, и обучите им своих сотрудников.
   
   Вероятно, было бы неправомерным ожидать, что все рабочие группы будут практиковать один и тот же процесс; разные инструменты и технологии, различные требования бизнеса и унаследованные в результате приобретения процессы и особенности корпоративной культуры обуславливают различия в стилях и методиках работы. В одной организации могут быть рабочие группы, практикующие каскадные, итеративные или agile-методы в зависимости от обстоятельств. В идеале, все рабочие группы в одном проекте должны соблюдать один и тот же процесс, но в ситуации с глобальной цепочкой поставки даже такие коллективы могут быть разобщены и создавать свои компоненты с определенной степенью автономии.
   
   С точки зрения организации разработки программного обеспечения в целом, для того чтобы определить согласованные точки соприкосновения и компонентов внутри каждой рабочей группы и между рабочими группами, важно определить границы или параметры, которые должны пересекаться во всех процессах. Определите артефакты, которые должны быть созданы, показатели, которые необходимо отслеживать, критерии успеха и механизм обеспечения контроля и руководства.
   
   В каждой отдельной рабочей группе определите и документируйте процессы, которым необходимо следовать, и обучите всех сотрудников. Если необходимы исключения (например, из-за ограничений доступа или разницы в инструментах), явно документируйте, в каких случаях они применяются.
   
   Четко обозначьте руководителя и ответственность каждого сотрудника: кто какие операции выполняет, что и кому необходимо сдать и какие стандарты должны соблюдаться. Возможно, вы захотите использовать концепцию таблицы "RACI", чтобы определить, кто отвечает (Responsible), кто подотчетен (Accountable), с кем необходимо проконсультироваться (Consulted) и кого проинформировать (Informed) для каждого промежуточного продукта или этапа процесса.
   
   При передаче промежуточных продуктов между рабочими группами или локальными подразделениями часто возникают проблемы. По возможности, используйте самые конкретные термины, процессы должны ясно определять необходимые промежуточные продукты для каждой передачи и планируемые входные и выходные артефакты. Например, обеспечьте рабочим группам ясность понимания, предоставив шаблоны для необходимых артефактов и определив контрольные точки при помощи объективных критериев входа и выхода. При помощи точного указания передаваемых промежуточных продуктов и материалов можно найти общую почву и гарантировать обеим сторонам то, что им нужно, независимо от количества этапов между ними. Это может быть особенно полезным при работе с поставщиками услуг аутсорсинга, которые могут следовать своим внутренним процессам.
   
   Подумайте, как обеспечить мониторинг изменений, трассируемость и подотчетность на протяжении всего жизненного цикла, чтобы можно было проверить, было ли сделано изменение, когда, и какое влияние оно оказало или окажет на другие задачи и промежуточные продукты.
   
   Везде, где это возможно, автоматизируйте процессы и рабочие потоки артефактов и встройте их в инструменты. Чтобы способствовать соблюдению процесса, инструменты должны облегчать эту задачу, а не заставлять отходить от него, т.е. быть не кнутом из известной пословицы, а пряником. Сокращая количество шагов, выполняемых вручную, вы одновременно уменьшаете возможности для совершения ошибок и экономите время и силы сотрудников рабочей группы. Кроме того, автоматизация может способствовать предотвращению задержек из-за временных различий в разных часовых поясах. Например, наличие автоматизированного процесса сборки и верификации сборки может позволить рабочей группе в Индии закончить и протестировать исправление дефекта, не дожидаясь начала рабочего дня группы, занимающейся этой сборкой в Соединенных штатах. Использование инструментов для определения процесса может также облегчить внедрение инструментов и процессов и помочь обеспечить совершенствование процесса по мере того как сотрудники учатся более эффективно работать в своей рабочей группе и во всем коллективе.
   
   
3. Управляйте активами и информацией.
   
   Управляйте активами и артефактами. Определите, кому необходим доступ к конкретным артефактам, и обеспечьте им соответствующие права доступа. Сюда можно отнести вопросы доступа по сети и доступности активов через глобальную сеть или Интернет, разрешений безопасности на выполнение определенных действий и просто возможности найти эти артефакты (а также правильно выбрать их версию).
   
   По возможности, старайтесь обеспечить трассируемость между связанными артефактами, чтобы на следующих этапах процесса можно было понять контекст используемого артефакта. Например, обеспечение трассируемости от дефектов и контрольных примеров до требований и моделей прецедентов может помочь тестировщикам понять, какие результаты они должны увидеть и почему, и обеспечивает ли тест покрытие нужной функциональности.
   
   Используйте механизм управления версиями для артефактов, отслеживания и трассировки изменений и обеспечьте трассируемость между корректными версиями разных артефактов. Делайте мгновенные снимки релизов (базовых линий) ваших активов с заранее заданными интервалами, например в конце каждой итерации или в каждой контрольной точке. Каждый релиз включает полный набор совместно используемых рабочими группами и применяемых в качестве опорных точек ассоциированных с ним версионированных артефактов, которые можно считать единицами или отдельными активами. Подумайте о применении инструмента управления активами для хранения и управления этими агрегациями связанных и версионированных артефактов и обеспечения их доступности для многократного использования.
   
   
4. Общайтесь, общайтесь и еще раз общайтесь.
   
   Четкое и эффективное общение может быть самым важным из факторов успеха и, безусловно, является ключом к созданию любого серьезного коллектива. Успешные проекты способствуют совместной работе и стимулируют создание коллективов и социальных сетей. IВ нерассредоточенной рабочей группе совместная работа может осуществляться неформальным образом в коридоре или в буфете, а также в процессе личных встреч. В территориально рассредоточенной группе необходимо больше работать над тем, чтобы каждый сотрудник оставался на связи.
   
   Продумайте план коммуникаций, который будет определять, как обеспечить своевременное информирование всех сотрудников рабочей группы и работу над достижением общих, разделяемых всеми целей. Общайтесь чаще и более открыто, работайте над установлением доверия между членами коллектива.
   
   Используйте любой из доступных механизмов совместной работы. Многие из стандартных механизмов хорошо известны и широко используются: это электронная почта, телеконференции и различные средства для создания примечаний или документирования, встроенные в инструменты разработки. Большинство из нас, кроме того, умеют общаться в чатах и через программы обмена мгновенными сообщениями, могут использовать Интернет-конференции и конференц-связь с передачей неподвижных изображений. Википедии и блоги рабочих групп - это еще один механизм, который с недавних пор получил широкое распространение. Создайте виртуальный аналог "буфета" через программы обмена мгновенными сообщениями, чатов для рабочих групп или других механизмов обеспечения совместной работы.
   
   В рассредоточенных коллективах с ограниченными межличностными контактами установить доверительные отношения не всегда просто. Создайте на центральном сервере профили для каждого члена коллектива с фотографией и аудиофрагментом, чтобы другие сотрудники могли ассоциировать лицо и другую личную информацию с именем и голосом. Если позволяют средства, периодически организуйте личные встречи (собрания группы), которые дают возможность установить взаимоотношения с использованием преимущества невербальных механизмов общения (хотя необходимо отметить, что культурные различия могут затрагивать и эти невербальные механизмы общения).
   
   IСамо собой разумеется, что вы должны планировать собрания рабочей группы с учетом разницы в часовых поясах локальных подразделений. В тех случаях, когда невозможно выбрать удобное для всех сотрудников время собрания, включите в план дополнительные встречи в альтернативное время, что позволит членам коллектива присутствовать на таких собраниях поочередно в удобные и неудобные часы. Планируя собрания и совещания по контрольным точкам, вы также должны учитывать праздничные дни, которые различаются в разных странах. Если запланировать проведение главного совещания по контрольной точке на время, когда в одном из регионов сотрудники на месяц уходят в отпуск или имеет место какое-нибудь важное политическое или религиозное событие, то это, скорее всего, приведет к переносу совещания и потенциальным конфликтам в коллективе.
   
   По возможности, организуйте совместную работу в контексте обсуждаемого объекта или артефакта. Используйте URL-ссылки для общего доступа к материалам по электронной почте или через чат. Создавайте аннотации или делайте комментарии непосредственно в артефакте и сохраняйте их вместе с артефактом для справки. Сохраняйте понятные записи бесед и решений, чтобы те, кто не работает над проектом, могли узнать, какое решение было принято и на каком основании. Для членов коллектива из других часовых поясов это может также сэкономить массу времени на ожидании ответов на свой запрос, ведь в этом случае можно прождать целый день, прежде чем на твой вопрос о принятии определенного решения или обосновании этого решения ответит кто-нибудь на другом конце земного шара.
   
   Текстовые записи также могут помочь преодолеть языковой барьер. Сотрудники рабочей группы, испытывающие трудности с разговорным языком, могут прочитать (а при необходимости перечитать) письменный документ, чтобы лучше понять само решение и его контекст. Полезно также предоставить им текстовые резервные копии голосовых коммуникаций, например общих диаграмм, текста и "тайного канала" в телеконференции. (Отметим, что такие резервные копии помогут также людям с ослабленным слухом.)
   
   Необходимо иметь представление об этнокультурных различиях в организации и привычных методах работы в различных локальных подразделениях. Например, сотрудники одних этнокультурных групп могут не решаться задать вопрос начальнику, а сотрудники из других этнокультурных групп - идти на конфронтацию и спорить с ним. Понимайте эти различия и добейтесь, чтобы их понимали все члены коллектива, чтобы можно было адаптировать и комбинировать стили работы в разных рабочих группах. Некоторые компании предлагают обучающие ресурсы по преодолению культурных различий, в других случаях вам придется учиться на собственном опыте или просить совета у тех, кто работает с подобными коллективами.
   
   
5. Создайте гибкую, приспосабливаемую ИТ-инфраструктуру и архитектуру.
   
   ИТ-инфраструктура, включая сети и инструменты разработки, должна обеспечивать поддержку различных сценариев территориально рассредоточенной организации. Убедитесь в том, что выбранные вами инструменты и платформы предоставляют мощность и гибкость, которые нужны для поддержки необходимых топологий, будь то топология репликаций, hub-and-spoke, централизованная или какая-либо их комбинация. Особые соображения:
   
   
   • доступ клиентов к серверу через сети LAN, WAN или Интернет;
   • обеспечение безопасности и возможность, при необходимости, ограничить доступ к артефактам;
   • возможность взаимодействия и интеграции с другими инструментами и платформами в неоднородной рабочей среде;
   • обеспечение совместной работы в коллективе;
   • возможность поддержки необходимых языков и национальных кодировок.

Заключение

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

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

Поставка с учетом критических факторов успеха, а именно:

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

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

Примечания

¹ Bernstein Research, "Future of IT Services," (Будущее ИТ-сервисов) 22.05.2006. Gartner Group, "Gartner on Outsourcing," (Gartner об аутсорсинге), 14 декабря 2005 г. Forrester Research, "Future of Outsourcing," (Будущее аутсорсинга), 24 октября 2006 г.

² Weier, Mary Hayes, "Tata Earnings Show Offshore Outsourcing Moving Beyond Software Development" (Доходы Tata от офшорного аутсорсинга превысили доходы от разработки программного обеспечения), журнал Information Week, 15 октября 2007 г. .

³ Gartner Group, "Gartner on Outsourcing," (Gartner об аутсорсинге), 14 декабря 2005 г.

Окончание