Как не стоит управлять удаленной командой разработчиков

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

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

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

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

Не верьте мифам и заблуждениям об удаленной команде

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

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

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

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

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

Не забывайте принимать и поощрять разнообразие

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

Но не волнуйтесь; разнообразие полезно для бизнеса!

Согласно опросу, проведенному The Economist Intelligence Unit , мультикультурные команды предпочитают крупные организации; многие руководители считают, что они способствуют инновациям благодаря более широкому знанию мировых тенденций. Кроме того, они менее склонны страдать от менталитета «группового мышления»; их разнообразие помогает им решать проблемы с разных точек зрения, создавая тем самым лучший набор решений, адаптированных для конкретных регионов и рынков.

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

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

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

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

Не относитесь легкомысленно к найму и обучению

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

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

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

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

Эмоциональная дистанция между удаленными менеджерами и их подчиненными также может представлять проблему, поскольку члены команды могут неохотно вступать в конфронтацию с новыми руководителями или даже обращаться к ним в формальной или неформальной обстановке. Хороший менеджер удаленных сотрудников должен осознавать это и настаивать на более личном взаимодействии — как я уже сказал: «Будьте активны». – какой смысл иметь команду талантливых удаленных разработчиков, если они не делятся с вами своими мыслями?

Не используйте сложную информационную систему

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

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

Моим давним любимым приложением для управления проектами является Redmine, кросс-платформенная система с открытым исходным кодом и кросс-базой данных. Эта платформа легко настраивается, и вы можете интегрировать свой собственный SCM, различные плагины и сервисные крючки.

Если вы не хотите утруждать себя поддержкой собственного сервера с Ruby и настраивать все самостоятельно (Redmine может быть сложным для неопытных системных администраторов), другим хорошим выбором является GitHub, в котором есть не только git CMS, но и GitHub Issues. , который хорошо интегрируется с вашими сообщениями о коммитах, запросами на включение и т. д.

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

Не занимайтесь микроменеджментом

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

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

Как и все остальное в жизни, все дело в поиске хорошего баланса.

Не беспокойтесь о часовых поясах, используйте их в своих интересах

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

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

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

Не форсируйте ежедневные цели, сосредоточьтесь на среднесрочных или долгосрочных целях

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

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

На мой взгляд, Agile-манифест (методологии) — это лучшее, что произошло в управлении проектами за последние несколько лет.

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

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

Не скрывайте информацию о бизнесе

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

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

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

Не игнорируйте удаленных членов команды

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

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

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

Опять же, это улучшит коммуникативные навыки и повысит доверие.

Советы по быстрому удаленному управлению командой

Поскольку я уже обобщил основные моменты в твитах и ​​иллюстрациях, вот еще несколько быстрых советов и мыслей.

• Эти общие правила могут применяться к удаленным и локальным разработчикам.
• Если вы будете заниматься микроменеджментом, вы упустите возможность учиться и позволять учиться.
• Будьте открытыми и заслуживающими доверия, так как это единственный способ создать хорошую удаленную команду.
• Имейте в виду, что оценка — это всего лишь оценка; вы столкнетесь с завышенными и заниженными оценками.
• Все, кто работает, ошибаются, и если ты не прощаешь чужие ошибки, то и свои не простят.
• Самое главное, что самая большая мотивация для любого разработчика (помимо удовлетворения от выполнения сложной задачи) — это деньги. Поэтому не откладывайте платежи и рассмотрите возможность введения бонусной политики.