Как правильно передать задачи на аутсорс, чтобы получить реальный эффект? — 18 августа 2026 г. в 05:53:00.838
Как правильно передать задачи на аутсорс, чтобы получить реальный эффект? Журнал «БИТ» опросил участников ИТ-рынка о преимуществах и недостатках аутсорсинга разработки. Исполнительный директор ЕМДЕВ Татьяна Попова ответила на вопросы редакции: 1. Вы передали разработку на аутсорс, чтобы сэкономить. Но через полгода поняли, что потеряли контроль над кодом — не понимаете, что написано, как тестировать, как поддерживать. Как вы вернули контроль? Что изменили в процессах? Нам хватило прозорливости не попадать в эту ловушку. Критичные условия эффективного привлечения аутсорса на разработку — ключевая экспертиза, постановка задач и контроль на стороне заказчика. Когда мы привлекаем внешние ресурсы, задача обязательно прорабатывается нашим архитектором, запросы проходят наше ревью. При подключении внешних тестировщиков также идет контроль тест-кейсов и ревью кода автотестов. Зачастую наши аутсорсеры даже не видят картину целиком. С постановкой задачи они получают необходимый контекст и доступ, необходимый для ее решения. 2. Расскажите о случае, когда аутсорсер сдал проект, а ваша команда не могла его поддерживать — код нечитаемый, документации нет, архитектура странная. Сколько стоило переделывать? Как вы теперь защищаетесь от таких ситуаций? В нашей практике такого не было, но были клиенты, пришедшие с такой проблемой. Часто такие случаи происходили, когда мы занимались заказной разработкой решений на базе Liferay, платформы для портальных решений на Java с открытым исходным кодом. Приходили клиенты, выбравшие эту платформу для своей задачи и подрядчика, оказавшегося некомпетентным в этой теме. В итоге на входе заказчик давал нам немасштабируемое решение «на костылях», которое даже его предыдущий подрядчик не мог поддерживать и развивать. Приходилось делать рефакторинг, что-то переписывать на правильные рельсы сразу, что-то по мере того, как унаследованный код становился проблемой производительности или функционального развития. Самое неприятное в этих проектах было спрятано в оценках. Зная, что задачу клиента на Liferay можно сделать быстро, мы давали соответствующую оценку, а потом, когда погружались в хитросплетения некорректных решений в коде предыдущего подрядчика, застревали. Несколько проектов из-за этого были убыточны. Защищаться следует двумя путями: 1) заранее предупредить клиента о рисках и работать только с оплатой по часам (T&M, time&material), нормально переписывая код; 2) не брать такие проекты: например, мы теперь перешли на продуктовую разработку и решения делаем на базе собственных продуктов. 3. Вы сэкономили 30% бюджета на аутсорсе разработки. Но сколько вы потратили на контроль качества, код-ревью, тестирование, управление проектом? Реальная экономия оказалась меньше? Как вы ее посчитали? Контроль качества, ревью присутствуют всегда. И тут не важно, свои разработчики решают задачу или внешние. Дополнительные затраты есть за счет онбординга, развертывания необходимого окружения привлеченными специалистами и т. д. Для нас нет экономии в привлечении аутсорса. Часто это, наоборот, дороже, чем делать своими силами, так как никто не знает наш продукт лучше нас. Но аутсорс позволяет быстро масштабировать команду — мы считаем, это его единственное преимущество. 4. Как вы защищаете интеллектуальную собственность при работе с аутсорсом? Были ли случаи, когда код «утекал» или использовался в других проектах? Какие юридические и технические меры вы принимаете? Для вендора модульной платформы риск повторного использования кода ниже, чем утечки продуктовых идей. Поэтому мы комбинируем юридические меры (NDA, отчуждение ИС, запрет на reuse) с техническими: разграничение доступов, принцип минимальных прав и изоляция модулей. А ключевые компоненты — ядро и базовые сервисы — принципиально не передаются внешним командам.