Как стать ПМом

За последние месяцы меня несколько раз спрашивали, что нужно для того, чтобы стать руководителем проекта (ПМ). Что примечательно, этот вопрос исходит в основном от джуниоров, молодых и амбициозных. Опуская сантименты "оно вам не надо" и т.д., попробую высказать свое субъективное и неправильное мнение на этот счет.

1. ПРИЧИНА

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

• "я зарабатываю пять тысяч в месяц" (деньги),
• "меня знают и уважают в Одессе" (слава),
• "я руковожу тремя проектами и сорока людьми" (власть).

Что звучит убедительней? Власть, только она наиболее полно позволяет человеку ощутить степень своего карьерного роста и практически количественно (в подчиненных) измерить его.

2. СРЕДСТВА

Теперь о средствах достижения вожделенного ПМства. В дополнение к очевидному - желанию стать ПМом - более-менее внятно озвучить я могу пять:

2.1. Опыт. Я придерживаюсь мнения, что стать хорошим ПМом, не отработав N лет в инжиниринге, нельзя. Плохим - можно, но мы не рассматриваем этот вариант по причине того, что все риски, связанные с плохим ПМом, разделяет его руководитель, а значит вряд ли назначит его на эту должность. Только через годы работы разработчиком, старшим разработчиком, техлидом и тимлидом можно приблизиться к креслу ПМа, поскольку:

• позиция разработчика даст вам прочувствовать то, как управлять собой и своим временем
• позиция старшего разработчика поможет вам глубже разобраться в областях, непосредственно не относящихся к кодингу: анализ и управление требованиями, оценка трудозатрат, ревью архитектуры и дизайна и т.д. Кроме того, обычной практикой является курирование старшим разработчиком одного или нескольких программистов.
• на позиции тим/тех-лида в первую очередь приходит понимание того, что такое ответственность за команду. Это очень важный пункт, который нельзя пропускать, поскольку через него мы приходим к умению нести ответственность за технические решения (свои и команды), организационные решения (свои и компании), ну и в целом за проект. Кроме этого, здесь вам придется научиться управлению рисками и проблемами, грамотному общению с заказчиком, а также основам того, как быть интерфейсом между командой, компанией (рекрутерами, HR, руководством, администрацией) и заказчиком.

К сожалению или к счастью, опыт здесь нельзя заменить знаниями. Разработчик, прослушавший курсы по управлению проектами, - это еще не ПМ. В системном анализе программные проекты относятся к классу сложных систем (СС) с неформализуемыми компонентами (в первую очередь - людьми). Управление ожиданиями подчиненных, понимание культурных и личностных особенностей разных заказчиков, понимание и принятие правил, по которым функционирует ваша организация (а также их выполнение) - все это нельзя получить из книг. Более того, даже формализуемые компоненты СС (собственно ПО) также требуют опыта. Например: никому не нужен в качестве архитектора вчерашний студент, пусть и очень знающий, но не спроектировавший N реальных систем с учетом требований производительности, масштабируемости, устойчивости к изменениям требований и т.д. - а ПМ должен выполнять ревью требований, архитектуры, тест-плана, поэтому и спрос с него соответствующий.

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

2.3. Инициатива (или "делайте больше"). Покажите своему руководителю (от которого зависит ваше повышение), что вы можете больше. Вам дали задачу? Найдите способ сделать ее лучше, чем указано в требованиях! Заложите больше масштабируемости, проведите рефакторинг, напишите больше тестов, оптимизируйте алгоритм. Однако, не бросайтесь с места в карьер: отсутствие опыта приведет только к тому, что вы будете предлагать нереализуемые, ненужные или ранее отвергнутые сценарии и тем самым злить начальство. См. также пункт 2.1.

2.4. Язык. Как правило - английский. ПМ, пишущий письма заказчику на плохом английском, с ошибками в словах и грамматике, отвратителен. С другой стороны, вполне можно писать простыми предложениями, употреблять в основном часто используемые слова - но ради Бога, грамотно! Оценить свою степень владения языком можно на курсах, у преподавателя, у более знающего коллеги, а также, частично, с высоты своего языкового опыта. См. также пункт 2.1.

2.5. Способности к руководству. Это что-то из области "можно вам доверить людей" или нет. Оценивать вас по этому пункту будет ваш руководитель, скорее всего, чисто субъективно, в связи с чем ограничусь примерами:

• "человек-фюрер", как правило, отлично справляется со всеми задачами, возложенными на него, и при этом (простите мой французский) аж ссытся, так хочет кем-нибудь поруководить. Обычно не упускает возможности дать коллегам понять, что главный здесь - он, а также зарисоваться перед начальством. Такому человеку доверять руководство людьми опасно - у него нет к этому природных способностей, и частично помочь здесь сможет специализированное обучение, опыт и внутренняя дисциплина.
• "человек-рыба" также хорошо выполняет все поставленные задачи, но другими людьми склонен не интересоваться, не заинтересовывать, не развивать. Обычно стремится большой объем работы выполнить сам, мотивируя тем, что у команды мало опыта. Такому человеку доверить руководство также можно только после предварительных упражнений.

Я бы мог перечислить еще много смешных типажей, но это - тема отдельного поста. Хорошее упражнение - попробовать посмотреть на свое поведение в офисном ареале со стороны, непредубежденным взглядом. Очень важно понимать свои недостатки в этой области, иногда они - причина того, почему вас не повышают. Как правило, с ними вам придется бороться на протяжении всей карьеры, поскольку они (в отличие от предыдущих четырех пунктов) - часть вашей личности. Вы хотите руководить людьми до судорог в коленках? Скрывайте силу вашего желания, не дайте никому догадаться! Вы уверены, что знаете все лучше всех? Превозмогите себя, дайте вашим коллегам шанс - пусть они сделают не так идеально, но зато приобретут опыт, и т.д.

3. ОТКЛОНЕНИЯ

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

• повышение произвел некомпетентный руководитель. Либо он (руководитель) пострадает из-за этого и отменит такое повышение, либо ПМ "натыркается" и будет сносно выполнять свои ежедневные обязанности, тем не менее лажаясь каждый раз, когда от него потребуется что-то, что выходит за круг его привычных задач (написать proposal для нового заказчика, выступить с презентацией на ежегодном собрании и т.д.)
• повышение произвел компетентный руководитель. В этом случае он (руководитель) принимает все риски, связанные с таким назначением, и возможно выполняет часть работ за своего ПМа. Такая ситуация возможна, когда:
• руководитель держит бразды правления в своих руках, отдавая ПМу рутинные технические задачи (распределение тасков между людьми, сбор индивидуальных отчетов и подготовка проектного отчета, написание / ревью технических требований и т.д.) О реальной власти ПМа в такой ситуации речь не идет - однако это может быть ловко замаскировано более опытным руководителем и подано молодому ПМу под правильным для него соусом из манипулятивных утверждений и обещаний.
• Другой вариант развития событий: руководителю нужен реальный ПМ, нанимать "готового" с рынка для компании экономически нецелесообразно, поэтому новый ПМ целенаправленно взращивается в реальных условиях. Это возможно при соблюдении требований 2.2, 2.3, [2.4], 2.5 из списка выше. При этому руководитель ПМа все так же несет ответственность за проект, готов придти ему на помощь в случае необходимости и в целом верит в него.
• компания понимает под ПМом что-то принципиально другое, чем то, что понимаю я. Мне встречались случаи, когда ПМами называли себя фактические продакт-менеджеры, сейлзы или аналитики. Скорее всего, ПМ в таком случае будет бесконечно далек от PMBOK.

4. ВЫВОДЫ

Чтобы стать ПМом, обязательно нужен инженерный опыт. Софт-скиллы (управление людьми, конфликтами, изменениями, ведение переговоров, навыки проведения презентаций и т.д.), как правило, приобретаются уже на новой должности (либо на должности тим/тех-лида при более дальновидной политике компании). В дополнение к опыту обязательна инициатива в смысле желания делать больше. Очень важны процессы (и да, agile - это процесс). Кроме того, важно знать свои недостатки, которые могут помешать вам в управлении людьми, и вести с ними постоянную борьбу.

Иногда можно увидеть в кресле ПМа дятла. Несмотря на то, что этому, как правило, можно найти объяснение, ответьте себе на вопрос: а вы - дятел? При желании можно придумать, как нацепить на себя лейбу ПМа, что будет служить формальным подтверждением вашей власти. Однако власть - это всего лишь одна из мер карьерного роста, и лейба ПМа не заменит содержания ПМа. Быть хорошим ПМом в средне- и долгосрочной перспективе гораздо выгодней, чем плохим:

• вы не теряете связи с инжинирингом, который развивается очень быстро
• вы сможете больше делать, брать на себя больше ответственности, ваша работа будет интересней
• вы не теряете возможности повышения зп. Хороший ПМ развивается на своей должности, плохой - держится за нее и за свой узкий круг обязанностей, внутри которого он чувствует себя комфортно, а снаружи - нет
• хороший ПМ пользуется уважением коллег, плохой - нет, его обсуждают за глаза, из-за него достается на орехи начальству
• у плохого ПМа нет перспективы роста (количества подчиненных, получения новых проектов и т.д.).

