IT-аутсорсинг: когда стоит передать работу подрядчикам

Привет! На связи Александр Погребняк, управляющий директор в компании IceRock. За 7 лет разработки мобильных приложений мы не только исполняли роль подрядчика, но и сами искали субподрядчиков для задач клиента, которые не могли выполнить самостоятельно.

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

Делегировать задачи субподрядчикам имеет смысл в двух ситуациях:

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

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

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

Наем подрядчика происходит в два этапа: поиск и отбор кандидата.

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

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

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

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

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

Обязательно оформляйте юридическую документацию:

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

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

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

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

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

А вас когда-нибудь подводили подрядчики? Как справлялись?