{"id":14285,"url":"\/distributions\/14285\/click?bit=1&hash=346f3dd5dee2d88930b559bfe049bf63f032c3f6597a81b363a99361cc92d37d","title":"\u0421\u0442\u0438\u043f\u0435\u043d\u0434\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0443\u044e \u043c\u043e\u0436\u043d\u043e \u043f\u043e\u0442\u0440\u0430\u0442\u0438\u0442\u044c \u043d\u0430 \u043e\u0431\u0443\u0447\u0435\u043d\u0438\u0435 \u0438\u043b\u0438 \u043f\u0443\u0442\u0435\u0448\u0435\u0441\u0442\u0432\u0438\u044f","buttonText":"","imageUuid":""}

Вредные советы компаниям, которые работают с аутстаффом

Аутстаффинг с возможностью использовать сотрудников из другой ИТ- компании набирает обороты. Всех учат, как правильно строить взаимодействие в команде с людьми из аутстаффа. А мы не будем. Мы дадим вредные советы: что нужно сделать, чтобы наверняка развалить проект и наделать кучу ошибок, даже если сейчас всё в порядке.

Не проводите онбординг аутстафф-разработчика

Не рассказывайте ему о бизнес-целях и внутренних процессах компании, а то ещё узнает все ваши секреты и откроет компанию-конкурента.

Не раскрывайте подробности проекта — технического стека и требований к спецу будет достаточно.

Скиньте ему док, в котором собраны ссылки на сотни инструкций и документов. Возникнут вопросы — пусть разбирается сам. Он ведь из аутстаффа — люди оттуда могут всё.

Не оплачивайте аутстафф-разработчику время на изучение продукта

Сразу просите оценку, как только поставите первую задачу. Его оценка кажется завышенной — выскажите своё недоумение. Не принимайте аргументов, что разработчик ещё не знаком с системой, там всё понятно и очевидно.

Допустить к задачам и трекингу времени аутстафф-разработчика можно, только когда он самостоятельно изучил систему и продукт компании, прошёл собеседование.

Не знакомьтесь лично с аутстафф-разработчиком. Сведите переписку с ним к минимуму

Задач в таск-трекере вполне достаточно. Не рассказывайте ему, кто за что отвечает в рабочих чатах. Он ведь из аустаффа: поработает с вами год-два и перейдёт на другой проект.

Не выделяйте отдельного сотрудника для работы с аутстафф-подрядчиками

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

Не добавляйте менеджера подрядчика в рабочие чаты и не допускайте его к таск-трекерам

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

Занимайтесь микроменеджментом

Поставьте себе напоминалку и спрашивайте не менее 10 раз в день, чем сейчас занят аутстафф-разработчик. Пристально следите за трекингом его времени. Пусть обосновывает каждый потраченный час. В аутстаффе все рисуют себе часы, а сами ничего не делают. Хорошо, что вы знаете, как с этим бороться.

Отдавайте аутстафф-сотрудникам только самые неинтересные задачи

Всё интересное оставляйте штатным, даже если они завалены работой. Резервируйте интересные задачи за собой.

Не давайте обратную связь по аутстафф-разработчикам

Ссылайтесь на занятость. Обещайте скинуть в ближайшее время, игнорьте назойливых менеджеров, которые просят обратную связь по разработчикам их компании. Главное — никакого фидбека. Это всё пустое и бессмысленное.

Отказывайтесь от разработчика сразу, как только показалось, что он плохо справляется с первой задачей

Не ждите окончания нескольких спринтов. Пусть подрядчик предлагает нового разработчика. Обсуждать ситуацию не надо. Менеджер подрядчика будет уговаривать вас подождать или дать другую задачу.

Разработчик справляется с задачей лучше некоторых штатных сотрудников — предложите ему работу

Скиньте его контакт своему эйчару. Начинайте хантить, наплюйте на договоренности и репутацию компании. Прижмут — валите всё на эйчара.

Только не воспринимайте наши советы уж слишком серьёзно, чтобы избежать неловких ситуаций.

0
1 комментарий
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
-2 комментариев
Раскрывать всегда