В общем-то, можно быть и дятлом в кресле ПМа. Главное - не обманывать себя. Удачи!

Project Management Plan Hell

В нашем центре разработки существует обязательная практика написания Project Management Plan'а (PMP) для каждого проекта. Под РМР у нас понимают документ объемом около 20-30 страниц следующего содержания:
- Scope проекта (milestones, deliverables, assumptions, constraints и т.д.)
- организационные диаграммы: внутренняя + интерфейсы на стороне заказчика
- планы по управлению рисками, требованиями, изменениями, схема эскалации проблем
- методики оценки проекта, планы верификации и тестирования, процедуры приемки задач и пр.
- план-график проекта
- цели качества и контролирующие их метрики
- план обучения персонала
- и т.д.

От каждого (условно) project manager'а в обязательном порядке требуется:
- составить такой документ (с учетом проектных задач, которые никто не снимает - 2-3 недели)
- провести ревью внутри команды с привлечением инженера по качеству, учесть замечания (если в команде человек 10-15 - 1 неделя)
- провести еще одно ревью с участием руководителя группы качества и сайт-менеджера и утвердить РМР на нашей стороне (с учетом занятости таковых - 2 недели)
- утвердить документ с ПМ'ом на стороне заказчика (с учетом занятости такового - 2 недели)

В общем итоге, составление и утверждение РМР занимает около 2 месяцев. За это время, разумеется:
- изменяется scope проекта, появляются новые задания и активности
- изменяется состав команды (кто-то приходит, кто-то, возможно, уходит)
- сдвигается план-график
- уточняются цели качества, изменяется набор метрик
- люди обучаются, план обучения также эволюционирует.

Все эти изменения требуют обязательного переутверждения РМР с проведением внутрикомандного ревью, что занимает около 6 недель. Таким образом, имеем:
- постоянно отстающий от реальности РМР
- постоянный цейтнот в связи с необходимостью его переутверждения (многие на это забивают, получая в результате другие проблемы: либо необходимость обманывать группу качества, декларируя соответствие реальности фактические устаревшего РМР, либо необходимость отбиваться от руководства, требующего переутверждения РМР).

Пути решения могут быть, например, такими:
- упрощение процедуры переутверждения РМР
- упрощение содержания РМР
- отказ от РМР.

Ага?

Настройка микрофона в Skype 2.1 под Ubuntu 10.04

У меня ноут Acer Aspire 3935, и я только что победил PulseAudio-микрофон в Skype!

Решение, которое мне помогло:

1. Устанавливаем pavucontrol:

sudo apt-get install pavucontrol

2. Запускаем pavucontrol, переключаемся на вкладку "Input Devices". Убеждаемся, что ползунки "Front Left" и "Front Right" движутся синхронно. В этом и проблема: в ноуте моно-, а не стерео-микрофон. Поэтому нажимаем кнопку "Unlock" и левый устанавливаем на 90%, а правый - на 10%.

После этих манипуляций у меня все заработало.

"Толстые" дороги в SLD

Для отрисовки карт в нащих плагинах к uDig, мы используем Styled Layer Decorator (SLD).

На прошлой неделе я решал проблему отрисовки дорог шириной более 1 пикселя. Вот как оно выглядело изначально:



Очевидные проблемы:

1. Отрисовка перекрестков. На перекрестках дорог видно не соединенные между собой окончания сегментов.
   
2. Взаимное наложение дорог. При слишком близком расположении, дороги хаотически взаимно перекрываются. Особенно это заметно, опять же, на перекрестках. Кроме того, в левом верхнем углу заметно, что сегменты двух дорог (со стрелочками) также поочередно перекрываются.

SLD обеспечивает настройку правил для отрисовки дорог с помощью LineSymbolizer:

<sld:LineSymbolizer>
 <sld:Stroke>
  <sld:CssParameter name="stroke">#00ff00</sld:CssParameter>
  <sld:CssParameter name="stroke-opacity">1</sld:CssParameter>
  <sld:CssParameter name="stroke-width">1</sld:CssParameter>
  <sld:CssParameter name="stroke-linejoin">round</sld:CssParameter>
  <sld:CssParameter name="stroke-linecap">round</sld:CssParameter>
 </sld:Stroke>
</sld:LineSymbolizer>

Предполагается, что, управляя параметрами linejoin (miter, round, bevel) и linecap (butt, square, round), можно добиться желаемого эффекта. Например, в статье "GeoServer render OpenStreetMap" приводится реальный SLD-стиль, использующийся для отрисовки OSM. Как видно из примеров, хороших результатов удалось добиться только для мелких масштабов; при приближении становятся видны артефакты перекрестков и назойливые "сосисочные" окончания дорожных сегментов.

