Аутсорс: почему этот термин стал слишком узким для целого пласта компаний

Вам нравится термин аутсорс? Некоторых в нашей компании Redlab передергивает, когда их называют аутсорс-разработчиками. Нет, по факту люди правы. Мы помогаем разрабатывать продукты и при этом не в штате — значит, мы аутсорс. Просто «аутсорс» — это что-то из начала 2010-х.

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

Многие воспринимают аутсорс, как руки, которые могут кодить отсюда и до обеда. «При использовании аутсорсинга не получается достигать такой же гибкости и скорости разработки. Кроме того, в организации не формируются знания о том, как работает продукт», — так считает, например, CIO Райффайзенбанка Никита Швецов. И он во многом прав, если смотреть на классических аутсорс-разработчиков. Проблема в том, что мир с начала 2010-х сильно изменился: появились новые технологии, способы коммуникации, возможности для совместной удаленной работы. И появился целый пласт новых аутсорс-компаний, которые можно назвать «аутсорс 2.0».

Давайте разберем основные мифы заказчиков и посмотрим, как с ними справляется «аутсорс 2.0».

Давайте сравним условный Ашан и Amazon. В первом вроде бы выбор большой. Но в Amazon ассортимент на порядок больше, потому что там торгуют люди со всего мира. То же самое и с наймом сотрудников. Когда компания решает развивать инхаус—разработку, то она вынуждена выбирать только из тех специалистов, которые доступны в конкретной локации. Условно, в Москве. Аутсорс-компания может набирать сотрудников по всему миру. Нужных специалистов может просто не оказаться в городе (или они все уже будут заняты). Когда вы ищете по всей стране или миру, то такой проблемы нет.

Да, в Москве много профессиональных разработчиков. Но хватит ли их, чтобы полностью закрыть потребности компании? Индекс HeadHunter для ИТ-сферы в Москве один из самых низких — он колеблется около 3. Это значит, что на одну вакансию есть три резюме. В среднем по рынку труда в Москве до пандемии коронавируса индекс составлял 9. Это значит, что на одну вакансию в ИТ в три раза меньше выбор резюме, причем наличие резюме не означает, что человек ищет работу.

Есть примеры успешных компаний, у которых разработка находится в регионах. Например, Miro из Перми, который недавно привлек $50 млн инвестиций. Ecwid из Ульяновска, привлекший $42 млн. Компания iSpring из Йошкар-Олы, большинство заказчиков которой в США. Когда компания ставит перед своим HR-отделом задачу собрать идеальную инсорс-команду разработки, а высококвалифицированных кадров не хватает, то команду начинают разбавлять менее профессиональными разработчиками. Зачем толпиться на рынке, где идут войны за кадры, когда можно посмотреть шире? Если не привязываться к конкретному месту, то воронка кандидатов по определению больше.

Есть еще один фактор — рынок разработчиков в Москве перегрет. По данным исследования HeadHunter по итогам 2019 года, средняя зарплата специалиста по разработке ПО составила 140 562 рубля, в Петербурге — 124 773 рубля, а регионах — 84 773 рубля. Разница значительная. При этом в регионах есть не менее профессиональные разработчики. Более того, аутсорс-разработчик может собирать талантливых специалистов по всему миру, а не ограничиваться только одной страной. Да, есть нюансы с тем, чтобы их найти и наладить с ними работу, но HR компании, которая изначально ориентирована на таких специалистов, справляется с этим. Тем более при найме в Москве нет гарантий, что вашего тимлида не сманят на более высокую зарплату. Согласно другому исследованию HeadHunter, ИТ и разработка — вторая по популярности категория для переманивания сотрудников (на первом месте идут продажи).

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

Раз разработчики сидят в офисе, то они больше вовлечены в проект? Это не всегда так. Вовлеченность невозможно создать искусственно. В недавнем фильме Юрия Дудя про Кремниевую Долину основатель Ecwid Руслан Фазлыев выразил интересную мысль: в Кремниевой Долине создали условия, которые позволяют компаниям процветать, а в России хотят всех умных собрать в одно место и ждать от них результата. Но программисты — это не муравьи, которых можно согнать вместе, и они гарантированно выдадут результат. Ключевой фактор успеха в другом — в интересе к проекту и созданной вокруг него инфраструктуре, которая мотивируем разработчика. Важен интерес к проекту и экосистема вокруг.

