GSA

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

В 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/

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

Пока что я знаю только два вопроса, которые помогают:

- за что Вы отвечали на прошлой/позапрошлой/т.д. работе? Что от Вас зависело? – как правило, если от человека ничего не зависит, то ответственность не вырабатывается. Главное что бы эта зависимость была досягаема. Ответы вроде: «сроки сдачи, но с клиентом общался не я и я его вообще никогда не видел» – не принимаются. Можно считать хорошим ответом: «командой не могли сдать проект, а значит никто не получал премии, а оставалась только моя часть». Тут видно, что если проявить безответственность, то завтра скушают коллеги.

- сколько проектов Вы провалили и почему? – хороший вопрос. Практика показывает, что нельзя все делать успешно. «Не ошибается тот, кто ничего не делает». Если все было у человека хорошо, то лучше закончить собеседование. «За одного битого, двух небитых дают». ;).

Если у Вас есть свои, подобного рода, вопросы, то пишите, буду очень рад.