• Распределенные проекты: идем дальше

    Posted on March 6th, 2009 Александр Орлов 6 comments

    К посту про важность продвинутого мышления в рапределенных проектах хороший комментарий оставил Данила Ковалев. Комментарий настолько хорош, что его надо процитировать. :)

    Хочется добавить следующее
    1) Из изложенного в посте ясно, что сильно возрастает потребность в чёткости коммуникаций. Продумайте и зафиксируете, как вы будете общатся с удалённой командой. Общая рекомендация такая:
    а) для знакомства рекомендуется 1 Vidoconference (подумайте о ресурсах – тех. средствах), крайне желательно все _критичные_ проблемы также разбирать на Video status meeting еженедельно. Смысл тут такой – проще решать конфликты и недопонимания, когда есть невербальная обратная связь (не забываем, что мы не native-speakers, и, скорее всего навыки общения (и fluent язык) развиты только у менеджера, что прискорбно, но обычно).
    b) для обсуждения текущих проблем – ежедневные (регулярные, зависит от итераций или project tracking points) phone conf. Состав участников – минимальный. (Важно, чтобы кол-во часов проводимых в конференциях, не перебивало кол-во часов для работы, не более 1 конференции в день. Для переговорщиков – не более 2-х)
    c) основные коммуникации – письменные. Обсудитье и согласитесь с общими положениями реагирования на mails (приоритеты) и следуйте им, чётко обсудите обязательные для заполнения поля в bug tracking system. Возможно, (в начале) делайте ревью багов перед assign (это касается как Dev так и QA) на удалённую команду.

    2) Все решения тактического порядка (не говоря уж о стратегических) должны быть доведены до удалённых команд. (Документирование процесса, однако тут важно не переборщить).

    3) С каждой стороны должен быть 1 переговорщик с публично и жёстко закреплённым графиком availability. Опять же – если вам дан моб.телефон, не стоит беспокоить человека в 2 часа ночи по его времени. Имейте совесть.
    Основной смысл переговорщика – не “козёл отпущения”, а наделённый опред. полномочиями коллега, который _помогает_ _ВАМ_ добиваться результата. Основная его обязанность – довести информацию до ответственного человека. Проблему решаете вы с этим человеком. Переговорщик вас с ним свёл – всё. Это необходимое, но не достаточное условие. Переговорщик должен быть в курсе проекта и участвовать в нём. (Это моё мнение, я считаю, что внешний человек тут не эффективен).

    4) Всегда занимайте позицию “Он прав”, когда вы не понимаете, в чём проблема. Ищите смысл, может быть даже и в не очень корректных формулировках.

    Я бы добавил еще пару пунктов.

    1. Владение языком. :) В мульти-национальных проектах, крайне желательно, чтобы все ключевые участники проекта одинаково хорошо владели языком. Видимо, английским. Английский важен не только для менеджеров, но и для тех лидов. Потому что они должны участвовать в принятии решений. Обсуждение в распределенном проекте затруднено:

    • Различием в часовых поясах. Фактически, у двух сторон проекта может быть пересечение только на час. А то и не быть вовсе.
    • Способом коммуникации. Общение – не личное, и обычно даже не видео-конференция, а банально – телефонная конференция.

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

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

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

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

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

    3. Личные встречи. Это очевидный пункт, но по-моему мы его упустили. Давайте его здесь для порядка тоже упомянем. Знакомиться посредством видео-конференций можно, но налаживать отношения довольно сложно. Неотвратимо появятся “козлы” на обеих сторонах.

    Список пунктов продолжает расти. :)

    Производительность команды
     

    6 responses to “Распределенные проекты: идем дальше”

    1. Alexey Petrenko March 9th, 2009 at 13:37

      > Если проект большой и состоит из нескольких
      > групп, то между ними неминуемо будут
      > возникать разногласия технического плана.
      > Одна группа написала какой-нибудь полезный
      > фрэймворк, вторая начинает сопротивляться
      > его внедрению, потому что они привыкли к
      > другому фрэймворку. В итоге бодание часто
      > отнимает силы, нервы и не приводит ни к
      > какому результату.
      Не проще ли заранее обсуждать нововведения?
      Потому что описанная ситуация выглядит, для второй команды, ровно как попытка объяснить им, что они ничего не понимают и всё делают неправильно.

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

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

      С партнёрами завсегда проще договариваться, чем пытаться строить отношения из серии “я знаю истину и сейчас её вам расскажу!” :)
      Хотя, естественно, и так действовать приходится иногда.

    2. Александр Орлов March 9th, 2009 at 19:36

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

      В жизни случалась ситуация, когда вроде на обсуждении все согласны (некоторые disagree & commit) – а начинается внедрение – и наступает тако-ое сопротивление, что ай-яй-яй. Вот тут-то чемпионы и помогают, когда они есть. :)

    3. Alexey Petrenko March 9th, 2009 at 23:03

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

      Я лишь высказался по поводу формулировки про то что мы молча, судя по всему, написали замену имеющемуся фреймворку и его внедряем…

    4. Александр Орлов March 9th, 2009 at 23:18

      Угу, ет плохо, хотя иногда и такое случалось. :)

    5. Alexey Petrenko March 9th, 2009 at 23:19

      You tell me?! :)

    6. Александр Орлов March 9th, 2009 at 23:22

      Леха, да мы с тобой можем книжку уже писать “Как писалась … с нуля”. :) Там таких историй понаберется, что Демарко со своим “Дедлайном” будет курить в сторонке.

    Leave a reply

    You must be logged in to post a comment.