Опыт организации работы удаленной команды

В этой статье я поделюсь своим опытом управления удаленными сотрудниками в работе веб-студии.
В течении последних 4 лет в удаленной команде специалисты из Питера, Москвы, Барнаула, Ростова-на-Дону, Екатеринбурга, Тольятти, Кисловодска, Украины, Белоруссии, Казахстана, команда проекта бывает от 13 до 40 человек. 

Из того что мы делали:

• разработка большого проекта для американцев — 8 человек в команде, 6 месяцев работы, все в разных часовых поясах, проект сдан успешно.
• Разработка 63 шаблонов для проекта umi.ru (дизайн+верстка, по сути 63 сайта за 3 месяца) в команде было 12 человек, все удаленно.
• Организация реальной конференции на 160 человек, организацией занимались удаленно 2 человека, я сама отдыхала за границей.
• ну еще много всякого, типа организация образовательной программы для форума на 1200 участников, 16 тренеров.

При организации работы удаленной команды возникают вопросы:
1. Где брать команду?
2. Как сделать так, чтобы они сделали то что вам надо, а не то что получилось/смогли.
3. Как контролировать качество/сроки/нужное подставить.

1. Где брать удаленную команду?

Логично  брать в команду людей, которые уже имеют опыт удаленной работы.

1.1. Все просто, если вам нужен программист/дизайнер/копирайтер/сеошник.
Идем на free-lance.ru, публикуем проект, получаем список желающих выполнить работу.
1.2. Рекомендации знакомых.
1.3. Тематические группы в социальных сетях от фейсбука до моего круга. Там можно находить стилистов, фотографов, юристов, опять же дизайнеров/рекламистов/программистов.
1.4. Форумы с разделом «Работа». Много интересных кадров можно найти на местных форумах, особенно если в этом городе сильные образовательные учреждения. Например, сильных программистов готовят в Екатеринбруге, Новосибирске, Таганроге.
1.5. Можно найти менеджера проекта уже со своей командой, такое тоже бывает.

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

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

Правило первое: «Берите в команду людей с опытом удаленной работы».
Правило второе: «Устанавливайте поощрения и наказания».

2. Как сделать так, чтобы они сделали то что вам надо, а не то что получилось/смогли.

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

А может этого?

В чем проблема, когда вы смотрите на на эти завтраки? В обоих случаях яйца и бекон. И это завтрак. Но вы предполагали что «это будет как-то по другому».

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

В случае с удаленной командой, вы не можете контролировать процесс, как именно они будут делать работу. Вы можете описывать конечный результат. И он должен быть по SMARTу — конкретный, измеримый, достижимый и определен во времени.

Итак, правило третье: «Менеджер проекта ставит команде проекта четкие цели конечного результата».

Сравните: 1. Надо сделать простенький сайт. НЕЕЕЕТ!
2. Надо сделать сайт-визитку на worpress, шаблон по ссылке, 15 страниц (см. карту сайта), без информационного наполнения, срок сдачи — пятница 15 марта 2013 года к 16 часам. Домен такой-то, хостинг такой-то. — ДААА!

Еще сравните. Решается проблема некорректной работы формы обратной связи.
1. Нужно заменить адрес приема электронной почты из формы обратной связи с ффф@aaaa.aa  на пппп@пппп.сс
2. С формы обратной связи перестали приходить письма. Разобрать с проблемой, письма должны приходить на пппп@пппп.сс. Срок до 9-00 утра завтрашнего дня, 11 февраля 2013 года.

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

Из правила постановки  задачи вытекает правило четвертое: «Менеджер формирует систему контроля результатов и правила коммуникации между членами команды».

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

Менеджер проекта определяет: Что контролируем (количественные показатели) и как контролируем (способ, система). Вернемся к завтраку.
Что будем контролировать: наличие продуктов, посуды, повара, время.
Как будет контролировать: визуально лично, визуально по фото (приготовите завтрак, пришлите мне mms-ку на номер телефона такой-то в течении 3 минут, не позднее 14-52 11 марта 2014 года).
Пример количественного контроля:

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

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

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

