Home
Александр Орлов's Journal
20 most recent entries

Date:2010-01-01 00:05
Subject:Мое хозяйство
Security:Public

Актуальное расписание тренингов Happy PM - на сайте.

Эффективные коммуникации: открытый тренинг Happy PM, 11-12 апреля 2009, С-Петербург. Запишись на первый тренинг Happy PM по лидерству!

Как стать менеджером в ИТ. Бесплатный онлайн тренинг. Мастер-класс от Александра Орлова и Славы Панкратова. Скачать запись!

Happy PM онлайн тренинг: Человеческий фактор 2.0. 12 февраля 2009. Детали

Happy PM Reality Show: 12-15 декабря 2008, С-Петербург, открытый тренинг проекта Happy PM. Узнай больше!
Тренинг окончен. Прочитать отчет и отзывы.

Проекты


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


Рассылка Клуба Успешных ПМов (выходит еженедельно)


Продукты

Информационная система "Как менеджеру программистов удвоить зарплату, сделать карьеру и начать жить"

Книга "Секреты Управления Программистами" (на Озоне)

Тренинги и семинары проекта Happy PM:

  • Становясь менеджером…
  • Фитиль для ПМа
  • Анти-Текучка
  • Построение карьеры
  • Менеджерские навыки: как писать письма и документы
  • Менеджерские навыки: публичные выступления

Статьи (про карьеру, менеджерские навыки, мотивацию сотрудников и саморазвитие)

1 comment | post a comment



Date:2009-07-10 10:00
Subject:Почему тебя никто не слушает
Security:Public

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

В качестве домашнего задания по тренингу «Как писать эффективные письма» один слушатель прислал письмо, которое он написал бы своему ПМу по улучшению некоторого процесса. Само предложение было очень здравое. Но завершалось оно словами «спасибо за внимание». И это навело меня вот на какие мысли. (Надеюсь, слушатель меня не предаст анафеме, тем более, что я постараюсь быть конфиденциальным. :) )

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

Как вы думаете, во втором варианте - поможет ли такое окончание продвижению вашей идеи? Вряд ли. А почему, вообще, идеи, которые мы шлем начальнику, никуда не продвигаются? Вариантов несколько:

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

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

post a comment



Date:2009-07-08 10:00
Subject:Преферанс после работы и черный ящик
Security:Public

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

Дошла очередь до чемпионов конкурса “Как позаботиться о сотрудниках”: 31 идея от false-true!

Автор: false-true и менеджер Серёжа :)

Несколько из изложенных ниже пунктов использовались на моей работе, и это было отлично!

1) Периодические совместные просмотры фильмов (обычно по пятницам). Как правило, в большинстве компаний есть проектор или широкоформатный монитор для видеоконференций. В основном выбирается какое-нибудь арт-хаусное кино, в хорошем качестве, которое мало кто видел. Можно, кстати, выбирать фильмы на английском языке или с субтитрами, чтобы и языковая практика была. Это и интересно и сплачивает. У нас показ обычно начинался за час до официального окончания рабочего дня.

2) Также классно еженедельно (ежемесячно) устраивать какую-нибудь простую соревновательную развлекательную игру в конце рабочего дня/недели. Например, преферанс, покер или даже лото:). В качестве банка начальство ставит небольшую сумму (~ 10-50$). Иногда и на свои можно сыграть после зарплаты (на символическую сумму:)). Ещё веселее и интереснее, чем кино.

3) Хорошо действую и соревнования в профессиональной области. Выдаётся задание написания определённого кода (метода, алгоритма и т.п.) решения конкретной задачи. Писать можно на любом языке - главное, чтобы результат был виден. Устанавливается сумма для победителя (~50-100 $). Задания лучше давать интересные и сложные и не очень часто (раз в квартал вполне хватит), чтобы не только программерские навыки пригодились, но и «соображалка». Победителю торжественно вручать приз.

