Журнал «БИТ» опросил участников ИТ-рынка о преимуществах и недостатках аутсорсинга разработки. Исполнительный директор ЕМДЕВ Татьяна Попова ответила на вопросы редакции:

1. Вы передали разработку на аутсорс, чтобы сэкономить. Но через полгода поняли, что потеряли контроль над кодом — не понимаете, что написано, как тестировать, как поддерживать. Как вы вернули контроль? Что изменили в процессах?

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

2. Расскажите о случае, когда аутсорсер сдал проект, а ваша команда не могла его поддерживать — код нечитаемый, документации нет, архитектура странная. Сколько стоило переделывать? Как вы теперь защищаетесь от таких ситуаций?

В нашей практике такого не было, но были клиенты, пришедшие с такой проблемой. Часто такие случаи происходили, когда мы занимались заказной разработкой решений на базе Liferay, платформы для портальных решений на Java с открытым исходным кодом.

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

Самое неприятное в этих проектах было спрятано в оценках. Зная, что задачу клиента на Liferay можно сделать быстро, мы давали соответствующую оценку, а потом, когда погружались в хитросплетения некорректных решений в коде предыдущего подрядчика, застревали. Несколько проектов из-за этого были убыточны. Защищаться следует двумя путями:

1) заранее предупредить клиента о рисках и работать только с оплатой по часам (T&M, time&material), нормально переписывая код;
2) не брать такие проекты: например, мы теперь перешли на продуктовую разработку и решения делаем на базе собственных продуктов.

3. Вы сэкономили 30% бюджета на аутсорсе разработки. Но сколько вы потратили на контроль качества, код-ревью, тестирование, управление проектом? Реальная экономия оказалась меньше? Как вы ее посчитали?

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

4. Как вы защищаете интеллектуальную собственность при работе с аутсорсом? Были ли случаи, когда код «утекал» или использовался в других проектах? Какие юридические и технические меры вы принимаете?

Для вендора модульной платформы риск повторного использования кода ниже, чем утечки продуктовых идей. Поэтому мы комбинируем юридические меры (NDA, отчуждение ИС, запрет на reuse) с техническими: разграничение доступов, принцип минимальных прав и изоляция модулей. А ключевые компоненты — ядро и базовые сервисы — принципиально не передаются внешним командам.

5. Если вы работаете с несколькими аутсорсерами одновременно, то как обеспечиваете совместимость кода, единые стандарты, интеграцию? Были ли конфликты между подрядчиками? Как их решали?

Наш продукт — наши стандарты, а не подрядчиков. Совместимость достигается не координацией «на словах», а жесткими правилами, которые включают единые архитектурные гайдлайны, код-стайл, API-контракты и общий CI/CD-контур. Постановка задач и ревью выполняются только нашими архитекторами и тимлидами.

На старте важно четко зафиксировать границы. Ядро и архитектура остаются внутри, на аутсорсинг передаются только изолированные задачи. Необходимо сразу выстроить CI/CD, code review и тестирование как обязательные процессы. Отслеживать стоит скорость, дефекты, покрытие тестами и общее время от появления задачи до добавления в релиз.

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

Полностью материал читайте по ссылке https://bit.samag.ru/uart/more/233