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