4) Оформление рабочего места – а именно разрешить команде, сотрудникам оформить их рабочее место по желанию. На стены можно вешать весёлые плакаты, постеры, стильные фотографии. Разработать и повесить корпоративный календарь (только не стандартный, проявите оригинальность!). Если действительно заняться этим, то всеобщее обсуждение такого важного момента очень объединяет - и позволяет многое узнать об интересах друг друга. А результат позволит с бОльшим удовольствием приходить на рабочее место. Можно даже специальную разметку для пола сделать, если нет разделения по комнатам. В общем, позвольте сотрудникам участвовать в оформлении их рабочих мест.

5) Хорошо бы организовать периодические беседы с менеджером или тим лидом – один на один. А менеджера с вышестоящим начальством. Где сотрудник может сказать о том, что он думает о своей работе, о своём месте в команде, о том, над чем ему было бы интересно работать, кем он себя видит и как хочет к этому «идти». Конечно, здесь важно, чтобы отношения между менеджером и сотрудником были не просто формальные. Ну и инициатива, конечно, от менеджера должна исходить, здесь требуется определённая профессиональная грамотность и человечность. При правильной постановке такие беседы мотивируют лучше всего.

6) Если беседы на должном уровне организовать не получается, то можно хотя бы организовать что-то вроде «чёрного ящика» («Для замечаний и предложений»), куда сотрудник может опускать бумажки с идеями как по проектам, так и по работе в целом. Ящик лучше поставить где-нибудь на кухне или в коридоре, где записки можно положить незаметно. Главное, что записки эти надо периодически освещать и обсуждать на общем митинге, если они и правда того стоят. Возможность обратной связи – это всегда «+».

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

Read the rest of this entry »

3 comments | post a comment



Date:2009-07-07 10:00
Subject:Цитата недели (Игорь Ашманов)
Security:Public

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

Должностные инструкции и правильные процедуры - далеко не всё. При запуске проекта руководитель в первую очередь вступает в человеческие отношения с коллегами, исполнителями, подчиненными.

1 comment | post a comment



Date:2009-07-06 10:00
Subject:Возможность встать и уйти
Security:Public

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

Коллеги, мы все не идеальны. В том числе, и наше начальство. Мы не читаем книжки по менеджменту :), и оно их так же не читает. Потому что времени у него еще меньше. И время от времени начальство заносит, и оно принимает глупые решения. Которые отражаются на нас.

На днях встречался со своим хорошим знакомым, руководителем крупного ИТ подразделения. Его начальство как раз приняло именно такое решение. После чего он встал и ушел из компании.

И это важный момент. Я считаю, у каждого из нас должна быть возможность встать и уйти. Иначе произойдет что? Мы будем внутренне не согласны с политикой руководства, но сказать против ничего не сможем. И нас продавят.

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

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

Коллеги, почему мы говорим о финансовой безопасности и саморазвитии? Задумайтесь - вы сейчас можете встать и уйти? Вы сможете сразу же найти работу, или жить за свой счет до тех пор, пока вы ее не найдете? Если не сможете - не ждите, пока от начальства прилетит плюха. Начните делать что-то уже сейчас.

2 comments | post a comment



Date:2009-07-03 10:00
Subject:Ценности компании как инструмент менеджера
Security:Public

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

Какие ценности определяют для себя ведущие компании вообще, и компания 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 принято помимо фактов и влияния подчеркивать, какая ценность была сотрудником продемонстрирована (или наоборот, наличие какой ценности не помешало бы :) ).

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

1 comment | post a comment



Date:2009-07-01 10:00
Subject:Именные мышки и программисты на тренингах по тестированию
Security:Public

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

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

Автор: Karina Lvova

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

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

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

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

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

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

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

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

3 comments | post a comment



Date:2009-06-30 10:00
Subject:Цитата недели (Уилл Роджерс)
Security:Public

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

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

1 comment | post a comment



Date:2009-06-29 10:00
Subject:Кого повышать, кого журить
Security:Public

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

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

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

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

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

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

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

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

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

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

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

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

post a comment



Date:2009-06-26 10:00
Subject:Ни одно доброе дело не должно оставаться безнаказанным
Security:Public

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

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

