Chaos Management: 2008

пятница, 17 октября 2008 г.

Конференция «Сложности внедрения проектного управления»

Привет.

Краткий анонс.

27 октября 2008 года состоится конференция «Сложности внедрения проектного управления», организуемая компанией “Богданов и партнеры”. Участие в конференции бесплатное, по предварительной записи.

Краткое описание целей конференции с сайта компании:

Развивайте Ваши навыки управления проектами!

Цель данной конференции - представить некоторые практические идеи в области управления проектами и дать вам несколько полезных инструментов и методов для применения этих идей в Ваших проектах.

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

Ознакомиться со списком докладов и зарегистрироваться вы сможете со страницы на сайте компании “Богданов и партнёры”: Конференция «Сложности внедрения проектного управления».


четверг, 16 октября 2008 г.

Почему важно понимать бизнес заказчика.

chaos Привет!

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

Уже больше года я руковожу рядом проектов в рамках одной программы, реализуемой для крупной российской компании, услугами которой пользуется, наверное, пятая часть населения страны. Один из проектов в рамках этой программы – разработка web-сайта для миллионной аудитории клиентов данной компании. Бизнес заказчиков этого сайта несколько: отдел маркетинга, отдел продаж, отдел работы с партнёрами компании и верхушка в лице нескольких заинтересованных лиц. И у всех этих заказчиков свои бизнес цели и, соответственно, свои требования к сайту и его функционалу. На выявление и документацию только бизнес требований всех заинтересованных сторон ушло два месяца очень и очень плотной работы – постоянные встречи, опросы, интервью, формулировка всего услышанного на бумаге и согласование. Я, как менеджер этого проекта, старался присутствовать на всех подобных встречах. Когда, наконец, все требования бизнеса были документированы и согласованы начался этап сбора функциональных и нефункциональных требований, но это отдельная история.

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

Через пару дней представитель отдела работы с партнёрами компании нашего заказчика звонит и говорит, что 1 ноября сайт должен работать кровь из носу и (внимание!!!) содержать новую функциональность, которая критична для партнёров. И сделать это нужно именно к 1 ноября, т.к. уже заключены ряд договоров с партнёрами компании. И в этих договорах прописаны пункты, согласно которым компания заказчика должна 1 ноября предоставить определённые сервисы клиентам партнёров посредством web-сайта, иначе – штрафы. С таким подходом (сначала заключаем договоры с указанием сроков, потом ставим в известность исполнителей), я думаю, встречались многие.

Что тут началось… Спонсор проекта со стороны заказчика звонит моему руководству и говорит, что 1 числа сайт должен работать и точка! Моё начальство звонит мне, предлагает взять в команду ещё людей, порвать тельняшки, ни шагу назад, за нами Москва и т.д. и за оставшийся месяц реализовать новую функциональность, провести полный цикл тестирования и установить сайт на пока отсутствующее железо =) Одним словом, запахло управленческим беспределом.

На предложение добавить людей в команду разработки сайта я сразу сказал “НЕТ!”. Согласно правилу Брукса, уже подтверждённому и моим опытом тоже, инъекция “неподготовленных” людей в проект разработки программного обеспечения, находящийся в завершающей фазе, лишь усугубляет ситуацию со временем окончания проекта. Это факт! Предложение “порвать тельняшки” в данном случае меня тоже не вдохновило, т.к. тельняшки рвать имеет смысл тогда, когда и менеджер и команда на 100% уверены в том, что после трёх недель работы по 14 часов в сутки они наверняка успеют и сделают то, что удовлетворит и их (команду разработки) и заказчика. Иначе, если три недели пота и крови заканчиваются разочарованием заказчика из-за нереализованных требований и неудовлетворённостью команды, общий моральных дух команды резко падает, желания работать и мотивация снижается ниже плинтуса. Хороший PM, на мой взгляд, никогда не должен допускать такой ситуации, т.к. люди в конечном итоге всегда важнее любых сроков.

Я сел и стал думать, что можно сделать, имея жёсткие временные ограничения, новые требования к функционалу и свободные ресурсы, не занятые на разработке сайта, но и не имеющие представления о проекте. В итоге, двигаясь в своих размышлениях снизу вверх, я дошёл до того, с чего, по-хорошему, нужно было начинать с самого начала. С бизнес требований данного конкретного заказчика. И подумав о бизнес целях, ещё раз их проанализировав, я понял, что отделу работы с партнёрами нужен на самом деле не сам сайт целиком, со всем его наполнением и возможностями, а только небольшая часть функционала, покрывающая потребности данного бизнес заказчика. Я прикинул, что если собрать, как пишет ДеМарко, “команду тигров” (команда из двух-трёх человек, способных “порвать” всё что угодно – реализовать любое сложное техническое решение в кратчайшие сроки =), то вполне можно реализовать до нужного срока отдельный сайт с ограниченным функционалом, который полностью покроет требования заказчика. Таким образом, минимизируются риски срывов сроков разработки, риски связанные с дальнейшими возможными проблемами с поставкой оборудования (т.к. этот небольшой сайт можно будет развернуть на существующем железе) и с переутомлением команды, занимающейся разработкой основного сайта. Красота =)

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

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

Лишь понимание того, для чего именно в конечном итоге нужен web-сайт отдельно взятому бизнес заказчику, позволило мне принять оптимальное, на мой взгляд, решение.

вторник, 30 сентября 2008 г.

Подача заявки на сдачу экзамена PMP. Часть 1.

Привет!

Мне уже не в первый раз приходят письма от читателей, в которых меня спрашивают как я подавал заявку на сдачу экзамена PMP, что собой представляет подтверждение опыта работы и подтверждение необходимого числа PDU (personal development units).

В этой заметке отвечаю на часть вопросов.

После регистрации на сайте http://pmi.org/ у вас появляется возможность подать заявление на сдачу экзамена PMP (см. стр. https://www.pmi.org/certapp/). Для этого необходимо перейти по ссылке “Apply for PMP Credential”, как показано на рисунке:

clip_image002

Затем в соответствующих разделах необходимо указать всю необходимую информацию:

clip_image004

Вам сразу предлагают ввести контактные данные (разделы “Contact Address” и ”Contact E-mail, Phone”). Тут всё просто и понятно. Заполнили данные на странице и нажимаете кнопку “Next” для перехода к следующему шагу. После того, как вы ввели свои контактные данные, e-mail и телефон, в разделе “Attained Education” необходимо указать ваше образование, год, когда получили диплом, название учебного заведения, его адрес и предметную область, в которой вы получили образование.

clip_image006Далее, в разделе “Requirements” на первой странице “ PMP Requirements Overview” вам подробно рассказывается о требованиях, которые предъявляет институт PMI к кандидатам на сдачу экзамена. Данные требования делятся на два раздела: “Project Management Experience” и ” Project Management Education” – требования к опыту работы в области управления проектами и требования к образованию в области управления проектами. На странице всё очень подробно и понятно написано. Я намеренно не пишу, сколько часов и месяцев требует PMI в данный момент от кандидатов, т.к. данные требования могут измениться.

На странице “Worksheet” представлена таблица, в которой вы всегда сможете посмотреть, сколько часов опыта и образования необходимо для подачи заявки и сколько часов вы уже подтвердили:

clip_image008