Если изначально в модели развития компании был заложен формат удаленной работы, то HR-служба проводит отбор с учетом этих особенностей. Проверяют, готов ли конкретный специалист к удаленному формату. У него должно быть все хорошо с софт скиллами, самоорганизацией, дисциплиной, мотивацией, знанием инструментария. Таким образом, команда не просто разработчик, она состоит из уже заинтересованных людей, которые просто сидят не в одном офисе. Человек сам выбирает удобный и продуктивный для него формат работы — в локальном офисе или дома, что только способствует результату. Во многих компаниях есть люди, которые приходят поработать в субботу или воскресенье в спокойной обстановке. На удаленке так постоянно. У нас в Ульяновске есть офис. Сотрудники обычно спрашивают в чате, есть ли кто-то в офисе. И если есть, то предпочитают оставаться дома. Для них так эффективнее. А недостаток личного общения восполняется в пятницу, когда все собираются в офисе.

Сейчас намного больше инструментов для взаимодействия удаленных команд, чем 5-10 лет назад. Slack, Zoom, Miro и еще с десяток других. Когда в России случилась пандемия коронавируса, то многие стали работать удаленно. И оказалось, что на удаленке тоже можно работать, причем часто эффективнее, чем в офисе.

Если говорить в парадигме старых аутсорс-команд, когда заказчик нанимает только руки, то возможны проблемы. «Давайте обсудим сначала с нашим сейлз-менеджером, через неделю назначим встречу с тимлидом». Но «аутсорс 2.0» работает по-другому. Включение в проект происходит моментально — для этого достаточно подключить через Slack или Zoom нужного специалиста и обсудить с ним задачу. Аутсорс-команды могут точно также работать недельными спринтами, устраивать летучки каждое утро, проверять гипотезы и быстро делать MVP. Важнее находиться в процессе головой, а не телом. А современные сервисы для совместной работы нивелируют или полностью устраняют все другие проблемы.

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

Хорошо, чтобы в компании были как минимум два человека — product-owner и архитектор системы. Это те люди, которые придумывают продукт, его архитектору и знают, как все должно работать. Для остальных позиций наличие сотрудника в штате не является обязательным. Если голова внутри заказчика, то все остальное можно закрыть аутсорс-разработчиками. Команд может быть несколько — под каждый продукт. Но если все они работают в концепции, которую формируют люди в штате компании, то проблем можно избежать.

Можно ли взять product-owner и архитектора системы на аутсорсе? Да, обе эти роли могут быть и вне компании. Главное, чтобы та информация, которую они аккумулируют, артефакты, которые создают, оставались у клиента. Эта информация должна быть актуальной, структурированной, поддерживаемой. И тогда, если, например, product-owner покинет проект, то новый человек посмотрит на базу знаний, архитектуру и довольно быстро разберется.

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

А как распознать «аутсорс 2.0», если 95% на рынке работают в старой парадигме? Например, можно поговорить с предыдущими заказчиками и узнать про опыт работы этого подрядчика. Еще один признак — поток исходящей от команды информации. На нашем примере могу сказать, что после обращения к нам заказчика, мы тут же проходим с ним подробный чек лист и предлагаем разные решения. По-другому не получается. Мы не просто руки, мы в первую очередь консультанты — вникаем в проект и помогаем заказчику понять, как сделать лучше. Причем это происходит на всех уровнях — сначала сейлз-менеджер, потом начальник производства, потом аналитики и так далее. Думаю, что так работают и другие компании, которые можно причислить к «аутсорс 2.0». Заказчик только позвонил, а его проект уже разобрали по косточкам и завалили вопросами.

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

Называть аутсорсом компании, которые хотят быть для заказчика не только руками, но и головой, не очень правильно. Это немного не то слово. Такие компании скорее являются партнерами в разработке. Важнее не выполнить в точности ТЗ и получить деньги, а помочь заказчику создать продукт и добиться успеха. Чем успешнее заказчик, тем успешнее мы. Причем качественные партнерские отношения складываются, когда аутсорс-команда прикрепляется к проекту и готова в подобном режиме работать более полугода. Мир поменялся, а нового слова для подобных компаний не придумали. Но таких компаний категории «аутсорс 2.0» будет появляться все больше. Теперь можно не нанимать себе в штат толпу людей, чтобы делать качественный продукт. Разработчики справляются со своими задачами удаленно, и их уровень вовлеченности при этом никак не страдает. В итоге, они получают возможность работать в комфортной для себя среде, а заказчик — возможность решать сложнейшие задачи не упираясь в ограничения своей штатной команды.