Цитата из одного реального 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 по тому, сколько они сделали для компании. Вы можете сказать. кто сделал больше, кто меньше.

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

post a comment



Date:2009-06-25 10:00
Subject:Сто правил NASA для руководителей проектов
Security:Public

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

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

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

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

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

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

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

Read the rest of this entry »

post a comment



Date:2009-06-24 10:00
Subject:Успешные отчеты компании и конкурс архитектурных рисунков
Security:Public

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

Продолжается публикация наследства конкурса “Как позаботиться о сотрудниках”. Сегодня - 9 идей от Дмитрия Мартынова.

Автор: dmitry_martynov

Исходим из того, что 300 у.е. дают каждый месяц

1) В конце месяца - попросить прислать по e-mail список наиболее заковыристых/интересных вопросов и как их разрулили. Консолидировать любым способом и разослать всем с объявлением победителя и премией 30-50 у.е.

2) Разослать обязательно успешный :) годовой финансовый отчет компании. Такие вещи до рядовых сотрудников обычно не доходят, а зря.

3) Сходный - прислать информацию о продвижении компании на рынке/сравнение с конкурентами при положительном тренде.

4) За особо выдающиеся успехи - обновлять/улучшать конфигурацию рабочей лошадки. Большинство реагирует весьма положительно.

5) Повесить доску почета а-ля “их разыскивает милиция”. Желательно “для своих” + люди в команде должны иметь чувство юмора. возможен вариант вставки фотографий лиц в подготовленную картинку.

6) Объявить конкурс класса лучший рисунок, отражающий суть/архитектуру проекта, в Gimp/Paintbrush. Чем юморнее тем лучше. Аналогично, победитель получает 30-50 у.е.

7) За особо выдающиеся успехи - дарить такую актуальнейшую вещь, как пакетик с зерновым кофе. Условия - на работе должна стоять кофе-машина и сорт должен быть классом выше, чем “бесплатный” на кухне.

8) Отпускать сотрудников не только на ИТ - бесплатные конференции, но (нечасто) и на те, которые ему интересны. Скажем человек ярый скейтбордист и ты знаешь что 1 день его отсутствия на соревнованиях по скейтбордингу ничего не изменит т.к. он потом отработает и отношения станут лучше.

9) Создать внутренний web-ресурс стягивающий RRS новости с тематических сайтов. Либо внутреннюю систему подписки по тематикам (возможно в крупных компаниях). Там же - публикации о компании в прессе.

1 comment | post a comment



Date:2009-06-23 10:00
Subject:Цитата недели (Стетнер Мори)
Security:Public

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

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

post a comment



Date:2009-06-23 10:00
Subject:Цитата недели (Стетнер Мори)
Security:Public

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

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

post a comment



Date:2009-06-22 06:07
Subject:360 фидбэки: что и как
Security:Public

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

Когда нас купил Intel, то через полгода пришла пора провести первую формальную аттестацию сотрудников. Но поскольку мы отработали всего полгода, то было решено сделать ее тренировочной. То есть после нее все получали статус Successfull, но всю процедуру мы прошли. Часть этой процедуры был сбор 360 фидбэков. Всего в Интеле я провел 4 формальные аттестации, поэтому некоторый опыт в этой области накопился. Тут есть свои тонкости.

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

Формализованная процедура выглядит так:

1. Инженер Епифан говорит вам, своему менеджеру, у кого менеджер может запросить на него 360 фидбэк.

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

В списке могут оказаться:

  • коллеги инженера
  • инженеры соседних групп
  • начальники соседних групп
  • заказчик

То есть все, с кем Епифан плотно общался.

3. Далее менеджер пишет каждому человеку из списка:

Уважаемый Иван Иваныч, помоги мне, пожалуйста, оценить моего инженера Епифана. Вы с ним много работали в течение года, поэтому я буду очень благодарен, если ты мне напишешь:

  • 3 самых важных достижения или результата, которых Епифан достиг в этом году
  • 3 сильные качества Епифана
  • 3 вещи, которые ему стоило бы улучшить

По английски эта структура называется 3 на 3 на 3: 3 Key Results, 3 Strengths, 3 Areas for Improvement.

4. После чего менеджер все это собирает, смотрит на то, что ему прислали и дополняет картину, которая уже сложилась в его голове по поводу Епифана.

Как раз из 360 фидбэков можно увидеть:

  • То, что человек постоянно конфликтовал с инженерами в соседней группе
  • То, что человек много и активно отвечал на вопросы других членов команды
  • То, что человек решал вопросы кастомера по телефону, и тот остался супер-доволен

К чему надо быть готовым?

К тому, что люди очень по-разному пишут 360 фидбэки. Менеджеры их обычно пишут неплохо. Инженеры же пишут их спустя рукава, для отписки и вообще «стучать - западло». Часто в секцию «Areas for Improvement» пишут: «было бы полезно улучшить свой английский». Знаете, как при защите дипломов и диссертаций - должна быть заполнена секция «Отмеченные недостатки». Туда обычно пишут: «недостаточное качество иллюстраций». Вот и тут так же: «было бы полезно улучшить свой английский». :)

Что с этим делать? Ничего не делать. :) Если человек реально всех достал, то инженеры про него напишут все, что думают, в Areas for Improvement. Если человек много всем помогал, то точно напишут это в Key Results и/или Strengths. Если же не пишут ничего, значит, скорее всего, каких-то больших проблем с человеком не возникало. И какой-то большой помощи они от него тоже не видели.

Такое ощущение, что это все, что нужно знать про формальную сторону 360 фидбэков. А чуть позже мы поговорим про то, что конкретно в каждую из секций, откуда брать факты и как все помнить.

post a comment



Date:2009-06-19 10:00
Subject:Работа в кризис
Security:Public

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

Не так давно меня написал письмо один из слушателей тренинга “Как стать менеджером в ИТ”. Если вкратце, то ситуация, про которую он писал, следующая. Слушатель работает сейчас ПМом, но есть ощущение, что компания дышит на ладан. И даже кое-где уже загибается. В связи с чем слушатель начал искать работу.

По знакомым позиций нет. По объявлениям - реакция какая-то невнятная. Почти нигде нет позиций. Хотя объявления висят. Похоже, HR’ы набирают базу резюме. В пару мест позвали на собеседование. Поговорили, потом выяснилось, что у них тоже нет позиций.

При этом речь идет о городе-миллионнике. Такое ощущение, что рынок мертвый. Хотя вот, говорит слушатель, позвонил по одному из объявлений, там говорят, что вчера уже наняли человека на эту позицию. Значит, рынок не своем мертвый.

Что делать в такой ситуации? - спрашивает слушатель. Я подумал, что возможно, мой ответ будет интересен не только ему.

На самом деле, что либо сделать резко в таких ситуациях тяжело. Делать надо заранее. Но начинать это делать никогда не поздно. Что конкретно делать? Обрастать профессиональными знакомствами.

Как известно только 10% позиций заполняются по объявлениям. 90% заполняются через знакомых. Приглашать ПМа по объявлению - затея вообще довольно рискованная. Приглашать ПМа, которого ты лично знаешь - наоборот, душе как-то спокойней.

Отсюда вывод - расширяйте, расширяйте и еще раз расширяйте сеть ваших профессиональных знакомств:

Сделайте себе визитки. Если компания не делает, сделайте за свой счет. Стоит все удовольствие $10 за 100 штук.

Начните ходить на конференции. Если компания не оплачивает, платите из своего кармана. Если вы там познакомитесь с директором, который потом пригласит вас на работу, то вы сразу окупите все свои затраты. На последней конференции, на которой я был - Software People - я познакомился примерно с 15 директорами компаний. Вы чем хуже?

А еще лучше выступите на конференции с докладом. Если вы работаете 3-5 лет - вам уже есть что рассказать. Ну так и расскажите.

Запишитесь в любое коммьюнити, связанное с управлением проектами. например, в Agile коммьюнити. Сходите на встречу, познакомьтесь с коллегами.

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

Заведите себе профиль с LinkedIn’е и МоемКруге. Там тоже живет много интересных людей. Найдите какого-нибудь интересного вам человека и пригласите его на чашечку кофе. Ну, может быть, откажет. А может, и согласится. Точно не убьет. :)

Главное - побольше общайтесь. Просто тупо начните больше общаться. Это вообще один из главных навыков ПМа. Почему бы не испольщовать его на пользу собственной карьере? :)

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

4 comments | post a comment



Date:2009-06-18 10:00
Subject:Памятка руководящему составу GE
Security:Public

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

Компанию GE мы все, конечно, сильно любим. Надо поменять лампочку, идешь в магазин - а там лампочки GE. Широко себя раскинула корпорация… :)

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

Выписка из правил поведения руководящих работников GE, 30-е годы 20 века:

  1. Твоя задача – проводить общую техническую политику и решать ежедневно возникающие
    затруднения.
  2. Будь внимателен к критике и улучшающим предложениям, даже если они непосредственно
    тебе ничего не дают.
  3. Будь внимателен к чужому мнению, даже если оно не верно.
  4. Имей бесконечное терпение.
  5. Будь вежлив, никогда не раздражайся.
  6. Будь кратким.
  7. Не делай замечаний подчиненному в присутствии третьего лица.
  8. Будь справедлив, особенно в отношении с подчиненными.
  9. Всегда благодари подчиненного за хорошую работу.
  10. Никогда не делай сам того, что могут сделать твои подчиненные, за исключением
    тех случаев, когда это связано с опасностью для жизни.
  11. Выбор и обучение способного подчиненного всегда более благодарная задача,
    чем выполнение работы самому.
  12. Если то, что делают твои сотрудники, не расходится с твоим мнением, давай
    им максимальную свободу действий.
  13. Не спорь по мелочам.
  14. Не бойся, если твои подчиненные способнее тебя, а гордись такими подчиненными.
  15. Никогда не используй своей власти до тех пор, пока все остальные средства
    не использованы, но в последнем случае применяй ее в максимально возможной степени.
  16. Если твое распоряжение оказалось ошибочным – признай ошибку.
  17. Старайся во избежание недоразумений давать распоряжения в письменном виде.

Взято отсюда. (Пользуясь случаем, хочу попиарить сайт моего товарища Григория Кнеллера executives.ru . И несмотря на то, что не вполне разделяю Гришино мнение о причинах неуспеха российского менеджмента :), должен сказать, что ресурс executives.ru получается категорически симпатичным.)

post a comment



Date:2009-06-17 10:00
Subject:Ящик пива по почте и разрыв льва
Security:Public

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

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

Автор: Антон Кукоба

1) Подарить IT-шный подарок нематериального типа: например лицензионную винду или офис, акаунт на рапидшаре, торентовый акаунт с большим ратио, игру любимого жанра если человек - игрун, любимый или ожидаемый фильм в высоком качестве (HDTV/blue ray), собственный хостинг или мыло его имени, и т.д.

2) Отправить пиво с открыткой, оформленой как email с благодарностями, по реальной почте, т.е. посылкой. “Ящик пива в атаче” смотрится ваще нереально.

3) Апгрейд рабочего железа / интернет канала.

4) Дать человеку в день рождения право вето на совещании. Т.е. человек может наложить вето на одно из решений менеджера.

5) Сделать в честь человека, что-то эпическое: порвать пасть льву (можно плюшевому), совершить поход с плакатом на “He/she is the best!” вокруг здания/по офису под песню Тины Тёрнер “You’re simply the best”, на крайний случай отжаться от пола 20 раз.

post a comment



Date:2009-06-15 10:00
Subject:Всевидящее око менеджера
Security:Public

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

Когда я пришел работать в компанию «Эльбрус-МЦСТ», там были интересные времена. Классный коллектив, ненапрягающая работа с Sun, командировки по 3.5 месяца в Силиконовую долину. Что еще нужно молодому неокрепшему уму питерского ИТшника? :)

Довольно любопытной была система зарплат. Все приходящие получали одинаковую зарплату - $1,100. Некоторым за определенные заслуги ее поднимали через год-два до $1,200 или даже $1,300. Те, кто отработал уже лет 5-7, и при этом были очень толковыми техническими ребятам, могли получать по $1,500.

Качественный скачок случался у человека ровно в одном случае - когда он становился тим лидером. Тогда его зарплата становилась $1,600 и могла потом потихоньку вырасти где-то до $1,800.

Оценка персонала и пересмотр зарплат происходили обычно так. Они не происходили вообще. Я имею, в виду регулярно. Иногда, когда бюджет компании рос (а рос он за счет приходящих новичков, у которых была минимальная зарплата), директор вызывал к себе тим лидов по одному и говорил: «Старик, у нас появились деньги. Кому поднимем зарплату в твоей команде?» Тим лидер говорил: «Давайте Пете. Он офигенный.»

Вот и вся оценка персонала. Увольнять никого не увольняли. (Было два клинических случая. Один раз человек просто ничего не делал в течение нескольких месяцев. И наш директор с большой неохотой пошел на увольнение. А второй случай - у человека что-то подвинулось в голове, и он просто стал себя неадекватно вести.)

Система работала прекрасно. Никаких конфликтов в коллективе не происходило. Поскольку поднимали зарплаты точечно, то те, кому поднимали, старались с коллегами этим фактом особенно не делиться. Иногда, делились и проставлялись, но это было редко.

Но однажды случилось пренеожиданнейшее событие. Мы так сильно выросли, что появился бюджет на то, чтобы поднять зарплату всем сотрудникам (ну, кроме новичков, конечно). Директор озадачил всех вопросом: «Мы думаем всем поднять зарплату на $50. Скажи, кому в твоей команде поднять на $100?» Я по старой схеме: «Давай поднимем Пете на $100.»

В тот же день, ко мне подходит Коля и говорит: «Саша, я знаю, что всем поднимают на $50. Но некоторым на $100. Почему мне поднимают зарплату на $50? Я же тут пашу как волк последние три месяца.»

Я не был готов к такому повороту событий. Более того, у меня не было ощущения, что Коля пахал последние три месяца как волк. :) О чем я ему и сказал. Он начал рассказывать, что он делал. И я слушаю его и понимаю, что 80% того, что происходило, я просто не видел.

А чему удивляться - у меня в команде тогда было 17 человек. Некоторых я не видел по месяцу (у нас была кабинетная система), но по отчетам видел, что ребята работают, все движется. И действительно все оно как-то работало.

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

Вот сидит тех лид и целый день отвечает на вопросы джуниоров. Даже несмотря на то, что его все время вырывают из потока, он умудряется сделать нормальный объем. Но то, что он тащит за уши джуниоров вы не видите (если, конечно, вы не сидите в той же комнате).

Часть информации проходит мимо менеджера и он должен уметь эту часть информации поймать, переварить и оценить. Иначе ни о какой справедливой оценке людей говорить будет нельзя.

Как ловить информацию. Способ давно известен - 360 фидбэк. Он прижился во многих крупных компаниях и неплохо работает.

На следующей неделе мы как раз поговорим у кого его запрашивать, как он пишется, и какие отписки туда пишут.

post a comment



Date:2009-06-13 10:00
Subject:Где и как собирались Software People
Security:Public

Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.

Последний месяц выдался богатым на события. Я побывал в Минске, Москве, Киеве и Днепропетровске. В Москве причем три раза. Два раза - фактически проездом, на встречах. А вот первый раз - я выступал с комическими куплетами на конференции Software People, симпатичной конференции, про которую и хотел бы рассказать. Итак, отчет. :)

Проведя три дня в столице Беларуси, я собрал свои вещи-пожитки и ночью на секретном поезде переместился в Москву, где уже второй день шла конференция Software People. День начался по традиции в историческом Кофе Хаусе на Новослободской, который, как я однажды обнаружил, работает круглосуточно. А историческим он стал после того, как мы там собрались однажды с Сергеем Архипенковым и Асхатом Уразбаевым, и там обсуждали детали создания Гильдии менеджеров программных проектов.

Read the rest of this entry »

post a comment


browse
my journal