7 ошибок управления удаленной командой

Бизнес-сфера одной из первой начала использовать ИТ-решения в своей экосистеме: мейнфреймы для сложных вычислений, вебсайта для продвижения и, наконец, ИТ-продукты, на которых строится бизнес. Иногда содержание "домашней" команды для работы над подобным продуктом возможно, но в большинстве случаев у заказчика недостаточно ресурсов или навыков для управления своей командой ИТ-профессионалов. Подобная ситуация встречается часто, и ее решение тривиально - аутсорсинг. Зачем же тратить ресурсы и время на построение команды, которая скорее всего будет распущена через год разработки – как только продукт будет готов? Намного удобнее заключить соглашение с компанией-аутсорсером, в которой уже есть профессионалы с так необходимыми клиенту навыками. Есть несколько основных направлений для аутсорсинга разработки продукта: Индия, Китай, Центральная или Восточная Европа. Все они хороши, но у каждого есть одна и та же проблема – они географически удалены от заказчика. В случае "домашней" команды у клиента есть полный контроль и бизнеса, и разработки продукта. В случае удаленной команды заказчик и дальше контролирует бизнес, но разработка продукта находится вне зоны его прямого контроля. Опять-таки, это типичная ситуация, но найти решение уже не так просто. Заказчик должен понять, что "там" уже есть человек, который управляет удаленной командой – вы. Вы знаете вашу команду, знаете сильные и слабые стороны каждого сотрудника, но главное ваше преимущество – вы находитесь рядом с командой. У вас куда как больше возможностей для управления разработкой продукта и именно на ваши плечи ложится обязанность управлять командой во всех, даже самых неблагоприятных, ситуациях. Итак, с одной стороны есть заказчик со своим бизнесом, а с другой стороны есть вы и ваша команда. Успех разработки продукта зависит от уровня общения между заказчиком и удаленной командой. Подобный тип общения существует в ИТ-сфере уже достаточно давно, и есть одна хорошая практика, которую вы можете использовать.

Разделение обязанностей

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

Семь ошибок

1. На стороне бизнеса нет человека, принимающего решения

Принятие решений – нелегкое занятие, а наличие временных рамок ни разу его не облегчают. Когда вам и команде требуется ответ на бизнес-вопрос, время на стороне заказчика не должно тратиться на поиск ответственного. Более того, может быть и худший вариант, когда на стороне заказчика есть несколько людей, принимающих решение, и они не могут договориться. Такое положение дел может привести к ситуации, когда со стороны бизнеса приходит решение, полностью противоположное уже принятому и реализованному в продукте: заказчик теряет деньги, а вы время, нервы и командный дух. Если же на стороне заказчика все же есть несколько принимающих решение людей, убедите заказчика в необходимости принятия ими консолидированного мнения, единого направления, в котором будет двигаться ваша команда. Иначе вы будете автоматически медлить с разработкой просто на всякий случай. Правило: Объясните заказчику необходимость одного и только одного бизнес ответа на каждый вопрос, заданный вашей командой.

2. Запросы удаленной команды обрабатываются очень медленно

Вам и вашей команде часто нужны ответы на бизнес-вопросы, и в большинстве случаев эти ответы нужны вам сейчас. Если заказчик отвечает на ваши запросы медленно, ваша команда может простаивать по 2-3 дня, буквально прожигая время и деньги. Объясните заказчику необходимость получения ответов на ваши вопросы в течение рабочего дня и ни часом позже. Если вопрос непростой, попросите уведомлять вас об этом, чтобы вы могли адекватно планировать ваши действия. Правило: Убедите заказчика отвечать на ваши запросы в течение рабочего дня и ни часом позже.

3. У удаленной команды нет четко поставленных целей

Заказчик управляет бизнес-частью вашего проекта и определение целей для удаленной команды и вас – его задача. Если у команды и вас нет поставленных целей – вы не приносите пользу заказчику. Если же вам поставлены нечеткие цели, может случиться то, о чем Питер Друкер писал: "Нет ничего более бесполезного, как эффективно делать то, что не надо делать вообще". Объясните заказчику обязательность постановки четких целей. Одним из наиболее эффективных способов постановки целей удаленной команде является функциональная спецификация. В идеале она должна разрабатываться вами совместно с заказчиком. Убедитесь, что в итоговой версии нет неясных моментов и что она соответствует поставленным бизнес-целям. Обязательно обсудите временные рамки и бюджет на разработку этой спецификации: часто слишком дорогие или слишком запоздалые фичи хуже, чем отказ от разработки новых фич вообще. Правило: Убедитесь, что вам поставлены четкие цели.