“PM Experience Months” – это длительность, а “PM Experience Hours” – это трудозатраты =) К примеру, вы могли последние три года работать в области управления проектами (PM Experience Months = 36), но т.к. совмещали должность менеджера проектов с должностью аналитика, то “PM Experience Hours” может быть значительно меньше необходимых 4500 часов или, если вы все три года на 100% работали PM’ом, то “PM Experience Hours” будет превышать 4500 часов.

Переходим к странице “PM Experience” и нажимаем на кнопку “Add Experience”. Далее для каждого проекта, в котором вы учувствовали, необходимо указать некоторые данные, которые вы будете вводить поэкранно, на каждом экране нажимая кнопку “Next” для перехода на следующий экран.

На первой открывшейся странице заполняем все поля, а именно: название вашей должности, даты начала и окончания проекта, ваша роль в проекте, предметная область проекта. Это просто =) Нажимаем “Next”. На следующей странице необходимо указать данные о компании, в которой вы работали над данным проектом: ваша должность в компании, название компании, адрес и телефон. Опять нажимаем кнопку “Next”. Настало время ввести контакты человека, с которым вы работали в этом проекте и который в случае необходимости (звонка из PMI) сможет подтвердить ваше участие в данном проекте. Необходимо указать имя человека, проектные “отношения” (заказчик, менеджер, участник и т.д.), контактные данные этого человека. Опять нажимаем кнопку “Next”.

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

InitiatingPlanningExecutingMonitoring and ControllingClosing
12%26%29%23%10%

Естественно, для разных проектов числа были разные, но в среднем получилось примерно столько, сколько указано в таблице.

Я описывал шесть своих проектов, некоторые из которых перекрывались во времени. В случае перекрывающихся по времени проектов, необходимо следить за тем, что бы по ошибке не вписать по 100% времени на каждый проект (получится, что в сутки вы работали по 16 часов, такое конечно бывает, но не на протяжении года =) Одним словом, нужно быть очень внимательным при заполнении часов по проектам, т.к. (как мне лично кажется) небрежно заполненные часы с явными несоответствиями могут привести к тому, что ваша заявка попадёт под аудит PMI и тогда всё значительно усложнится (об аудите я расскажу в отдельной заметке, если это будет интересно – пишите в комментариях).

Итак, когда вы внесли всю информацию по всем проектам, можно перейти к разделу “PM Education”, в котором необходимо указать название курса, имя провайдера обучения (компании, в которой вы проходили обучение – она должна быть зарегистрированным провайдером обучения в PMI), даты начала и окончания курсов, количество фактических часов обучения (Hours) и количество часов, которые идут в зачёт PDU (Qualifying Hours). Я проходил курсы в компании PMExpert и в поле “Course Title” указывал не только название курса, но и его код, который указан на выданном сертификате.

После того, как вы закончили вносить информацию об образовании в области управления проектами, вам осталось совсем немного: раздел “ Optional Information” можно в принципе пропустить, можно и заполнить, на ваше усмотрение; в разделе “ Certificate” необходимо указать своё имя в точности так, как оно потом будет указано на вашем будущем сертификате; в разеделе “Agreement” вам предлагают ознакомиться и согласиться (или не согласиться) с соглашением; в разделе “Review & Submit” вам покажут сводную таблицу по всем предыдущим разделам и в случае, если что-то осталось незаполненным – укажут на это.

clip_image010

Если всё заполнено и вся введенная информация верна, ставьте галку “All information that I have provided is accurate and complete” и нажимайте кнопку “Submit Application”. Ваша заявка уходит на рассмотрение.

PMI обработал мою заявку за четыре дня, сообщив по ранее указанному мной e-mail о положительном результате. После того, как ваша заявка была рассмотрена и принята, вы можете записываться на экзамен!

Стоит отметить, что заполнение данных заявки может происходить не в один присест. Т.е. сегодня вы можете заполнить данные об образовании, завтра внести данные об одном проекте, на следующей неделе о другом и т.д. Все данные, которые вы указываете, после нажатия на кнопку “Next” или “Submit” сохраняются на сайте, и вы в любое время можете их изменить или дополнить. Так что пока вы не поставили галку на пункте “All information that I have provided is accurate and complete” и не нажали кнопку “Submit Application” – всё можно отредактировать.

Вот собственно и всё. Ничего сложного. Если возникнут вопросы – пишите в комментарии, с удовольствием отвечу!

Удачи!


четверг, 4 сентября 2008 г.

PMBOK Guide 4ое издание – как оно влияет на ваш экзамен

pmbok3 Привет!

В этой заметке привожу свой вольный перевод статьи “The PMBOK Guide 4th Edition - What it means for your Exam”, которая опубликована в блоге Корнелиуса Фихтнера, PMP (Cornelius Fichtner, PMP). Оригинал статьи можно прочесть здесь.

Автор: Cornelius Fichtner, PMP
Перевод: Алексей Павлов, PMP

PMBOK Guide 4ое издание – как оно влияет на ваш экзамен

Ранее в этом году Project Management Institute (PMI) выпустил предварительный вариант PMBOK® Guide 4th edition. Вот что PMI пишет о данном предварительном варианте: “Все глобальные стандарты PMI были выработаны общими усилиями, учитывая знания, мнения и опыт типичных проектных команд, экспертов и других профессионалов в области управления проектами. Период публичного обсуждения предварительного варианта является критичным для достижения консенсуса”. Сразу после выпуска предварительного варианта PMBOK® Guide 4th edition PMI по всему миру начал собирать обратную связь от менеджеров проектов. Эта обратная связь будет (или не будет) включена в новый вариант руководства.

Я ожидаю, что официальный выпуск четвёртого издания PMBOK® Guide произойдёт в декабре 2008 года. Для меня, как для PMP-тренера, это означает, что я начинаю получать письма, содержащие два типа вопросов. Первый тип вопросов приходит от моих действующих студентов, которые обеспокоено спрашивают о том, как выход новой редакции PMBOK® Guide повлияет на предстоящий экзамен PMP. Они хотят знать придётся ли им сдавать экзамен, основываясь на выходящем PMBOK® Guide 4th edition. Второй тип вопросов поступает от моих бывших студентов, которые совсем недавно стали PMP. Они задают один из двух вопросов: “Придётся ли мне пересдавать экзамен?” либо “Значит ли выход новой редакции руководства то, что у меня будет “устаревший” сертификат PMP?”

Ответ на все три вопроса: Нет. Далее приведены детальные ответы:

Вопрос: “Придётся ли мне сдавать экзамен на PMP по новому PMBOK сразу после его выхода?” Ответ: Нет. Оглядываясь назад мы видим, что всякий раз, когда PMI выпускает новую версию PMBOK Guide, они устанавливают некоторый временной интервал, в течении которого экзамен на степень PMP основывается на предыдущей версии руководства. Это период составляет 8-10 месяцев. Я бы ожидал вступления в силу “нового” экзамена на PMP где-то между августом и сентябрём 2009 года. Точнее будет известно, когда PMI объявит официальную дату. Всем, кто подал заявку на экзамен до официальной даты вступления в силу “нового” экзамена, будет позволено сдавать “старый” экзамен.

Вопрос: “Придётся ли мне пересдавать экзамен?” Ответ: Нет. Вам не требуется пересдавать экзамен PMP до тех пор, пока не пройдёт трёхлетний срок после которого необходимо подтверждать степень PMP, как это указано в PMI's Continuing Certification Requirements Program. Ваша степень PMP продолжает быть действительной.

