Команда, работающая над продуктом, совсем не обязательно располагается в одной локации. В современном мире все происходит чаще как раз наоборот. Так, безусловно, удобнее. Но в этом есть и определенные сложности.
Об этом и пойдет речь в данной статье
Когда люди работают в одном помещении, лицом к лицу, общение происходит через мимику, жесты, интонацию и слова. Если у команды есть доска задач, то скорость разработки продукта увеличивается колоссально.
Но почему же тогда так популярны распределенные команды?
Ответ на поверхности - для современного бизнеса важно получать доступ к талантам по всему миру и разрабатывать решения для аутсорсинга. Если нет возможности собрать всех под одной крышей, то нужно учиться создавать распределенные команды.
Оптимизируйте размер и состав команды
Для распределенной команды очень важно правильное сочетание талантливых людей. Например, у вас есть распрекрасный разработчик, но вы не можете его нанять, потому что ваша команда разработки находится в другой стране. Невозможность задействовать доступные таланты увеличивает общие затраты вашей компании на подбор персонала.
Важно распределять не только разработку, но и ваши процессы и задачи. В описанной выше централизованной модели вы рискуете зайти в тупик, если вашей компании нужно открыть или закрыть региональное представительство.
Например, пребывание всех ваших разработчиков в одной стране, всех ваших менеджеров проектов в другой стране и всех ваших тестировщиков в третьей стране не способствует оптимальной работе распределенных команд. Такой подход часто приводит к одностороннему потоку информации и может привести к хаосу и взаимным обвинениям, если что-то пойдет не так. Вы также рискуете непрерывностью определенного функционала, если вам придется закрыть одно региональное представительство, скажем, где работают все менеджеры по продукту. Такие факторы, как сложность сферы деятельности, техническая сложность, также могут усложнить набор и удержание нужных людей в распределенной команде.
Распределите работу равномерно
Неравномерная рабочая нагрузка может стать причиной узких мест. Следует серьезно относиться к жалобам на рабочую нагрузку и быть готовыми аккуратно и быстро сбалансировать распределение работы.
Уравнять рабочую нагрузку сложно, но это возможно с помощью SWAT-анализа (Субъективная методика оценки рабочей нагрузки). Создание SWAT в распределенной среде является не менее сложной задачей, потому что члены команды распределены географически, а SWAT требует очных встреч один на один.
Поддержание относительно равномерной рабочей нагрузки в команде также является важной частью поддержания движения команды. Если кто-то перегорает из-за нереально высокой рабочей нагрузки, перераспределите некоторые задачи между разработчиками, если это возможно. Если кому-то не хватает работы, найдите способы удержать вовлеченного в проект человека. Люди, находящиеся в крайних состояниях от идеальной нагрузки, обычно теряют фокус и в конечном итоге оказываются оторванными от коллектива и рабочего процесса.
Agile-практики
По определению Agile опирается на набор взаимно поддерживающих практик. Когда в одной команде одна практика не имеет смысла, от этой практики следует отказаться, либо заменить. С распределенными командами соблюдение и закрепление практики требует больше времени и усилий. Владельцы продуктов и Scrum-мастера, которые продвигают практику, даже когда она явно не работает, становятся «врагами народа».
В распределенной среде передовые практики использования инструментов играют жизненно важную роль при внедрении Agile. Например, вы можете применить комментирование кода, настроив политику регистрации изменений в Team Foundation Server, или вы можете использовать централизованный инструмент отслеживания ошибок и назначать обновления статуса перед ежедневным стэндапом для отслеживания обновления статусов. В течение первых нескольких недель после того, как вы установите подобные практики, вы заметите, что все следуют этим правилам. Когда вы приближаетесь к релизу, люди начинают пренебрегать ими, поэтому как Scrum-мастер, вы должны аргументировать необходимость их использования для отслеживания хода реализации проекта и помочь разработчикам довести их до автоматизма.
Разница во времени
Команды, участники которых работают в разных часовых поясах, сталкиваются с уникальными коммуникационными проблемами. Несмотря на то, что ежедневные стэндапы и пересекающиеся рабочие часы в некоторой степени смягчают эту проблему, часть работы часто откладывается, потому что требуется уточнение, что-то требует доработки, потому что изменения одного человека повлияли на работу остальных в другом месте или изменения не были полностью учтены. Подобные регулярные переделки могут повлиять на здоровье команды и может пострадать моральный дух, когда людей неоднократно просят повторить работу. Иногда требуются принудительная синхронизация разработчиков и обмен статусами всей командой о состоянии дел в конце дня.
В одной организации, в которой я работал, все обменивались статусами в конце дня, в которых содержалось состояние версии кода, состояние сборки и все известные проблемы, над которыми нужно было поработать или не учитывать, когда разработчики из других регионов начинали свой день.
Вы можете помочь своей команде работать с теми, кто работает по всему миру, сначала ознакомив всех с информацией о часовых поясах, в которых работают члены команды.
Вы можете использовать что угодно: от физической карты с кнопками, отображающими распределение команды, до утилит для часовых поясов, таких как Microsoft Time Zone, или один из инструментов в Microsoft Outlook, например, Time Zone Data Updater. Когда вы включаете несколько календарей в Outlook, вы можете видеть время в других часовых поясах. В Windows вы можете использовать несколько часов.
Культурные различия
В течение жизненного цикла большого проекта члены распределенной команды сталкиваются с различными ситуациями. Знание культурных различий может помочь им понимать более глубокий контекст.
Например, люди в разных культурах имеют разные представления об авторитете. В западных странах можно сказать: «Нет» — даже если кто-то с более высоким авторитетом просит вас что-то сделать. Однако во многих индийских и азиатских культурах подходящим ответом в той же ситуации было бы: «Да» — потому что авторитетная фигура задала вопрос, даже если отвечающий знает, что он или она не сможет выполнить обещание. В большинстве азиатских культур приход на встречу рано или поздно не обязательно является дурным тоном, как в Соединенных Штатах или Великобритании.
ЧТО ЕЩЕ
Организовывайте взаимодействия лицом к лицу: иногда, особенно для крупных проектов, необходимо личное собрать вместе ключевых членов команды, чтобы выстроить командные договоренности и сформировать команду. Убедитесь, что в ваш бюджет заложены средства на командировки и сообщите задействованным членам команды о требованиях к поездке.
Планируйте постоянные демонстрации и ретроспективы: демонстрации продукта с ретроспективой в конце увеличивают прозрачность вашего проекта, транслируют его статус и обеспечивают мгновенную обратную связь, а также возможности для настройки процесса. Вовлечение клиентов в эти демонстрации (в специально отведенное с постоянной периодичностью время) способствует общему пониманию бизнес-контекста проекта и позволяет заинтересованным сторонам общаться с командами разработчиков.
Предоставьте необходимые инструменты и обучение: команды часто используют инструменты неоптимальным образом и распределенные команды ничем не отличаются. Сначала определите инструменты, которые необходимы. Получите общее одобрение от вашей команды, также можете проконсультироваться на форумах, таких как Stackoverflow.com, чтобы узнать, какие инструменты будут полезны для вашей команды в конкретном проекте. Во-вторых, обучайте команду инструментарию. Не ожидайте, что члены команды узнают все о новом инструменте, не используя его, особенно если они узнали об этом из онлайн-ресурсов. Дайте им время после обучения протестировать инструмент в реальной работе.
Реорганизовывайте команды в последнюю очередь: дайте всем членам команды достаточно времени, чтобы показать свои навыки и вовлеченность. В распределенной команде общение и отслеживание личного прогресса труднее. Частые изменения в составе команды усугубляют эти проблемы. Постоянное перетасовывание состава команд может привести к снижению доверия, морального духа и продуктивности.
Развивайте приверженность качеству и поставке: не все понимают важность качества и поставки. Обязательно проинформируйте членов вашей команды об уровне качества и требованиях к поставке, которые вы ожидаете для каждого проекта. Постоянно ищите способы улучшить качество и поощрять людей, которые демонстрируют внимание к качеству и желают взять на себя ответственность за проект от начала до конца.