Взаимодействие между людьми — тема, которую сложно полностью раскрыть в одной статье. Мы регулярно испытываем сложности в общении на своем родном языке и в своей локальной среде. A когда речь идёт о распределенных командах, сложностей может быть еще больше: добавляются языковые барьеры, разные часовые пояса, определенные культурные различия. В таких условиях недопонимания могут возникать чаще, чем в локальных командах, а их последствия могут быть более заметны — от задержек в проектах и снижения качества конечного продукта до эскалации конфликтов и потери доверия в команде. Своим опытом работы с международными командами в статье делится Юлия Немудрова.
Раньше я жила и работала в России, а недавно переехала в США. И если говорить про американский рынок, то почти в каждой компании вы встретите именно интернациональную команду, где собраны люди из разных стран и культур. Удаленный формат работы также подливает масло в огонь. Например, я работаю на полной удаленке, и в моих командах есть люди из США, Индии и Польши. Работать в такой среде невероятно интересно, но также — сложно. В этой статье я поделюсь практическими рекомендациями и советами, основанными на моем опыте. Я думаю, что часть советов применима и для локальных команд. Однако, я постаралась осветить те моменты, которые могут сыграть решающую роль именно в глобальной среде. Эти знания помогли мне быстрее адаптироваться и наладить работу с коллегами по всему миру, а сейчас способствуют ускорению процесса разработки и поддерживают продуктивную атмосферу в командах несмотря на разницу в часовых поясах и культурах.
Работа с командами разработки и стейкхолдерами в глобальной среде
Представьте ситуацию: вы как всегда составили детальные user stories, все обсудили на grooming сессиях, дали четкие инструкции и отдали задачу команде разработки. Проходит неделя, команда приносит результат… И это не совсем то, что вы ожидали. Знакомо? По моему опыту, «нечеткие требования» — это фраза, которая чаще всего будет звучать в такой ситуации. Независимо от страны.
Или другая ситуация: фича готова, вы довольны, а главный стейкхолдер говорит: “Вообще-то мы договаривались по-другому”. При работе в глобальных командах такие ситуации могут привести к значительному замедлению прогресса. Поэтому сейчас я уделяю очень пристальное внимание тому, насколько мне самой понятны ожидания от итогового результата и насколько четко я транслирую их командам. Вот некоторые из приемов.
Визуализируйте как можно больше
“Показать” для меня всегда в разы лучше, чем “рассказать”. И если есть что-то, что работает одинаково хорошо в любой культуре, то это визуализация.
Для команд разработки почти к каждой задаче в дополнение к текстовому описанию я готовлю визуальный элемент: от самого простого — могу сделать скриншот экрана, выделить какую-то область и написать комментарий что нужно исправить; могу добавить максимально реальный mock обновленной страницы или workflow из нескольких страниц со стрелками, стикерами и комментариями. Также, во время обсуждений я почти всегда открываю приложение и показываю на примере: лайф демо ошибки или процесс as is. Команда настолько привыкла, что теперь иногда коллеги сами напоминают мне об этом, когда я этого не делаю: “Открой, пожалуйста, приложение и покажи, где это”.
Я использую визуализацию и для сбора и подтверждения требований к продукту. Например, недавно мне нужно было подтвердить rollback plan в случае неудачного запуска, и я нарисовала очень простую схему, где первый уровень – что именно пошло не так, а второй уровень – что мы можем сделать в зависимости от этого. Зелеными стикерами я обозначила понятные пункты, к которым нет вопросов, розовыми – то, что надо обсудить. Это дает вид полной картины и понимание пробелов одновременно, а это всегда важно для стейкхолдеров.
Для визуализации я использую Miro много лет и мне он очень помогает, но вы можете выбрать любой другой подходящий инструмент. Например, российские аналоги – flip, sBoard, “Онто”.
Активно и регулярно проверяйте понимание задач командой
Мы знаем, что четкие и понятные требования — залог успешной работы. Понятие “четкости” конечно может варьироваться в зависимости от “сеньорности” команды, но так или иначе ваша задача как менеджера продукта — убедиться в том, что команда понимает, что вы от них ожидаете и как должен выглядеть итоговый результат.
На каждой груминг-сессии после обсуждения задачи я обязательно задаю максимально прямые вопросы вроде: “Понятны ли acceptance criteria?”, “Как вы поняли expected result (ожидаемый результат)?” или “Есть ли у вас сомнения? Любые сомнения”. Я спрашиваю каждого по отдельности, включая разработчиков и QA. Если задача сложная, иногда переспрашиваю каждого по 2 раза в течение обсуждения. Это может показаться излишним, поскольку если есть сомнения — люди должны высказаться, но в действительности так работает не всегда (мы еще поговорим о разнице культур чуть позже). Спустя время как и в любой команде вы научитесь “слышать” (а скорее даже чувствовать) уровень уверенности и понимания задачи командой по их ответам на ваши вопросы.
Не экономьте время на документацию
Я согласна, что «работающий продукт важнее полной документации». И слышала разные мнения: например, что PRD или BRD уже не модно – достаточно написать user stories и раздать командам. Однако, я вижу, что с крупными проектами так не работает – что-нибудь обязательно потеряется, команды рассинхронизируются, а вы забудете, что от вас просили стейкхолдеры в этом месте. Возможно, в стартапах этот совет не пригодится, но в корпорациях будет очень полезен. Четко задокументированные требования помогают избежать рассинхронизации и путаницы в дальнейшем.
Я понимаю, что документация может показаться пустой тратой времени. Однако, по своему опыту знаю, что, потратив чуть больше времени сейчас, вы сэкономите его потом. Например, прислав ссылку на подготовленный документ, вместо получаса объяснений на встрече что конкретно мы делаем, как и зачем (и мы кстати еще поговорим про языковой барьер позже), вы всегда сможете погрузить команду в контекст и задачи заранее. Плюс, если стейкхолдеры подтвердили вам документ, то им сложно будет “передумать”. Инвестировав время в качественную документацию сейчас, вы избежите потерь в будущем.
Сейчас я инвестирую в эти пункты больше времени, чем раньше, и на практике вижу, что это минимизирует недопонимания и недоразумения. Потратьте время на эти практики на этапе планирования — это позволит ускорить процесс разработки и улучшить качество результата.
Самоорганизация и управление временем – “уровень 2.0”
Разница во времени — ещё один аспект, который требует особого внимания. Когда члены команды начинают работать, вы можете быть уже offline и наоборот. Я вижу, как из-за этого иногда выпадают целые дни прогресса, и заметила за собой, что стараюсь быть еще более организованной, чем когда-либо.
Чтобы избежать неприятных сюрпризов, придерживайтесь следующих правил.
Старайтесь не делать ничего в последний момент
Одна из первых вещей, которые я усвоила, работая с командами из разных стран, – это необходимость быть “на шаг впереди”. Я стараюсь ничего не отправлять в последний момент, потому что по закону подлости в нужный момент обязательно не откроется ссылка, файл окажется слишком тяжелым или архив — сломанным как раз тогда, когда команда должна зарелизить что-нибудь завтра.
Если запаса по времени совсем нет — это огромный риск для глобальных распределенных команд. Когда они начнут работать, вы будете спать, а когда вы проснетесь и увидите сообщение про сломанную ссылку или отсутствие доступа – будет уже слишком поздно что-то исправить. Поэтому старайтесь всегда держать запас времени.
Уделите больше внимания управлению временем
Еще один важный аспект – это умение гибко планировать свой график. Советую построить свой день так, чтобы максимально охватить общие часы работы с учетом пересечения часовых поясов по времени с другими странами. Я нахожусь на западном побережье США и работаю с 6 утра как раз из-за этого. И даже так у меня получается всего 2,5 часа “общего времени” с Индией и 2 часа с Польшей.
Раньше у меня была привычка начинать день спокойно и иметь хоть чуть-чуть времени, чтобы настроиться. Сейчас такой роскоши нет. Каждый раз, когда я начинаю свой рабочий день, я знаю: это время на встречи, обсуждения, и решение вопросов, требующих быстрой реакции. Все остальное должно подождать — никаких задач, требующих моего полного фокусирования, на утро у меня нет. Также, сейчас я планирую свое “завтра” накануне — то есть “сегодня” в конце рабочего дня. Такой подход ускоряет взаимодействие: позволяет решать большинство вопросов здесь и сейчас пока рабочий день на другом конце света еще не закончился, а значит не откладывать проблемы на завтра. А также избежать лишнего переключения контекста для разработчиков. В условиях разницы во времени менять свои привычки необходимо.
И конечно же, никто не отменял общие принципы итеративной работы, регулярные встречи для синхронизации, milestones, трекинг и т.д. — в этом работа не сильно отличается.
Культурные различия
Когда работаешь с людьми из разных стран, важно понимать, что мы все видим мир по-своему. Одна и та же ситуация может трактоваться совершенно по-разному в зависимости от культурных традиций. Мне кажется, что книга “The Culture Map” Erin Meyer будет отличной отправной точкой в пути познания этих различий. Очень рекомендую ее прочитать. Ниже поделюсь ситуациями из своего опыта и тем, какие уроки я вынесла для себя.
Знайте культурные особенности всех членов вашей команды и научитесь “читать между строк”
Я не поддерживаю стереотипизацию как таковую, но все же в каждой культуре можно найти черты, которые будут общими для большинства людей, воспитанных и выросших в ней. Я считаю, что как минимум знать о них — уже половина успеха. Опишу пару примеров.
Некоторые культуры не привыкли открыто высказывать критику. Например, если разработчик из Индии говорит вам: «я не уверен», – иногда это может означать «я с этим категорически не согласен». Или наоборот: разработчик из России или Польши может открыто и уверенно выражать сомнения, но это не значит, что он отвергает идею и отказывается решать задачу.
Другой особенностью, о которой важно помнить в контексте создания продуктов, может быть то, что в некоторых культурах не принято проявлять инициативу и открыто высказываться пока тебе не дали слово. Даже если это brainstorm meeting. Поэтому, в то время как мои американские коллеги будут активно обмениваться мыслями, иногда даже вежливо перебивая друг друга (что является нормой), мои коллеги из Азии могут промолчать и не поделиться своими мыслями вообще, потому что их не спросили. Если такие люди есть в вашей команде — не забудьте пригласить их к обсуждению и отдельно спросить их мнения на тот или иной счет, чтобы получить полную картину.
Также, например, работая на разных рынках, важно понимать разницу в подходах к донесению информации. В России (или Германии), например, часто важно показать процесс того, как вы пришли к результату. В США, напротив, ценят краткость и конкретику: сначала результат, а уже потом детали.
Будьте аккуратны с негативным фидбеком и открыто говорите о своих ожиданиях
Это, пожалуй, основная “опасная” зона. В некоторых культурах просто не принято давать негативный фидбек. Вообще. Поэтому прямо высказывая свое мнение, вы можете кого-то ненароком обидеть. Об этом надо помнить и тщательно подбирать момент, тон и слова.
Однако не смешивайте умение выражать свою точко зрения прямо и понятно с негативом. Я часто слышу, что “Being direct and going straight to the point” — это супер-сила людей из русскоговорящих культур. Ее важно использовать в работе, необходимо лишь научиться балансировать — оставляя тот же смысл, выбирать правильные слова. И лучше не использовать “слова – усилители”, такие как “very”, “extremely”, “highly” и т.д. Некоторые коллеги открыто делились, что они идут ко мне потому что знают, что услышат открытый и честный фидбек на ситуацию, это может быть очень важно в понимании рисков или принятии важных решений.
Также будет полезно сообщить о своих ожиданиях заранее — о том, как вы привыкли работать, какой вклад вы бы хотели видеть от каждого, что для вас неприемлемо. Даже в локальных командах не нужно предполагать что что-то является само собой разумеющимся, а тем более это применимо к командам глобальным. Например, я всегда прошу сообщать о возможных проблемах и потенциальных рисках заранее. И поэтому я всегда оперативно реагирую на подобные запросы. Также я часто напоминаю, что поддерживаю культуру открытых дверей и открыта ко всем вопросам и сомнениям. Я напоминаю об этом для того, чтобы все чувствовали себя комфортно написать мне в любой момент (и я имею в виду рабочие дни: читать рабочие чаты в выходные или нет — это только ваш выбор!). Мне кажется, что даже просто озвучивание этой открытости помогает вырастить доверие в общении. Возможно, кто-то чувствует себя неуютно ставить под сомнение ваши идеи на общей встрече, но в личной переписке или разговоре сможет раскрыться. Предоставьте им такую возможность.
Языковой барьер
Языковой барьер — ещё один аспект работы в глобальных командах, который может влиять на продуктивность. Здесь важно помнить, что он не только “ваш”, он — общий. В американских компаниях рабочий язык команды — английский, но часто для многих в команде он не является родным. Что может помочь в таких ситуациях:
Упрощайте коммуникацию
Чтобы минимизировать риски непонимания с командой и коллегами, я рекомендую использовать простые и понятные слова и фразы. Конечно, не стоит в профессиональной среде разговаривать на уровне А1, но также не нужно щеголять знанием английских метафор. Если очень хочется блеснуть знаниями языка — созвонитесь с коллегой, для которого этот язык — родной. В интернациональной среде почти на любой встрече будут люди, для которых английский не является родным, вам нужно об этом помнить, ведь как мы знаем, цель любой коммуникации — чтобы люди тебя поняли, а не “показать умение говорить красиво”.
“Эффект метафор” я, кстати, часто испытываю на себе: у меня есть один коллега (native speaker), который использует сложные предложения и часто вставляет в них метафоры. Так вот, мне приходится часто его переспрашивать: “Let me confirm I get it right…” или “Let me say it back to you to confirm my understanding: …”. И переспрашивать — окей, он спокойно объясняет мне всё иначе.
Дисклеймер: не советую применять эту рекомендацию и специально упрощать свой язык на встречах с топ-менеджментом — там это может сработает против вас. К подобным встречам лучше чуть более тщательно подготовиться чтобы знать термины и важные для донесения мыслей слова: это поможет вам не переживать о том, что вы забудете какое-то слово в моменте.
Записывайте встречи на видео
Я работаю удаленно и все мои встречи — это видеозвонки. В первые месяцы я записывала почти все: очень сложно было сходу вникнуть во все детали, да еще и на иностранном языке (акценты и разные произношения сильно влияют на уровень понимания). Сейчас я все еще записываю некоторые встречи: например, если тема новая или сложная и мы обсуждаем требования со стейкхолдерами (потом я могу поделиться этим видео с командой если нужно). Также, у нас есть правило: все груминг сессии с командой разработки записываются на видео и ссылка на запись всегда прикреплена к задаче, чтобы каждый в любой момент мог посмотреть видео и вспомнить детали, которые мы обсуждали.
Иметь запись встречи будет полезно в случае, когда вы не все поняли: вы сможете вернуться и переслушать отдельные моменты. Также это хорошая помощь в условиях плотного графика и при встречах back-to-back — если не успели сделать детальные заметки, всегда можно вернуться и пересмотреть запись, чтобы не упустить ничего важного. С развитием AI появились удобные инструменты, которые делают заметки и саммари встречи за вас (например, Otter.ai, Fireflies.ai, tl;dv), если правила вашей компания позволяют — пользуйтесь ими и экономьте своё время.
Не стесняйтесь переспрашивать или просить прислать вам запрос в письменном виде
Если вы что-то не поняли — не стесняйтесь переспросить. Это нормально. Можно прямо попросить объяснить то же самое, но другими словами: “Sorry, I still didn’t quite understand. Could you please say it in different words?”. В международных командах люди к этому давно привыкли и относятся спокойно. Иногда если я чего-то не понимаю на слух, я прошу написать мне эту же информацию текстом, прислать дополнительные материалы и дать время на ревью.
Я уже говорила про визуализацию выше и не хочу повторяться, но это один из мощнейших инструментов в борьбе с языковым барьером.
P.s. Юмор и мемчики – интернациональны!
Добавляйте фана в работу. Если коллега прочитал ваше сообщение в чате, но не ответил, а вам очень надо получить от него информацию — пришлите ему смешную гифку как напоминание, что вы все еще ждете. У меня есть один коллега, которому я шлю смешные гифки с котами чтобы привлечь его внимание когда мне нужен какой-то срочный ответ и я не могу его получить. Конечно, прежде чем делать что-то такое, поймите, принято ли это в вашей компании. Убедитесь, что вы с коллегами “на одной волне” и не отвлекаете их от серьезных дел, посылая смешные картинки. И я бы не рекомендовала посылать гифку со смешным котом кому-то из топ-менеджмента (хотя в вашей компании это может быть окей).
Заключение
Работа менеджера продуктов в глобальных удалённых командах — это всегда вызов. Но еще это всегда жутко интересно! Если что-то идет не так, применяйте свои лучшие продуктовые скиллы: идентифицируйте, где именно проблема, стройте гипотезы и тестируйте их, а я буду рада почитать про ваши эксперименты в комментариях.
Помните, что каждый элемент взаимодействия — будь то понятная схема или вовремя отправленный файл — играет важную роль в итоговом успехе команды, а значит — и продукта.
