Почему важны распределенные команды и как их создать

«Предположим, вы один в стартапе и вам нужен партнер. Тебе бы понадобилось много времени, чтобы найти партнера, верно? Он будет половиной вашей компании. Почему вам нужно тратить меньше времени на поиски трети вашей компании, четверти вашей компании или пятой части вашей компании? Когда вы работаете в стартапе, первые десять человек определят, преуспеет компания или нет. Каждый составляет 10% компании. Так почему бы вам не потратить столько времени, сколько необходимо, чтобы найти всех лучших игроков? Если бы трое не были такими уж замечательными, зачем вам компания, в которой 30% ваших сотрудников не такие замечательные?» - Стив Джобс

В 2003 году писатель Майкл Льюис опубликовал книгу под названием Moneyball: The Art of Winning an Unfair Game. На первый взгляд, книга представляет собой классическую историю проигравшего: бейсбольная команда, испытывающая трудности, понимает, что скауты талантов, которые полагаются на многолетнюю мудрость, упускают возможности для создания команд-победителей. Развивая свою скаутскую тактику, чтобы включить в нее современные инструменты и методы, команда выявляет и нанимает список недооцененных игроков, добиваясь побед над противниками с гораздо большими платежными ведомостями.

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

Компании играют в Moneyball, используя распределенные команды

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

В прошлом году более 43% американских работников работали удаленно, что значительно больше, чем 9%, которые сказали то же самое в 1995 году.

В 2016 году компания TinyPulse, занимающаяся привлечением сотрудников, провела опрос более 500 удаленных сотрудников и обнаружила, что они были счастливее, чувствовали себя более ценными и были намного более продуктивными, чем их коллеги на местах. Более 43% американских работников в прошлом году работали удаленно, что значительно больше, чем 9%, которые сказали то же самое в 1995 году. В целом компании, которые разрешают удаленную работу, продемонстрировали более низкий уровень стресса, более высокую эффективность и меньшую текучесть кадров.

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

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

Общие проблемы с распределенными командами

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

• Качество: почти двадцать лет назад впервые знакомство с распределенными командами произошло в контексте традиционной модели аутсорсинга, полностью ориентированной на экономию средств. Сотрудничество казалось невозможным: инструменты, которые мы сегодня считаем само собой разумеющимися, такие как Slack или GitHub, не существовали, обмен электронной почтой занимал дни из-за проблем с часовым поясом, пропускная способность была дорогой — и по какой-то причине все были удивлены, когда программное обеспечение, созданное самым дешевым разработчики, которых мы могли найти, оказались паршивыми.
• Наглядность: менеджеры проектов ненавидят сюрпризы. Вот почему директор завода регулярно проверяет производственную линию, а прораб сидит за столом в трейлере на стройплощадке. Конечно, не так много случаев, когда вам нужна физическая близость для проверки прогресса в программном продукте или привлечении профессиональных услуг — кроме близости к хорошему Wi-Fi-соединению или мобильной вышке — но присутствие сохранило свою важность для менеджеров всех виды.
• Ортодоксия Agile: мы видим, что многие компании рассматривают или активно внедряют Agile-трансформацию. В рамках этой трансформации они, как правило, обращаются за советом для своих руководителей к Agile-книгам, коучам и консалтинговым фирмам. Когда дело доходит до создания команд, эти эксперты обычно говорят одно и то же: «Ваши команды должны находиться в одном месте». Это был здравый совет пятнадцать лет назад — Agile во многих отношениях был реакцией на описанные выше условия, которые делали сотрудничество на расстоянии практически невозможным и требовали жесткой практики каскадного управления проектами.

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

1. Аренда для удаленной совместимости

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

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

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

2. Чтобы управлять распределенными командами, создайте песочницу

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

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

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

3. Обучите менеджеров отслеживать результаты, а не результат

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

В частности, для удаленных команд крайне важно, чтобы показатели производительности измеряли качество результатов, а не просто производительность: сколько хорошего программного обеспечения мы поставили в прошлом месяце? Является ли скорость нашего развития стабильной, предсказуемой и ускоряется ли она со временем? Демонстрирует ли команда постоянное улучшение? Удаленные команды должны оцениваться по правильным метрикам, так как менеджеры имеют меньшую видимость процесса выполнения самой работы и не имеют возможности дать частичный кредит, наблюдая за тем, как их сотрудники «показывают работу».

4. Используйте правильные инструменты

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

• Чат в реальном времени. Чат в реальном времени — жизненно важный инструмент для удаленной команды. Вы хотите иметь возможность воспроизвести непосредственное взаимодействие и совместную работу, которые были бы у вас в совмещенной команде. Чат в реальном времени необходим не только для общения, но и для создания удаленной культуры. Для достижения успеха жизненно важно, чтобы все общение в команде было сосредоточено в одном месте — помните, что песочнице нужны стены. В Toptal мы используем Slack, но альтернативы включают HipChat, Flowdock и Skype.
• Информационные излучатели: без личных взаимодействий для обмена информацией вам понадобится онлайн-вики и стена историй, чтобы донести информацию до команды. В Agile или Kanban-разработке вся команда и все заинтересованные стороны должны иметь доступ к немедленной информации о статусе разработки — историях в процессе, ожидании тестирования, дефектах и ​​т. д. Команда также должна иметь доступ к информационным панелям для конвейера сборки и статус, покрытие кода и другие ключевые данные. Как удаленный менеджер, вам нужен единый источник достоверной информации для каждой области информации, на которую команда и заинтересованные стороны полагаются при определении статуса.
• Видеоконференции: видеочат в реальном времени является важным дополнением к обмену мгновенными сообщениями — по нашему опыту, нет ничего лучше, чем реальный разговор с другим человеком. В Toptal мы используем Zoom, звонки Slack и иногда Skype для личных встреч, статусных встреч и демонстраций кода. Ежедневные схватки с помощью видеоконференций — отличный способ укрепить командную культуру и доверие.

5. Церемонии объятий

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

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

Вывод: вы уже можете полагаться на распределенные команды

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

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

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

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