Автостопом по галактике. Как минимизировать риски в международных проектах

Всем привет! Меня зовут Алексей, я Project Manager в компании Astound Commerce. Более восьми лет я занимаюсь управлением проектами как в продуктовых, так и в сервисных компаниях. Последние несколько лет я управляю проектами в сфере e-commerce, работая с командами, распределенными по всему миру (США, Великобритания, Италия, Румыния, Словакия, Колумбия, Болгария, Индия, Чехия).

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

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

Voyage в мир рисков

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

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

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

Таких категорий тоже немало, поэтому давайте перенесемся практически к самому концу классификации и ближе к центру нашей вымышленной галактики и объединим (или разделим) все риски в две группы: туманность отрицательных рисков и туманность положительных рисков. Первую группу еще называют угрозами (threats), а вторую — благоприятными возможностями (opportunities).

Но сама по себе классификация рисков нам ничего не говорит о том, что же с этими рисками делать дальше. Как быть?

Стратегии реагирования на риски

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

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

Итак, всего существует 5 стратегий реагирования на отрицательные риски (угрозы) и 5 стратегий реагирования на положительные риски (благоприятные возможности). Первая и пятая стратегии являются общими для обоих видов рисков.

Стратегии реагирования на угрозы:

1. Эскалация (Escalate).
2. Уклонение (Avoid).
3. Передача (Transfer).
4. Снижение (Mitigate).
5. Принятие (Accept).

Стратегии реагирования на благоприятные возможности:

1. Эскалация (Escalate).
2. Использование (Exploit).
3. Разделение (Share).
4. Увеличение (Enhance).
5. Принятие (Accept).

Как можно догадаться, стратегии реагирования на положительные риски являются не чем иным, как зеркальным отображением стратегий реагирования на отрицательные риски:

Эскалация ↔ Эскалация

Уклонение ↔ Использование

Передача ↔ Разделение

Снижение ↔ Увеличение

Принятие ↔ Принятие

Сегодня мы поговорим только об одной стратегии реагирования на определенную группу рисков, а именно — о методах снижения (минимизации) рисков на проектах, разворачиваемых в разных странах и/или разных часовых поясах

Вот она среди всего вышеизложенного многообразия галактик и туманностей:

Остановимся здесь!

Пожалуй, следует привести классическое определение данной стратегии из PMBoK:

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

А что минимизировать будем?

Теперь, собственно, о том, какие риски присущи реализуемым в разных странах и/или разных часовых поясах проектам. Какие они? Сколько их? Как их определить?

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

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

Но все же можно выделить две группы рисков*, которые наиболее характерны для таких проектов. Коротко их можно назвать «временны́е риски» — связанные с рассинхронизацией проектного времени, и «культурные риски» — связанные с культурными различиями участников проекта. Давайте посмотрим, к каким последствиям они приводят и как эти последствия минимизировать (а в идеале — избежать).

Временные риски

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

Непродуманный подход к организации проектного времени приводит к:

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

Например, если вы — проектный менеджер, и ваш проект включает специалистов из двух локаций (из Украины и из Токио) — вы должны учитывать, что хоть вы и трудитесь в 15:37 в поте лица над задачами проекта, ваши токийские коллеги, скорее всего, поют в караоке, так как у них на часах уже 21:37. Вряд ли они обрадуются, если вы решите с ними связаться.

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

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

Как это сделать?

Знайте, когда праздник не на вашей улице

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

Предположим, одна из ваших команд находится в Медельине (Колумбия). Команда состоит из пяти человек. При планировании проекта вы не учли пять государственных праздников в Колумбии, которые приходятся на даты реализации проекта. Пять праздников = пять выходных. Результат — минус 200 рабочих часов, неприятный сюрприз, которого можно было бы избежать.

Сокращайте вынужденные простои

В данном контексте простой для распределенных команд — это ситуация, когда одному участнику проекта или команде из часового пояса, в котором сейчас рабочее время, необходимо что-то от другого участника проекта или команды из часового пояса, в котором сейчас нерабочее время.

Пример: украинской команде разработчиков необходимо получить спецификации от американской команды для того, чтобы начать разработку завтра утром. В Киеве сейчас вечер, в Нью-Йорке — утро. Американская команда в течение дня завершила спецификации, но не отправила украинской команде.

Мафия засыпает, просыпается украинская команда.

Украинская команда утром начала рабочий день и обнаружила, что работать она не может — нет спецификаций. В Нью-Йорке ночь, и никто не может отправить спецификации украинской команде, она вынуждена простаивать. Целый день потерян.

Одним из решений, минимизирующих вышеописанный риск, может быть следующее: каждый вечер перед завершением рабочего дня украинская команда отправляет американской команде в проектный канал связи (slack, e-mail и т.п.) ряд открытых вопросов, требующих решения до наступления следующего украинского рабочего дня. После чего украинская команда отправляется отдыхать. Пока в Киеве ночь, в Нью-Йорке — рабочий день, в течение которого уполномоченные специалисты готовят ответы украинской команде, чтобы с наступлением украинского рабочего дня вопросы были решены, и украинская команда смогла продолжить работу без вынужденных простоев. В свою очередь, если у американской команды есть вопросы к украинской, она также их адресует конкретным специалистам перед завершением своего рабочего дня, и далее по вышеописанной схеме. Все очень просто, но нужно не забывать о таких простых, но эффективных решениях.

