Comments 5
ИМХО вы смешиваете в одну кучу отусорс как задачу и оутсорс как аутстафинг. Из этого ничего хорошего не выйдет.
Если отусорс как задача, у задачи есть конкретный результат. Оценивается только он. Акты подписываются только тогда, когда результат строго соответствует ТЗ. Этап проработки ТЗ соответствует финансовым рискам и требованиям к результату. И да, в таком сценарии часто проще сделать сами, чем написать приемлемое ТЗ. Внутри работаете без ТЗ и у вас нет необходимы компетенции и "тормозов", "тормоза" нужны для того, чтобы не требовать от задачи соответствия не явным критериям к качеству.
Если отусорс это аутстафинг, то это все тот же процесс онбординга и всего остального. Плюс такого подхода в возможности быстрее чем на кадровом рынке наращивать и сокращать ресурсы. Но и минусов хватает, один из основных, радикально другое управление онбордингом, другие требования к зрелости локальных процессов.
Судя по всему бизнес к вашей команде предъявляет противоречивые требования к результату оутсорса, т.е. за результат ответственность ложится на вас, плюс не выделяют профильные доп.ресурсы на это направление, в стиле сами как-нибудь разберитесь и отвечайте, но сделают пусть за 5 копеек индусы и в штат, чтобы никого не брать. ИМХО это от принципиального не понимания, что оутсорс и взять в штат это не две медали одного и того же, это абсолютно разные вещи и для оутсорса тоже нужен отдельный штат поддержки этого процесса со своими компетенциями, нельзя просто повесить эту задачу на инхаус комманду разработки.
Учитывая, что тут описано три случая обращения к команде аутсорса, выгоднее и менее геморно было бы при втором случае убедить руководство, что нужно взять людей в штат. Скорее всего это было бы дешевле и вам не пришлось бы заниматься интеграцией команды аусорса к себе в команду. А так по итогу получается, что вы имеете аутсорсеров у себя в команде, только еще платите больше и страдаете с интеграцией :) самый большой позитив вижу в том, что вы получили ОПЫТ :)
Бизнес, бывает, говорит: "Вот задача ее надо сделать. Если своих ресурсов не хватает - возьмите на рынке". Это некий такой буст под проект. Проект сделали, команда отчалила, а свой ИТ отдел с этим будет жить. Брать в штат на короткий (до года проект) не лучшее решение. Есть проект, есть сумма. Ищется опытная команда.
К большому сожалению, на рынке сейчас много тех кто продает аутстаф услуги. По факту оказывается, что эти "товарищи" начинают искать разработчиков на фрилансе в момент обращения. Т.е. это не "команды", а менеджеры разводилы.
А суть именно в подключении команды. Где каждый знает что делать, где выстроенные процессы и все такое.
Для формирования эффективных практик взаимодействия с аутсорсом важно глубже детализировать причину (или комплекс причин), почему вообще решили привлекать аутсорс дополнительно к внутренней команде.
Например:
Нужно под конкретный проект увеличить ресурсы, а на постоянной основе не нужно.
Нужна гибкость в управлении бюджетом: резко сократить бюджет на аутсорс проще, чем резко сократить фонд оплаты труда.
Нужна дополнительная экспертиза, которой нет в команде.
В условиях дефицита специалистов не удается найти специалистов, которые готовы пойти работать в штат данной компании, а подходящих аутсорсеров удалось найти.
Внутренние бизнес заказчики испытывают сомнения во внутренней команде разработки и хотят подключить аутсорс для сравнения результатов или для снижения зависимости от внутренней команды (чтобы, например, в случае ее резкого полного увольнения аутсорсер мог временно подхватить работу).
Есть бюрократические ограничения (нередко в том числе абсурдные), которые усложняют возможность увеличить количество штатных позиций, но не мешают выделить бюджет на аутсорс.
Внутрикорпоративная борьба за бюджет и влияние привела к тому, что у некоторого подразделения (за пределами ИТ департамента) есть бюджет на проект, который оно готово дать на привлечение аутсорса. Но не готово дать на расширение ставок во внутренней команде разработки департамента ИТ, так как волнуется, что вскоре сотрудники, принятые на эти ставки, перестанут работать на задачи данного подразделения, а переключатся на задачи других внутренних заказчиков. По этой же причине в крупных компаниях нередко появляются программисты, которые не числятся в ИТ департаменте. И должность у них называется иначе, хотя фактически они занимаются программированием.
Могут быть и другие причины.
От того, какие причины актуальны, зависит, как лучше действовать.
В некоторых случаях может быть эффективен подход, при котором находится постоянный аутсорсер, а работа с его сотрудниками выстраивается по принципу аутстаффа. У аутсорсера выделяется 2-3 человека, которые погружаются в процессы заказчика, проходят тот самый онбординг, который может занимать несколько месяцев. В том числе высаживаются на время проекта в офис заказчика (если практикуется работа в офисе, а не удаленка). После этого в будущих проектах уже можно сэкономить время на онбординг, так как специалисты уже адаптированы. В отличие от найма в штат, в такой ситуации, например, можно не платить аутстафферам несколько месяцев если сейчас они не нужны, а потом подключить опять. Или резко сократить бюджет на них. И т.д. - в общем, это может быть выгоднее штата если актуальны некоторые причины поиска аутсорса из перечня выше.
Работа с аутсорсом: наш опыт