Клуб Успешных Менеджеров Программистов

Отпуск до 12-го июля

Коллеги, сдерживая в себе эмоции, хочу сообщить вам, что сегодня проект Happy PM уходит в отпуск до 12-го июля. Что это будет означать:

• Посты на сайте будут выходить. И будет их много. Запланирован рассказ в нескольких главах про систему оценки сотрудников. И еще много чего интересного.
• Телефон +7 921 931 7807 отвечать будет.
• Рассылка выходить не будет до 12-го июля.
• Заявки в магазине будут отложены до 12-го июля.
• E-mail info@happy-pm.com отвечать не будет до 12-го июля.
• IT-радио до 12-го июля будет вести Слава Панкратов в одиночку. Следите за страничкой радио.

Ценности компании как инструмент менеджера

Какие ценности определяют для себя ведущие компании вообще, и компания Intel в частности? В Intel этих ценностей шесть. Изначально их было пять, но потом руководители подумали-подумали и решили добавить шестое.

Эти ценности написаны везде и всюду - на корпоративных календариках, которые все надевают себе на бейдж. На корпоративных порталах и постерах - короче, везде. Из-за чего у многих сотрудников на саму фразу «ценности компании» вырабатывается жесткая аллергия. Но по сути, то, что там написано, все равно сидит у всех в голове. А для менеджера - это прекрасный инструмент при оценке сотрудников. Итак, какие ценности есть в Intel:

Discipline - дисциплина. Причем, это означает не приход на работу вовремя, а то, что человек не нарушает правил и договоренностей, под которыми он подписался. Решили делать вот так - делаем вот так.

В понедельник сказал, что сделает к пятнице; в пятницу начал делать и обнаружил, что там работы на две недели - незачет. Сказал «к пятнице», сделал к пятнице - зачет.

Quality - ориентация на качество. Насколько человек думает о качестве того, что он делает. Насколько он повышает качество своей работы.

Если он сидит и фигачит код без юнит тестов, а потом в его коде находится больше всего ошибок - это одно. Если человек после первой итерации задумывается: «хм, а почему в моем коде так много ошибок? Может быть, пописать юнит тестов? Может быть, устроить формальные инспекции?», а потом он пишет юнит тесты и устраивает инспекции - это другое.

Risk Taking - инновации и нестандартность мышления. Сколько новых здравых идей сотрудник предлагает. Как он себя ведет в критических ситуациях? Получается у него придумать красивое, рискованное решение, которое позволит спасти проект? Или он сидит и просто делает то, что ему говорят?

Results Orientation - насколько человек ориентирован на результат. Если человек по каждому вопросу, который он мог бы решить сам, бегает к менеджеру или тех лиду, у него проблемы с нацеленностью на результат.

Если человека уносит в сторону, и он закапывается куда-то в соседнюю область, потому что там интересней, вместо того, чтобы закончить свою задачу - проблемы с нацеленностью на результат.

Умение самостоятельно, быстро и качественно решать вопросы не означает, что человек никого не спрашивает, а пытается все стены пробить свои лбом. Главное здесь - фокус человека на результат.

Customer Orientation - насколько человек думает о потребителях его работы. Не о заказчике, а о потребителях его работы. Это могут быть и заказчик, и коллеги, и менеджер. Что происходит, когда к человеку приходит кто-то и просит помочь? Если тон говорит: «Отвянь, у меня тут своих дел до фига,» - это одно. Если он говорит: «Старик, сейчас не могу, подойду через часок?», подходит и помогает - это другое.

Если человек думает о том, что бы еще такого полезного сделать для своих коллег, заказчика. Какой бы скрипт написать, чтоб всем было удобней? Может быть, предложить заказчику сделать демо на конференцию? Это Customer Orientation.

Great Place to Work (GPTW) - делать эту компанию тем местом, где люди хотят работать. Этой ценности вообще изначально не было. Потому что один из основателей Intel Энди Гроув по свидетельствам очевидцев был нраву крутого и совсем не веселого. Но потом, видимо, расслабился и решил таки сделать Intel компанией, где люди хотят работать.

(Кстати, если кто-то еще не читал книгу Энди Гроува «Выживают только параноики» - купите и прочтите! Нрава-то дяденька был крутого, но книжка толковая.)

Как ценность GPTW проявляется в поведении сотрудников? Кто-то распечатал прикольных постеров, повесил на стенку. Кто-то прибил табличку «Коридор имени нашей супер-команды». Кто-то предложил рвать пасть льву с логотипом конкурентов на боку.

Discipline

Quality

Risk Taking

Results Orientation

Customer Orientation

Great Place to Work

Взгляд сквозь ценности. Глядя сквозь призму таких вот ценностей обычно хорошо видно, в чем сотрудник силен, в чем не очень. И что ему нужно улучшать. В Intel при написании 360 фидбэков, self-assessment’ов и performance review принято помимо фактов и влияния подчеркивать, какая ценность была сотрудником продемонстрирована (или наоборот, наличие какой ценности не помешало бы ).