Вопрос: “Значит ли выход новой редакции руководства то, что у меня будет “устаревший” сертификат PMP?” Ответ: Нет. Текущая версия PMBOK Guide никак не влияет на статус вашей степени PMP. Я сдавал экзамен на степень PMP в 2004 году, и я не являюсь “PMP второго издания”. Я просто PMP. Вы можете сравнить это со своим университетским дипломом. Вы получили диплом несколько лет назад, а учебная программа много раз поменялась с тех пор. Ваш диплом и степень PMP действительны сейчас так же, как были действительны после того, как вы сдали экзамен.

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

вторник, 2 сентября 2008 г.

Архитектура есть всегда!

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

<Разработчик встревоженно>: У нас на проекте нет ни одного документа, описывающего архитектуру! У нас и архитектуры никакой нет!
<Архитектор филосовски>: Архитектура есть - просто она очень простая...

Думаю, IT-шники шутку поймут =)


А у вас есть usability-аналитик?

analytics Привет!

Случилось так, что у нас в компании временно не стало usability-аналитика (человека, проектирующего интерфейс взаимодействия пользователя и разрабатываемого продукта). Аналитика не стало (он жив, просто сменил место работы =), но проекты идут своим чередом и запросы на изменение текущих требований и внешнего вида разрабатываемых продуктов продолжают приходить от заказчика, как и прежде. Раньше я, как менеджер проектов, в которых всё это происходит, регистрировал запрос, проводил первичный анализ, ставил задачу usability-аналитикам, затем принимал работу у аналитиков и вместе с командой разработчиков оценивал трудозатраты на реализацию доработки или изменения, а затем согласовывал оцененное изменение с заказчиком. Сейчас, когда не стало единого источника экспертного мнения относительно пользовательского интерфейса и взаимодействия пользователя с системой, всё изменилось.

Сейчас, принимая запрос на изменение (change request) от заказчика, я сам занимаюсь usability-анализом, постановкой задачи дизайнерам (раньше с дизайнером взаимодействовал usability-аналитик), аудитом результатов его работы и конечной приёмкой работ дизайнера.

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

Что происходит, когда программисты проектируют интерфейс взаимодействия человек-машина хорошо и печально известно. Когда этой работой занимается менеджер проекта – результат не столь плачевен, т.к. менеджер ориентирован (должен быть) на удовлетворение заказчика. Но менеджеры всё же не аналитики и результат моих трудов, как usability-аналитика тоже на мой взгляд не удовлетворителен, даже не смотря на то, что мне часто приходилось выступать в роли не только бизнес- но и usability-аналитика. Проектирование взаимодействия, так же как и проектирование архитектуры системы, требует от человека сосредоточенности, погружения в т.н. “поток”. Только в таком состоянии приходят по-настоящему блестящие идеи и решения.

У руководителей проектов, так же как у программистов, дизайнеров и аналитиков, так же есть состояние “потока”, в котором их производительность и результативность сильно возрастает, но это совсем не тот “поток”, который нужен для работы над одной конкретной задачей. У меня в ежедневнике на каждый день записано десяток задач, каждую секунду в голове крутится ещё 3-4 и ежечасно возникают задачи, которые невозможно запланировать, но нужно решать прямо сейчас, не откладывая. В таком режиме, когда переключение между задачами происходит иногда по три раза в минуту, спроектировать действительно хороший сценарий взаимодействия невозможно.

Я знаю, что во многих компаниях считается, что иметь аналитика пользовательского интерфейса и usability-аналитика – это роскошь. Я сам работал в таких компаниях, где менеджерам приходилось самостоятельно проводить бизнес-анализ, затем анализ функциональности, затем usability-анализ и анализ внешнего вида системы, прорисовкой прототипов рабочих экранов и написанием спецификаций. Я сам всем этим занимался и знаю, что все эти задачи менеджер может сделать хорошо… но не блестяще. Сейчас мне крайне некомфортно, если в команде проекта нет выделенного аналитика, т.к. я точно знаю, что удобство использования будущего продукта, будь то сайт или десктопное приложение, значительно ухудшится при отсутствии такого рода эксперта. А значит, понизится лояльность конечного пользователя и заказчика, что с финансовой точки зрения гораздо “дороже” для компании, чем один эксперт в области usability в штате или на контракте.

Очень хорошо, на мой взгляд, проблемы отсутствия проектирования взаимодействия человек-система описаны в книге Алана Купера “Психбольница в руках пациентов”, которая была написана в 1998 году, но которая останется актуальной ещё очень-очень долго. Всем менеджерам и техническим директорам рекомендую.

Вопрос к тем, кто дочитал до конца – как у вас в компании обстоят дела с разного рода аналитикой? Кто ей занимается – специально обученные люди (эксперты-аналитики) или те, на кого падёт перст начальства или у кого есть время?

 

пятница, 29 августа 2008 г.

Ещё одна причина для проведения ежедневного SCRUM-митинга

2007.12.12_forum Привет!

В своих текущих проектах, количество разработчиков в которых не превышает пяти человек, я применяю один из инструментов, позаимствованных из методологии SCRUM. Это, так называемые, SCRUM-митинги (SCRUM-meetings).

SCRUM-митинг – это, обычно, ежедневное короткое, как правило не более 15 минут, совещание на котором члены команды рассказывают прежде всего друг-другу, что они сделали за вчерашний день, что собираются делать сегодня и какие у них возникли проблемы. Проблемы и темы для обсуждений фиксируются и обсуждаются уже в дальнейшем среди тех, кто заинтересован в этих вопросах, не отнимая тем самым время у остальных участников встречи. Таким образом, всего за 15 минут общения происходит очень эффективный обмен информацией. И это действительно так. Более подробно о методологии SCRUM и нюансах SCRUM-митингов можно прочитать в различных публикациях в Internet.

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

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

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

Всё вышесказанное относится к небольшим командам (до 7-9 человек по моему опыту). Если участников становится больше, то временные “накладные расходы”, возникающие при таких ежедневных встречах, могут свести на нет положительный эффект от них.

Одним словом, пробуйте, сравнивайте, выбирайте!

P.S. Мы свои SCRUM-митинги проводим сидя, а не стоя, как рекомендуется в литературе по SCRUM =)

Удачи и хороших выходных!


понедельник, 25 августа 2008 г.

Тонкости прохождения экзамена на степень PMP от Rita Mulcahy, PMP

