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

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

1. Недостаточное знание предметной области

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

• Постарайтесь найти компанию, которая уже разрабатывала подобный продукт или работала с вашей или смежной отраслью. Это можно сделать, изучая портфолио и кейсы потенциальных подрядчиков;
• Пообщайтесь с представителем компании, чтобы удостовериться в заявленном опыте;
• Выделите время на онбординг. В этот период вам нужно объяснить внешней команде основные цели предстоящей работы, рассказать о важных нюансах и предоставить им глоссарий. Возможно, стоит создать welcome презентацию, гайд или чек лист, который поможет быстрее адаптироваться, узнать о ценностях компании, особенностях отрасли и приступить к работе.

2. Текучесть кадров

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

Но внешние разработчики точно не увольняются чаще внутренних. IT-специалистов в аутсорс компаниях задерживает возможность обучения, менторства, разнообразие проектов, используемых технологий и “своя” среда. Также при увольнении аутсорс-компания оперативно предоставит нового специалиста на проект, что сложнее обеспечить при работе со внутренней командой.

• Обговорите последствия смены разработчика и узнайте, как это решает компания-подрядчик. Можно даже прописать в договоре, как должна происходить замена.
• Чтобы подключение нового специалиста было безболезненным, выделите время на его посвящение в планы проекта и знакомство с компанией (см. пункт про онбординг выше).
• Уточните, как разработчики документируют код. Если они “не тратят на это ваше время”, нужно искать другую компанию. Почему? Документирование кода – это уважение к коллегам и забота о новых сотрудниках, которые смогут в разы быстрее включиться в проект. Также это значительно упрощает поддержку и дальнейшее развитие проекта.

3. Более высокая стоимость команды

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

Аутсорсинг может даже снизить затраты на разработку за счет опыта и высокой компетенции специалистов, бесплатного (для вас) менторства среди аутсорс-разработчиков, а также работы с другими регионами и странами, где зарплаты ниже.

Как не допустить перерасхода бюджета:

• Убедитесь, что в команде присутствует грамотный тимлид, который будет эффективно распределять задачи между участниками и управлять процессом.
• Следите за тем, как происходит замена и добавление разработчиков. Излишнее количество людей ведет к удорожанию продукта. Также недобросовестный подрядчик может заменять сотрудников с более высоким грейдом на менее квалифицированных, не меняя для вас стоимость найма. Такие замены могут привести к увеличению времени, затраченного на разработку.

4. Удаленная работа

Отсутствие личной коммуникации – это особенность не столько аутсорсинга, сколько формата удаленной работы в принципе. Вообще, этот риск достаточно условный: если вы успели научиться работать с распределенной командой, то никаких проблем с удаленкой не возникнет.

• Поддерживайте общение с использованием видеозвонков (митов). Выясните комфортную частоту таких встреч, составьте расписание и придерживаться его.
• Убедитесь, что ведущие всех плановых митингов уточняют понимание задач и проверяют согласие с ними всех участников. Они также должны прислушиваться и уважать мнение команды. Если же не согласны с ним – аргументировать такие решения. Для обеспечения комфортной работы также важно учитывать soft skills разработчиков.

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

5. Сохранность конфиденциальной информации

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

• До передачи конфиденциальной информации заключите с поставщиком соглашение о неразглашении (NDA). В соглашении должен быть указан четкий перечень информации, которую нельзя разглашать, порядок обращения и лица, которые могут получить доступ к ней. Размер неустойки и санкции за разглашение также стоит прописать.
• Ещё на этапе выбора проведите комплексную проверку контрагента. Можно сделать это самостоятельно или отдать задачу вашей службе безопасности.
• Если ваш продукт требует специальных мер обеспечения безопасности данных и кода, то отдавайте разработку продукта партнеру, который имеет лицензию ФСТЭК России на деятельность по технической защите конфиденциальной информации.

Учтите, что любые спецмеры приведут к повышению стоимости конечного продукта.

Общие советы по работе с внешней командой

Начать работу с простого проекта

При работе с масштабным проектом снизить риски позволит “пробный период” – маленький проект, или какая то обособленная часть от основного, например, MVP или POC. Чтобы удостовериться, что команда вам подходит, проверить её вовлеченность, качество конечного продукта и соответствие срокам, хватит одного-двух месяцев. Это может показаться излишней перестраховкой, но замена команды посреди проекта, написание плохого кода или нарушение сроков повлечет гораздо бОльшие потери.

Использовать штатного проджекта

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

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

Гайд “Как организовать разработку IT продукта с привлечением внешней команды”

Получить гайд

Прописать в договоре гарантийный срок

Даже лучшая команда может случайно пропустить какой-то баг. А QA могут не обнаружить его во время тестирования.

Чтобы эти проблемы вас не беспокоили, можно прописать гарантийный срок на код, в течение которого при нахождении какой-то ошибки команда без доплат её устранит.

В итоге

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