На мой взгляд, совершенно не обязательно распечатывать постеры с вот этими ценностями и развешивать их в своей компании на каждом углу. Просто попробуйте воспользоваться призмой ценностей. Через эту призму довольно хорошо выстраиваются ожидания от сотрудников. То есть, прежде чем озвучивать Васе, что он теперь тест менеджер - посмотрите, что это будет означать с точки зрения ценностей. Глядишь, нужные слова сразу запросятся на язык.

Именные мышки и программисты на тренингах по тестированию

Очередная порция идей от участников конкурса “Как позаботиться о сотрудниках”:

Автор: Karina Lvova

1) Попросить вышестоящее начальство написать благодарность особо отличившемуся сотруднику, ну или написать самим, а начальство попросить отправить.

2) Позаботиться о том, чтоб у всех сотрудников были визитки.

3) Попросить штатных дизайнеров нарисовать поздравительную открытку или открытку с благодарностью для сотрудника.

4) Подарить именной сувенир (ручку, чашку, мышку :)).

5) Делиться с сотрудниками информацией о делах в компании(особо актуально в период кризиса)позитивного характера - пришел новый проект, взяли кого-то на работу.

6) Постоянно побуждать сотрудников принимать участие в развитии процесса в компании(напр, находить новые тулзы), делиться идеями и внедрять стоящие.

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

По поводу именных мышек. Вот в Sun Store, помнится, продавались отличные семейные трусы с логотипом Sun. С тех пор ни разу не видел семейных трусов с логотипами компанией. Почему не делают?… Бомба же.

Цитата недели (Уилл Роджерс)

Даже если вы находитесь на правильном пути, то никуда не доберетесь, если будете просто сидеть на одном месте.

Кого повышать, кого журить

Хорошо, вот допустим, вы, как менеджер, со всеми поговорили, всех опросили, собрали 360 фидбэки. И даже написали перформанс ревью, которые, на ваш взгляд, отражают основные важные моменты работы каждого сотрудника. Что дальше?

В Intel дальше каждый менеджер должен был проставить людям оценки. Для простоты скажем, что оценок этих было три:

• Successful - то есть человек отработал хорошо, вполне в духе ожиданий от него.
• Exceeds Expectation - человек жег как мог и превысил ожидания от его позиции и зарплаты.
• Below Expectations - человек недоработал. Отработал хуже ожиданий от его позиции и зарплаты.

Что нужно, чтобы сказать - хуже, лучше или в соответствии с ожиданиями от работал человек. Бинго! Нужно, чтобы эти ожидания были сформулированы!

Кто формулирует ожидания? Частично компания, частично сам менеджер. В компании это выглядит обычно как таблица компетенций, например вот такая. Сам же менеджер проясняет и доносит до своих сотрудников дополнительные детали.

Ну, например: «Вася, ты теперь будешь тест менеджером. Я не ожидаю, что ты прямо завтра закроешь все проблемы с тестированием. Но я ожидаю, что через два месяца ты уже будешь самостоятельно писать тест план, общаться с аналитиком, отслеживать работы по тестированию, и отслеживать статус проекта по качеству. Чтобы в любой момент времени ты мог сказать мне, можем мы выпускать продукт или нет.»

Дальше проходит два месяца. Менеджер оценивает - как там тест менеджер Вася. И вдруг видит - ух ты, Вася не только закрыл собой все тестирование, но еще и помог аналитику с выбором и настройкой системы хранения требований. А еще подготовил фрэймворк для юнит тестов и помог разработчикам внедрить практику test driven development. Что это означает? Вася превысил ожидания.

А может быть наоборот. Менеджер приходит: «Вася, как там статус проекта?» - «Иван Петрович, не могу сказать, сейчас донастраиваем серваки.» Через неделю: «Иван Петрович, оказалось, что на VMWare наша чача не запускается.» - «А раньше это нельзя было проверить. У нас 2 дня до релиза.» - «Иван Петрович, раньше мы тесты писали.» В общем, не закрыл Вася собой тестирование - получает Below Expectations. Или Successful, если потом до конца года удачно поработает.

Ключевая мысль этого поста: менеджер должен озвучивать ожидания от сотрудников. Если ожидания не озвучены - будьте уверены, сотрудник поймет не так, что вы от него хотели. В результате - либо вам, как менеджеру, придется отступить от своей оценки. Либо сотрудник останется с ощущением. Что система оценок несправедлива.

Что помогает выстраивать ожидания? Ценности компании. Знаю, что для многих сотрудников, особенно инженеров, фраза «ценности компании» означает «мозгопромывательское бу-бу-бу». Однако это важная штука. А для менеджера - полезный инструмент.

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

Ни одно доброе дело не должно оставаться безнаказанным

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

Цитата из одного реального self-assessmentа.

На прошлой неделе мы говорили о 360 фидбэках, как их собирать с людей, и из каких частей они (фидбэки, не люди) должны состоять. На самом деле форма «3 на 3 на 3» - универсальна. Она применяется как раз при написании Performance Review - то есть формального документа, который отражает жизнь сотрудника в компании за прошедший год.

