Аутстаф VS Аутсорс: что полезнее бизнесу и разработчикам
Расскажем, почему нужно менять подход к моделям сотрудничества. Теперь во главе бизнес ценность, а не то, в каком виде мы продаем разработку.
Различия моделей
Для компании-разработчика и аутсорс, и аутстаф предполагают продажу человеко-часов заказчику. Разница будет в величине ответственности сторон. Для аутстафа мы выделяем разработчиков на проект заказчика. Выполнение работ ребятами – наша ответственность. Менеджментом и отслеживанием успешности продукта занимаются люди на стороне заказчика, и об этих процессах мы можем вовсе не иметь представления. Иными словами мы «продаем руки», которыми не управляем.
Аутсорс – это когда заказчик приходит и говорит: «Сделайте мне продукт». Ну, или «часть продукта». Нужно создать нечто такое, что принесет заказчику деньги. Для этого предстоит принять нужные решения, правильно выстроить и выполнить работу. При этом мы знаем, что должен «уметь» продукт, какую выгоду он должен принести, как должен работать и почему заказчику именно такой продукт нужен. Знаем мы это, потому что понимаем задачу. Так, мы продаем не просто «руки», а экспертизу.
Экспертиза – это, помимо умения качественно закрывать задачи, погружение в бизнес, проактивность и ответственность за результат. Ответственность заказчика здесь выражена в желании подробно описать свои ожидания и синхронизироваться с нами на демо.
Везде важно понять задачу
Не всегда при обсуждении работ на аутстафе клиент готов делиться подробностями проекта, на который нанимает внешние кадры. Просто есть задачи, и их просто нужно закрыть. Однако нет задач, которые не работали бы на оценимую пользу.
Даже если на проекте нужно «просто закрыть техдолг», по завершении работ можно будет оценить пользу.
Например, если решение багов ведёт к большей отказоустойчивости сервиса, то тем самым увеличивает лояльность пользователя. Тот с меньшей вероятностью столкнется с ошибкой. Больше довольных пользователей – больше выгод (пользы) для бизнеса. Подобные связи могут быть и менее очевидными, но важно раскопать их.
Если на старте знать, для чего нужны «рабочие руки», из большой команды специалистов проще подобрать наиболее подходящих – со схожим опытом, например. Это выгодно прежде всего для заказчика – он потратит меньше времени на онбординг вспомогательных кадров и быстрее увидит пополнение колонки «done».
Мы становимся эффективнее, когда понимаем, на какой результат работаем. Поэтому продавать просто «руки», которым не раскрыли сути проекта, нам не так интересно, а заказчикам – не так полезно.
Важнее не формат, а бизнес-ценность
В идеальном мире мы всегда знаем, каким должен быть результат работы, будь она в аутсорс- или аутстаф-формате. Так мы можем предложить не просто технические умения, а комплексную экспертизу в разработке продуктов, даже если нужно «просто закрыть техдолг».
Бизнес, который приходит за заказной разработкой, хочет знать, за что платит деньги. Приятнее платить не по факту отработанных часов, а за улучшенную функциональность.
На аутстафе, если не прояснить цели на старте, сложно установить прямую связь между выполненной работой и изменениями в продукте. Поэтому понять задачу ценно. Да и нам, как разработчикам, приятнее отчитываться о комплексном результате, а не просто о закрытых задачах.
Оптом выгоднее
Можно выделять команды, а не разработчиков по одному. Получится своеобразная смесь из аутсорса и аутстафа.
Как это работает: у заказчика на проекте укомплектованы все роли кроме, например, фронтендеров. Мы получаем запрос, понимаем задачу, оцениваем проект, время и выделяем нужных для работы людей. Заказчик покупает экспертную команду, а не личности по одной. Если кто-то из команды не сможет в определенный момент работать, то мы сможем заменить без потери качества и долгих согласований.
Такой подход берет от аутстафа покупку-продажу часов и «рабочих рук», а от аутсорса – продуктовое видение задачи и экспертизу с учетом целей проекта. Взять готовую команду с проверенным опытом проще, чем тратить время на HR-активности: поиск, найм и онбординг. Всё это отдалит время релиза, получение прибыли и результатов.
Секрет напоследок
Заказчики порой не хотят распыляться на объяснения, потому что могут и сами не видеть четкой связи между тем самым условным «закрытием техдолга» разработчиками и получением дополнительной прибыли. Ключ к успеху здесь – эффективные переговоры, у которых две цели: познакомить заказчика со своей экспертизой и сделать так, чтобы заказчик познакомил нас со своим бизнесом и его ближайшими целями.
Спасибо, что обратили внимание на наш материал! Теперь в мире стало больше людей, знакомых с нашей работой. Кстати, если вы работаете так же или, наоборот, совершенно не согласны с нашим видением, то расскажите об этом в комментариях! Интересно обсудить разные подходы и впитать опыт со стороны.
При всех преимуществах, обе модели обладают общим существенным недостатком: отсутствие административной зависимости от Заказчика. Этот недостаток приводит к деградации функции при аутсорсинге (я бы предложил в качестве определения аутсорсинга - "передача профильных или непрофильных функций на сторону") и снижению эффективности процессов при аутстаффинге (здесь мое определение аутстаффинга - "привлечение стороннего персонала для решения операционных задач").
Мы наблюдаем совершенно иную картину. Как работает аутсорс с точки зрения бизнеса? К вам приходит подрядчик и говорит, что ту задачу, которую вы хотите решить, он выполнит за МЕНЬШИЕ деньги, нежели это сможет сделать ваша внутренняя команда либо команда на аутстаффе. Более того, подрядчик собирается это сделать не только быстрее и эффективнее, так еще и заработать на этом, то есть маржу свою получить.
Иными словами, мы видим тут не деградацию функции, а наоборот рост производительности и эффективности, конечно, только если заказчик сможет хорошо выполнять роль заказчика. Но если заказчик не может корректно ставить свои бизнес-цели, то у него проблемы далеко не в разработке, а в общей системе управления.
Как работает аутстафф? По сути это просто долговременная аренда сотрудников, которая позволяет быстро расширять и сокращать команду, не меняя штатное расписание. К такому механизму прибегают, когда хотят сохранить экспертизу у домашней команды, сформировав из нее ядро, а оболочку ядра собрать из арендованных сотрудников.
Есть еще краткосрочная аренда команды, называется T&M, но это нужно компаниям без больших компетенций в IT.
Теперь что даёт административная зависимость от заказчика. Даёт она драматическое падение эффективности. Например, мы работали с одним из крупных российских банков через одну из их дочек. После возникновения финансовых проблем у дочки банка, мы вывели свои команды с направления, на котором работали. Туда пришла другая дочка банка, которая предоставляет людей на айтстафф. Результат? Крах всего направления.
Вам не поможет административная зависимость, если система управления не может управлять IT. Аутстафф тоже не очень поможет. На аутсорсинге шансов будет больше, но это будет вопрос везения.
Если же система управления нормальная, то можно без проблем использовать хоть что.
Очень меткие определения, спасибо!
Только подскажите, пожалуйста, что вы подразумеваете под административной зависимостью от Заказчика?
Спасибо! Я не претендую на исчерпывающее определение. Под адм зависимостью я понимаю реакцию на управленческое воздействие со стороны Заказчика, которая при таких моделях взаимодействия очень слабо выражена, если сравнивать с внутренним персоналом.