среда, 22 июня 2011 г. - www.msmirnov.ru

Сложности распределенных команд и проектов

В данном сообщении я решил описать сложности, которые возникают в процессе работы над большими проектами в составе распределенных команд.

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

Еще хочу обратить внимание, что данные проблемы не являются не решаемыми.

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


1. Часовые пояса.
Большая разница во времени (например, 12 часов) существенно замедляет процесс разработки.

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

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

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

Можно, конечно, не задерживаться, а просто написать письмо, но это еще хуже.

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


2. Языковой барьер.
Де-факто инструментом общения сейчас является английский язык.

Писать и читать на нем все более или менее уже научились.

Намного сложнее слушать и быстро отвечать.

Еще сложнее, когда твой собеседник сам не очень хорошо говорит по-английски и при этом у него сильный акцент, например, китайский или индийский.

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

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



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



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


5. Демотивация.
Предыдущий пункт приводит к демотивации членов команд, так как они не чувствуют глубокой причастности к работе над проектом. Проект на становиться для них, что называется “своим”.

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


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


6. Сложности в соблюдении единого стиля разработки.
Это касается как стандартов кодирования, так и технических и архитектурных решений.


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



7. Сложности во вскрытии проблем.
Проектные подгруппы и отдельные сотрудники незаинтересованны в потере собственного авторитета. Поэтому они, при возможности, могут перекрывать путь для негативной информации. Это возможно в силу затрудненности коммуникаций. Такое развитие событий может приводить к неразрешимым проблемам в проекте.


8. Важные вопросы могут решаться не по принципу выбора верного решения из нескольких возможных, а по принципу близости протеже решений к руководству. Последствия, я думаю, очевидны.
Мой сайт - www.msmirnov.ru

8 комментариев:

  1. Что-то мне сейчас кажется, что все проблемы эти (за исключением языкового барьера, пожалуй) решаются созданием нормальной системы для виртуальной команды.
    То есть, берём и решаем, например вопрос структуры.

    * На одном проекте должен быть один менеджер проекта, а не по одному в каждом бранче (нафик-нафик)!

    * Архитектор(ы) должны работать не против друг друга, а вместе. Если предполагается один - то он один, если несколько - то это architecture team со всеми вытекающими, а не один архитектор там, другой тут, делающие принципиально разные вещи и слабо имеющие представление о работе друг друга.

    * Разработчики получают своё "поехали" только после того, как добро дано архитектурной командой (как командой).

    * Та же фигня с бизнес-аналитиками.

    * Все члены команды должны иметь принципиально одинаковую связь с менеджером проекта, бизнес-аналитиками и архитекторами. Пишу "принципиально" потому, что объективные затруднения в виде часового пояса и языкового барьера никуда не денешь, но в остальном всё должно быть равно. То есть, если я выучил язык и готов проснуться ночью - я ничем не отличаюсь от "локального" члена команды, у меня нет никаких дополнительных ступеней до этих людей и т.д. :)

    Мораль: проблема решена сотни раз в нашей индустрии (и до неё не только в нашей), решается она просто организацией работы.

    P.S. Я не рассматриваю случай сабпроекта, только случай, когда это один и тот же проект. В случае сабпроекта немного иначе, но смысл примерно тот же - организационная "чистка" и прояснение.

    ОтветитьУдалить
  2. Alexey Raga менеджер в бранче нужен чтобы была прямая свясь с разработчиками. ты не можешь както мотивировать людей и решать их проблемы если ты работаешь удаленно да еще в другом часовом поясе. нужна face2face связь
    я думаю ты имел в виду одит Program Manager всего, но несколько project manager в каждом бранче

    ОтветитьУдалить
  3. Нет, я имел в виду именно project manager. Project Manager управляет, ещё раз, прежде всего проектом а не людьми.
    На местах должны быть тимлиды. Если мультипроектная ситуация - то department manager'ы или functional manager'ы. Но никак не project manager'ы. Этот один. Их просто больше не нужно.

    ОтветитьУдалить
  4. Alexey Raga тимлиду обычно пофигу кто и что не успевает
    нужен ктото кто разбирается в людях, хоть проджект хоть кто, а не занимается техническими вопросами.
    я не видел ни одного примера где компания бы работала нормально без местного менеджера

    ОтветитьУдалить
  5. Alexey Raga кстати, вы должны это были проходить на заняниях
    там очень детально разбиралось почему то как ты описал никогда не будет работать :)

    ОтветитьУдалить
  6. Michael Nemtsev А я и не говорю, что она должна работать без местного менеджера.
    Department Manager'а никто не отменял, благо тут явно имеем друго департамент. Просто он не является менеджером проекта.

    И уж точно дряни с миллионом пиэмов на проекте нигде не то, что не предлагалось, а и более того, явно утверждалось, что менеджер проекта на линейном проекте один.
    Более того, я даже специально эту тему поднимал и она специально обсуждалась.
    Это так и будет работать.

    Это, кстати, ты должен помнить, что department или functional менеджер может выполнять работу project manager'а (хоть и не слишком эффективно) в том случае, когда проект замкнут в рамках департамента. В рассматриваемом случае это не так.

    ОтветитьУдалить
  7. Alexey Raga deparment менеджерне будет менеджить проблемных людей, у него другие проблемы. нужен именно микро-менеджмент какойто, кто разбирается в текущей команде и может ее мотивировать

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

    ОтветитьУдалить