GSA

Нашел великолепный набор статей/заметок: http://local.joelonsoftware.com/wiki/Russian

Там можно прочитать о многом. Я пока остановился на «Искусство проведения интервью». Все же вопрос подбора персонала меня очень сильно волнует, т.к. я уверен, что «кадры решают все». (Но от «незаменимых людей нет» я тоже не отказываюсь!).

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

Главные принципы проведения собеседования (интервью):

• определить «Толковый и доводит дело до конца.».
• Вы не уверены на 100%, что «надо брать», то ответ должен быть «не брать»! Аргументация: «лучше отказаться от хорошего кандидата, чем нанять плохого. Плохой работник будет стоить кучу денег, усилий и времени, которое другие люди потратят, исправляя его ошибки»(с).
• перед собеседованием ни с кем не общаться по поводу кандидата и следить что бы Вам никто его не рекомендовал, так же как и не советовал отказаться. Даже подсознательная предвзятость очень сильно влияет на Ваше решение.
• даже если Вы в ходе собеседования поняли, что «не брать!», то Вы все равно должны прорекламировать Вашу компанию.

Вопросы, которые надо задать:

• необходимо задать вопрос о последнем (или самом понравившемся/лучшем) проекте, в котором соискатель принимал участие. Если это студент, то спросите о теме диплома, или чем он занимался (по направлению работы). Тут самое главное обратить свое внимание на то, как человек загорается рассказывая об этом. Если человеку нравится тем, чем он занимается, то это хорошо и надо брать.
• задать любой вопрос, на который человек 100% не знает ответа – «вопрос на засыпку». Как пример: «сколько заправок в г. Энске?». Положительно если человек попытается решить проблему, пусть он будет ее неправильно решать, но он будет ее решать! Делать что-то правильно – можно научить.
• попросить человека набросать дизайн/архитектуру приложения/план работ. Тут главное обратить внимание на встречные вопросы. Главным встречным вопросом должен быть: «Зачем это? / Для кого это? / Что с этим будут делать?». Т.е. если человек хочет понять главную цель, то это хорошо. Если же он просто хочет это сделать, как попросили, то очень вероятно, что вся работа будет делаться, что бы просто сделать и получить з/п.
• задать вопрос-провокацию. Надо словить соискателя на том, в чем он 100% прав и сказать, что Вы с ним не согласны. Тут проверяется умение отстаивать свою точку зрения: «слабость/сила кандидата». Сильные будут спорить и найдут способ доказать Вам свою правоту.

Нашел еще в одном блоге был почти опросник для собеседования. Собираюсь сделать себе такой же. Думаю скоро таки сделаю и выложу.

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

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