В своей книге по подготовке к сдаче экзамена PMP Rita Mulcahy даёт советы, которые на её взгляд, помогут успешно пройти экзамен PMP. Я в свободной форме, но близко к тексту перевёл эти советы:

  1. Ключом к ответам на вопросы PMI является:
    • Объективное понимание материала. Не думайте, что данный экзамен проверяет память; он проверяет знания, практический опыт и умение анализировать! Вы должны понимать части этой книги (моё прим.: Рита пишет о своей книге, в которой приведены эти советы), как они используются в реальном мире и как они работают при взаимодействии друг с другом.
    • Иметь реальный опыт использования всех основных инструментов и методов управления проектами.
    • Прочесть PMBOK Guide.
    • Понять области знаний, которым PMI придаёт особое значение (моё прим.: PMI-isms, не знаю, как адекватно перевести, разве что PMI-измы =)
    • Быть хорошо знакомыми с типами вопросов (моё прим.: которые встретятся на экзамене).
    • Практиковаться в интерпретации двусмысленных вопросов и вопросов с большим количеством информации.
    • Практиковаться в выборе ответа среди, казалось бы, двух или трёх правильных ответов.
    • Привыкнуть к мысле о том, что на экзамене будут вопросы, на которые вы не сможете ответить.

  2. Контролируйте экзамен, не давайте ему контролировать вас. Что вы почувствуете, если, прочитав первый вопрос, вы не будете знать на него ответ? Если тоже самое случится со вторым вопросом? И с третьим? По многим причинам это может случиться! Вот что нужно делать. Если вы не можете сразу дать ответ на вопрос, используйте функцию Mark for Review и вернитесь к нему позже. Это будет означать, что ваш первый проход по вопросам экзамена будет очень быстрым. Теперь вы более подготовлены? Представьте, как хорошо вы будете себя чувствовать, когда всё, что вам останется сделать – это просмотреть несколько вопросов, которые смутили вас ранее. Запомните это. Это может послужить большим облегчением для вас на экзамене.

  3. Контролируйте ваше волнение. Вы можете быть не согласны с некоторыми вопросами на этом экзамене. Вы так же можете быть удивлены тому, сколько вопросов вы пометили для последующего просмотра. Если вы всё ещё думаете о вопросе 20, в то время как достигли 120 вопроса, то вы получите 100 вопросов, о которых вы недостаточно хорошо подумали. Побеспокойтесь о том, что бы контролировать своё волнение.

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

  5. Первым делом среди представленных в вопросе слов выделите сам вопрос (зачастую им является последнее предложение), затем прочтите остальную информацию. Отметьте тему, о которой идёт речь в вопросе и ключевые слова (например, “за исключением”, “включая”, “не является примером…”). Это поможет вам понять, о чём спрашивается в вопросе и уменьшит потребность в повторном чтении вопроса. Определите, каков должен быть ваш ответ и только потом смотрите на представленные варианты ответов.

  6. Одна из основных причин, по которой люди отвечают неверно - это то, что они не читают все четыре варианта ответа. Не допускайте этой ошибки! Практикуйтесь читать вопрос и все четыре варианта ответа, когда готовитесь к экзамену. Лучше всего практиковаться в чтении вариантов ответов с конца (сначала D, затем C и т.д.). Такого рода практика позволит вам выбрать ЛУЧШИЙ ответ.

  7. Практикуйтесь быстро исключать ответы, которые являются очевидно неверными. Многие вопросы имеют только два наиболее вероятных варианта ответа и два очевидно неверных варианта.

  8. Может быть более одного “правильного” ответа на каждый вопрос, но только один “ЛУЧШИЙ” ответ. Практикуйтесь в поиске ЛУЧШЕГО ответа.

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

  10. Были предприняты попытки сделать все варианты ответов примерно одной длинны. Поэтому не следуйте старому правилу гласившему, что наиболее длинный вопрос является правильным.

  11. Были затрачены усилия на использования в вопросах “отвлекалок” – выделяйте то, что отвлекает вас от правильного ответа. Это могут быть внешне правдоподобные варианты ответа, которые могут выбрать слабо подготовленные люди. Такие отвлекающие вещи могут привести к тому, что может показаться, что у некоторых вопросов есть два или более правильных ответов. Многим людям кажется, что есть лишь тень разницы между вариантами ответа. Обращайте внимание на такого рода вопросы, когда практикуетесь в ответах на экзаменационные вопросы.

  12. Обращайте внимание на такие слова, как “первый”, “последний”, “следующий”, “лучший”, “никогда”, “всегда”, “за исключением”, “не является”, “наиболее вероятно”, “наименее вероятно”, “в первую очередь”, “изначально”, “наиболее” и т.д. Удостоверьтесь в том, что вы внимательно прочитали вопрос и заметили эти слова, иначе вы ответите на вопрос неверно! На экзамене будет много вопросов, которые потребуют от вас понимания процессов управления проектами и их применение в реальном мире.

  13. Остерегайтесь вариантов ответа, которые являются истинными утверждениями, но не являются ответом на поставленный вопрос.

  14. Остерегайтесь вариантов ответа, которые содержат общие ошибки в области управления проектами. Они намеренно используются, что бы определить действительно ли вы знакомы с управлением проектов. Поэтому, вы можете не знать, что ответили на вопрос неправильно! Следите за своими ошибками и практикуйтесь по мере чтения этой книги. (Смотрите лист “Общие ошибки и заблуждения в управлении проектами” в конце этой главы.)

  15. Варианты ответа, которые представляют собой обобщения, как правило, бывают неверными, так что следите за словами “всегда”, “никогда”, “должны”, “полностью” и так далее. С другой стороны, варианты ответов, которые являются аккуратными и компетентными, являются, как правило, правильными, так что следите за словами “обычно”, “иногда”, “может быть”, “возможно” и ”в общем”.

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

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

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

  19. Не ожидайте, что в помещении, где вы будете сдавать экзамен, будет тихо. Студент с моего курса PMP Exam Prep в течении трёх часов сдавал экзамен под звуки оркестра, игравшего под окнами тестового центра. Другие студенты рассказывают о том, что рядом с ними сдавали экзамены, которые требовали интенсивного печатания на клавиатуре. Многие тестовые центры имеют наушники, подавляющие шум (моё прим.: я брал с собой ушные затычки, продающиеся в аптеках).

  20. Следите за т.н. “rah, rah” (моё прим.: я так понял, что это что-то типа нашего “вах, вах” =) вопросами (например, “Менеджер проекта так важен”, “ИСР так важна”).

  21. Хорошенько расслабьтесь и выспитесь в ночь перед экзаменом. НЕ УЧИТЕСЬ! Вам потребуется время, что бы обработать всё, что вы выучили, для того, что бы вспомнить это на экзамене.

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

  23. Возьмите с собой что-нибудь перекусить! Вы не сможете взять еду с собой в комнату, где будет проходить экзамен, но осознание того, что еда рядом, может облегчить муки голода (моё прим.: ох уж эти американцы, четыре часа без еды и начинаются невыносимые муки голода =).

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

  25. Используйте всё время экзамена. Не уходите до тех пор, пока не просмотрите каждый вопрос дважды.

  26. Помните, что это нормально изменять ответы, если у вас есть на это весомые причины.

  27. Создайте план прохождения экзамена и придерживайтесь его. Это может значить “Я передохну 10 минут после каждого 50-ого вопроса потому что я быстро устаю”, или “Я отвечу на все вопросы как можно быстрее, а потом передохну и снова просмотрю свои ответы”.

Вот 27 советов по прохождению экзамена PMP от Риты, под большинством из которых я сам готов подписаться! Материал взят из книги “PMP Exam Prep” Fifth edition by Rita Mulcahy, PMP. Перевод мой, художественный.



пятница, 15 августа 2008 г.

Пятница – день отчётов

chart Привет!

Сегодня пятница. У меня пятница - день отчётов.

Я сейчас руковожу одновременно четырьмя “горячими” проектами. Под термином “горячие” я понимаю проекты, по которым ведётся очень активная деятельность, на которые направлены пристальные взоры начальства и заказчиков. По всем четырём проектам заказчики и начальство требуют от меня разного рода отчётность с разной периодичностью. По пятницам я всегда (ну… почти всегда) стараюсь выдавать заказчику отчёты в стандартной форме. Я верю в то, что периодическая отчётность является очень полезной практикой (даже если эти отчёты читает только менеджер со стороны заказчика) и вообще улучшает карму любого PM’а =)

