Наверное, практически любая компания, работающая в сфере IT аутсорсинга, сталкивалась с ситуацией, когда в проекте со стороны клиента представлены не только бизнес-пользователи, но также и технические специалисты. Обычно данная ситуация усложняет выполнение проекта, поскольку проектная команда превращается в слугу двух господ: приходится выполнять требования и бизнеса, и технарей одновременно, причем зачастую эти требования противоречат друг другу.
Впрочем, мы оставим в покое бизнес-пользователей, и сосредоточимся на технических специалистах заказчика и тех трудностях, которые они привносят в проект.
Диспозиция: проект полностью пишется «нашей» командой с нуля в течении полугода. В этот момент по инициативе заказчика решено начать делать регулярные (раз в две недели) ревью кода и вообще проверить проект на соответствие их стандартам кода, архитектуры и идеологии. Стоит отметить, их специалисты представлены не сферическими техническими начальниками в вакууме, а вполне адекватными программистами синьор уровня из США (не Индия, заметьте), которые пишут свои проекты параллельно с нашим.
Прошло два месяца после начала регулярных ревью и проект оказался в состоянии холодной войны между «нами» и «ими». И ситуация грозила перерости в реальные боевые действия – разгромные ревью кода и грозные письма превратились в печальную повседневность.
Проблемы вырисовались примерно следующие:
1. Противостояние «мы-они»
Программисты, как мне кажется, не очень любят критику своего кода, а если еще и критикует какой-то непонятный заокеанский дядя, то сам Бог велел держать для него дулю в кармане. Оно и понятно: мы этот код в муках рожали и любим его как родного ребенка, а тут люди, которые в него и строчки не добавили, вдруг говорят, что код этот вообще-то корявенький, плохо структурированный и слабо расширяемый. Такие люди –враги, и спор тут не уместен.
2. «Они не выполняют то, что мы им говорим»
Так как программисты — не солдаты в армии, то на указания «сверху» копать от забора и до обеда, к тому же еще и определенным стилем, на определенную глубину, да чтоб еще и траншеи получались витееватой заморской архитектуры, они реагируют вполне определенным образом. А именно: к дуле в кармане из первого пункта тут же добавляют вторую, невинно улыбаясь при этом. И, конечно, продолжают делать по-своему.
Кроме того, я не знаю, как представляли нас себе наши коллеги-американцы. Надеюсь, не думали, что мы кодим, сидя под березами, выпивая раз в полчаса 100 грамм водки (тимлид – 200 грамм), и медведи при этом наигрывают нам на балалайках «Ох, полным-полна моя коробочка…». Но определенно наше нежелание выполнять их прямые указания не меняло мнение о нашей адекватности в лучшую сторону уже хотя бы потому, что они:
a. Клиенты
b. Выдвигают логичные с их точки зрения и проверенные опытом требования
c. Все-таки американцы :)
3. «Трудности перевода»
Среди отечественных технических специалистов количество людей, способных свободно общаться с иностранцами, не столь велико, как хотелось бы. Да и вообще, как я заметил, программисты могут свободно владеть 5-ю языками программирования, но при этом с перенебрежением относиться даже к родному языку, употребляя пресловутые «девченки» и «делаеться», не морщась. Стоит ли говорить о том, что призывы учить английский ни к чему не привели? Именно поэтому попытки объяснять американским коллегам какие-то сложные архитектурные решения заходили в тупик не раз и не два. Впрочем, даже менее сложные предметы обсуждения зачастую давались с трудом.
Когда перечисленные выше проблемы стали очевидными, назрела необходимость искать пути выхода из сложившейся ситуации. Их мне виделось два:
1. Репрессивно-карательный – просто заставить команду выполнять все требования программистов клиента. Однако, по моему опыту, подобные меры с программистами работают крайне плохо и очень недолго. К тому же, недовольными в результате остаются все стороны.
2. Путь взаимопонимания – попытаться понять их, донести свои идеи, искать компромисы, где это возможно. Звучит как утопия, такого не бывает, но мы решили попытаться.
Собственно, взаимопонимание и решили мы искать с помощью парного программирования. Конечно, задача «заманить» заокеанских коллег в парное программирование сама по себе не простая, но если это удастся, то результаты обещают быть замечательными. Во всяком случае, у нас получилось действительно здорово.
Решение: сначала кратко остановлюсь на технологических подробностях организации процесса. Для получения удаленного доступа к десктопу мы пробовали использовать и Live Meeting, и WebEx. Учитывая тот факт, что из-за корпоративных политик безопасности у наших коллег отсутствуют «внешние» мессенджеры, то поначалу для аудиосвязи нам приходилось использовать телефоны с громкой связью. Это было не очень удобно, поэтому мы разжились гарнитурами. В итоге мы остановились на WebEx-е, так как у них для аудиосвязи предоставляются специальные бесплатные (toll-free) номера, на которые можно звонить, например, из Skype.
Обязательно так же иметь текстовый чат под рукой, особенно после окончания парной сессии, потому что обычно возникает много «не услышал», «недопонял» да и просто «а вот еще...»
Во время парного программирования мы старались придерживаться следующих правил:
1. Программисты пишут код в стиле пинг-понг, то есть сначала один пишет тест, второй – реализацию, а потом меняются ролями.
2. В процессе работы необходимо постоянно обсуждать с напарником то, что делаешь или собираешься делать и почему. Если общаться не о чем, значит, задача выбрана неверно – мы никогда не брали простые и очевидные задания для работы в паре.
3. Парная работа должна быть спланирована так, чтобы занимать цельный временной промежуток от начала до конца. Никакие звонки, совещания и прочее не должны прерывать разработчиков.
Теперь перейдем к тому, как отразился данный подход на наших проблемах, описанных выше:
1. Противостояние «мы-они»
С помощью парного программирования нам удалось разрушить отношение американских коллег к нашему коду как к чужому, а наши программисты перестали воспринимать их как «левых» дядек, которые могут только огульно критиковать, не особо глубоко вникая в суть, так как теперь код писали и мы, и они. Действительно, когда часть кода собственноручно написана теми людьми, которые делают ревью, то складывается совсем другое к нему отношение. Более того, мы время от времени оказывались в ситуации, когда один из американцев начинал критиковать код, который, как выяснялось, принадлежал его соотечественнику. В таких случаях нам оставалось только довольно потирать руки, слушая как «наехавшему» объясняют, что он не прав, на порядок доходчевее и красочнее, чем получилось бы у нас :)
2. «Они не выполняют то, что мы им говорим»
Если раньше по окончанию ревью кода мы имели список изменений, который мы как-то с горем поплам пытались реализовать, пропуская бессмыссленные по нашему мнению пункты, и делая остальные согласно нашему разумению, то теперь мы имели возможность работать над этим списком в паре с заокеанским коллегой. А значит, мы могли уточнить все детали, обсудить трудности, которые мешают реализации тех или иных пунктов и так далее. Соответственно, и они получили возможность объяснить причину возникновения того или иного требования к архитектуре или коду. В результате мы поняли, что в большинстве случаев нам предлагают вполне вменяемые вещи, а они перестали думать о нас как о красных партизанах, пускающих под откос эшелоны со списками их буржуазных требований и устраивающих откровенный саботаж. Перестали ли думать, что кодим под березами – не уверен :)
3. «Трудности перевода»
Как все понимают, в парном программировании третьему нет места, поэтому так или иначе, а программисту придется разговаривать самому. Это уже не общий митинг, где все скажет менеджер, а остальным можно отделаться OK, No, Yes и самым радостным Bye!
С одной стороны это гораздо сложнее, но с другой – проще, потому что перед вами двумя открыт кусок кода, и речь будет идти в основном о нем. Это задает четкий и ограниченный контекст и таким образом облегчает общение. Кроме того, программистские идеи универсальны, а термины – в основном уже англоязычные, что значительно помогает взаимопониманию.
Спустя некоторое время я обратил внимание на две вещи. Во-первых, когда человек сам пару раз побэкает-помэкает в разговоре с иностранцем, то ему обычно становится так стыдно, что он моментально бежить учить язык. Уже не нужны никакие дополнительные стимулы, и курсы, оплачиваемые компанией, оказываются и даром не нужны – моментально находятся и время, и собственные деньги на личного репетитора. А во-вторых, когда разговорный язык уже подтянут до достаточного уровня, и языковой барьер и страх общения преодолены, то наступает сплошной кайф от того, что тебя неплохо понимает тот, с кем раньше объяснялся чуть ли не на пальцах. Особый fun почему-то случается, когда получается удачно пошутить — надо видеть эти довольные лыбы до ушей, когда в ответ на твою шутку с «той» стороны раздается смех.
Кстати, здесь же хочу упомянуть и о разнице менталитета, с которой мы столкнулись. У нас довольно распространено «жаловаться на жизнь», у американцев же наоборот, всегда все должно быть «good». Следуя данной логике мы какое-то время «жаловались», принося на ревью наиболее запущенные куски кода, с целью выслушать советы по улучшению. Они, естественно, разносили это все в пух и прах и страшно расстраивались, думая, какой же у нас остальной код, если такой страшный говнокод мы принесли им на ревью. Понадобилось какое-то время, чтобы до нас дошло, что на ревью надо приносить лучшие куски кода и именно этого от нас ждут – показать, насколько мы понимаем, что от нас хотят и что мы вообще можем. После успешных ревью такие части кода становились внутренними эталонами, согласно которым все в дальнейшем и делали рефакторинг. Совет прост: не стоит показывать людям код, который никто и никогда не пытался приводить в порядок, доводите его сначала хотя бы до состояния «не стыдно», а еще лучше – «горжусь».
Итог
Суммируя все перечисленное выше, хочется отметить, что искать взаимопонимание со своими иностранными коллегами и налаживать с ними коммуникации стоит в любом случае. Это приносит множество преимуществ, и при этом я не могу придумать ни одной отрицательной стороны данного процесса, кроме, разве что, временных затрат. Ну, а если ваша команда считает зарубежных коллег мутантами и те отвечают вам взаимностью, то я советовал бы заняться этим в первую очередь. Мне кажется, парное программирование подходит для данной цели как нельзя лучше. А если у кого-нибудь получилось использовать для той же цели что-нибудь еще – буду благодарен, если поделитесь опытом в комментариях.
Автор: Alina_DIO
