{"id":13516,"url":"\/distributions\/13516\/click?bit=1&hash=37bd7b4748a2966bbc26730b25e2618c42f364e4b1fef4e1064b7cb954a0c2b0","title":"\u041f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u0438\u043d\u0432\u0435\u0441\u0442\u0438\u0446\u0438\u0438 \u043e\u0442 \u00ab\u0413\u0430\u0437\u043f\u0440\u043e\u043c \u043d\u0435\u0444\u0442\u0438\u00bb","buttonText":"\u0417\u0430 \u0447\u0442\u043e?","imageUuid":"9ff0d7f7-ef07-5cab-961b-7241d5749f52","isPaidAndBannersEnabled":false}

Вовремя ловим лосей: советы малому бизнесу как пробовать ИТ-аутстаффинг

Есть заблуждение, что аутстаффинг это для больших: банки, телеком, маркетплейсы и т.д. Связано это с тем, что под аутстаффингом часто понимают готовность клиента платить дороже, лишь бы сократить время на рекрутинг и закрыть нужные позиции срочно. Отчасти это правда, — именно из-за банков мы наблюдали такой спрос на услугу, — но размер далеко не главное.

Аутстаффинг — это на самом деле про зрелость. На стороне клиента должны быть развиты технические и управленческие компетенции, только тогда модель эффективна. По своему опыту скажу, что большой ИТ-отдел на стороне заказчика не гарантирует успешность такого сотрудничества. И наоборот, подключение разработчика в команду из двух человек может быть выигрышным. Как говорится, не попробуешь не узнаешь.

Рекомендую начинать сотрудничество с пилота. Обязательное условие для пилота заранее определить уровень убытков, которые вы готовы понести. Исходите из пессимистичного сценария, что сотрудничество не сложится. Устанавливая такой «стоп-лосс», вы заодно ответите для себя на ряд вопросов:

  • действительно ли мне нужно столько людей одновременно?
  • у меня есть время и ресурсы для их ввода на проект?
  • смогу ли я обеспечить им бесперебойный поток задач?
  • задачи имеют жесткие ограничения по срокам?
  • как отразится их подключение на производительности остальной команды?

Пилот лучше всего проводить, когда на проекте все относительно спокойно и не надо тушить пожары. Но про аутстаффинг обычно вспоминают именно, когда нужно усиление, чтобы успеть в срок. Так не работает (привет, Брукс!).

Поставщику невыгодно бросать человека в пекло, так как тогда он рискует через месяц получить выгоревшего разработчика. Поэтому заказчика услуги тоже оценивают, и могут не спешить вступать с ним в финансовые отношения. Для этого существуют пробный период, который либо не выставится в счет, либо может идти со скидкой если сотрудничество не сложится. Обычно для этого достаточно двух недель. За такой срок обеим сторонам становится ясно, есть ли перспективы для такого сотрудничества или нет.

Если вы хотите попробовать аутстаффинг, но сомневаетесь, то не бойтесь на берегу договориться с поставщиком о «ловле лося». Выделите задачу со средним приоритетом, которую по вашей оценке разработчик должен успеть решить за пробный период с учетом времени на онбординг. Здорово, если задача будет и нести ценность бизнесу и заодно знакомить разработчика с проектом.

Билль о правах XP

Продолжаю череду размышлений на тему зависимости от подрядчика и проблемы смены команды. Сегодня расскажу об одной практике, которая позволит выстроить здоровые отношения с IT-поставщиком.

0
Комментарии
Читать все 0 комментариев
null