Три из четырёх проектов я веду (пытаюсь, во всяком случае) по методологии SCRUM – очень много запросов на изменения от заказчика, очень короткие итерации, заказчик максимально вовлечён в процесс. По этим трём проектам заказчик требует минимум отчётности (или не требует вовсе), т.к. он и так постоянно в курсе того, что происходит, знает, куда уходит время и деньги. Именно поэтому по этим трём проектам отчётом, как правило, является краткое письмо, резюмирующее проделанные за неделю работы или даже пятиминутный разговор по телефону или Skype’у.

Четвёртым проектом я управляю по классической методологии описанной в PMBOK – проект разбит на фазы, объём работ на каждую фазу зафиксирован, запросы на изменения (change requests) обрабатываются согласно ранее принятому регламенту, форма отчётности по утилизации ресурсов зафиксирована... На этом проекте заказчик не так активно вовлечён в процесс разработки продукта, поэтому количество информации в отчётах о прогрессе проекта должно быть больше, нежели в предыдущих трёх.

Сам отчёт состоит из двух частей – календарный план проекта (в формате MS Project) и собственно описание текущего статуса (в MS Word).

С календарным планом в MS Project все, в общем-то, понятно, а вот про описание статуса стоит поговорить.

Практика показывает, что чем меньше отчёт, тем выше вероятность того, что заказчик вообще будет его читать. Поэтому я умещаю все отчёты на одну страницу, при этом пишу всё предельно простым языком. Отчётность по освоенному объёму (earned value) – это очень здорово, но, если честно, я не встречал ещё заказчиков, которые требовали бы такой отчётности и понимали разницу, к примеру, между CPI и SPI. Освоенный объём можно и нужно использовать, но до заказчика лучше доносить фразу “Мы опережаем график работ на 10% от планируемого!!!”, чем “Вууухуу! На этой неделе SPI = 1.1!!!” =)

Сам лист отчёта я разбиваю на четыре части:

  1. Шапка, в которой описано по какому проекту данный отчёт, кто его составил, когда, и за какой период.
  2. Раздел “Прогресс проекта за отчётный период”, в котором обычными словами описываю, что именно произошло в проекте за отчётный период. В этом разделе я пишу только то, что может быть интересно и полезно заказчику и что он сможет понять. Т.е. фраза “Реализована страница, а так же соответствующий функционал, позволяющий пользователям входить в систему, используя свой логин и пароль” предпочтительнее, чем “Реализовали DAL и GUI для авторизации”.
  3. Раздел “Текущие вопросы и проблемы. Способы их решения/предотвращения”. В данном разделе озвучиваются произошедшие риски, описываются их последствия, а так же озвучиваются наиболее актуальные угрозы и благоприятные возможности (threats and opportunities) и способы их предотвращения и усиления соответственно.
  4. Раздел “Последующие шаги на следующий отчётный период” описывает планы на следующий отчётный период.

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

Всем удачного окончания рабочей недели!

четверг, 14 августа 2008 г.

К нас снова приезжает Эдвард Йордон

Я уже однажды писал о приезде Эдварда Йордона в Россию и о том, кто это такой (если кто-то не знает).

В сентябре он снова приезжает. На этот раз в Санкт-Петербург и Москву.

Москва, 26 сентября: “Человеческий фактор в разработке ПО: Привлечение, мотивация и удержание ключевых сотрудников. (Peopleware: Recruiting, Motivating and Retaining Key IT Professionals)”.

Москва, 27 сентября: “Полевые учения. Моделирование динамики проектов разработки ПО. (Software War Games: Dynamic Modeling of Software Projects)”.

Санкт-Петербург, 22 сентября: “Человеческий фактор в разработке ПО: Привлечение, мотивация и удержание ключевых сотрудников. (Peopleware: Recruiting, Motivating and Retaining Key IT Professionals)”.

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

Членам PMI предоставляется скидка.

понедельник, 11 августа 2008 г.

Мой высокоуровневый план подготовки к сдаче на PMP

Привет! В этой заметке я опишу высокоуровневый план подготовки к сдаче экзамена на степень PMP, который, с моей точки зрения, является достаточно эффективным.

Ссылки на материалы, которые я буду упоминать, можно найти в предыдущей статье.

Итак…

  1. PMBOK Guide Third Edition: Внимательно прочитать PMBOK вплоть до 77 страницы – до Главы 4, Управление интеграцией проекта.

  2. PMBOK Guide Third Edition: Выучить наизусть (ВНИМАНИЕ – ЭТО ОЧЕНЬ ВАЖНО!!!) таблицу 3-45 на стр. 70 (“Соответствие между процессами управления проектами и группами процессов управления проектом и областями знаний”). Эта страница – фундамент дальнейшего обучения. Это карта, которая в дальнейшем позволит не запутаться в процессах, входах и выходах 44-х процессов. Чем раньше вы выучите данную таблицу, тем лучше. Эта таблица станет первым memory dump’ом, который вы будете использовать на экзамене. Выучить данную таблицу достаточно просто (хотя с первого взгляда так не кажется). Очень полезно (и необходимо!) раз в пару тройку дней воспроизводить эту страницу на чистом листе по памяти.

  3. PMBOK Guide Third Edition: Внимательно прочитать Приложение F (стр. 337) – “Краткое изложение областей знаний по управлению проектами”.

  4. PMBOK Guide Third Edition: В ознакомительном режиме, быстро прочитать остальную часть PMBOK, т.е. не стараясь запомнить входы, выходы, названия и определения.

  5. PMBOK Guide Third Edition: Распечатать, разложить по квартире, в сумки и рюкзаки и постоянно почитывать Глоссарий (разделы “Принятые сокращения”, стр. 348 и “Определения”, стр. 350).

  6. Затем прочитать книгу “PMP Exam Prep” Fifth edition by Rita Mulcahy, PMP. Важно проходить все тесты и выполнять все задания для каждой главы.

  7. После первого прочтения книги Риты необходимо заново от начала до конца прочитать PMBOK. Весь. Целиком. На этот раз, внимательно читая определения, обращая внимания на входы, выходы, инструменты и методы.

  8. Затем снова, с самого начала необходимо прочитать книгу “PMP Exam Prep” Fifth edition by Rita Mulcahy, PMP. Снова пройти все тесты. Очень важно прочитать эту книгу несколько раз, т.к. с каждым прочтением элементы “мозаики” УП встают на своё место.

  9. Параллельно пунктам 7 и 8 необходимо проходить все доступные тесты. Из коммерческих я очень рекомендую программу Project Management IQ 9.0, в которой есть более тысячи вопросов по всем областям знаний, несколько режимов (в том числе и режим экзамена), а так же объяснения и комментарии к ответам.
    Так же есть множество бесплатных ресурсов, в которых можно найти много тестовых вопросов. При прохождении тестов очень важно записывать, в каких именно областях знаний и группах процессов у вас есть пробелы. Какие именно вопросы вызывают у вас затруднения. Какие определения для вас незнакомы. Всё это лучше записывать в специальную рабочую тетрадь. Далее, при повторном прочтении PMBOK, книги Риты или любой другой подготовительной литературы, необходимо уделять особое внимание тем областям, в которых у вас имеются пробелы.

  10. Будете смеяться, но опять нужно от начала и до конца прочитать PMBOK. Внимательно! Уделяя особое внимание пунктам в вашей рабочей тетради, которые возникли после прохождения тестов.

  11. И в последний раз прочесть “PMP Exam Prep” Fifth edition by Rita Mulcahy, PMP.

  12. Параллельно пунктам 6-11 полезно читать различную подготовительную литературу (я читал книгу М. Ньюэла, см. предыдущее сообщение), а так же слушать обучающие подкасты (я выбрал Project Management PrepCast by Cornelius Fichtner, PMP – лучший, на мой взгляд, подкаст для подготовки к экзамену PMP, к тому же дешёвый, всего 49$).

  13. Хотя бы раз до экзамена сесть и пройти тест из 200 вопросов в режиме экзамена, т.е. без подсказок, обращений к справочному материалу и долгих пауз. Засечь, сколько на это понадобилось времени и когда возникала необходимость в отдыхе. Я отдыхал 5 минут после 90-ого вопроса, 5 минут после 180-ого и 5 минут после 200 перед тем, как пройтись по всем отмеченным мной в процессе экзамена вопросам.

  14. Создать второй memory dump (первый – это таблица со стр. 70 PMBOK, о которой я говорил в п. 2). Второй memory dump будет содержать все (или почти все) необходимые формулы, которые могут понадобиться на экзамене. Зачем именно нужен memory dump я расскажу в одной из следующих заметок, а так же выложу свою версию memory dump’а с формулами.

