The Advantage: Organizational Health Model

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

Топ 5 качеств хорошего менеджера

1. Развивай каждого своего подчененного.
2. Решай проблемы сразу же, как они поступают.
3. Спасай самого худжего своего подопечного.
4. Помогай другим, не себе.
5. Помни кто ты и кем ты был.

Российский нацстандарт по управлению проектами

Проект российского национального стандарта по управлению проектами прошел этап публичного обсуждения и передан на утверждение в Федеральное агентство по техническому регулированию и метрологии, говорится в сообщении компании PM Expert.

Работа над созданием российских национальных стандартов в области проектного управления ведется с 2008 г. специалистами Автономной некоммерческой организации "Центр стандартизации управления проектами", учрежденной компаниями PM Expert и ГК "Проектная Практика".… полный текст на сайте CNews

На мысль натолкнули:
CNews

Руководитель проекта и руководитель программы: в чем отличия?

Having a good program manager is one of the secret formulas to making really great software. And you probably don’t have one on your team, because most teams don’t.

Хороший руководитель программы - один из секретов формулы успеха. Но, скорее всего, у Вас его нет; потому что его, как правило, нет в большинстве команд.

Joel Spolsky [...]

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

Давайте сначала взглянем на вопрос с точки зрения науки.
Что нам говорит PMI:

1. Цели проектов — получение осязаемых результатов (deliverables); Цели программы — улучшение бизнеса.


2. Менеджер проекта управляет исполнителями; Менеджер программ руководит менеджерами проектов.


3. Управление проектами может включать в себя управление расходами (project cost management); Управление программами может включать в себя управление как расходной, так и доходной частью программы (Program financial management)

Безусловно, руководитель программы отвечает за более широкий спектр задач, чем руководитель проекта. По сути, руководитель программы управляет руководителями проектов. Но, что более важно, работа руководителя проекта заканчивается с выпуском продукта (например, программного продукта). А работа руководителя программы зачастую не заканчивается даже после распространения, внедрения и начала получения прибыли от разработанного продукта.

Вот почему Джоэл так высоко ценит роль руководителя программы.

И, конечно, Джоэл прав, далеко не каждая компания (даже среди тех, кто производит конечный продукт, а не продает сервис) создает ячейку "руководитель программы" в своей организационной сетке. Зачастую, по причине того, что эту роль берет на себя топ-менеджеры. И хорошо, если одной программой руководит один человек. В противном случае задачи делятся по департаментам. И успех можно достичь, только если все департаменты работают, как слаженный механизм (швейцарских часов). А если нет - то в какой-то момент, кто-то потянет одеяло на себя, повышая качество своей работы за счет других. И этого, боюсь, не избежать.

Позиция руководителя программы в белорусских реалиях предоставления сервиса оффшорной разработки очень редка. Тем не менее, она не исключена.
Уровень доверия некоторых заказчиков доходит до того, что роль руководителя программы делегируется на сторону исполнителя. Да, это возможно! Конечно, такая схема взаимодействия не может не наложить ограничения на исполняемые функции. И, тем не менее, набор основных обязанностей и задач заставляет мыслить иначе.

...it's wonderful to see that most industries realize the importance of focusing on program and project managers as key to their organizational success, and not just as a role.
Kyle A. Mabin, program manager, consumer electronics for Intel Corp. [...]

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

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

Раз уж коснулся статей Джоэла Спольски, то сошлюсь на еще одну - "Две истории", где описывается 2 подхода к управлению. Вот небольшой отрывок:

В Juno куча менеджеров, примерно четверть от общего количества сотрудников, и большую часть времени они занимаются тем, что суют свой нос всюду, куда могут дотянуться, и контролируют всё, что поддаётся контролю. Разительный контраст с Microsoft, где для того, чтобы подтвердить твои полномочия в принятии решений могут запросто выгнать вице-президента.

Удачи и не ошибайтесь с целями!

P.S.: И в заключении, еще немного информации о зарплатах руководителяей программ в ведущих компаниях США:

зарплаты в известных компаниях (взято с Glassdoor Salary)

Спасибо:
Wikipedia: Управление программами.
Joel on Software: How to be a program manager.
PMI Blogs: Voices on Project Management. Elevating the Project Manager's Role.

Не нарушайте правила

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

Не задавайте два разных вопроса в одном письме.
Ответ получите только на один, на который проще (удобнее) ответить.

Когда это правило можно нарушить?

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

В таком случае, в нити другой (например, технической) переписки можно задать вопрос касательно основной проблемы (то есть задать два разных вопроса вместе). Если получите ответ только по техническим вопросам -- значит, скорее всего, над вашей проблемой вряд ли работают. И нужно быть extra pushy, чтобы решить задачу.
А если над проблемой, все-таки, работают. То очень вероятно, что ее статус будет обновлен.


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