Понятие аутсорсинга в IT существует уже более 30 лет и в связи с ускоренной цифровизацией традиционных отраслей становится все более популярным. По экспертным оценкам, рынок подобных услуг (а отдать партнерам можно все – от заказной разработки до технической поддержки систем) по итогам 2021 года достигнет 351 млрд долларов. О том, когда и почему порой необходимо перейти на аутсорс и как правильно выбрать подрядчика, рассказывает генеральный директор финтех-компании RBK.money и фаундер IT-компании Osnova Денис Бурлаков.
Почему аутсорсинг?
Причин для перехода на аутсорс может быть несколько. Во-первых, нехватка компетенций: у существующей команды может не быть необходимых навыков, а развивать их самостоятельно ради разового проекта долго и дорого. Однако даже если проект не разовый, есть смысл переложить непрофильные риски на своих подрядчиков, которые, как правило, работают в своей нише много лет и накопили существенные компетенции.
Это актуально не только для ИТ. Например, автопроизводитель не будет заниматься разработкой машинных масел, но привлечет партнера на аутсорсе, чтобы техника была заправлена качественным продуктом.
Вторая причина – дефицит ресурсов для масштабирования или ускорения вывода продукта на рынок. Исключительно увеличением штата эту проблему не решить – требуется создание работоспособной команды с распределенными ролями, доказанными компетенциями. В противном случае мы получим 30 человек, которые не умеют взаимодействовать между собой. Поскольку аутсорсинг возможен не только в виде обычного договора субподряда, но и в формате body shopping – аренды специалистов, это может стать хорошим выходом из ситуации.
Однако следует помнить, что в первом случае партнер отвечает за проект целиком, а в ситуации с body shopping ответственность за результат лежит на заказчике, который выступает работодателем для чужой команды.
Как выбрать партнера?
Главное на старте – трезво оценить способность партнера реализовать проект. Очевидно, что для задач, связанных с биллингом, вряд ли стоит нанимать команду, которая специализируется на софте для «умного дома» и управления недвижимостью. Нет ничего плохого в том, чтобы осваивать новые области, но опыта у компании-новичка явно будет меньше, чем у тех, кто много лет не рынке. Мы, например, как специалисты в интернет-эквайринге, не беремся за логистические задачи, не программируем систему управления самолетами, потому что нет понимания бизнес-потребностей и тонкостей процессов.
Еще один критически важный момент: те, кому вы хотите доверить софтверную разработку или обслуживание систем, должны понимать стек технологий, с которым предстоит работать. Иными словами, важно оценить capability maturity model – техническую зрелость потенциального аутсорсера, а для этого проговорить, как исполнители будут узнавать о проблемах заказчика, что они будут делать при появлении этих проблем, как поддерживается service level agreement.
К сожалению, в большинстве компаний процессы не структурированы, а держатся на двоих-троих энтузиастах, и выбывание любого из них – катастрофа для проекта.
Цена как главный фактор
Когда первые стадии пройдены, и вы понимаете, что компания в этом бизнесе не новичок, у нее есть экспертиза и опыт работы с нужными технологическими стеками, начинается обсуждение стоимости. На этом этапе подозрительным будет предложение цены ниже рыночной: демпинг может свидетельствовать о том, что дела у потенциального аутсорсера идут плохо и других заказчиков нет, что может быть следствием низкого качества работ.
Оценка качества управления проектами при выборе партнера имеет исключительное значение. Заказчик должен знать, как руководители проектов определяют масштаб работ, выстраивают календарный план, следят за соблюдением дедлайнов. В любом проекте должны быть контрольные точки и понимание у исполнителей, когда их нужно достичь и что для этого потребуется.
В противном случае под разговоры про agile-технологии и scrum создается иллюзия управления проектами, а на деле сроки начинают плыть, бюджет расти, команда разработки меняется (иногда по несколько раз), а результата так и нет.
Помимо проверки качества управления, необходимо периодически проводить контроль качества самого программного продукта и документировать действия на каждом этапе разработки, в том числе на стадии формирования бизнес-требований и системного анализа. В противном случае последствия некачественной проработки на каждом этапе будут накапливаться как снежный ком и в конечно итоге приведут к тому, что решение либо не работает, либо не выполняет те функции, которые требуются.