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