USD 94.09
ЕВРО 100.53
Оффшоры не гибки.
Это был основной постулат в корпоративном ИТ с тех пор, как итерационный
подход к разработкам был принят более десятилетия назад. Расстояния,
казалось, могут сильно усложнить гибкую, тесную совместную работу,
самоуправление и быструю разработку.
Согласно сентябрьскому отчету 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 часов позже зоны оффшорной команды,
общение в реальном времени было сильно затруднено. Каплун вышел из положения,
введя новую роль – владелец практик продукта – которого он разместил в Киеве.
Этот сотрудник прошел обучение в Сан-Франциско и понимает бизнес, его процессы
и может давать указания команде разработчиков, если у тех возникают вопросы,
чтобы не ждать следующего дня.
Подготовлено НП «СОДЕЙСТВИЕ»
