Published on
Updated on 

Индия - масштабирование людей

Authors
  • Эта публикация - перевод статьи. Ее автор - Jan Wedel. Оригинал доступен по ссылке ниже:

    India - Scaling People

Мой опыт работы с офшорными командами и что пошло не так.

Я недавно прочитал твит @sivalabs, который заставил меня задуматься:

В Индии огромное количество талантливых, трудолюбивых и энергичных разработчиков программного обеспечения. Они просто не знают, что могут сказать «НЕТ» некоторым необоснованным требованиям со стороны их начальников, и они делают плохо, но в срок.

Это действительно проблема?

После одного года работы с оффшорной командой мы потеряли около миллиона евро, и нам нужно было переписать большую часть программного обеспечения. В чем на самом деле была проблема? Я долго думал об этом. Но давайте вернемся к середине 2015 года.

Менеджер: Ян, мне нужно, чтобы ты поехал в Бангалор, чтобы приобрести команду в Индии.

Ян: Почему?

М: Потому что у меня есть приказы топ-менеджмента, что нам нужно нанять 10 разработчиков за рубежом.

Я: почему?

М: Потому что лучше масштабируется.

Я: Люди масштабируются?

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

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

Подготовка

Иерархия

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

Итак, мы создали таблицу сопоставления (без шуток, мы действительно это сделали):

Роль

Нас

Их

Разработчик

Человек А

Человек Д

Руководитель группы

Человек Б

Человек Е

Менеджер проектов

Человек В

Человек Ж

Менеджер отдела

Человек Г

Человек З

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

Светская беседа и прямой подход

Во-вторых, мы узнали, что вы всегда начинаете разговор с небольшого разговора. Я ненавижу болтать.

Вы никогда не будете прямо критиковать людей, но всегда будете говорить что-то окольным путем. Я тоже это ненавижу. Похоже, я подходящий парень для этой работы, а?

План

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

Бангалор

После очень приятного перелета на следующий день мы пришли в офис, чтобы встретиться со всеми. Мы доставили водителя к нам в «Кибер Парк, Электронный Город». Я уже улыбался в этот момент.

К нашему удивлению, в офисе не было никого, кроме менеджера проекта. Мы (как немцы) узнали, что пунктуальность не является главным приоритетом в Индии. После 45 минут ожидания почти все присоединились к нашей встрече.

Мы очень четко дали понять, что мы искали команду, способную мыслить самостоятельно, высказываться, если что-то кажется неправильным с их точки зрения, и что обеспечение высокого качества важнее, чем своевременное выполнение.

Онлайн оценка

Разработчикам из пула талантов мы дали подготовленную онлайн-оценку, включающую пару технических вопросов, написание кода, тесты и некоторый SQL.

Это была катастрофа. Конечно, не было явного победителя, и онлайн-инструмент сообщал, что кандидаты фактически копировали решения друг у друга. Некоторые из них сидели в одной комнате с офисом. Отличное начало.

Интервью

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

Следующее, что нужно было изучить, было то, что на самом деле существует очень значительная разница в ранжировании разработчиков на младший, средний и старший уровни. В Германии вы бы не назвали себя старшим, а подали заявку на должность старшего. В большинстве резюме, которые мы получили, кандидаты фактически представляли себя, например, как «Старший разработчик». Во-вторых, кандидаты оценили себя как «старшие», как только они 2-3 года работали над исправлением ошибок в унаследованном приложении. Обычно, по моему опыту, старший имеет 10-15 лет профессионального опыта, который включает в себя более крупные проекты, в лучшем случае «зеленое поле». Но у нас явно не было таких кандидатов.

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

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

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

Тренировка

Следующим шагом было обучение подобранной команды. Как упоминалось ранее, у нас было два разработчика из нашей команды плюс ведущий разработчик нашей собственной инфраструктуры. Но прежде всего мы постарались подчеркнуть очень простые, но важные вещи:

  • Независимость: они должны чувствовать себя уважаемой командой, которая может принимать собственные решения.
  • Уверенность: они должны быть в состоянии говорить, если они видят что-то неправильное или неэффективное. Мы пытались указать на то, что мы также совершаем ошибки, и им следует смело говорить об этом.

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

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