Обязательны общие правила:
— именования файлов и хранения информации.
— использование сервисов и софта для коммуникаций (skype, ICQ, соц.сети, Google.Docs, CRM, багтрекеры)
— начисление и выплаты денег (это почасовая оплата или фикс за проект, выплаты раз в месяц, или после приема работ, на электронные деньги или на карту, и тд.)
— процедура приемки работы (сколько времени идет проверка, что будет считаться ошибкой и уйдет на доработку, а что нет, кому сдавать работу и т.д.)
— условные обозначения
— как хранятся контакты команды проекта.

и так далее.

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

Пример организации работы над 63 сайтами для проекта UMI.RU. Чтобы сделать 1 сайт нужно было сделать/утвердить дизайн, выложить файлы, потом сделать/утвердить верстку, выложить файлы. Так как каждый сайт делался в 3 цветах, общее количество файлов было около 1000. Про этот проект я расскажу отдельно.

Еще один пример организации удаленной работы около 25 человек. Проект мониторинга цен на продукцию известного бренда. Требовалось обойти и отфтографировать (на 1 точку от 1 до 8 фото) — более 500 точек по всему городу. Затем полученные фото результат аудита необходимо было передать Заказчику в определенном виде.

Как была организована работа — заведен аккаунт в Яндекс.Диск, и каждый из 25 исполнителей подключен в аккаунт. Разработаны условные обозначения, каждая точка имела номер и несколько идентификаторов (пройдено, не найдено, вбито).
Исполнители были обязаны каждый день, после прохождения точки, заливать фотографии в Яндекс.Диск. Динамику выполнения проекта видел и Заказчик и менеджер проекта.
На этом же проекте мы допустили стратегическую ошибку. Зная, что фото придется передавать через интернет, заранее не ввели правило установить настройки фотоаппарата на минимальное разрешение фотографий в 800х600. В результате, получили почти 7Гб фотографий, который перекачивались Заказчику 2 дня.
Лучше потратить еще 2 часа на продумывание правил проекта, чем исправлять его по ходу.

Если система организована хорошо, менеджер проекта может тратить на контроль проекта  2-3 часа в неделю.

Еще про контроль. Правило шестое: Рассчитывайте и контролируйте производительность команды проекта.

Вроде элементарная вещь, но ее мало кто делает. Если вам надо сделать 63 сайта за 3 месяца то 63сайта/3 мес = 21 сайт/мес. Или 1 сайт/1 рабочий день. Если прошла неделя, и за 5 рабочих дней сделан 1 сайт, то отставание в 4 раза. Самое время менеджеру по другому организовывать работу. Не обязательно ждать 3 месяца, чтобы выяснить, что вы не укладываетесь в сроки.
Если мы знаем, что 1 звонок делается за 2,5 минуты, а сотрудник делает 1 звонок за 10 минут, самое время или поменять сотрудника, или разобраться что он там эти 10 минут делает.

Что делать если людей на проекте много? Если людей больше 10 человек, полноценно уделить внимание/обучить каждого не удастся. Если менеджер проекта будет делать все сам, то риски, что он просто не выдержит к концу проекта велики. А нам этого не надо, поэтому

Правило седьмое. Формируй малые группы, делегируй бригадирам. 

Если в проекте есть однородная работа, например загрузка большого объема описаний товаров в интернет магазин, обучаете одного человека. Попутно он может сделать и пошаговую инструкцию как это делать правильно. Когда приходят новые исполнители, уже бригадир обучает новичков и первично контролирует их работу. Хорошо работает схема 1+4.  На одного бригадира — 4 исполнителя. Бригадиру платится чуть больше, все довольны.

Что делать если на проекте что-то идет не так? Люди могут по разным причинам выходить из проекта. Менеджер проекта должен иметь план Б:
— запасные исполнители на каждую позицию на проекте.
— получать промежуточные результаты работы простым способом. Один из них — работа в облаке. Если весь проект в облаке, даже если один член команды пропал, его файлы достанутся следующему исполнителю.
— стройте работу с проектом таким образом, чтобы передача функционала другому исполнителю занимала минимальное количество времени.
— предусматривайте финансовую ответственность за уход с проекта.
— имейте заместителя с самого начала проекта. Иначе не видать вам отпуска, и простенькое ОРВИ менеджера проекта может полностью его завалить.
— заведите правило документировать ход проекта или самый часто используемый функционал. Например, у нас исполнители пишут инструкции по работе с софтом и эти инструкции кочуют из проекта в проект.

Если есть вопросы, милости прошу в комментарии, так же делитесь своими способами управления командой.