![]() | You are viewing Log in Create a LiveJournal Account Learn more |
| Александр Орлов's Journal 20 most recent entries |
Актуальное расписание тренингов Happy PM - на сайте.
Статьи (про карьеру, менеджерские навыки, мотивацию сотрудников и саморазвитие)
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
Обычно «спасибо за внимание» в письмах ПМу пишут в двух случаях. Первый - у вас очень дружеские отношения с ПМом. Второй - вы высказали идею и самоустраняетесь от дальнейшей деятельности. Типа: «я свое предложение высказал, и делайте теперь что хотите». Как вы думаете, во втором варианте - поможет ли такое окончание продвижению вашей идеи? Вряд ли. А почему, вообще, идеи, которые мы шлем начальнику, никуда не продвигаются? Вариантов несколько:
Если у вас из раза в раз идеи не проходят - подумайте, что происходит? Кто тот человек, который должен продвинуть твою идею? Какие у него полномочия? Чего ему надо от этой жизни? Что он, наконец, думает о вашей работе и о вас лично? И прежде чем писать «спасибо за внимание» и обижаться, подумайте, что со всем этим можно сделать. post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
3 comments | post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there. Должностные инструкции и правильные процедуры - далеко не всё. При запуске проекта руководитель в первую очередь вступает в человеческие отношения с коллегами, исполнителями, подчиненными. 1 comment | post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
На днях встречался со своим хорошим знакомым, руководителем крупного ИТ подразделения. Его начальство как раз приняло именно такое решение. После чего он встал и ушел из компании. И это важный момент. Я считаю, у каждого из нас должна быть возможность встать и уйти. Иначе произойдет что? Мы будем внутренне не согласны с политикой руководства, но сказать против ничего не сможем. И нас продавят. А когда людей продавливают, то на них уже нельзя опираться. Эти люди замалчивают свое мнение, свои истинные мотивы. Потому что уйти они не могут и начинают опасаться, что их уволят. И кстати, как бы парадоксально это ни звучало, работодателю тоже выгодно иметь в своей компании людей, которые могут из нее уйти в любой момент. Эти люди свободны в своем мнении. Они не будут молчать, скрывать свое мнение, чтобы потом спрыгнуть в удобный для них момент. Коллеги, почему мы говорим о финансовой безопасности и саморазвитии? Задумайтесь - вы сейчас можете встать и уйти? Вы сможете сразу же найти работу, или жить за свой счет до тех пор, пока вы ее не найдете? Если не сможете - не ждите, пока от начальства прилетит плюха. Начните делать что-то уже сейчас. 2 comments | post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
Эти ценности написаны везде и всюду - на корпоративных календариках, которые все надевают себе на бейдж. На корпоративных порталах и постерах - короче, везде. Из-за чего у многих сотрудников на саму фразу «ценности компании» вырабатывается жесткая аллергия. Но по сути, то, что там написано, все равно сидит у всех в голове. А для менеджера - это прекрасный инструмент при оценке сотрудников. Итак, какие ценности есть в 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 принято помимо фактов и влияния подчеркивать, какая ценность была сотрудником продемонстрирована (или наоборот, наличие какой ценности не помешало бы На мой взгляд, совершенно не обязательно распечатывать постеры с вот этими ценностями и развешивать их в своей компании на каждом углу. Просто попробуйте воспользоваться призмой ценностей. Через эту призму довольно хорошо выстраиваются ожидания от сотрудников. То есть, прежде чем озвучивать Васе, что он теперь тест менеджер - посмотрите, что это будет означать с точки зрения ценностей. Глядишь, нужные слова сразу запросятся на язык.
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
По поводу именных мышек. Вот в Sun Store, помнится, продавались отличные семейные трусы с логотипом Sun. С тех пор ни разу не видел семейных трусов с логотипами компанией. Почему не делают?… Бомба же. 3 comments | post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there. Даже если вы находитесь на правильном пути, то никуда не доберетесь, если будете просто сидеть на одном месте. 1 comment | post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
В Intel дальше каждый менеджер должен был проставить людям оценки. Для простоты скажем, что оценок этих было три:
Что нужно, чтобы сказать - хуже, лучше или в соответствии с ожиданиями от работал человек. Бинго! Нужно, чтобы эти ожидания были сформулированы! Кто формулирует ожидания? Частично компания, частично сам менеджер. В компании это выглядит обычно как таблица компетенций, например вот такая. Сам же менеджер проясняет и доносит до своих сотрудников дополнительные детали. Ну, например: «Вася, ты теперь будешь тест менеджером. Я не ожидаю, что ты прямо завтра закроешь все проблемы с тестированием. Но я ожидаю, что через два месяца ты уже будешь самостоятельно писать тест план, общаться с аналитиком, отслеживать работы по тестированию, и отслеживать статус проекта по качеству. Чтобы в любой момент времени ты мог сказать мне, можем мы выпускать продукт или нет.» Дальше проходит два месяца. Менеджер оценивает - как там тест менеджер Вася. И вдруг видит - ух ты, Вася не только закрыл собой все тестирование, но еще и помог аналитику с выбором и настройкой системы хранения требований. А еще подготовил фрэймворк для юнит тестов и помог разработчикам внедрить практику test driven development. Что это означает? Вася превысил ожидания. А может быть наоборот. Менеджер приходит: «Вася, как там статус проекта?» - «Иван Петрович, не могу сказать, сейчас донастраиваем серваки.» Через неделю: «Иван Петрович, оказалось, что на VMWare наша чача не запускается.» - «А раньше это нельзя было проверить. У нас 2 дня до релиза.» - «Иван Петрович, раньше мы тесты писали.» В общем, не закрыл Вася собой тестирование - получает Below Expectations. Или Successful, если потом до конца года удачно поработает. Ключевая мысль этого поста: менеджер должен озвучивать ожидания от сотрудников. Если ожидания не озвучены - будьте уверены, сотрудник поймет не так, что вы от него хотели. В результате - либо вам, как менеджеру, придется отступить от своей оценки. Либо сотрудник останется с ощущением. Что система оценок несправедлива. Что помогает выстраивать ожидания? Ценности компании. Знаю, что для многих сотрудников, особенно инженеров, фраза «ценности компании» означает «мозгопромывательское бу-бу-бу». Однако это важная штука. А для менеджера - полезный инструмент. И в следующий раз мы поговорим о том, какие ценности ставят себе ведущие компании. Они обычно примерно про одно и то же. Поэтому расскажем на примере шести ценностей компании Intel. post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
На прошлой неделе мы говорили о 360 фидбэках, как их собирать с людей, и из каких частей они (фидбэки, не люди) должны состоять. На самом деле форма «3 на 3 на 3» - универсальна. Она применяется как раз при написании Performance Review - то есть формального документа, который отражает жизнь сотрудника в компании за прошедший год. Собственно, первая веха в процессе формальной аттестации - это как раз создание Performance Review. Для этого менеджер:
Что должно быть внутри всех этих документов. Чтобы менеджеру легче было сравнивать достижения сотрудников, понять самому и объяснить потом людям, почему они получили вот такую прибавку, и что нужно сделать, чтобы прибавка была больше, менеджер обращает внимание на следующие вещи: Факты. Во всех документах по каждому поводу должны приводиться факты. Недостаточно написать: «Коля очень конфликтный человек.» Нужен пример, как и где это проявилось. Если мне кто-то в 360 фидбэке такое напишет про моего человека, я автора переспрошу: «в чем эта конфликтность выразилась»? Где брать факты? Вот вас просят написать 360 фидбэк на коллег, вы сами хотите вспомнить факты про сотрудников. Где их взять, если процесс формальных аттестаций проводится раз в год? В конце года обычно ты уже ничего не помнишь, кто там что накосячил или кто чем отличился в начале года. Поэтому в Outlook’е заводится папочка Focal. В ней подпапочки с именами людей. Пришло благодарственное письмо от заказчика в адрес ваших сотрудников - бац! Копию в папочку. Написал вам менеджер соседней группы, что ваш Серега уже утомил своими косяками - бац! Копию в папочку. Сами пишете кому-то «спасибо» - копию в папочку. Короче говоря, получается простенькая система досье. Может быть, «досье» звучит как-то немного по-милицейски и вообще коварно, но поверьте, с его наличием жить становится гораздо проще. И вы не забудете поблагодарить хорошим словом на формальной аттестации того, кто вам реально помог.. Влияние. Кроме фактов, о чем бы мы не говорили - о достижениях, сильных сторонах или слабых сторонах человека - важно то, как это все повлияло на работу, на коллег, на результаты проекта. Это важно подчеркивать. Например, вместо «Вася всегда готов прийти на помощь джуниорам» лучше написать «Вася всегда готов прийти на помощь джуниорам (strength). Он ответил на две сотни вопросов во время начала проекта (факт), и это позволило джуниорам практически моментально включиться в работу и выйти на хороший, взрослый уровень по производительности (влияние на команду и проект).» Или вместо «Коля не отвечает на письма» лучше написать «Коля не отвечает на письма (Area for Improvement). Например, он не ответил на два письма заказчика непосредственно перед релизом 2.7 (факт). В итоге заказчик позвонил мне как тех лиду проекта, долго на меня орал и остался не вполне удовлетворенным работой с нашей командой (влияние на работу с заказчиком). Если бы Коля стал более дисциплинированным в работе с почтой, это позволило бы избежать таких проблем.» В принципе, для сравнения людей между собой этих ключевых вещей - фактов и влияния обычно оказывалось достаточно. Имея факты и влияние людей на проект, команду, заказчика вы можете выстроить их в список от 1 до N по тому, сколько они сделали для компании. Вы можете сказать. кто сделал больше, кто меньше. Но чтобы сказать, кого из этих людей надо повышать, кого пожурить, а кому просто сказать «хорошая работа», этого всего не достаточно. Нужны сформулированные ожидания от сотрудников. И про это мы поговорим в следующий раз. post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
Коллеги из NASA сформулировали свои best practices в виде 100 правил для руководителя проектов. И мне кажется, с ними стоит ознакомиться. (Правила взяты с it4business.ru) post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
1 comment | post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there. Предоставьте своим сотрудникам широкие возможности учиться у других, не старайтесь быть их единственным учителем. post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there. Предоставьте своим сотрудникам широкие возможности учиться у других, не старайтесь быть их единственным учителем. post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
Вкратце - что такое 360 фидбэк. Каждый сотрудник обычно работает не в вакууме. За год он успевает поработать с самыми разными людьми. Интересно же, чего они про вашего думают? И вот вы как менеджер к ним приходите и спрашиваете: «ну как там наш Епифан-то?» А поскольку вы ходите не к одному человеку, а по кругу ко всем, с кем Епифан поработал, то это и называется 360 фидбэк. Формализованная процедура выглядит так: 1. Инженер Епифан говорит вам, своему менеджеру, у кого менеджер может запросить на него 360 фидбэк. 2. Менеджер смотрит на этот список и добавляет к нему еще несколько людей (некоторых может из списка убрать). Инженеры как-то обычно не включают в список тех, с кем они отчаянно ругались в течение года. В списке могут оказаться:
То есть все, с кем Епифан плотно общался. 3. Далее менеджер пишет каждому человеку из списка:
По английски эта структура называется 3 на 3 на 3: 3 Key Results, 3 Strengths, 3 Areas for Improvement. 4. После чего менеджер все это собирает, смотрит на то, что ему прислали и дополняет картину, которая уже сложилась в его голове по поводу Епифана. Как раз из 360 фидбэков можно увидеть:
К чему надо быть готовым? К тому, что люди очень по-разному пишут 360 фидбэки. Менеджеры их обычно пишут неплохо. Инженеры же пишут их спустя рукава, для отписки и вообще «стучать - западло». Часто в секцию «Areas for Improvement» пишут: «было бы полезно улучшить свой английский». Знаете, как при защите дипломов и диссертаций - должна быть заполнена секция «Отмеченные недостатки». Туда обычно пишут: «недостаточное качество иллюстраций». Вот и тут так же: «было бы полезно улучшить свой английский». Что с этим делать? Ничего не делать. Такое ощущение, что это все, что нужно знать про формальную сторону 360 фидбэков. А чуть позже мы поговорим про то, что конкретно в каждую из секций, откуда брать факты и как все помнить. post a comment
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
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
Если серьезно, то для меня GE означает Джэк Уэлч. Потрясающий менеджер, который написал несколько потрясающих книг. Однако, компания жила и процветала и до него. Уверен, что в бОльшей степени благодаря своему менеджменту, который руководствовался следущей памяткой на все времена.
Взято отсюда. (Пользуясь случаем, хочу попиарить сайт моего товарища Григория Кнеллера executives.ru . И несмотря на то, что не вполне разделяю Гришино мнение о причинах неуспеха российского менеджмента :), должен сказать, что ресурс executives.ru получается категорически симпатичным.) post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
Довольно любопытной была система зарплат. Все приходящие получали одинаковую зарплату - $1,100. Некоторым за определенные заслуги ее поднимали через год-два до $1,200 или даже $1,300. Те, кто отработал уже лет 5-7, и при этом были очень толковыми техническими ребятам, могли получать по $1,500. Качественный скачок случался у человека ровно в одном случае - когда он становился тим лидером. Тогда его зарплата становилась $1,600 и могла потом потихоньку вырасти где-то до $1,800. Оценка персонала и пересмотр зарплат происходили обычно так. Они не происходили вообще. Я имею, в виду регулярно. Иногда, когда бюджет компании рос (а рос он за счет приходящих новичков, у которых была минимальная зарплата), директор вызывал к себе тим лидов по одному и говорил: «Старик, у нас появились деньги. Кому поднимем зарплату в твоей команде?» Тим лидер говорил: «Давайте Пете. Он офигенный.» Вот и вся оценка персонала. Увольнять никого не увольняли. (Было два клинических случая. Один раз человек просто ничего не делал в течение нескольких месяцев. И наш директор с большой неохотой пошел на увольнение. А второй случай - у человека что-то подвинулось в голове, и он просто стал себя неадекватно вести.) Система работала прекрасно. Никаких конфликтов в коллективе не происходило. Поскольку поднимали зарплаты точечно, то те, кому поднимали, старались с коллегами этим фактом особенно не делиться. Иногда, делились и проставлялись, но это было редко. Но однажды случилось пренеожиданнейшее событие. Мы так сильно выросли, что появился бюджет на то, чтобы поднять зарплату всем сотрудникам (ну, кроме новичков, конечно). Директор озадачил всех вопросом: «Мы думаем всем поднять зарплату на $50. Скажи, кому в твоей команде поднять на $100?» Я по старой схеме: «Давай поднимем Пете на $100.» В тот же день, ко мне подходит Коля и говорит: «Саша, я знаю, что всем поднимают на $50. Но некоторым на $100. Почему мне поднимают зарплату на $50? Я же тут пашу как волк последние три месяца.» Я не был готов к такому повороту событий. Более того, у меня не было ощущения, что Коля пахал последние три месяца как волк. А чему удивляться - у меня в команде тогда было 17 человек. Некоторых я не видел по месяцу (у нас была кабинетная система), но по отчетам видел, что ребята работают, все движется. И действительно все оно как-то работало. Но при пересмотре зарплат и при оценке людей важно не только, работает там все или нет. Важно, насколько вы в курсе того, что делают ваши люди. Вот сидит тех лид и целый день отвечает на вопросы джуниоров. Даже несмотря на то, что его все время вырывают из потока, он умудряется сделать нормальный объем. Но то, что он тащит за уши джуниоров вы не видите (если, конечно, вы не сидите в той же комнате). Часть информации проходит мимо менеджера и он должен уметь эту часть информации поймать, переварить и оценить. Иначе ни о какой справедливой оценке людей говорить будет нельзя. Как ловить информацию. Способ давно известен - 360 фидбэк. Он прижился во многих крупных компаниях и неплохо работает. На следующей неделе мы как раз поговорим у кого его запрашивать, как он пишется, и какие отписки туда пишут. post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
Проведя три дня в столице Беларуси, я собрал свои вещи-пожитки и ночью на секретном поезде переместился в Москву, где уже второй день шла конференция Software People. День начался по традиции в историческом Кофе Хаусе на Новослободской, который, как я однажды обнаружил, работает круглосуточно. А историческим он стал после того, как мы там собрались однажды с Сергеем Архипенковым и Асхатом Уразбаевым, и там обсуждали детали создания Гильдии менеджеров программных проектов. post a comment |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||