Explore
Уложитесь в мой дедлайн?
Oops! Something went wrong while submitting the form.
Если с внутренней разработкой все более менее ясно, то аутсорс разработки часто путают с аутстафом. Но это два разных термина. Чтобы не было путаницы и мы были на одной волне в понимании, поясним, что есть что.
Аутсорс — это когда компания-клиент передает задачи или функции компании- подрядчику. Purrweb работает именно по такой модели. Например, приходит стартапер с $50 тыс. и идеей: сделать мэтчинговую платформу для музыкантов, чтобы гитарист виртуоз мог найти барабанщика и сколотить свою группу. Мы составляем оценку, согласуем со стартапером, и делаем приложение “под ключ”.
Аутстаф — это когда компания-клиент получает доступ к квалифицированным сотрудникам компании-подрядчика. Мы не работаем по такой модели. Но если бы занялись, выглядело бы это так.
Приходит тот же стартапер, но у него уже есть команда и 3 месяца она разрабатывала эту самую платформу. Но прямо перед релизом фронтендер устал от работы в офисе и решил уйти на фриланс. Самостоятельно фронтендера по щелчку пальцев не найдешь, а с помощью аутстаффинга такое возможно. Purrweb выделяет разработчика с двухлетним опытом на React Native и на время реализации проекта он выполняет задачи, которые ему ставит тимлид команды стартапера.
Теперь когда мы определились в понятиях, разложим по полочкам все плюсы и минусы аутсорса разработчиков.
Стоимость в 2 раза ниже. Часовые ставки разработчиков из США и Восточной Европы отличаются почти в 2,5 раза. Средние часовые ставки senior-разработчика в США — $78-125, а в Восточной Европе — $30-59. Причём по качеству и квалификации ребята из Украины не уступают американцам. А иногда даже и превосходят. Опыт WhatsApp тому подтверждение.
История аутсорса разработчиков в этой компании началась в 2009 году. Тогда рынок мессенджеров был еще пуст, но уже начинали появляться первые попытки в виде мессенджеров Blackberry и Facebook. Действовать нужно было быстро, не было времени собирать свою команду и распределять роли в IT команде. Поэтому WhatsApp отдали на аутсорс разработку мобильного приложения для iOS группе программистов из России. Это помогло сэкономить на постоянных издержках без потери в качестве и скорости.
Нет ресурсных “просадок” по проекту. Аутсорс разработки — это более гибкий подход с точки зрения состава команды. Например, на проекте 3 месяца работали тимлид, бэкендер, фронтендер и QA. После релиза такая большая команда уже не нужна. Хватит бэкендера и фронтендера на 20 часов, и QA на 5 часов в неделю. В аутсорсе разработки есть такая опция. А если ребята в штате, то придется искать дополнительные задачи или платить за неполный загруз специалистов.
Или другой вариант: сроки поджимают и нужно за 2 месяца разработать продукт, на который обычно нужно 3. Похожая ситуация была на нашем проекте Headcount: B2B-сервис для перевода денег за работу подрядчикам по всему миру. Вообще на такие проекты мы ставим 3 разработчиков, но заказчику нужен был готовый продукт через 2 месяца. Поэтому мы добавили еще 2 разработчиков, полетели в разработку и успели в срок.
Не ограничиваетесь локальным пулом талантов. В условном Хабаровске сложнее найти разработчика на Ruby on Rails, нежели в Москве. Просто потому что сейчас все дороги ведут в столицу. Но перевозить уже собранную команду из 20 человек только для того, чтобы закрыть пару позиций, нелогично. Аутсорс разработки позволяет не ограничиваться тем, что предлагает рынок одного города.
Например, еще в 1999 на старте проекта Alibaba отдавал разработку на аутсорс. На тот момент в Китае не было специалистов уровня, которые могли бы обеспечить быстрый рост платформы. Плюсом к этому, основатель компании решил сфокусироваться на ключевой компетенции Alibaba — eСommerce и воспользоваться сторонней экспертизой. Как показывает история, стратегия оказалось успешной: капитализация Alibaba $570 млрд.
Можно делегировать отдельные процессы. Не обязательно отдавать всю разработку на аутсорс. Можно делегировать только часть функционала и задач, например тимлидство или проектный менеджмент. Так было на проекте Mamado — сервисе для родителей, которым нужны товары и услуги для детей.
Заказчица пришла к нам с готовым приложением, которое писали год, но так и не довели до работающего состояния. Нужно было помочь докрутить приложение и довести до релиза. Попутно налаживали менеджмент: скрам, спринты и ежедневные митапы. В результате приложение зарелизили в срок, а команда заказчицы теперь понимает, как вести проект, чтобы укладываться в дедлайны.
Низкая цена ≠ высокое качество. Чудес не бывает: выбирая аутсорсера за $20/час, наивно ожидать результат на $50. За качественный продукт нужно платить. Чтобы не получить на выходе криво написанный код, нужно обращаться к компаниям из середины ценовой вилки или чуть выше.
Не лучший стек, а такой, какой есть. Аутсорсер может предложить не самые подходящие инструменты, а то, с чем у него есть опыт работы. И здесь важно, чтобы ребята, предлагающие аутсорс разработки, могли дать объективную оценку того, действительно ли они смогут помочь или нет.
Например, наша ключевая экспертиза — React, React Native и Electron. Когда к нам приходит проект на оценку, конечно, мы ищем варианты реализации на нашем стеке. Но если видим, что наш стек не справляется с нужным функционалом, мы говорим об этом на берегу и ищем компромиссные решения.
Подрядчик не понимает сложность задачи. Молодым веб студиям не хватает опыта и они побыстрее хотят закрыть сделку, следуя логике: “сейчас продадим, потом разберемся”. Это неэффективный процесс, так как сложно прогнозировать сроки и создавать ожидания у клиента. Именно поэтому на сложных проектах, где не хватает исходной информации и непонятны бизнес-требования к приложению, мы предлагаем услугу по аналитике и прототипированию. После этого заказчик видит, как будет работать приложение и такой ли продукт ему нужен. А мы может дать точную оценку на разработку.
Барьеры: язык, онлайн, часовые пояса. Вам очень повезло, если аутсорсер говорит на том же языке, что и вы, и работает в том же часовом поясе. Но, чаще всего, ситуация обстоит иначе: общаться приходится на английском и есть разница во времени. И каким бы хорошим ни был английский у проектного менеджера, все равно есть место недопониманиям, которые намного легче прояснять на родном языке. А в случае с часовыми поясами может получиться ситуация, в которой разница в 11 часов не играет на руку продуктивности и начинаются поздние созвоны.
Онлайн общение менее доступное и естественное. Чтобы обсудить пару рабочих вопросов, придется сначала выбрать удобное время для обоих. Когда наконец-таки созвонились, у кого-то может начать барахлить интернет. Еще 5 минут на то, чтобы починить роутер или переключиться на мобильный интернет. И вот спустя суммарные 24 часа с момента возникновения проблемы, вы начали ее решать.
Самый хрупкий момент жизненного цикла стартапа — это начало. Бизнес ангелы еще не стоят в очереди, чтобы вложить свои $100K, продукта как такового еще нет. Поэтому пока нет продукта, который приносит прибыль, брать на себя зарплаты, аренду и налоги просто опасно для кошелька. Аутсорс разработчиков с этой точки зрения более предсказуем и прогнозируем. Если аутсорсить в веб-студию, то на руках будет детальная оценка, со сроками и планом.
Когда нужно сделать сайт или CMS с понятным вам функционалом, лучше довериться разработке на аутсорсе. Это тот продукт, который один раз хорошо сделал и пользуйся. Не нужно собирать команду или держать штат на поддержке. По такой схеме работает ФК “Спартак”. У них есть свой IT отдел, который занимается билетным сервисом и инфраструктурой стадиона, а разработку сайтов и приложений отдают аутсорс.
Когда уже есть команда, но не хватает отлаженного менеджмента или экспертизы в какой-то области, можно отдать процесс на аутсорс — тот самый случай проекта Mamado. Или например, у вас есть HTML/CSS разработчики, но вам нужно разработать мобильное приложение.
Разберем аргументы за и против поиска команды для разработки.
Внутренняя экспертиза. В ходе разработки приложения самостоятельно команда набивает свои шишки, но при этом и нарабатывает свою экспертизу. Работает это по принципу маховика. Сначала нужны гигантские усилия, чтобы сдвинуть маховик с места. Но после того как его сдвинули, он наращивает потенциал и даёт рост. 3 месяца команда притирается друг к другу и продукту. А затем когда продукт уже запущен, команда уже “в теме” и на доработки требует намного меньше времени, нежели раньше.
Быстрый багофикс после релиза. Через месяц после релиза, когда придет условно 1000 пользователей, могут вылезти баги. Команда на аутсорсе к тому моменту уже будет занята другим проектом. И даже беря в расчет гибкость аутсорса разработки, быстрее чем за 2-3 дня подключить на проект нового аутсорс-разработчика не получится. Все это время приложение или сайт будут простаивать. Когда после релиза уже есть своя команда, намного проще прибежать со словами “у нас сайт упал” и ребята сразу возьмутся за работу.
Вовлеченность команды. С внутренней командой, как ни крути, больше персональных точек соприкосновения: корпоративы, тимбилдинг, LFP. Это улучшает корпоративную культуру и сплоченность в команде, что напрямую влияет на настроение тиммейтов и их вовлеченность в свою работу.
Для аутсорс-команды ваш стартап — это еще один проект в Jira, который нужно довести до релиза. Как правило, подрядчик на аутсорсе разработки следуют заранее согласованному плану и места для инициативы там мало.
Прозрачная коммуникация. Общение в офлайне с людьми, говорящими на вашем родном языке — простое и понятное. Если нужно, можно подойти к коллеге и быстро обговорить рабочие моменты. Не нужно тратить время на стыковку расписаний, танцы с бубном вокруг роутера.
Разгон маховика — это время. Срок вывода готового продукта на рынок растягивается. На сбор и распределение ролей в IT команде нужно время. Чтобы сдвинуть маховик с места нужно минимум 1-2 месяца с начала работы команды над проектом. Чтобы собрать команду разработчиков из 5-7 человек, нужно потратить еще 2-3 месяца. Во время “разгона” сотрудникам нужно платить зарплату — постоянные издержки. И не факт, что результат реально будет. Должно сойтись много звезд: опыт разработчиков, грамотный проектный менеджмент, сплоченность команды.
Скрытые издержки. Своя команда — это не только зарплаты, но и больничные, отпуска, страховка, пенсионные отчисления, налоги. Да и поиск команды для разработки займет в лучшем случае 1,5 месяца. В США например в среднем нужно 43 дня, чтобы нанять только одного разработчика. Причем не всегда можно найти IT специалистов своими силами и заполнить все роли в IT команде. Иногда без рекрутингового агентства просто не обойтись. Каждому сотруднику нужно дать ноутбук, монитор, стол и стул. Не забываем про пространство, где все это поставить.
Отвлечения при личном общении. Коммуникация в офлайне более гладкая и доступная, но это может идти во вред продуктивности. Есть место для разговоров не по делу возле кофе-машины. Больше отвлечений в виде коллег, разговаривающих вокруг. При этом вы отвечаете за результат работы команды, а не аутсорсер.
Ответственность за команду. В начале проекта ключевой риск лежит в самом продукте. Нужна ли миру социальная сеть для художников? Или новый агрегатор такси заказов? Не узнаешь, пока не сделаешь продукт и не попробуешь. В случае с аутсорсом разработки, если не получилось, то команда просто переключится на другой проект. Собирая свою команду, отчасти берешь ответственность за будущее своих тиммейтов. Поэтому когда проект не выгорает страдаете не только вы, но и команда, потерявшая работу.
После запуска продукта довольно быстро становится понятно, нужен ли он кому-то или нет. По нашему опыту стартаперы пользуются аутсорсом разработки для создания MVP и в это время ищут своего CTO, который забирает готовый проект после релиза. Пока проект на поддержке CTO, набирается команда, которая дальше занимается разработкой приложения самостоятельно. Такой сценарий менее стрессовый и резкий для стартапера, так как процесс поиска команды для разработки идет параллельно с аутсорс разработкой и экономится время.
Если вы собираетесь заказывать на аутсорсе проект с годовым бюджетом от 8 миллионов рублей в год, стоит задуматься о поиске команды для разработки в штате. При таких бюджетах затраты на аренду, зарплаты и налоги в долгосрочной перспективе окупятся. В случае если бюджет ниже, стоит нанять команду на подряде, выйдет дешевле.
Допустим, у вас уже далеко не стартап, а вполне себе работающая продуктовая компания. И вы решили запустить новое направление своего продукта. В таком случае логичнее собрать еще одну команду, а не отдавать на аутсорс разработку. Все, что нужно — нанять разработчиков и масштабировать отработанные процессы менеджмента и разработки на новый проект.
Чтобы сделать финальный выбор между внутренней командой и аутсорсом, нужно ответить на 5 вопросов:
Держа ответы на эти вопросы в одной руке и нашу статью в другой, вы сможете сделать взвешенный выбор. Если же выбор пал в сторону разработки на аутсорсе, мы готовы помочь.
Аутсорс выгоднее на старте продукта и при разовых задачах: нет затрат на рабочее место, оборудование, ДМС и налоги с ФОТ. Штатный middle-разработчик обходится компании в 180 000–250 000 ₽ в месяц с учётом всех отчислений, тогда как аутсорс-команда для MVP фиксирует стоимость ещё на этапе сметы. Инхаус-команда оправдывает себя, когда продукт уже работает и требует постоянной поддержки и итераций — то есть с момента, когда объём задач стабильно превышает 3–4 специалиста на полный рабочий день.
Три ключевых риска: потеря контекста при смене подрядчика, зависимость от чужого графика при срочных задачах и сложность с конфиденциальностью кода. Чтобы снизить их, требуйте NDA на старте, фиксируйте в договоре передачу всех прав на код и документацию, держите техническое задание и репозиторий на своей стороне. Хорошая аутсорс-компания обеспечивает выделенного менеджера проекта и еженедельные демо — это стандартный минимум, который позволяет сохранять контроль без погружения в операционку.
Наём одного senior-разработчика в России занимает в среднем 2–3 месяца: размещение вакансии, воронка откликов, техническое интервью, оффер и онбординг. Сформировать команду из 4–5 человек — от 4 до 6 месяцев. Аутсорс-команда выходит на проект за 1–2 недели после подписания договора: состав уже сработан, процессы выстроены. Для стартапов, которым важно попасть в окно рынка, разница в скорости старта критична.
Аутсорс наиболее эффективен для MVP и прототипов с ограниченным бюджетом, для проектов с чётко ограниченным скоупом (мобильное приложение, редизайн, интеграция с API), а также когда нужна экспертиза в узкой технологии — например React Native или конкретный облачный стек — которой нет внутри компании. Инхаус предпочтительнее, когда продукт является основным бизнес-активом и требует непрерывного развития, глубокой интеграции с внутренними системами и быстрой реакции на инциденты.
Гибридная модель — это сочетание штатной команды и аутсорс-подрядчика. Типичная схема: инхаус-тимлид или технический директор управляет продуктом и принимает архитектурные решения, а аутсорс-команда выполняет разработку под его руководством. Такой подход применяют компании, у которых есть продуктовая экспертиза, но не хватает ресурсов для закрытия всех задач силами штата. Он позволяет масштабировать разработку без долгосрочных обязательств по найму и снижает риски зависимости от одного подрядчика.
Оценивайте по четырём критериям: наличие релевантных кейсов в вашей нише (попросите портфолио с описанием задачи и результата), прозрачность процессов (как фиксируется скоуп, как отслеживается прогресс), юридическое оформление (договор, передача прав на код, NDA) и коммуникация на старте — насколько быстро и конкретно компания отвечает на вопросы до подписания. Рейтинги на Clutch и отзывы прошлых клиентов дают дополнительную точку верификации, но не заменяют прямое общение с референс-заказчиком.
.svg)
%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1).png)
%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1).png)
%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1).png)