4. Заказчик не заботится о членах удаленной команды

Одним из выражений, почти всегда воспринимаемых ИТ-сферой в штыки, является фраза "Люди – это ресурсы". Люди не хотят быть ресурсами, у каждого из них есть своя жизнь, свой характер, свои надежды и желания. Ваша команда – это люди, а не ресурсы. Убедитесь, что у заказчика не сложилось иного мнения и что он относится к вам всем с должной долей уважения. Постарайтесь представить ему каждого члена команды, пускай и заочно. Попытайтесь вовлечь клиента в мотивирование членов команды: пускай он делится своим видением проекта и периодически хвалит команду – ваши сотрудники будут работать куда как более креативно и продуктивно, если они воодушевлены проектом. Даже самое маленькое письмо с похвалой от заказчика значительно повышает настроение в команде. Правило: Объясните заказчику, что люди - это не ресурсы.

5. Совместная разработка осуществляется неправильными инструментами

Иногда сложно вспомнить детали позавчерашнего тет-а-тет разговора – как кто-нибудь в здравом уме может рассчитывать вспомнить детали разговора по скайпу месячной давности? Разговоры по скайпу, чаты, почта – буквально все, в чем может содержаться информация, относящаяся к проекту, должно содержаться в одном месте. Это облегчит жизнь и вам, и заказчику, когда вы будете выяснять особенности решения, принятого два месяца назад неизвестно кем и неизвестно почему. Использование интернета облегчает совместную разработку людьми, разделенными географически. Использование адекватных инструментов для управления проектами значительно облегчит вам работу: предоставление общего доступа к документам, совместная проработка UX, управление временными затратами. Microsoft Project – пример системы управления проектами, которая не подходит для совместной разработки ПО. Большинство простых действий в ней занимают слишком много времени, а люди склонны к "забыванию" вещей, которые попусту тратят их время. Как результат, какие-то важные беседы и решения могут избежать сохранения и потеряться в самый нужный момент. Backpack от 37 Signals и Confluence от Atlassian – примеры инструментов, которые хорошо подходят для совместного ведения проекта. В отличие от MS Project, они концентрируются на простоте использования и фокусируются на хранении всех ваших бесед, документов и схем – именно то, что необходимо для совместной работы с заказчиком. Правило: Используйте системы управления проектами, подходящие для совместной разработки проекта.

6. Заказчик требует беспрекословного подчинения от вас и вашей команды

Говард Бехар, один из директоров Starbucks, всегда использовал в своей работе набор мудрых высказываний, которые накапливались за его длинную практику. Одним из моих любимых выражений является "Позвольте уборщику самому выбирать метлу". Говард считает, что единственный способ получить максимальную отдачу от сотрудника, это показать ему направление и дать ему достаточно свободы для выполнения задачи. Этот принцип легко применить и к разработке ПО: вам и вашей команде просто надо иметь цель и достаточно свободы для ее достижения. Люди не могут работать лучшим образом, когда у них не хватает свободы. В рамках создания ИТ-продуктов, свобода означает гибкие требования и плавающие дедлайны. Не бойтесь говорить с заказчиком об этих свободах, предлагайте свои варианты, обсуждайте дедлайны. Правило: Не бойтесь обсуждать необходимые команде свободы с заказчиком.

7. Заказчик проверяет каждую минуту в тайм репортах вашей команды

Тайм репорты обычно используются при оплате работы удаленной команды заказчиком: они показывают, сколько времени потратил каждый член команды на работу над проектом и чем он занимался. Эти отчеты хороши для того, для чего они создавались, но, как и любой инструмент, они могут быть использованы не по назначению. Иногда информация из тайм репортов используется заказчиком для придирок к качеству работы удаленной команды и как повод к отказу от оплаты. Как уже писалось ранее, "Позвольте уборщику самому выбирать метлу". Заказчик уже выбрал вас и доверился достаточно для начала разработки своего продукта на вашей стороне. Объясните ему бессмысленность подобного недоверия. Да, клиенту нужен контроль, но тайм репорты – совсем не подходящий для этого инструмент. Какие же показатели хороши для контролирования качества работы удаленной команды? Качество кода, выполнение временных обязательств, качество документации (где она нужна и есть), действия команды в критических ситуациях – и любой другой показатель, релевантный и полезный для вашего конкретного проекта. Сами предложите заказчику оценивать качество работы по этим критериям. Если он будет ими доволен – с чего бы вдруг ему вообще исследовать запятые в ваших тайм репортах? Правило: Договоритесь с заказчиком о действительно важных критериях, по которым он сможет оценивать качество вашей работы.

Вывод

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

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.