Мотивация удаленных сотрудников

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

В IT индустрии все чаще встречаются проекты с распределенными командами. Это удобно — спецификация, код, баги, мануалы легко перемещаются из одного конца планеты в другой за доли секунд. Это выгодно — аутсорсинг проектных процессов, будь то разработка, тестирование или саппорт, в Индии или Китае обойдется в 3–5 раз дешевле аналогичных сервисов в странах Европы или США.

Никого не удивишь проектом, в котором сейлз, маркетинг и бизнес анализ находятся в Англии, разработка в России, тестирование и саппорт — в Индии. Компания, в которой я работал, специализировалась именно на таких проектах. Наиболее слабыми местами в них, я бы назвал коммуникации внутри проекта и мотивацию его участников. Эта статья описывает эффективный подход к решению этих проблем в проектах с распределенной командой.

Треугольник мотивации

В своей статье, PMP James R. Chapman, описывает три фактора, необходимых для мотивации сотрудника. Это ответственность за задачу, инструменты и знания, регулярная отчетность. Визуально их можно представить как треугольник мотивации:
Треугольник мотивации
Джеймс утверждает, что, в 9 случаях из 10, этот треугольник даст в результате мотивированного сотрудника и, как следствие, задачу, выполненную в срок. Рассмотрим особенности перенесения этой модели на управление сотрудниками, находящимися в сотнях километров от вас.

Ответственность за задачу

Как это ни странно, но задачи необходимо ставить. Хорошо использовать любой удобный вам трекер (MS Project, Trac и пр). Плохо использовать почту или IM. Категорически нельзя ставить задачи устно (что не записано — того нет). Для того, чтобы исполнитель ощутил ответственность за задачу и результат, необходимо выполнить 3 шага:

  1. Поставить задачу в виде SMAR[T] (Specific, Measurable, Achievable, Realistic, [На данном этапе без Time-bound]);
  2. Получить WBS и оценку задачи от исполнителя;
  3. Поставить задачу в виде SMART (Specific, Measurable, Achievable, Realistic, Time-bound);

Плохой пример

[ПМ] Необходимо до завтра пофиксить все баги.
[Исполнитель] Постараюсь.
[ПМ] Ок.

Хороший пример

[ПМ] Необходимо пофиксить 4 бага (#111, 222, 333, 444), дай оценку плз.
[Исполнитель] #111, 222, 333 — по 2 часа на каждый. По #444 — нужен ресерч, я бы заложил на него часа 4, плюс 2 часа на фикс.
[ПМ] Ок, добавил тебе задачу «пофиксить 4 бага (#111, 222, 333, 444)» в MS Project. Приступай, завтра к 18–00 жду результат.
[Исполнитель] Ок.

Инструменты и знания

Для того, чтобы выполнить этот пункт, убедитесь что исполнитель:

  • обладает достаточными знаниями и умениями для выполнения задачи. Если исполнитель ни разу не сталкивался с задачами такого рода, либо это новый участник проекта — налицо риск, что задача выполнена не будет, спланируйте его;
  • обладает необходимым software, hardware и прочими, нужными для выполнения задачи, инструментами;
  • имеет доступ к репозиторию с документацией проекта;
  • имеет доступ к репозиторию с кодом проекта;
  • имеет доступ к трекеру задач и багов;
  • ознакомлен с правилами и процессами, организованными в проекте. Каждый участник должен четко понимать как мы делаем проект — как и когда пишем спецификации, как пишем и ревьювим код, как и когда тестируем итд. Для этого хорошо иметь отдельный документ (Project Management Plan) либо Wiki проекта;
  • имеет возможность быстро связаться со всеми участниками проекта. Хорошо подходит Skype чат и Email группа. Также, полезно расшарить список телефонов всех участников команды;
  • знает роли и обязанности каждого участника. Обязательно знает и имеет возможность связаться с аналитиком (автором спецификаций) и тестером (автором описаний багов);
  • имеет канал коммуникации для оповещения о срочных проблемах. Email и телефон ПМа или тим лида, например;

Регулярная отчетность

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

Хороший пример

Сделано за вчера:
— закончил DiagramView компонент, залил в свн
— пофиксил 2 бага (#111, 222)

Текущие задачи:
— разработать DiagramEdit компонент. Планирую закончить 2 октября.

Проблемы/вопросы:
— аналитик не ответил на мое письмо вчера, это может задержать разработку

Плохой пример

Сделано за вчера:
— фиксил баги.

Текущие задачи:
— фиксить баги

В отчетах я контролирую две основные вещи:

  1. Формат отчета. В поле «сделано» должны стоять сделанные задачи, результаты их выполнения. Это пункт самоконтроля исполнителя и полезный источник информации для ПМа. Важно не допускать ерунды в этом пункте, возвращать репорты, говорящие что человек «читал», «писал» или «работал», требовать результат.
  2. Обратная связь. Необходимо читать и анализировать отчеты, отвечать на вопросы, решать проблемы. Если сотрудник двигает даты, нужно спросить в чем дело. Если показывает хорошую производительность — сообщите ему об этом и поставьте в копию всех. Таким образом, отчет не будет отпиской, а будет выполнять свою важную коммуникационную роль.

Итог

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

Автор: Вадим Тиканов

Опубликовано на Хабре: http://habrahabr.ru/blogs/pm/71587/

Реальные кейсы роста продаж
и повышения конверсии!

Узнайте как другие увеличивают продажи на 10%, 30%, 50% или даже в 2 раза!

100% без спама!