PM @ BY

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

2010-01-27T10:34:00.005+02:00

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

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

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

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

2009-11-19T22:03:00.007+02:00

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:

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

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

Управление проектами может включать в себя управление расходами (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.

Kick Off и что ему предшествует

2009-04-22T11:37:00.000+03:00

Когда-то читал статью о том, что HR гуглит соискателей на предмет обнаружения какого-либо интересного факта из их истории.

Люди по-разному относятся к этому. Кому-то (например тем, кто ведет блог с 15-летнего возраста) этот факт не очень по душе. И это понятно. Но, с другой стороны, если информация опубликована в интернете -- то она может быть прочитана. Google смотрит на этот вопрос вовсе радикально и считает, что понятия полной конфиденциальности личной жизни уже нет. На текущий момент представление гугла больше относится к США и западным странам...
Но статья немного не про это :)

Как вы начинаете работу на проекте? Гуглите ли вы контактные данные заказчиков?

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

А как же обратная сторона?
Будет ли кто-то счастлив, узнав, что информацию о нем тщательно собирали?
Уверен, что большинство отнесется к этому факту негативно.

Как тогда лучше поступить? С одной стороны стремимся построить прозрачные и взаимо-доверительные отношения, а с другой стороны делаем потенциальный шаг в сторону нарушения личного пространства.
Вот тут и приходит на помощь неформальное общение. То есть, по сути дела, ваша задача сделать так, чтобы вас добавили в свои контакты linkedin, facebook, чтобы заказчик делится с вами фотографиями и впеча
тлениями и т.д.
Продуманая тематика Small Talk также поможет завоевать доверие.

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

Оставайтесь на связи.

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

2009-03-30T13:49:00.005+03:00

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

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

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

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

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

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

Xobni. Инструмент обработки корреспонденции.

2008-12-23T11:00:00.005+02:00

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

В результате выяснил, что такой продукт есть. И, кроме всего прочего, он является хорошим помощником при активной работе с письмами. Xobni (Inbox наоборот). На главной странице Xobni опубликован отзыв Билла Гейтса о том, что Xobni -- это новый принцип построения социальной сети. "Bill Gates called Xobni the next generation of social networking."
Через 10 минут использования становится ясно почему это действительно так.

Xobni легко интегрируется в Outlook панелью справа. Это удобно на широкоформатных мониторах.

Эффективный поиск писем, контактов и связанных документов. Существенно отличающийся от стандартного поиска в аутлуке и в Google Desktop, поскольку используется другой принцип связи объектов.

Contact's Network. Интересная фича. Строит сеть контактов на основе переписки (кто кому писал и кто кого может знать).

Conversations. Список обсуждаемых тем (на основе заголовков сообщений).

Files Exchanged. Список файлов, которыми обменялись с выбранным контактом.

И практически все описанные возможности доступны при выборе темы переписки.

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

Статистика.
Собственно то, ради чего плагин устанавливался :)
Большой набор отчетов по различным критериям:
- количество писем по дням недели, по контакту, по времени суток, исходящих или входящих;
- усредненное количество писем в день/неделю за выбранный интервал времени;
- время ответа на письмо, среднее время ответа контакту;
- рейтинг пользователей;
- графики распределений;
- и так далее.

Например, время, затраченное на ответ (понимаешь наиболее эффективные часы своей работы) выглядит так:

Или количество писем за выбранный интервал времени, с разбивкой по неделям:

И много прочих полезностей и интересностей.

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

Project Management. Зачем нужны руководители проектов?

2008-12-02T17:37:00.003+02:00

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

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

Конечно, вопрос ответственности не самый простой. Но в рамках статьи в блоге можно разобраться, по крайней мере, с основными обязанностями.

Попробуем абстрагироваться от стереотипов, которые уже могли сложится, и вдуматься в название. Project manager -- это руководитель проекта. РУКОВОДИТЕЛЬ. ПРОЕКТА.
Ни слова о разработчиках :)

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

