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

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

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

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

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



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

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

Как это ни странно, но задачи необходимо ставить. Хорошо использовать любой удобный вам трекер (MS Project, Trac и пр). Плохо использовать почту или IM. Категорически нельзя ставить задачи устно (что не записано — того нет). Для того, чтобы исполнитель ощутил ответственность за задачу и результат, необходимо выполнить 3 шага:
Поставить задачу в виде SMAR[T] (Specific, Measurable, Achievable, Realistic, [На данном этапе без Time-bound]);
Получить WBS и оценку задачи от исполнителя;
Поставить задачу в виде SMART (Specific, Measurable, Achievable, Realistic, Time-bound);

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


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


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

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

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

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

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


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


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

Итог

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

(С) ХабраХабр.ру


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


Для такой отчетности удобно использовать 3 вопроса из скрам-митинга в немного вольной интерпретации (отправляется по эл. почте):
1. Что ты сделал за сегодня?
2. Что тебе мешало?
3. Что ты сделаешь завтра?

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

По инерции, отчет следующего дня содержит в пункте 1 задачи пункта 3 предыдущего дня, если что то не сложилось — то объяснение этого в пункте 2.