Не люблю перепечатывать другие посты. Но, ИМХО, это очень полезный пост. Отличается от большинства постов тем, что здесь нет вопросов и советов. Здесь просто автор делится личным опытом внедрения мотивации удаленных сотрудников. Самую большую ценность я вижу в том, что это работает где-то у нас (в постСоюзе) и это по силу любому начинающему или чуть с опытом менеджеру. Итак статья:
В 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);
Плохой пример
[ПМ] Необходимо до завтра пофиксить все баги.
[Исполнитель] Постараюсь.
[ПМ] Ок.
Хороший пример
[ПМ] Необходимо пофиксить 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 октября.
Проблемы/вопросы:
— аналитик не ответил на мое письмо вчера, это может задержать разработку
Плохой пример
Сделано за вчера:
— фиксил баги.
Текущие задачи:
— фиксить баги
В отчетах я контролирую две основные вещи:
- Формат отчета. В поле «сделано» должны стоять сделанные задачи, результаты их выполнения. Это пункт самоконтроля исполнителя и полезный источник информации для ПМа. Важно не допускать ерунды в этом пункте, возвращать репорты, говорящие что человек «читал», «писал» или «работал», требовать результат.
- Обратная связь. Необходимо читать и анализировать отчеты, отвечать на вопросы, решать проблемы. Если сотрудник двигает даты, нужно спросить в чем дело. Если показывает хорошую производительность — сообщите ему об этом и поставьте в копию всех. Таким образом, отчет не будет отпиской, а будет выполнять свою важную коммуникационную роль.
Итог
Попробуйте построить такой треугольник в своем проекте, поддерживайте его и оценивайте производительность участников команды. Это звучит парадоксально, но работая по такой схеме с удаленными сотрудниками, вы, с большой вероятностью, получите лучший результат, чем с сидящими рядом людьми.
Автор: Вадим Тиканов
Опубликовано на Хабре: http://habrahabr.ru/blogs/pm/71587/
Я хочу написать о том, как сотрудники живут в одном мире, а руководитель в другом.
В предыдущем