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