Развитие

Вернувшись в Германию, мы несколько недель руководили их командой, работая с нами в Германии, чтобы еще больше интегрировать его.

Первые недели у нас была совместная ежедневная встреча по скайпу, которая прошла неплохо. Разница во времени составляла всего три с половиной часа (да, три с половиной!), Каждый кусок кода был проверен одним из наших разработчиков. Но это было очень исчерпывающе и не могло продолжаться вечно. Затем мы переключились на еженедельные встречи, обзоры в основном проводились их руководителем.

Конец

Мы действительно ожидали высокого оборота разработчиков, потому что нам сказали, что как только кто-то получит немного лучшее предложение, она уйдет. Этого не произошло. Команда почти стабильна, ушел только один разработчик по личным причинам.

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

Затем мы углубились в это и сделали некоторую статистику по git коммитам. Оказалось, что из тех 8-9 разработчиков, которых мы наняли, в конце проекта только 3 из них фактически выполняли код. Хотя я не получил объяснения, их менеджеры, вероятно, продавали своих сотрудников нескольким проектам. Я слышал, что это происходит от людей, работающих там.

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

Мы получили почти миллион евро, чтобы доставить обе заявки в состояние, приемлемое для нашего клиента. Это не включает фактический персонал, обучение и командировочные расходы.

Кажется, что затраты масштабируются лучше, чем люди.

2018

(Новый) Менеджер: Ян, нам нужно подумать о привлечении оффшорной команды в Индию, потому что она лучше масштабируется.

Ян: Но, но, но...

В чем была проблема?

Я серьезно спрашиваю себя, в чем была проблема. Могли ли мы сделать что-то по-другому, чтобы сделать это историей успеха?

Удаленная работа

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

Уровень квалификации

Да, у всех кандидатов не было опыта в тех рамках, которые нам нужны. Вероятно, они работали в скучных старых проектах. Но, как @sivalabsправильно указано в его твите, в Индии много талантливых и умных разработчиков. Их школьные и университетские системы гораздо лучше ориентированы на обучение людей работе в сфере высоких технологий, чем мы в Германии.

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

Иерархия

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

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

Фокус на качество

Они просто не знают, что могут сказать «НЕТ» некоторым необоснованным требованиям со стороны их начальников, и они поставляют плохое качество работы в срок.

Не было никаких установленных сроков, по крайней мере, в нашем проекте. Мне действительно кажется, что они просверлены, чтобы доставить как можно быстрее, как только это будет выглядеть поверхностно. В предыдущем проекте я придумал это как CDD (дизайн, управляемый компилятором). Это готово, когда это компилируется. Это, безусловно, серьезная проблема, если вам нужна команда с равными правами и обязанностями, которая работает вместе над большим проектом.

В 2017 году была волна индийских кандидатов, которые подали заявку на стажировку, несмотря на то, что они фактически работали в течение нескольких лет в качестве разработчиков профессии в Индии. Я спросил одного из них, мы с ним действительно приехали в Германию. Он сказал, что он ненавидел дух, то, как программное обеспечение было разработано в Индии. Недостаток качества. Он также приехал из Бангалора.

Соотношение личности и баланса между работой и личной жизнью

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

Большинство из них пришли довольно поздно (около 9 или 10 утра), в основном из-за интенсивного движения в городе. Некоторым из них понадобилось 1 час (или больше) езды в одну сторону. Затем они сделали долгие часы. 10-11 часов было довольно нормально. Тем не менее, они много общались, общались на кухне и т. Д., Которые фактически вычитали из своего рабочего дня. Таким образом, я едва нашел кого-то, кто просто сделал их 8 часов и пошел домой.

Итак, чтобы подвести итог. большинство разработчиков потратили значительно больше времени на работу, но их, насколько я заметил, оценивают не как отдельных лиц, а как обменные ресурсы. Это может привести к снижению приверженности их работе.

Культура и Менталитет

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

Но это просто не сработало.