Скрытые расходы офшорной разработки

В таблице всё выглядит просто. Старший разработчик, $35 в час, 8 часов в день, 20 дней в месяц. Это $5 600 в месяц. Против того же человека в штате за $12 000–$15 000. Математика очевидна, решение кажется простым.

Потом проходит шесть месяцев, и итоговая цифра не совпадает с таблицей.

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

Скрытый расход 1: накладные расходы на управление

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

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

Если у вас три офшорных разработчика по $35 в час, и управление ими занимает 60% времени технического лида с зарплатой $120 000 в год, вы уже добавили $72 000 к эффективной стоимости этих трёх разработчиков. Это существенно меняет математику.

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

Скрытый расход 2: потери при передаче контекста

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

Разработчик, работавший в вашем продукте 18 месяцев, понимает неявные ограничения — технический долг в модуле X, причину, по которой нельзя трогать функцию Y, бизнес-логику, зарытую в комментарии двухлетней давности. У офшорного разработчика ничего этого нет.

Построение этого контекста занимает время — как правило, 6–12 недель до того, как офшорный разработчик начнёт работать на полной скорости. При коротком контракте вы можете вообще не достичь полной скорости. При более длинном — вы платите за разгон каждый раз, когда разработчик уходит из проекта.

Хуже того: передача контекста никогда не бывает полной. То, о чём вы не знаете, что нужно объяснить, не объясняется. Это становится багами.

Скрытый расход 3: переделки из-за неправильно понятых требований

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

Неправильно понятое требование, обнаруженное на второй день, стоит часа исправления. То же непонимание, обнаруженное на code review, стоит дня. Обнаруженное в QA — недели. Обнаруженное в продакшене — значительно больше.

В офшорных контрактах с низким качеством спецификаций и медленными циклами обратной связи процент переделок в 20–30% — норма. Это 20–30% рабочих часов разработчиков без какого-либо результата. Почасовая ставка на эти часы — стопроцентные потери.

Скрытый расход 4: потери из-за разницы часовых поясов

Разница в 6–9 часов означает, что блокер, поднятый в конце рабочего дня в Восточной Европе или Юго-Восточной Азии, получит ответ не раньше следующего утра. Один потерянный рабочий день на каждый вопрос.

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

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

Скрытый расход 5: знания, которые уходят с концом контракта

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

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

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

Как выглядит хорошее офшорное взаимодействие

Офшорная модель, которая работает, выглядит иначе, чем та, на которую подписывается большинство компаний.

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

Пересекающиеся рабочие часы. Требование 4 часов реального пересечения с вашей основной командой — это не приятный бонус, это устранение 24-часовой задержки принятия решений, которая убивает скорость. Вложите это в контракт.

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

Передача знаний как непрерывный процесс. Документация, записи архитектурных решений, комментарии к коду, записанные демонстрации — не спринт на последней неделе контракта. Знания должны накапливаться в течение всего взаимодействия, а не испаряться в конце.

Вопросы, которые стоит задать до подписания

• Кто с нашей стороны отвечает за это взаимодействие, и какую часть своего времени это займёт?
• Какова политика ротации команды? Как часто разработчики уходят из проекта?
• Какое пересечение часовых поясов у нас будет, и гарантировано ли оно контрактом?
• Как вы управляете передачей знаний при завершении взаимодействия?
• Можем ли мы посмотреть примеры документации, созданной в предыдущих проектах?
• Как выглядит путь эскалации, когда нужно решение в нерабочее время?

Если ответы расплывчаты — контракт, скорее всего, не защищает вас от описанных выше расходов.

Когда офшорная разработка экономически оправдана

Сценарий	Офшор работает	Офшор не работает
Размер команды	4+ выделенных разработчика	1–2 эпизодических участника
Длительность	12+ месяцев	Краткосрочные проекты
Качество спецификаций	Детальные проверенные спецификации	Размытые требования
Внутреннее управление	Выделенный технический лид	Перегруженная инженерная команда
Пересечение часовых поясов	4+ гарантированных часа	Только асинхронно
Преемственность знаний	Низкая ротация	Частые смены команды

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

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

Оцениваете варианты офшорной разработки или пытаетесь понять, почему существующее взаимодействие не даёт результатов? Напишите нам на hello@cimpleo.com. Мы структурировали такие взаимодействия с обеих сторон и можем сказать, что на самом деле идёт не так.