Все понимают, что с набором задач на фазы старта, планирования и завершения проекта все далеко не просто. Эти фазы многого стоят. Возможно поэтому на фазе разработки теряют бдительность (представляя, что здесь все тривиально) и "забывают" о контроле качества. Хотя и осознают, что это не менее важно, чем сама разработка.

Большинство компаний выполняют тестирование в рамках независимого сервиса -- отдельный департамент компании или даже внешний QA. Думаю, назначение менеджера со стороны QA и является ключевым фактором, почему проектный менеджер зачастую "снимает" с себя обязанности по контролю качества.

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

На мысль натолкнули:
http://dev.by/node/4009
http://en.wikipedia.org/wiki/Project_Management

Качество управления качеством. Отзвуки SQA Days 2008.

2008-11-19T18:46:00.006+02:00

Немного о качестве QA сервиса в Беларуси.

На днях в Минске впервые прошла конференция SQA Days 2008. Хороший знак. Теплится надежда, что качество белорусских проектов будет расти не только за счет усиленного и длительного баг-фиксинга, но и за счет качественного тестирования.

Что касается самой конференции, многие участники отметили слабую подготовку докладчиков. Красивые и громкие темы по сути являлись докладами на университетском уровне или даже ниже. Похоже многие выступления были только для строчки в CV. В основном это касается минчан :( Иностранные гости выглядели достаточно достойно (причины очевидны).

Неужели в Беларуси нет хорошего QA, с хороше теоритической и практической базой? Есть, но очень мало. Почему? Вижу 7 причин этого.

Лет 5-7 назад (когда возможностей было больше, чем желающих, и когда IT компании появлялись и росли не по дням, а по часам) все испытывали огромную нехватку специалистов, тем более грамотных. Так зарождался IT бизнесс в Беларуси.
Так как ресурсов не хватало, многие компании брались за обучение и выращивание грамотных специалистов. На вступительном собеседовании редко говорили "нет". Как правило, если кандидат не подходил, то ему либо предлагали более низкую зарплату, либо более "низкую" должность с перспективами роста. Наиболее типичный случай – это начать с QA, а затем перейти в разработчики.
Многие соглашались на такой вариант. И действительно, после освоения базовых процессов, переходили в разработчики. Так отдел QA лишался своих лучших кадров. Это причина №1.
Компании это было выгодно (разумеется, только в краткосрочной перспективе), поскольку ставка разработчика выше и его дороже продавали. О долгосрочной перспективе тогда еще не думали, да и сейчас далеко не все об этом задумываются. Причина №2.

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

Безусловно, это все наложило отпечаток на общественную оценку и рейтинг департамента QA. Многие (а нередко и сами тестеры) считали и считают, что QA не требует высокой квалификации. Как правило, тестирование в этом случае представляют только как monkey tests. Низкий рейтинг – причина №3.

Причина №4, или стеротип "QA – это для девчонок". Сейчас никто не будет спорить, что пол не важен при выборе IT профессии. Раньше мыслили иначе. Деятельность была разграничена по гендерному признаку. И, стало быть, QA был "не для всех".

После всех манипуляций -- кто остался работать в QA? Бывшие(?) студенты, которые не ушли в разработчики (хорошо, если по собственному желанию, а не потому, что не получилось). А те, кто уже с "опытом" (то есть давно работают в QA) -- переходят в управление. Это, конечно, специфично не только для QA, тем не менее, это причина №5.

Причина №6. До сих пор управление качеством, тестирование и т.п. не преподается в ВУЗах. Правда, некоторые компании уже начали привлекать своих сотрудников к чтению лекций для подготовки кадров. Но пока это больше похоже на "кружок любителей IT".

Причина №7. А где мне учиться, если я хочу стать классным специалистом QA? Конференции в Минске пока не дают того опыта и знаний, которые можно почерпнуть.

Каждый развивает себя сам, как умеет и как считает правильным.