Собственно, первая веха в процессе формальной аттестации - это как раз создание Performance Review. Для этого менеджер:

• Собирает 360 фидбэки на инженера
• Просит самого инженера написать Self-assessment - то есть само-оценку в формате «3 на 3 на 3»: Key Results, Strengths, Areas for Improvement
• На базе 360 фидбэков и Self-assessment’а пишет Performance Review на каждого своего сотрудника. Пишет опять же по форме «3 на 3 на 3».

Что должно быть внутри всех этих документов. Чтобы менеджеру легче было сравнивать достижения сотрудников, понять самому и объяснить потом людям, почему они получили вот такую прибавку, и что нужно сделать, чтобы прибавка была больше, менеджер обращает внимание на следующие вещи:

Факты. Во всех документах по каждому поводу должны приводиться факты. Недостаточно написать: «Коля очень конфликтный человек.» Нужен пример, как и где это проявилось. Если мне кто-то в 360 фидбэке такое напишет про моего человека, я автора переспрошу: «в чем эта конфликтность выразилась»?

Где брать факты? Вот вас просят написать 360 фидбэк на коллег, вы сами хотите вспомнить факты про сотрудников. Где их взять, если процесс формальных аттестаций проводится раз в год? В конце года обычно ты уже ничего не помнишь, кто там что накосячил или кто чем отличился в начале года.

Поэтому в Outlook’е заводится папочка Focal. В ней подпапочки с именами людей. Пришло благодарственное письмо от заказчика в адрес ваших сотрудников - бац! Копию в папочку. Написал вам менеджер соседней группы, что ваш Серега уже утомил своими косяками - бац! Копию в папочку. Сами пишете кому-то «спасибо» - копию в папочку.

Короче говоря, получается простенькая система досье. Может быть, «досье» звучит как-то немного по-милицейски и вообще коварно, но поверьте, с его наличием жить становится гораздо проще. И вы не забудете поблагодарить хорошим словом на формальной аттестации того, кто вам реально помог..

Влияние. Кроме фактов, о чем бы мы не говорили - о достижениях, сильных сторонах или слабых сторонах человека - важно то, как это все повлияло на работу, на коллег, на результаты проекта. Это важно подчеркивать.

Например, вместо «Вася всегда готов прийти на помощь джуниорам» лучше написать «Вася всегда готов прийти на помощь джуниорам (strength). Он ответил на две сотни вопросов во время начала проекта (факт), и это позволило джуниорам практически моментально включиться в работу и выйти на хороший, взрослый уровень по производительности (влияние на команду и проект).»

Или вместо «Коля не отвечает на письма» лучше написать «Коля не отвечает на письма (Area for Improvement). Например, он не ответил на два письма заказчика непосредственно перед релизом 2.7 (факт). В итоге заказчик позвонил мне как тех лиду проекта, долго на меня орал и остался не вполне удовлетворенным работой с нашей командой (влияние на работу с заказчиком). Если бы Коля стал более дисциплинированным в работе с почтой, это позволило бы избежать таких проблем.»

В принципе, для сравнения людей между собой этих ключевых вещей - фактов и влияния обычно оказывалось достаточно. Имея факты и влияние людей на проект, команду, заказчика вы можете выстроить их в список от 1 до N по тому, сколько они сделали для компании. Вы можете сказать. кто сделал больше, кто меньше.

Но чтобы сказать, кого из этих людей надо повышать, кого пожурить, а кому просто сказать «хорошая работа», этого всего не достаточно. Нужны сформулированные ожидания от сотрудников. И про это мы поговорим в следующий раз.

Сто правил NASA для руководителей проектов

Вот есть такая организация NASA. Спутники там запускает, космонавтов, и вообще. И в ней, как нетрудно догадаться, есть проекты. Причем, процент успешности этих проектов космически далек от привычных нам 30%. Которые из года в год кочуют по отчетам Standiush Group. Как так? Почему в NASA умеют, а в нашей индустрии не умеют?

Коллеги из NASA сформулировали свои best practices в виде 100 правил для руководителя проектов. И мне кажется, с ними стоит ознакомиться. (Правила взяты с it4business.ru)

Руководитель проекта

Правило 1
Руководитель проекта должен посетить каждого, кто делает что-нибудь в его проекте хотя бы один раз, должен знать всех менеджеров в своём проекте (как из государственных органов, так и у субподрядчиков), а также членов команды проекта. Людям нравится, когда руководитель проекта заинтересован в их работе и лучше всего посетить их лично и увидеть самому, что они делают.

Правило 2
Руководитель проекта должен знать мотивацию участников проекта (то есть их систему премирования и штрафов, их регламенты и другие компоненты культуры этих компаний).

Правило 3
Принципы управления не изменяются. Меняются только средства. Вы по прежнему должны найти нужных для выполнения работы людей и найти путь, следуя которому они смогут выполнить её.

Read the rest of this entry »

Менеджерские навыки