Вот 14 пунктов, каждый из которых можно разбить, детализировать и сделать календарный план, с датами начала и окончания работ по каждому из пунктов. Менеджеру проектов, имеющему реальный опыт работы, достаточно, на мой взгляд, двух месяцев для подготовки по данной программе, что бы сдать на PMP, тратя на подготовку четыре часа в день, включая прослушивание подкастов по пути на работу и домой. Для кого-то это время может быть больше, для кого-то меньше.

Если будут вопросы – пишите в комментарии! Удачи!

четверг, 7 августа 2008 г.

Новости PMI

Привет!
Несколько новостей от PMI, с которыми можно ознакомиться как на сайте PMI, так на сайте pmexpert.ru
  1. Программа подтверждения аттестата РМР (Continuing Certification Requirements program — CCR)

    В PMI существует программа Постоянных Требований Сертификации (Continuing Certification Requirements program — CCR), которая поддерживает непрерывное образовательное и профессиональное развитие лиц, получивших аттестат РМР и/или РgМР.

  2. PMI® внедряет степень профессионала по управлению расписаниями — Scheduling Professional (PMI-SP)

    Project Management Institute (PMI®) разработал рекомендации для специалистов по расписаниям, работающих в проектных командах. Новая сертификация называется PMI Scheduling Professional (PMI-SP)SM.

  3. PMI® внедряет степень профессионала по управлению рисками — Risk Management Professional (PMI-RMP)

    PMI® объявил о внедрении новой степени для менеджеров проектов, специализирующихся в управлении проектными рисками, которая называется PMI Risk Management Profesional (PMI-RMP).
Материал взят из рассылки pmexpert.ru

среда, 6 августа 2008 г.

Материалы для подготовки к сдаче на PMP

Привет.
В этой заметке я расскажу о материалах, которые я использовал для подготовки к сдаче на PMP.
  1. Книгу “PMP Exam Prep” Fifth edition by Rita Mulcahy, PMP
  2. Подкаст Project Management PrepCast (подкасты для подготовки к сдаче на PMP) by Cornelius Fichtner, PMP.
  3. Бесплатные тесты, доступные в Интернет.
Этих материалов, на мой взгляд, вполне достаточно, что бы человеку с реальным опытом управления проектами подготовиться к сдаче на степень PMP за минимальное время.

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

На сам экзамен я записался примерно два месяца назад (т.е. за два месяца до экзамена). Составил план и начал готовиться. В день я занимался примерно час-полтора и то, преимущественно в дороге от дома до работы и обратно: читал книгу Риты, слушал подготовительные подкасты Карнелиуса… Одним словом, готовился я неспешно. За две недели до сдачи я оценил пробелы в своих знаниях и перешёл в режим ускоренной подготовки: час-полтора в день я слушал подкасты, пока был в дороге, и три часа по вечерам тратил на прохождение тестов и чтение. За день до экзамена я отложил все обучающие материалы и дал мозгу время расслабиться. В четверг, 31 июля я успешно сдал экзамен и стал PMP.

О том, как именно, на мой взгляд, эффективнее всего готовиться к сдаче на PMP я расскажу в следующей заметке, в которой приведу высокоуровневый план подготовки.
Если есть вопросы - задавайте!

суббота, 2 августа 2008 г.

PMP passed

Здравствуйте!

Меня можно поздравить, в этот четверг (31 июля 2008 г.) я успешно сдал экзамен на степень PMP! )

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

Так же я могу выложить свой т.н. 'memory dump', который я готовил специально для экзамена, если это кому-то поможет.

А сейчас - принимаю поздравления! =)


среда, 28 мая 2008 г.

Пять основных рисков при разработке ПО

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

1. Внутренние изъяны календарного планирования. 40%
2. Изменение требований. 35%
3. Отсутствие разработчиков (болезнь, отгул, т.д.). 10%
4. Нарушение (двусмысленное понимание) спецификации. 10%
5. Низкая производительность разработчиков. 5%

Так же, каждый PM может добавить ещё полторы сотни уникальных рисков, присущих их проектам =)



четверг, 8 мая 2008 г.

Конференция PM Days 2008

28 мая 2008 года в Москве пройдёт первая международная конференция PM Days 2008.

Главное отличие PM Days - что она создана менеджерами для менеджеров и Вам не придется полдня слушать как хорошо внедрять продукт компании X..Z. Обсудим как реально драйвить команды, использовать факапы по назначению :-) И многое другое...”

Официальный сайт: http://www.pmdays.ru/
Программа: http://www.pmdays.ru/programm/

P.S. 27 мая 2008 года в Москве пройдёт третья международная конференция SQA Days 2008, на которую приглашаются специалисты по тестированию и обеспечению качества программных систем, а также другие заинтересованные лица. Конференция посвящается вопросам, связанным с тестированием и обеспечением качества веб-приложений.


четверг, 10 апреля 2008 г.

John van Eiken о ловушках, подстерегающих руководителей различных уровней

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

В итоге, мы отлично пообщались, поделились различными фишками и успешными практиками.

Плюс ко всему мой коллега снабдил меня схемой (см. далее) и на следующий день прислал несколько аудио-файлов, в которых John van Eiken рассказывает об основных ловушках, которые подстерегают руководителей всех уровней в их профессиональной деятельности. Я вчера прослушал все эти файлы и нашёл для себя кое-что интересное и полезное, о чём раньше даже не задумывался.

Выкладываю эти файлы одним архивом: John van Eiken.zip

А вот и сама схема (кликабельна):





пятница, 4 апреля 2008 г.

Метод обучения новых сотрудников

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

Такой метод обучения применялся ещё индейцами – молодой индеец жил с уже опытным своим соплеменником на протяжении какого-то времени и просто повторял все действия, которые делал его наставник. На охоте, в быту, в ритуалах. Таким образом постигалась мудрость предков =)

