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

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

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

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

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

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

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

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

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

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

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

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

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

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 часов позже зоны оффшорной команды, общение в реальном времени было сильно затруднено. Каплун вышел из положения, введя новую роль – владелец практик продукта – которого он разместил в Киеве. Этот сотрудник прошел обучение в Сан-Франциско и понимает бизнес, его процессы и может давать указания команде разработчиков, если у тех возникают вопросы, чтобы не ждать следующего дня.

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