Продолжив поиски и поэкспериментировав с параметрами LineSymbolizer, я сделал вывод, что возможностей SLD для отрисовки таких "толстых" дорог, какие у нас были изначально (8-14 пикс.) попросту недостаточно. Уменьшив ширину до 2-6 пикселей и выставив linecap = butt, linejoin = miter, я получил такой результат:



Цвета я поменял на более близкие к Google Maps, но это не принципиально.

Кроме этого, заметил следующее:

1. Для отрисовки направлений движения GeoServer в стиле tiger.sld использует TextSymbolizer, печатающий "стрелочку":
   

   
   <sld:Label>
       <ogc:Literal>←</ogc:Literal>
   </sld:Label>
   

   
   Однако, я столкнулся с тем, что стрелочка у меня непредсказуемо переворачивается (очевидно, это зависит от направления вектора, представляющего дорогу, относительно базовой точки). Поэтому направление движения я задаю с помощью LineSymbolizer, отрисовывающего стрелочку попиксельно.
   
2. Управлять порядком отрисовки дорог с помощью разных Rule внутри одного FeatureTypeStyle толком нельзя, поскольку GeoTools применяет эти правила в непредсказуемом порядке. Я вынес правило для отрисовки каждого из типа дорог в отдельный FeatureTypeStyle, после чего они стали отрисовываться в порядке, указанном в моем SLD.

На этом я пока что и остановился.

Поёт Михаил Анчаров

Илья СЕЛЬВИНСКИЙ

ВОР

Вышел на арапа. Канает буржуй.
А по пузу – золотой бамбер.
– «Мусью, скольки время?» –
Легко подхожу...
Дзззызь промеж роги!! – и амба.

Только хотел было снять часы –
Чья-то шмара шипит: «Шестая».
Я, понятно, хода. За тюк. За весы.
А мильтонов – чертова стая.

Подняли хай: «Лови!» – «Держи!..»
Елки зеленые!! Бегут напротив...
А у меня, понимаешь ты, шанец жить, –
Как петух недорезанный, сердце колотит.

Заскочил в тупик: ни в бок, ни черта.
Вжался в закрытый сарай я...
Вынул горячий от живота
Пятизарядный шпайер:

– «Нну-ну! Умирать – так будем умирать!
В компании таки да веселее...»
Но толпа как поперла в стороны, в мрак
И построилася в целую аллею.

И я себе прошел, как какой-нибудь ферть,
Скинул джонку и подмигнул глазом:
– «Вам сегодня не везло, мадамочка Смерть?
Адью до следующего раза!»

1922

Яндекс-цвет

Пусть здесь полежит

Dallas Clayton, "Very Awesome Book"

There are places in the world
Where people do not dream…
Of rocket-powered unicorns
And candy cane machines
Of magic watermelon boats
And musical baboons
Or teeny tiny trumpet players
Training pet raccoons
Yes there are places in the world
Where people dream up dreams
So simply un-fantastical
And practical they seem…
To lose all possibility
Of thinking super things
Of dancing wild animals
With diamond-coated wings
Instead they dream of furniture
Of buying a new hat
Of owning matching silverware
Could you imagine that?
Instead they lay awake at night
Wishing for a car
Not one that runs on jellybeans…
But one that’s reg-u-lar
They dream of breakfast sandwiches
They dream of telephones
Sometimes they even dream of dreams
That aren’t even their own
Yes there are places in the world
Where dreams are almost dead
So please my child do keep in mind
Before you go to bed
To dream a dream as big
As big could ever dream to be
Then dream a dream ten times as big
As that one dream you see
Then once you’ve got that dream in mind
Please dream a million more
And not a million quiet dreams
A million dreams that roar!
A million dreams so loud they scream
So loud they sing and shout
So super huge they say
“Hey world! Guess what I’m dreamin’ bout”
“I’m dreaming about everything
that no one thought to wonder
Dreams so big that they’ve got dreams
And they’ve got dreams up under!”
Please dream for those who’ve given up
For those who’ve never tried
Please use your dreams
To make new dreams
For all the dreams that died
Cause you’re the one whose dreams can be
Whatever dreams you want
Whose dreams can change the way things are
And the way that things are not
And if they say that all your dreams
Are too big to come true
You tell them that I told you…
“That’s what dreams are meant to do!”
They’re meant to make you seem as if
You don’t know up from down
Because dreams are dreams and that’s why
Dreams are worth having around!
So when you think your dreaming’s done
Just remember what I said
“close your eyes my child
and dream
that perfect dream
inside your head”

Отсюда: http://www.veryawesomeworld.com/awesomebook/inside.html