Трудности международного аутсорса. Реальные истории из практики

Трудности международного аутсорса. Реальные истории из практики

Евгений Козак
Автор:
Фронтенд-разработчик уровня Senior
Степень магистра CTU University (San Jose, California)

По данным Statista, объем мирового рынка IТ-аутсорсинга вырос на 13% и достиг $360 млрд. Соответственно, увеличился спрос на айтишников из других стран. Однако работа с иностранными специалистами несет в себе много трудностей.

Первая история

Первая история случилась со мной в британской компании с главным офисом в Лондоне. Это не очень большая компания, в штате всего 20-30 программистов, но зарплата у них очень большая. Компания решила сократить расходы и поискать программистов подешевле извне.

Тогда компания наняла трех или четырех программистов-фрилансеров из Бразилии. Когда они начали работать, то наши программисты немного испугались. Думали, что сейчас бразильцы всё быстро сделают, а мы окажемся невостребованными. Не тут-то было! Наши опасения оказались напрасными.

Мы тогда работали на React-проекте. Когда эти программисты начали создавать компоненты, то сразу возникли проблемы. Действительно, они работали очень быстро, но когда мы пытались использовать их код, то всё разваливалось. Приходилось всё переделывать. Проверить код заранее мы не могли, потому что у нас не было таких полномочий.

При этом с программистами из Бразилии было легко общаться. У них неплохой английский. Они оперативно отвечают, хорошо всё понимают.

К работе относятся очень несерьёзно: делают, чтобы было. Когда просишь их исправить ошибки, то они не хотят этим заниматься, предлагают переделать самому. Бывает, что всё-таки исправляют, но очень долго. Из-за этого я очень сильно нервничал.

Думаю, проблема здесь в том, что этим программистам или платят очень мало, или у них очень мало опыта. Они не особо стараются. Быть может, у них сразу на несколько проектов, поэтому они стремятся сделать всё побыстрее, а на качество уже не обращают внимания.

Дело тут не конкретно в Бразилии. Такое отношение к делу может быть у программистов из любых стран: ЮАР, Польши, Италии, России и Украины, Грузии, Молдавии.

Вторая история

Эта история тоже произошла в британской компании, но в другой. Офис находится в Нью-Йорке, и есть большой аутсорсинговый офис в Индии. В то время компания работала над очень мощным серьезным проектом: мы делали дашборд для компании из США. Пришлось нанимать много людей из Индии.

Весь топ-менеджмент (лиды, сеньоры, менеджеры) был из Британии и пара человек из США.

Сложилась такая картина: очень хорошие, крутые программисты в Лондоне, а джуниоры и мидлы из Индии. На два сеньора из Британии приходилось восемь программистов-джунов из Индии. У них было мало опыта. Также проблема была в технической части: код страдал от огромного количества багов. В итоге тимлид попросту ничего не успевал: и общаться с клиентом, и контролировать команду.

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

У нас был план по количеству задач, которые мы должны были выполнить. Ребята попросту ничего не успевали, а если и делали, то неправильно и некачественно. Я должен был работать за них. Конечно, было много переработок. Также мне нужно было много всего объяснять, а они не понимали.

Еще нужно было объяснить своему главному менеджеру, почему так всё происходит. Менеджер понимал, что программисты не очень хорошие, но ему надо было объяснять задержки клиенту. Вот такой замкнутый круг.

Этот контракт длился около 11-ти месяцев. Уже через два месяца я понял, что проект катится в тартарары. Программисты из Индии писали очень плохой код, не было времени всех проверять. Людей, которые разбираются, то есть лидов и сеньоров, катастрофически не хватало.

Даже бывало так, что перед дедлайном нам надо было сделать демку для клиента и показать, чего мы добились за четыре спринта. Некоторые индийцы как раз именно в это время «заболевали» и отпрашивались с работы. Доработать нужно было очень много, но до дедлайна оставалось всего четыре дня.

Я старался сделать всё, что было в моих силах. Постоянно перерабатывал, всем всё объяснял. В итоге нам было что показать клиенту. Ему демки даже нравились, но все равно было видно, что они «сырые».

Так аутсорсинг оказался очень плохим. В итоге проект развалился, потому что код был написан очень плохо. Ошибок было столько, что никак ничего уже не исправить.

Потом клиент сказал, что хочет работать только с лидами и сеньорами, а от аутсорсинга хочет вообще отказаться и разорвать контракт с компанией.

Рекомендации по найму специалистов на аутсорсе

Тщательнее отбирать специалистов

Отбор следует усложнить. Специалистам на аутсорсе нужно давать те же задания, что и местным. Отбор должен состоят из собеседования и тестового задания на время.

Лучше брать не количеством, а качеством: нанять одного хорошего программиста, чем несколько плохих. Это будет и дешевле, и эффективнее.

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

Предлагать более высокую зарплату

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

Приставить к команде тимлида

Тимлид будет контролировать процесс, исправлять ошибки и давать подсказки. Он должен получать больше из-за объема работы. Важное условие: тимлид должен быть из той же страны, что и вся команда. Так им будет легче понять друг друга.

Общий вывод

Многие программисты из Англии, особенно из-за роста популярности удаленки, боятся, что их заменят программисты из Польши, Болгарии, Румынии, Индии, Пакистана, и России.

На самом деле, найти хорошего программиста, особенно из другой страны, — нелегко. Хороших программистов мало. Имею в виду таких, которые могут сами всё сделать от и до и ответить за результат.

Напишите что думаете или задайте вопрос!

Есть вопросы, пожелания, предложения? Пишите нам,
мы обязательно ответим.

Чем грозит неправильное делегирование? Крах для руководителя 1038 8.8.2022 Чем грозит неправильное делегирование? Крах для руководителя

Делегирование — это передача обязанностей подчиненным, обладающим достаточными знаниями и ...

Можно ли открыть бизнес в одиночку? Иногда для старта команда не нужна 1130 6.8.2022 Можно ли открыть бизнес в одиночку? Иногда для старта команда не нужна

Я учредитель аутсорсинговой компании, которая оказывает бухгалтерские услуги. История создания ...