На одном из моих первых проектов в тестировании я прочувствовала если не все, то основные «прелести» неправильного управления командой внештатных специалистов. На первом же созвоне, как только нас ввели в проект, менеджер объяснял задачи с таким запалом, будто мы не только что присоединились к рабочим чатам, а уже были частью команды месяцев шесть…
— Ты ж понимаешь {а я не понимаю}, там API нестандартное {в каком смысле?}, ты разберёшься {не факт}.
— Документация? Мы пишем {до сих пор?}, в процессе меняем еще кое-что {потом мы узнаем, что практически всё}.
— С вопросами? Ну, ко мне можете приходить, но лучше Пашу {какого?} пингуйте, у меня еще три проекта {ого, ты Юлий Цезарь}, не всегда вижу сообщения {почти никогда не видит}.
Я слушала и радовалась, что созвон без камер, потому что в голове было: «Пу-пу-пуууу {ну, почти}…» — а выражение «рука-лицо» приобрело буквальный смысл…
Как аутстаффер с опытом, я сразу поняла, что с управлением какая-то неразбериха. И вообще никто не объяснил, как именно моя работа {и какая именно работа, собственно!} вписывается в общий процесс. Я как бы «включена», но при этом как бы и «нет». И вот такие ситуации происходят довольно часто, когда аутстаффера-тестировщика просто «забрасывают» в проект без необходимого погружения.
Конечно, в итоге там мы все разрулили, но прослыли ребятами из серии «у вас что, опять вопросы???». Потом нас за это поблагодарили и даже ставили в пример штатным работникам, мол, видите, люди не стесняются спрашивать, указывать на недочеты, экономят этим время и ресурсы и т.д. Рада, что мы оказались полезны и в менеджменте 🙂
И до того проекта, и после — я убеждена, что с первого дня работы аутстаффера всё должно быть чётко прописано: и задачи, и ожидания, и контакты, и график и все остальное.
Вот он, корень проблемы: человек не внутри команды, не в контексте, ему не дали внятных вводных. Но почему-то от него ждут того же уровня вовлеченности, что и от штатных сотрудников. Так не работает. Если аутстафф-специалист не управляется так же, как команда, будет только головная боль.
Давайте разберемся, как избежать типичных ошибок и выстроить эффективное управление аутстафферами-тестировщиками.
Как управлять аутстаффером с первого дня работы
Чтобы мы приносили пользу, нас нужно встроить в команду. Типичная ошибка — аутстаффера бросают в проект без нормального онбординга со словами: «Разберёшься по ходу!» А потом удивляются, что человек «не вписался» в команду. Это как если бы вы взяли нового игрока в футбольную команду и сказали: «Ну ты ж умеешь играть, давай!» А потом удивлялись, что он не забивает {голы, в смысле}. Важно сделать с первого дня:
- Онбординг — без него никак. Чётко прописывайте, что ожидаете от специалиста в первые дни. Дайте ему понять, какие задачи стоят на ближайшее время, и как они вписываются в общий процесс.
- Познакомьте его с командой, прежде чем погружать в тестирование. Нам очень важно знать, кто чем занимается и кому можно задавать вопросы. Вам это будет архи-выгодно, поверьте.
- Дайте ментора, если есть возможность, который будет помогать с адаптацией в проекте, если что-то пойдёт не так.
- Покажите инструменты и дайте все необходимые доступы. Где хранится документация? Как пользоваться системой деплоя? Какие есть инструменты для работы?
💡 Пример:
В одной компании мы проходили недельный онбординг: первые 3 дня изучали продукт, документацию, макеты и тд, тестировали, знакомились с тем, как и что работает, а на четвёртый день нам назначили уже реальные задачи под присмотром «старичков». Это не потеря времени! Это помогает быстрее включиться в работу и избежать ошибок, когда кто-то «не в теме».
Как контролировать работу: баланс между доверием и тотальным надзором
Есть тут такая ошибка — микроменеджмент. Когда менеджер следит за каждым шагом аутстаффера, скидывает отчёты в реальном времени и требует 5 {и такое бывало} созвонов в день. Результат часто бывает обратным: я работаю, чтобы сдать отчет менеджеру, а не чтобы выполнять свой план работы. Что вы можете сделать?
- Установить чёткие точки контроля. Например, раз в неделю смотрите прогресс и обсуждаете задачи. Не нужно каждый день спрашивать, как дела. Это мешает, отвлекает {и бесит}. Вам мы нужны продуктивные, а не психованные, ведь так?
- Использовать прозрачные инструменты — трекер задач и код-ревью.
- Применять KPI, которые реально измерить (не «работает быстро», а «выполнил N задач в срок»).
💡 Пример:
Со мной такого не случалось, но коллега работает в проекте, где аутстафферы отчитываются не через отчёты, а через пулл-реквесты. Ревью кода автоматически показывает качество работы. Если всё ок — задача закрыта, можно двигаться дальше.
📌 Когда все задачи чётко прописаны, а инструменты для контроля прозрачны, микроменеджмент и не нужен. Результат будет виден и без постоянных напоминаний. {ой, кажется, звучит, как совет сократить менеджера, упс}
Как сделать так, чтобы аутстаффер реально включался в работу
Если человек не чувствует связи с командой, его мотивация будет близка к нулю. Он будет делать свою работу, но не будет вкладываться в проект. Это, кстати, не редкость: у аутстафферов часто нет такого чувства, как у штатных сотрудников, что их работа имеет реальную ценность для команды. Но это можно и нужно менять. Чтобы человек реально включался:
- вовлекайте его в командные обсуждения. Пусть он знает, над чем работает команда, зачем это делается и какие цели стоят. Но это не про ненужные ему миты!!!
- давайте понять, что его работа действительно влияет на результат. Ведь когда я понимаю, что то, что я сделала, влияет на впечатление конечного пользователя от продукта, это круто. Это мотивирует.
- обсуждайте важные моменты в проекте, делитесь контекстом: почему принимаются те или иные решения? Да, мы не штатные, но мы участники процесса — оно нам надо!
💡 Пример:
Один из заказчиков устраивал для аутстафферов регулярные встречи, на которых рассказывали, как их работа влияет на продукт и какие улучшения они приносят пользователям. Прям презентации делали с графиками. Это значительно повысило вовлечённость в проект.
📌 Если я понимаю, зачем я здесь {то есть там}, моя вовлечённость и мотивация будут на высоком уровне.
Юридическая сторона: как не попасть в неприятности
Страшно, но надо проговорить это. Ведь никак не обойтись без юридических аспектов. Зачастую компании думают, что аутстаффинг — это просто. Но если не подготовиться юридически, можно остаться не только без результата, но и с проблемами. По опыту моих старших коллег, расскажу, что они считают важным:
- подписать NDA. Даже если проект не критичный, всегда лучше обезопасить себя,
- ограничивать доступы — давать только те, которые нужны для работы,
- прописывать чёткие условия в договоре — сроки, обязательства по передаче кода и ответственность.
💡 Пример:
Есть легенда, что в темном-темном городе один странный-странный заказчик решил не подписывать NDA, а через полгода работы аутстаффер ушёл с частью кода и передал его конкурентам.
📌Юридическая защита — не формальность, а реальная необходимость, которая помогает избежать неприятных сюрпризов.
Что делать, если аутстаффер уходит?
Неважно, как долго человек работал в проекте, его уход всегда создаёт риски для команды. Без должной подготовки этот процесс может быть болезненным. Нужно заранее позаботиться о том, чтобы:
- были задокументированы все ключевые решения и шаги в проекте,
- был настроен процесс передачи знаний,
- в идеале была запланирована замена, чтобы не было «паузы» в работе.
📌 Если процесс передачи знаний отлажен, уход не станет катастрофой.
Вывод: управление внешатниками — это настройка процессов, а не тотальный контроль
Аутстаффинг не про «нанять людей». С людьми еще нужно грамотно работать. Если у вас уже работают аутстафферы, проверьте себя:
- Вы правильно ввели его/их в проект? (онбординг, знакомство с командой и чёткие задачи)
- Установили прозрачный контроль? (без перегибов и излишнего надзора)
- Вовлекли в работу? (зачем и как выполняются задачи)
- Обеспечили юридическую защиту? (договоры и NDA)
- Подготовились к его/их уходу? (с документацией и процессами передачи знаний)
Если все ответы «да», ваши внештатники будут работать так же эффективно, как штатные сотрудники.
Аутстафф — это не временная заплатка, а часть проекта. Если относиться к нему так с самого начала, можно получить сильного игрока, который действительно принесёт пользу.
