К посту про важность продвинутого мышления в рапределенных проектах хороший комментарий оставил Данила Ковалев. Комментарий настолько хорош, что его надо процитировать.
Хочется добавить следующее
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. Личные встречи. Это очевидный пункт, но по-моему мы его упустили. Давайте его здесь для порядка тоже упомянем. Знакомиться посредством видео-конференций можно, но налаживать отношения довольно сложно. Неотвратимо появятся “козлы” на обеих сторонах.
Список пунктов продолжает расти.
> Если проект большой и состоит из нескольких
> групп, то между ними неминуемо будут
> возникать разногласия технического плана.
> Одна группа написала какой-нибудь полезный
> фрэймворк, вторая начинает сопротивляться
> его внедрению, потому что они привыкли к
> другому фрэймворку. В итоге бодание часто
> отнимает силы, нервы и не приводит ни к
> какому результату.
Не проще ли заранее обсуждать нововведения?
Потому что описанная ситуация выглядит, для второй команды, ровно как попытка объяснить им, что они ничего не понимают и всё делают неправильно.
Отдельный вопрос так ли на до было писать новый фреймворк, если уже один есть и он работает.
Если же он чем-то не устраивает, то нужно обсудить эти неустраивания и убедиться, что проблема действительно существует.
И уже потом принимать решение о написании нового фреймворка или доработки старого.
Главное вовлечь в процесс все учавствующие команды, что бы ни у кого не создавалось ощущение, что пришли какие-то странные люди и хотят от них чего-то странного.
С партнёрами завсегда проще договариваться, чем пытаться строить отношения из серии “я знаю истину и сейчас её вам расскажу!”
Хотя, естественно, и так действовать приходится иногда.
Вэтс тру. Но чтобы на стадии обсуждения не возник дедлок, таки чемпионы на другой стороне тоже не помешают.
В жизни случалась ситуация, когда вроде на обсуждении все согласны (некоторые disagree & commit) – а начинается внедрение – и наступает тако-ое сопротивление, что ай-яй-яй. Вот тут-то чемпионы и помогают, когда они есть.
Естественно, иметь на той стороне человека, с которым налажен хороший контакт и который имеет влияние на команду, завсегда хорошо.
Я лишь высказался по поводу формулировки про то что мы молча, судя по всему, написали замену имеющемуся фреймворку и его внедряем…
Угу, ет плохо, хотя иногда и такое случалось.
You tell me?!
Леха, да мы с тобой можем книжку уже писать “Как писалась … с нуля”. Там таких историй понаберется, что Демарко со своим “Дедлайном” будет курить в сторонке.
Последние коментарии