Хорошая, в принципе, идея! Есть же в XP парное программирование (практическое воплощение которого я, правда, пока ещё не видел своими глазами =)

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

Если у кого-то есть подобный опыт – поделитесь плз.


среда, 2 апреля 2008 г.

Новая система online управления бизнесом (проектами)

Коллеги прислали ссылку на новый русский проект, позволяющий управлять небольшим предприятием и/или проектом. Проект ещё молодой и функционирует в demo-режиме. Но обещает быть очень даже привлекательным с точки зрения функционала и простоты использования. Так что, возможно, скоро русскоязычный народ слезет с Basecamp’а =)

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

Основная часть «Мегаплана» - это инструмент для постановки и контроля выполнения задач — «Таск-менеджер».

На сайте А.Лебедева можно прочитать более подробный обзор и посмотреть скриншоты (ссылка).




Ежедневные митинги в стиле SCRUM

Один из проектов, который я сейчас веду - это небольшой (вернее маленький) проект по разработке ПО для одной крупной российской компании. Проект короткий – всего пара месяцев. Делаем не с нуля, а переделываем то, что уже было сделано нашей компанией для зарубежных компаний. Т.е. кастомизируем уже существующий софт под нужды заказчика, параллельно занимаемся локализацией. Не суть. Смысл в том, что есть чёткое понимание того, что должно быть в итоге, но чёткого ТЗ, в котором собраны все требования, как такового нет – оно формируется в процессе разработки. Такой вот своеобразный fast tracking =)

Так вот, на проекте работают два разработчика, архитектор, тестировщик и я, менеджер проекта и локализатор в одном лице =)

Решил попробовать на этом проекте методику SCRUM-митингов. Т.е. ежедневных собраний, продолжительностью не более 15 минут, на которых каждый участник команды отвечает на три вопроса: что было сделано вчера, что будет сделано сегодня и какие имеются проблемы. Я не ожидал, что эти собрания окажутся настолько эффективными. Раньше, в других проектах, когда одних разработчиков было 5-7 человек, плюс тестировщики, аналитики, архитектор и дизайнер – такие собрания были невозможны, т.к. на это уходило бы масса времени. А при маленькой команде – это то, что надо. Все проблемы вскрываются сразу же, нет такого, что разработчик сидит, пыхтит над проблемой, которая возникла у него во вторник и о которой все узнают только в пятницу на еженедельном статус митинге. К тому же о всех флуктуациях требований к реализуемой функциональности все участники проекта узнают как только они появляются.

Единственное отступление от заповедей SCRUM’а, которое я сделал – это позволил обсуждать проблемы на наших ежедневных митингах. В SCRUM-митингах проблемы только озвучиваются, а разбираются уже за рамками встречи, что бы не отнимать времени у всех участников. В случае маленького проекта и кол-ва участников меньше 5 человек можно себе позволить небольшие обсуждения.

Очень рекомендую прослушать подкаст (podcast) Рона Хологана, PMP (Ron Holohan, PMP) с сайта http://pm411.org/ под названием “Managing effective meetings (part 2 of 2)”, в котором он подробно рассказывает о такого рода собраниях. Очень рекомендую!



вторник, 1 апреля 2008 г.

Mindomo – бесплатный online аналог MindManager

Наткнулся сегодня на такой замечательный сервис в Internet, как Mindomo. Это немного упрощённый, но вполне функциональный вариант MindManager’а, которым пользуются многие PM’ы.

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

Одним словом, очень удобный сервис, на мой взгляд!

Вот пример.


четверг, 27 марта 2008 г.

Зелёный свет

Я писал в прошлой заметке о том, что заказчик был очень недоволен сроками, указанными в предварительном плане проекта, который я ему предоставил. На этой неделе у меня состоялось несколько телефонных разговоров с менеджером заказчика. Я объяснял, почему всё так выходит, и объяснял про связь стоимости, качества и времени.

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

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

В итоге, обдумав и оценив ситуацию, заказчик принял решение:
1. Сделать нас генеральными подрядчиками.
2. Увеличить бюджет в несколько раз.
3. Бюджет теперь будет выделяться по схеме “time and material”, т.е. не за человеко-часы, а за кол-во людей занятых в проекте умноженное на их полное рабочее время. Это очень радует! =)
4. Теперь ответственность за все проекты, реализуемые в рамках данной программы, лежит на нас.

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

Такие вот дела… =)

четверг, 20 марта 2008 г.

“Это НЕПРИЕМЛЕМО!!!”

Сегодня подготовил и отправил менеджеру заказчика календарный план первого этапа проекта. Объём работ был согласован, состав команды проекта утверждён, дело оставалось, по сути, за продолжительностью работ. Ok, составил график, согласовал и отредактировал с командой, всё отлично. Отсылаю менеджеру со стороны заказчика и через 2 минуты получаю в скайп: “Это НЕПРИЕМЛЕМО!”

Вот так вот. Никого не интересует реальность. Народ хочет пожить сказкой, а когда показываешь реальность, тебе говорят, что это неприемлемо =) Забавно, это уже не первый мой проект, который я оцениваю, и я нутром чую, что та дата, которая указана в колонке Finish – реальна процентов на 70. Т.е. даже с учётом летних отпусков разработчиков, задержек со стороны подрядчиков и наших задержек, с учётом основных рисков и того, что мы до сих пор не учли и не учтём - мы таки можем успеть к указанной в плане дате, если хорошо поработаем. Даже неумолимая статистика, которую я веду последние два года по всем своим проектам (собираю метрики до и после), говорит о том, что вероятность успеть раньше этого срока – крайне невелика.

И вот, блин-горелый, в который раз первые слова, которые приходится слышать после обнародования действительно реального плана – это “Это НЕПРИЕМЛЕМО!!!”.

Назначил на понедельник встречу по поводу обнародованного плана. Даже интересно, согласится ли заказчик с указанной датой, увеличит бюджет или урежет функциональность… Время покажет ;)


среда, 19 марта 2008 г.

Эдвард Йордон (автор книги “Путь камикадзе” она же “Смертельных марш”) приезжает в Россию!

Эдвард Йордон, автор Смертельного марша или Пути камикадзе (в оригинале “Death march”), планирует провести в Москве и Санкт-Петербурге семинар «Управление безнадежными проектами» (“Managing Death-March Projects”).

Семинар обещает быть очень интересным! И не только для менеджеров проектов, но и для команд разработчиков.

О самом семинаре можно подробнее прочитать тут.

Стоимость: 11 350 р. Действуют скидки.

Примечательно, что посещение семинара даёт 8 PDU.



Пять основных рисков в программных проектах

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

