USD 65.59 ЕВРО 75.18

7 советов по работе с оффшорными командами разработчиков

Аналитика

7 советов по работе с оффшорными командами разработчиков

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

Оффшоры не гибки.

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

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

Но за последние несколько лет многие нишевые оффшорные девелоперы потихоньку
разрабатывали свои эксклюзивные предложения по итеративным разработкам. И
некоторые ИТ директора готовы принять такую оффшорную модель.

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

Ниже семь подсказок, как заставить это работать:

1. Подготовьтесь

Ежедневное управление разработками (скрамы) через Skype или другую систему
видеоконференции – единственный способ работать гибко при 
распределено-удаленной системе работы, считает Карпентер. Но никто не хочет
потратить 15 минут для поиска подходящей комнаты и оборудования  для 15
минутной проверки статуса. Это подтверждает сентябрьский отчет Forrester:
«потерянное на поиск помещения и оборудования время для установления
коммуникации серьезно замедляет работу». Выход – в создании стандартов не
только для коммуникации, но также  программных инструментов и методов для
обсуждения и обмена объектами.

2. Начните с малого

Роман Каплун, директор инженерного сервиса для сайта дешевых путешествий
Hotwire,  решил остановиться на оффшорной разработке, потому что ему
приходилось конкурировать с такими гигантами, как Apple, Facebook, и Google для
поиска программистов. Он решил работать с русским ИТ провайдером Luxoft, но
начал с небольшой тестовой работы, которая длилась полтора года.

Потом Luxoft начал предоставлять услуги разработки из Киева (Украина) и
Омска (Россия) в маленьких группах. «Было важно выстроить наши отношения и
выяснить, как работать вместе наиболее эффективно», — говорит Каплун.

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

3. Рассмотрите возможность смешанной модели работы

Джо Снайадо, CIO компании Standard & Poor изначально испытывал проблемы
с оффшорными разработками. Поэтому он предпочел заплатить больше, чтобы
партнеры предоставили часть персонала для работы в офисе и часть в близлежащих
регионах – в пределах двух часов по часовой зоне. Он создал наполовину
оффшорную модель разработки 50/50.

4. Управляйте активно

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

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

5. Инвестируйте в обучение

Бизнес модель Hotwire предполагала, что клиенты снимают комнату в отеле, не
зная, какую именно – за это они получают скидку. Но эта система была неизвестна
большинству разработчиков из Восточной Европы. Поэтому Каплун привез их на
предприятие, чтобы ознакомить их с бизнес-моделью, продуктами и объяснить точку
зрения заказчика.

6. Выбирайте правильного партнера

Многие индийские ИТ компании построили свой бизнес на методологии водопада и
не смогли масштабироватся или выполнять работу по методологии гибкой
разработки, считает Стефани Мур, вице-президент и главный аналитик по
аутсорсингу в  Forrester Research.

Например, компании Infosys и Tata Consultancy Services применяют гибкую
методологию разработки в менее чем 20% своей работы. Большие международные
провайдеры с оффшорными центрами, такие как HP и IBM имеют примерно такой же
процент подобных разработок. Но есть и такие компании, которые построили свой
бизнес исключительно вокруг гибкой методологии разработок, например
ThoughtWorks и Matrix Global. Постарайтесь не связываться с разработчиками,
если у них нет опыта в оффшорных проектах по гибкой методологии.

7. Учитывайте временные зоны

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

Но для Hotwire, чей офис живет на 10-14 часов позже зоны оффшорной команды,
общение в реальном времени было сильно затруднено. Каплун вышел из положения,
введя новую роль – владелец практик продукта – которого он разместил в Киеве.
Этот сотрудник прошел обучение в Сан-Франциско и понимает бизнес, его процессы
и может давать указания команде разработчиков, если у тех возникают вопросы,
чтобы не ждать следующего дня.

 

Подготовлено НП «СОДЕЙСТВИЕ»