Недавно мне посчастливилось закончить контракт на проекте, где подавляющим большинством разработчиков были индийцы. “Проект с индусами” – своего рода мем, с которым связаны некоторые стереотипы, и сегодня я хочу поделиться с вами своим впечатлением и подсветить моменты, с которыми я столкнулся. Итак, поехали!
Языковой барьер
Даа, в самом начале было не просто: естественно, все общение происходило на английском. И знаете что?
Английский английский и индийский английский (его еще называют хинглиш) – это разные вещи
Однажды мне сказали, что русскому человеку намного проще понять хинглиш, так как в наших языках много похожих звуков. Ммм… ну, нет. Могу заверить, что это совершенно не так.
Я сам, конечно, не гуру английского языка, но понять, что говорят европейцы (которых было всего несколько человек), я мог, а вот индийцев поначалу было совсем не разобрать. Так что, вот, держи фразу, которая станет главной по частотности использования на первые 2 месяца для подобных проектов:
“Sorry, I didn't get you, can you please repeat?”
Спустя месяц я начал неплохо понимать одного индийца, с которым общался чаще всего. И только я успел подумать, что теперь-то все нормально – и бац, новый созвон с новыми коллегами, и мне снова ничего не понятно.
Если ты начал понимать одного индийца – это еще не значит, что ты теперь понимаешь всех. Ну, это ничего: я постепенно привык к произношению второго индийца, третьего, и только после этого начал понимать всех примерно одинаково.
Через год я уже освоился, и теперь мне иногда кажется, что индийский английский я понимаю лучше, чем носителей языка. Коллега из нашей компании, который слышит мое общение на английском, сказал, что у меня самого акцент стал, как в хинглише.
Так что если тебя волею судеб затянуло на похожий проект и ты не улавливаешь ничего из того, что тебе говорят – не бойся и не переживай, через 2-3 месяца вы будете понимать друг друга лучше, чем носитель языка вас двоих.
Стереотип 1: “Русский с индусом понимают на английском друг друга лучше, чем их понимает носитель”
Берем, есть такое – но нужна практика. А, впрочем, этот стереотип подходит к любому акценту, смотря с кем работать.
Английский английский и индийский английский (его еще называют хинглиш) – это разные вещи
Однажды мне сказали, что русскому человеку намного проще понять хинглиш, так как в наших языках много похожих звуков. Ммм… ну, нет. Могу заверить, что это совершенно не так.
Я сам, конечно, не гуру английского языка, но понять, что говорят европейцы (которых было всего несколько человек), я мог, а вот индийцев поначалу было совсем не разобрать. Так что, вот, держи фразу, которая станет главной по частотности использования на первые 2 месяца для подобных проектов:
“Sorry, I didn't get you, can you please repeat?”
Спустя месяц я начал неплохо понимать одного индийца, с которым общался чаще всего. И только я успел подумать, что теперь-то все нормально – и бац, новый созвон с новыми коллегами, и мне снова ничего не понятно.
Если ты начал понимать одного индийца – это еще не значит, что ты теперь понимаешь всех. Ну, это ничего: я постепенно привык к произношению второго индийца, третьего, и только после этого начал понимать всех примерно одинаково.
Через год я уже освоился, и теперь мне иногда кажется, что индийский английский я понимаю лучше, чем носителей языка. Коллега из нашей компании, который слышит мое общение на английском, сказал, что у меня самого акцент стал, как в хинглише.
Так что если тебя волею судеб затянуло на похожий проект и ты не улавливаешь ничего из того, что тебе говорят – не бойся и не переживай, через 2-3 месяца вы будете понимать друг друга лучше, чем носитель языка вас двоих.
Стереотип 1: “Русский с индусом понимают на английском друг друга лучше, чем их понимает носитель”
Берем, есть такое – но нужна практика. А, впрочем, этот стереотип подходит к любому акценту, смотря с кем работать.
А как люди они как?
На моем проекте коллеги из Индии были максимально приятными в общении ребятами. Ноль токсичности, на вопросы отвечают, в чатах не морозятся, всегда можно было попросить устроить созвон по нужным тебе вопросам.
Была, конечно, на проекте пара ребят, которых было непросто поймать с их расписанием созвонов в гугл-календаре по 10 часов из 8 рабочих каждый день. Но и они, если заняты, сообщали об этом, и мы планировали наше общение на свободные окошки.
Отдельным пунктом хочу выделить отсутствие раздражительности из-за того, что я поначалу не разбирал, что они говорят, и постоянно их переспрашивал. Все относились с пониманием, что приятно.
Где-то слышал, что индийцы – мастера перекладывания ответственности на ближнего своего. Конечно, имело место привлечение человека или переназначение задачи, если считалось, что проблема находится в его зоне компетенций, например, в сервисе, с которым тот работает.
Был даже один забавный случай, когда мы неделю “перестреливались” задачей с командой из соседнего сервиса, так как ни мы, ни они не знали, что между нами был еще один прокси сервис, в котором и была проблема. Но все же эти процессы происходили через скрам мастеров, с согласованиями, и я никогда не чувствовал, что на меня пытаются спихнуть то, чем я не должен заниматься.
Также один из стереотипов гласит, что индийцы не могут сказать “нет”, даже если они чего-то не знают или не могут сделать. Что они соглашаются на все, и если не понимают, как это делать, делают какашку. Я с таким не встречался: возможно, это стереотип только для тех, кто заказывает проекты у индийцев =)
При общении заметно, что в их менталитете сказать напрямую “нет”, “я считаю, что это неправильно”, “я не согласен” сложно, так как для них это считается чем-то грубым. Но это не мешает работе, просто эти фразы заменяются на “я думаю, ты в основном прав, но …”. К этому быстро привыкаешь и работе это не мешает. А если они чего-то не понимают, то сами тебя по сто раз переспросят.
Из особенностей созонов: если кто-то работает не из офиса, то звонки дополнялись чудным сопровождением шума машин, плача детей, криков попугая и прочей прелестью.
В целом, от коммуникации в команде остались только положительные впечатления.
Стереотип 2: “Индийцы – мастера в перекладывании ответственности”
Нет, на моем проекте такого не было.
Стереотип 3: “Не говорят “нет”, если чего-то не знают, и делают потом фигню”
Тоже нет, в плане общения все вели себя абсолютно корректно. Даже стало интересно, насколько индийцы считают нас грубыми в общении =)
Стереотип 4: “В Индии очень шумно”
Ооо да, скрипы, стоны, плач. Иногда, бывает, приходится напрячься, чтобы услышать человека.
Была, конечно, на проекте пара ребят, которых было непросто поймать с их расписанием созвонов в гугл-календаре по 10 часов из 8 рабочих каждый день. Но и они, если заняты, сообщали об этом, и мы планировали наше общение на свободные окошки.
Отдельным пунктом хочу выделить отсутствие раздражительности из-за того, что я поначалу не разбирал, что они говорят, и постоянно их переспрашивал. Все относились с пониманием, что приятно.
Где-то слышал, что индийцы – мастера перекладывания ответственности на ближнего своего. Конечно, имело место привлечение человека или переназначение задачи, если считалось, что проблема находится в его зоне компетенций, например, в сервисе, с которым тот работает.
Был даже один забавный случай, когда мы неделю “перестреливались” задачей с командой из соседнего сервиса, так как ни мы, ни они не знали, что между нами был еще один прокси сервис, в котором и была проблема. Но все же эти процессы происходили через скрам мастеров, с согласованиями, и я никогда не чувствовал, что на меня пытаются спихнуть то, чем я не должен заниматься.
Также один из стереотипов гласит, что индийцы не могут сказать “нет”, даже если они чего-то не знают или не могут сделать. Что они соглашаются на все, и если не понимают, как это делать, делают какашку. Я с таким не встречался: возможно, это стереотип только для тех, кто заказывает проекты у индийцев =)
При общении заметно, что в их менталитете сказать напрямую “нет”, “я считаю, что это неправильно”, “я не согласен” сложно, так как для них это считается чем-то грубым. Но это не мешает работе, просто эти фразы заменяются на “я думаю, ты в основном прав, но …”. К этому быстро привыкаешь и работе это не мешает. А если они чего-то не понимают, то сами тебя по сто раз переспросят.
Из особенностей созонов: если кто-то работает не из офиса, то звонки дополнялись чудным сопровождением шума машин, плача детей, криков попугая и прочей прелестью.
В целом, от коммуникации в команде остались только положительные впечатления.
Стереотип 2: “Индийцы – мастера в перекладывании ответственности”
Нет, на моем проекте такого не было.
Стереотип 3: “Не говорят “нет”, если чего-то не знают, и делают потом фигню”
Тоже нет, в плане общения все вели себя абсолютно корректно. Даже стало интересно, насколько индийцы считают нас грубыми в общении =)
Стереотип 4: “В Индии очень шумно”
Ооо да, скрипы, стоны, плач. Иногда, бывает, приходится напрячься, чтобы услышать человека.
If-esle – хлеб с маслом любого волшебника индийского программиста
Кто-то говорит, что если над проектом работают ребята из Индии, то это 100% говнокод, кто-то говорит, что это стереотип, и там есть много хороших спецов и это уже давно не так.
И мне попался … максимально первый вариант.
Подобно археологическим слоям, на проекте заметно, что в свое время был культ наследования. Так же, как у любого уважающего себя человека, у всех классов должно быть как можно больше родственников, а еще лучше, чтобы все классы имели одного прародителя, старейшину, который так или иначе принимает участие в жизни всех членов этой большой семьи. Абстракции и интерфейсы – это как то бездушно, можно обойтись и без них.
Зачем лишний раз усложнять архитектуру проекта, когда любую проблему можно обернуть в if-else. Еще не было ни одной задачи, которая бы не пала под натиском этой могущественной конструкции.
Кстати, был побочный плюс: почти вся логика запроса – в одном файле. Не придется прыгать по файлам, достаточно всего лишь быстро ознакомиться с двумя-тремя тысячами строк кода, чтобы понять, что происходит. Красота!
Это был проект, где старая кодовая база диктовала правила написания нового кода, и эти правила гласили:
Голый PHP без фреймворков – Да
Фабрики возвращают объекты с одинаковым интерфейсом – Нет
Файлы по 2к + строк кода – Да
Неиспользуемый или закомментированный код – Да
Класс БД наследуется от класса Логирования – Да
Использование интерфейсов и абстракций – Минимум
Использование наследования – Максимум
Сами индийцы признавали, что их код не очень. Видно, что они пытались применять паттерны проектирования – иногда удачно, иногда не очень.
Мне встречалась фабрика, которая возвращала объекты без общего интерфейса. Ну и что можно вызывать, а что нет? От подобных решений с ума сходили IDE, украшая пол кода красным, я сам и мои коллеги по офису, которым я все это показывал, чтобы порофлить.
Поначалу я удивлялся, как это все работает столько лет, как это можно держать в голове и ничего не сломать, внося изменения? Ответ пришел сам собой – никак =) Код постоянно генерировал кучу багов, которые приходилось разгребать, что съедало большую часть времени спринтов.
Хочется отметить, что сами индийцы – ребята неглупые и хорошо разбираются в бизнес-логике этого проекта. Порой у меня создавалось впечатление, что они специально пишут в стиле, который смогут поддерживать только другие индийцы, таким образом национализировав проект.
Стереотип 5: “Индийский говнокод”
О да, да и еще раз да.
И мне попался … максимально первый вариант.
Подобно археологическим слоям, на проекте заметно, что в свое время был культ наследования. Так же, как у любого уважающего себя человека, у всех классов должно быть как можно больше родственников, а еще лучше, чтобы все классы имели одного прародителя, старейшину, который так или иначе принимает участие в жизни всех членов этой большой семьи. Абстракции и интерфейсы – это как то бездушно, можно обойтись и без них.
Зачем лишний раз усложнять архитектуру проекта, когда любую проблему можно обернуть в if-else. Еще не было ни одной задачи, которая бы не пала под натиском этой могущественной конструкции.
Кстати, был побочный плюс: почти вся логика запроса – в одном файле. Не придется прыгать по файлам, достаточно всего лишь быстро ознакомиться с двумя-тремя тысячами строк кода, чтобы понять, что происходит. Красота!
Это был проект, где старая кодовая база диктовала правила написания нового кода, и эти правила гласили:
Голый PHP без фреймворков – Да
Фабрики возвращают объекты с одинаковым интерфейсом – Нет
Файлы по 2к + строк кода – Да
Неиспользуемый или закомментированный код – Да
Класс БД наследуется от класса Логирования – Да
Использование интерфейсов и абстракций – Минимум
Использование наследования – Максимум
Сами индийцы признавали, что их код не очень. Видно, что они пытались применять паттерны проектирования – иногда удачно, иногда не очень.
Мне встречалась фабрика, которая возвращала объекты без общего интерфейса. Ну и что можно вызывать, а что нет? От подобных решений с ума сходили IDE, украшая пол кода красным, я сам и мои коллеги по офису, которым я все это показывал, чтобы порофлить.
Поначалу я удивлялся, как это все работает столько лет, как это можно держать в голове и ничего не сломать, внося изменения? Ответ пришел сам собой – никак =) Код постоянно генерировал кучу багов, которые приходилось разгребать, что съедало большую часть времени спринтов.
Хочется отметить, что сами индийцы – ребята неглупые и хорошо разбираются в бизнес-логике этого проекта. Порой у меня создавалось впечатление, что они специально пишут в стиле, который смогут поддерживать только другие индийцы, таким образом национализировав проект.
Стереотип 5: “Индийский говнокод”
О да, да и еще раз да.
Рефакторинг, конечно, нужен, но не сейчас
Рефакторинг больше, чем переименование переменных, проходил с трудом, так как несмотря на наличие тестов, код с большим количеством изменений боялись принимать: а мало ли что сломается?
Однажды мне удалось выбить время для рефакторинга в одном сервисе, использовав аргументы, насколько это нужно и полезно. После недели работы восточный коллега, который должен был принять код, начал всячески откладывать применения этих изменений, ссылаясь на более срочные задачи. В итоге изменения с рефакторингом успели протухнуть, и мы их так и не доставили.
Несмотря на все сложности, на проекте были и интересные задачи, и возможность написать новый функционал, не скованный оковами легаси кода. Но после таких задач было еще больнее возвращаться к выковыриванию багов из легаси кода, что тоже подкидывало дровишек в топку выгорания.
Стоит также признать, что чем дольше ты на проекте и чем лучше ты себя зарекомендовал, тем охотнее принимают твои изменения, и процесс хоть и медленно, но идет. В начале моей работы на проекте IDE рябил от количества ошибок и предупреждений, при написании этой статьи я даже хотел вставить скриншот. Но с удивлением обнаружил, что сейчас не могу найти таких файлов.
Можно пользоваться такой стратегией: делаешь изменения в файле по задачам – попробуй убрать часть ошибок, подсвеченных IDE, сделай код чуть более читабельным, но не делай слишком много изменений за раз, чтобы изменения приняли.
Желание: “Постепенно сделаем конфетку”
К сожалению, бизнес требует решать бизнесовые задачи в первую очередь. При таком объеме тех долга и таком сопротивлении изменениям отрефакторить весь проект кажется невозможным, но нужно стараться.
Однажды мне удалось выбить время для рефакторинга в одном сервисе, использовав аргументы, насколько это нужно и полезно. После недели работы восточный коллега, который должен был принять код, начал всячески откладывать применения этих изменений, ссылаясь на более срочные задачи. В итоге изменения с рефакторингом успели протухнуть, и мы их так и не доставили.
Несмотря на все сложности, на проекте были и интересные задачи, и возможность написать новый функционал, не скованный оковами легаси кода. Но после таких задач было еще больнее возвращаться к выковыриванию багов из легаси кода, что тоже подкидывало дровишек в топку выгорания.
Стоит также признать, что чем дольше ты на проекте и чем лучше ты себя зарекомендовал, тем охотнее принимают твои изменения, и процесс хоть и медленно, но идет. В начале моей работы на проекте IDE рябил от количества ошибок и предупреждений, при написании этой статьи я даже хотел вставить скриншот. Но с удивлением обнаружил, что сейчас не могу найти таких файлов.
Можно пользоваться такой стратегией: делаешь изменения в файле по задачам – попробуй убрать часть ошибок, подсвеченных IDE, сделай код чуть более читабельным, но не делай слишком много изменений за раз, чтобы изменения приняли.
Желание: “Постепенно сделаем конфетку”
К сожалению, бизнес требует решать бизнесовые задачи в первую очередь. При таком объеме тех долга и таком сопротивлении изменениям отрефакторить весь проект кажется невозможным, но нужно стараться.
Часть команды, часть корабля
Про пять стадий принятия что-нибудь слышали? Ага, тут тоже можно испытать нечто похожее.
Ты понимаешь, что это говнокод, и так жить нельзя. Ты надеешься хоть как-то сделать лучше, торгуешься за рефакторинг, упираешься в потолок одобрения по времени на рефакторинг и количеству изменений и рано или поздно смиряешься. Просто начинаешь делать задачи, чтобы они работали.
Возможно, для бизнеса в этот момент такой подход даже лучше, но это как-то дизморалит. В такой ситуации приходит осознание, что выгорание напрямую зависит от продолжительности горения твоей задницы. И если ты со временем успокоился и все принял, как есть – возможно, это просто потому что гореть уже нечему.
Желание: “Хорошо делай, плохо не делай”
Приходится считаться с определенными правилами и рамками, который диктует легаси код.
Ты понимаешь, что это говнокод, и так жить нельзя. Ты надеешься хоть как-то сделать лучше, торгуешься за рефакторинг, упираешься в потолок одобрения по времени на рефакторинг и количеству изменений и рано или поздно смиряешься. Просто начинаешь делать задачи, чтобы они работали.
Возможно, для бизнеса в этот момент такой подход даже лучше, но это как-то дизморалит. В такой ситуации приходит осознание, что выгорание напрямую зависит от продолжительности горения твоей задницы. И если ты со временем успокоился и все принял, как есть – возможно, это просто потому что гореть уже нечему.
Желание: “Хорошо делай, плохо не делай”
Приходится считаться с определенными правилами и рамками, который диктует легаси код.
Индийский код – это не индийцы
В заключение хочу сказать, что весь негатив, который есть в статье, относится исключительно к коду, а не к людям. На моем проекте мне посчастливилось общаться с замечательными коллегами без токсичности, без раздражения, всегда готовыми ответить на вопросы и помочь разобраться со своим кодом. Так что не стоит относиться к ребятам из Индии предвзято. Помните, они сами находятся в заложниках у своего легаси кода.