Парное программирование в аутсорсинге: достижение взаимопонимания с техническими специалистами заказчика

    Наверное, практически любая компания, работающая в сфере 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». Следуя данной логике мы какое-то время «жаловались», принося на ревью наиболее запущенные куски кода, с целью выслушать советы по улучшению. Они, естественно, разносили это все в пух и прах и страшно расстраивались, думая, какой же у нас остальной код, если такой страшный говнокод мы принесли им на ревью. Понадобилось какое-то время, чтобы до нас дошло, что на ревью надо приносить лучшие куски кода и именно этого от нас ждут – показать, насколько мы понимаем, что от нас хотят и что мы вообще можем. После успешных ревью такие части кода становились внутренними эталонами, согласно которым все в дальнейшем и делали рефакторинг. Совет прост: не стоит показывать людям код, который никто и никогда не пытался приводить в порядок, доводите его сначала хотя бы до состояния «не стыдно», а еще лучше – «горжусь».

    Итог
    Суммируя все перечисленное выше, хочется отметить, что искать взаимопонимание со своими иностранными коллегами и налаживать с ними коммуникации стоит в любом случае. Это приносит множество преимуществ, и при этом я не могу придумать ни одной отрицательной стороны данного процесса, кроме, разве что, временных затрат. Ну, а если ваша команда считает зарубежных коллег мутантами и те отвечают вам взаимностью, то я советовал бы заняться этим в первую очередь. Мне кажется, парное программирование подходит для данной цели как нельзя лучше. А если у кого-нибудь получилось использовать для той же цели что-нибудь еще – буду благодарен, если поделитесь опытом в комментариях.
    DIO
    8.67
    Company
    Share post

    Comments 5

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

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

        Ну, а ответ на вопрос «зачем мы нужны» примерно следующий: их мало и они очень дорогие, а нас много и мы довольно дешевые. И их временные затраты на парное программирование не идут ни в какое сравнение с нашими на проект в целом. Более того, мы не отдаем все стори на парное программирование с ними, только самые сложные, ключевые или непонятные.
        +1
        Как решили проблему большой разницы во времени?
          0
          Планировали парное программирование на американское утро и разрешили нашим программистам делать то, что они любят и так — приходить к 12-ти :)
          0
          Спасибо за полезный опыт.

          Only users with full accounts can post comments. Log in, please.