Сейчас я составляю высокоуровневый календарный план (вернее его заготовку), который потом будет уточняться и согласовываться со всей командой. После оценки трудозатрат на первую итерацию я заложил 10% на риски и 10% на управленческий резерв. При защите плана проекта перед спонсором необходимо обосновать каждый пункт плана, т.к. заказчики деньги считают. Для обоснования времени, выделенного на риски данной фазы я взял 5 основных рисков программных проектов, описанных в книге Тома ДеМарко и Тимоти Листера “Вальсируя с медведями: управление рисками в проектах по разработке программного обеспечения” и проанализировал их с точки зрения вероятности возникновения и возможного урона при наступлении события риска. Вот список этих рисков с моими комментариями в скобках:

  1. Внутренние изъяны календарного планирования (подразумевается, что нет идеальных планов и в любом случае, что-то пойдёт не так, этот риск является одним из основных).

  2. Изменение требований (заказчик захотел “зелёный бант” и что бы “оно пело и плясало” в середине проекта).

  3. Текучесть кадров (можно его назвать ещё просто – Кадры и в качестве подпунктов включить Текучесть кадров и всякого рода Отпуски, неожиданные отгулы, болезни и т.д. – так я и сделал).

  4. Нарушение спецификаций (имеется ввиду двусмысленное их понимание. Т.е. есть описанная в спецификации функциональность, которая утверждена заказчиком. Заказчик думает, что под этой функциональностью подразумевается одно, а команда проекта подразумевает другое. И обе стороны могут даже не догадываться о различиях в понимании… пока не наступит фаза приёмки =)

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


Очень рекомендую всем, кто ещё не занимается управлением рисков в своих проектах, оценивать хотя бы эти пять основных рисков. Это очень освежает =)

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


вторник, 18 марта 2008 г.

Видео уроки по подготовке к PMP

В одном из подкастов Корнелиуса услышал о коротеньких (5-10 минут) видео-уроках, основанных на PMBOK. Данные видео-уроки можно смотреть прямо с сайта, для этого достаточно зарегистрироваться. Сами уроки бесплатные. Если ты готовишься к сдаче PMP, то, на мой взгляд, после обеда, вполне можно потратить минут 10-15 на просмотр данного материала.

Итак, идём и смотрим PMP® Exam Prep Lunchtime Lecture Series


понедельник, 17 марта 2008 г.

Заказчик и предварительные оценки

Предоставлять заказчику предварительные оценки трудозатрат по проекту – штука крайне опасная. С одной стороны эти оценки могут измениться раза в полтора, а то и в два (на то они и предварительные), с другой – эти оценки могут накрепко отложиться в голове у заказчика и он будет потом ими же вас и “шантажировать”. Вечная дилемма, о которой написано достаточно много, но “серебряной пули” до сих пор никто не изобрел, ибо заказчики каждый раз разные.

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

Эх, одна голова хорошо, а три лучше – пойду, всё же, посоветуюсь с коллегами =)

А вы в каком виде доставляете предварительные оценки до своих заказчиков, что бы в последующем эти оценки не сыграли против вас?

P.S. Кстати, полезная, на мой взгляд, книга о том, как можно оценивать малые и средние проекты: “Сколько стоит программный проект”, С. Макконнелл.


воскресенье, 16 марта 2008 г.

Диаграмма процессов управления проектами

На сайте Андрея Куликова, PMP (кстати, интересный сайт – советую покопаться!) нашёл картинку с диаграммной процессов управления проектами. В отличие от того, что можно найти в PMBOK, в данной диаграмме процессы сгруппированы по пяти фазам очень наглядно.

Данную диаграмму можно применять в качестве check list’а для себя и своих проектов. Я распечатал эту диаграмму и повесил на стену около рабочего места, подкрасив маркером те процессы, которые я уже интегрировал в свою практику управления проектами. Теперь, на любом из этапов моих текущих проектов (а их аж 4 штуки сейчас, о господи! =))) я буду смотреть на данную диаграмму и стараться закрасить ещё один её пунктик. Т.е. ещё на один процесс усовершенствовать свою рабочую методологию.

Конечно, применять в своих проектах всё то, что описано в PMBOK вот так сразу – сложно, да и не имеет смысла. Но об этом я напишу в другой заметке =)

А вот и сама диаграмма (кликабельно):

Источник: "Диаграмма процессов Риты".

Интересный подкаст Карнелиуса и Дины

На днях прослушал интересный подкаст известного многим Cornelius Fichtner, PMP, в котором он общается с так же многим известной Dina Henry Scott, PMP на тему управления проектами вообще, без привязки к какой-то определённой области знаний или методике. Вроде бы обычное бла-бла-бла между двумя PM’ами, но на мой взгляд очень интересное и местами смешное бла-бла =) Рекомендую для прослушивания в непринуждённой обстановке.

Итак, слушаем “Everyday, Real Life Project Management” с Cornelius Fichtner, PMP и Dina Henry Scott, PMP: прослушать.

пятница, 14 марта 2008 г.

Таймер обратного отсчёта

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

Как показала практика – это неплохо отрезвляет. Когда люди видят, что до часа Х осталось 28 дней, они начинают реально задумываться – а успевают ли они сделать то, что на них запланировал PM. Реакция команды на дату на счётчике – ещё один показатель состояния проекта для проницательного PM’а.

Подсказка: как показала практика, не стоит брать за дату отсчёта – дату планируемой сдачи продукта заказчику! Обычно между feature complete (реализацией всей функциональности и требований) и внедрением продукта есть ещё окончание тестирования, багфиксинг, стабилизация и т.д. Так что если разработчики будут видеть, что “До внедрения осталось 60 дней”, они будут к этому относиться иначе, чем если на счётчике будет что-то вроде “До конца разработки осталось 40 дней”.

Я пишу сколько дней осталось до окончания разработки маркером на доске и каждое утро обновляю счётчик. Дело секундное, а польза ощутимая!

четверг, 13 марта 2008 г.

Почему важно использовать email

Реальность ещё раз напомнила мне одну из истин из области управления проектами, которую вбивала в мою голову моя наставница.

“Запомни, юный друг, что когда ты общаешься с заказчиком относительно своего проекта, кто бы он не был твой заказчик, всегда и всё делай через email! В один прекрасный день это спасёт твой зад.”

Как же она была права…

Идея в том, что даже если ты, как pm, о чём-то договорился с заказчиком (его представителем) по телефону, в устной беседе или по аське/скайпу, то всё равно – не поленись, опиши всё это в письме и пошли ему с просьбой ещё раз формально всё это подтвердить.

А не то, будет как случилось недавно со мной – на протяжении достаточно долгого времени я добивался (в устной форме, при встречах, через скайп) подписания одного из проектных документов у одного из представителей заказчика (дружественная компания, знакомый менеджер). Он долго и упорно динамил меня под разными благовидными предлогами. Когда мне это надоело и я послал письмо с запросом с копией вышестоящему начальнику, то в ответ от того менеджера (естественно тоже с копией своему начальнику) получил примерно следующее: “Впервые слышу об этом документе!!!”.

Моя ошибка. Если бы я изначально общался бы с ним через почту, то впоследствии у меня были бы доказательства.

На этот раз ничего фатального не произошло, но я воспринял это, как звоночек!

Одним словом, ещё раз напоминаю себе слова моей мудрой наставницы: “Всё через письма!”.

среда, 12 марта 2008 г.

Подписывание документов

Всегда! Всегда подписывай все документы, по которым ведётся работа в проекте! Даже если заказчик - это дружественная компания и менеджер проекта со стороны заказчика твой хороший знакомый!

Как говаривала моя наставница: "Никому не верь! Даже мне! Если мой проект будет под угрозой и ради его спасения мне придётся тебя подставить - не сомневайся, я это сделаю!"

Она долго работала в большой корпорации, где крысиная возня и подковёрные игры были обычным делом. Это её закалило =)

Так что главный лозунг этой недели таков: «Подписанный документ – прикрытый зад!» =)

Начало

Привет всем!

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

Итак, поехали! =)