Еще одним решением может быть наличие одного или нескольких членов проектных команд, для которых комфортно работать в слот времени, накладывающийся на рабочее время всех или большинства команд. К примеру, один из членов команды в вышеописанном случае может работать с 15:00 до 00:00, таким образом обеспечивая постоянную связь между американской и украинской командами в рабочее время каждой из них. Этим человеком с необычным графиком может быть и PM, но зачастую целесообразнее, чтобы это был член команды разработки.

Вышеописанные решения хоть и не являются панацеей, но прекрасно минимизируют риски простоя и увеличивают прозрачность проекта. By the way, один день простоя для команды из пяти человек — это 40 часов проектного времени.

Говорите о времени на понятном собеседнику языке

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

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

Письмо #1

Dear Mr. Heisenberg,

Let me notify you that the weekly status meeting will be held at 12pm GMT-5:30 MST, 12.12.20

Письмо #2

Dear Mr. Heisenberg,

Let me notify you that the weekly status meeting will be held on this Thursday at 17:30 (your time zone)

А теперь ответьте на несколько вопросов:

• Какое из двух писем вам понятнее?
• Какое из них удобнее читать?
• Какое из них не вынуждает вас думать и производить дополнительные калькуляции в уме?

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

• получатель запомнил только время, но забыл проверить, в каком именно часовом поясе оно обозначено (или не понял, как его пересчитывать);
• получатель запомнил время и автоматически подумал, что это в его часовом поясе;
• получатель не обратил внимания на дату (или не понял, в каком она формате);
• получатель пересчитал время для своего часового пояса, но почувствовал раздражение.

Первое письмо создало все условия для того, чтобы получатель не пришел на митинг, тогда как второе минимизировало такие риски. Второе письмо не вызывает раздражения и мысли «вникну и отвечу потом», оно понятно и этим приятно.

Проявляйте заботу о получателях ваших писем и сообщений.

О заботе о тех, кому вы пишете и, в принципе, о том, как писать — в великолепной, по моему мнению, книге «Новые правила деловой переписки», М. Ильяхов, Л. Сарычева.

Культурные риски

Это вторая обобщенная группа рисков. В данном случае имеются в виду именно международные проекты, ведь гипотетически в разных часовых поясах могут работать команды одной или родственных национальностей, и в таком случае культурные различия будут сведены к минимуму. Например, «Москва — Владивосток» — семь часов разницы, но культурные различия будут практически нулевыми, в отличие от «Москва — Нью-Йорк» при той же разнице во времени. Как же минимизировать такие риски?

Уделяйте больше времени коммуникациям

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

Учитывайте, что если ваш проект разворачивается, например, в Германии, Индии и Японии, то, скорее всего, ни один из членов команды не будет носителем языка. Британский английский, индийский английский, немецкий английский и японский английский — очень разные английские, и нужно какое-то время, чтобы привыкнуть к акцентам и включиться в разговор. Это необходимо учитывать при планировании и подготовке к встречам. В устном или письменном общении используйте те слова, которые, по вашему мнению, будут понятны большинству из тех, кому они адресованы. Двусмысленность обратно пропорциональна простоте изложения.

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

Также полезно записывать все звонки и онлайн-совещания, которые вы считаете важными. Zoom, а с недавних пор и Google Meet, прекрасно с этим справляются. Все эти совещания в 99% случаев будут проходить на английском, причем, скорее всего, на неродном английском, поэтому велика вероятность, что какую-то часть вы можете не понять или понять неверно. Именно поэтому хорошо бы иметь возможность пересмотреть запись совещания, чтобы разобраться с неоднозначными вопросами.

Чаще индивидуально общайтесь с членами команды, и не только о проекте. Это особенно важно для распределенных remote команд, когда коммуникации и так минимальны. Такого рода общение выполняет две очень важные функции: держит в тонусе вас и ваших vis-a-vis как дополнительный инструмент мониторинга и удовлетворяет социальную составляющую потребности в общении, препятствуя выгоранию. Эмпатия наше все.

Учитывайте контекст

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

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

Второй пример: коммуникации можно условно разделить на две группы — коммуникации с низким контекстом и коммуникации с высоким контекстом. Коммуникация с низким контекстом подразумевает, что слова означают лишь то, что они означают, никаких двусмысленностей. Коммуникация с высоким контекстом предусматривает додумывание и чтение реального смысла между строк. Низкий контекст оперирует фактами и очевидностями, высокий — интуицией, опытом и метафорами.

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

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

Более детально об этом можно прочесть в книге «The Culture Map: Breaking Through the Invisible Boundaries of Global Business» by Erin Meyer. В русском переводе — «Карта культурных различий. Как люди думают, руководят и добиваются целей в международной среде».

Заключение

Несомненно, данная статья охватывает лишь некоторые риски и рекомендации по их снижению, которые могут возникать в проектах, распределенных в разных странах и/или разных временных зонах. Общая рекомендация — старайтесь быть как можно проще, понятнее и вежливее. Такой подход, на мой взгляд, помогает минимизировать многие риски, и не только связанные с проектами.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU