Chaos Management

PMI-Agile Certified Practitioner (PMI-ACP)

noreply@blogger.com (Alexey Pavlov) — Tue, 28 Jun 2011 23:43:00 +0000

PMI начал приём заявок на сдачу экзамена на сертификат PMI-Agile Certified Practitioner (PMI-ACP). Первые экзамены начнутся в конце ноября этого года.
Доступны следующие материалы для подготовки:
✔ Review the PMI-ACP credential handbook.
✔ Review the PMI-ACP Examination Content Outline
✔ Review the current reference list for the PMI-ACP certification

Интересно, что будет с "сертификатами" от Scrum-альянса через года полтора-два?

- iЗаписка на ходу

Best practices check list

noreply@blogger.com (Alexey Pavlov) — Wed, 19 May 2010 07:34:00 +0000

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

После того, как некое улучшение было выбрано, опробовано и одобрено командой, мы «обкатываем» его ещё пару-тройку спринтов. После этого, если это улучшение нам действительно помогает и нравится, то мы переводим его в разряд best practices и переносим в отдельный список в Confluence проекта, который называется «Что прижилось и работает (продолжаем использовать)» =)

Т.к. best practices не являются священными и неприкосновенными, мы на каждой ретроспективе пробегаем по этому списку и:

Проверяем, что мы не забыли следовать практикам из этого чек-листа, а если забыли, то анализируем почему.
Обсуждаем (быстро-быстро), действительно ли каждая практика из этого списка всё ещё является «best» и если нет, то убираем её из этого списка.

Таким образом мы следуем принципам кайдзен, который, вообще говоря, «косо смотрит» на best practices в привычном их понимании.

Небольшой пример того, что у нас может попасть в список «Что прижилось и работает (продолжаем использовать)»:

Ограничить количество задач, которые могут находиться в состоянии WIP (N-1) - вынужденное парное программирование, нацеленность на скорейший резуьтат. Если фича в тестировании и найдена ошибка - переходит обратно в процесс, одна фича из процесса уходит (прокачиваем: уменьшение времени, необходимого для подготовки фичи к приёмки заказчиком на стейдже, коллективное владение кодом, кросфункциональность команды).
Деплой не может начаться позднее 15:00. Т.е. если заказчик требует внести изменения после 15:00 или до 15:00 не даёт отмашку на деплой - выкат переносится на следующий день. Это согласовано с заказчиком. Мы, в свою очередь, уведомляем заказчика о реализованных фичах сразу после их исполнения.
Дважды в неделю проводим технический standup meeting на котором каждый рассказывает про то, как именно он реализовал, реализует и собирается реализовать тот или иной функционал (архитектура, подход и т.д.). Командное ревью архитектуры и кода. Длительность не более получаса. Привлекаем разработчиков и архитекторов из других команд. Заранее планируем, чтобы люди приходили (прокачиваем: качество кода, коллективное владение кодом, кросфункциональность команды).
Деплойментом занимается каждый член команды по очереди и в паре с кем-то (прокачиваем: кросфункциональность команды).

Бэклог улучшений

noreply@blogger.com (Alexey Pavlov) — Wed, 19 May 2010 07:29:00 +0000

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

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

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

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

Небольшой пример того, что у нас находится в бэклоге:

В дополнению к фокус-фактору и качеству кода добавить ещё один показатель для оценки процессов - субъективную удовлетворенность работой команды.
Составлять план демо самостоятельно во время работы над спринтом каждым участником комманды.
Тренировка действия в случаях крит. ситуаций на проде.
Составить RoadMap по рефакторинга всего кода и выделению модулей из продукта.
Расшарить знания по JS - вернуть уроки по JS.

Презентация тест плана в начале каждой итерации

noreply@blogger.com (Alexey Pavlov) — Wed, 28 Apr 2010 10:00:00 +0000

Давно используем одну интересную практику в наших проектах – на следующий день после планирования очередной итерации тестировщик презентует всей команде тест-план на данную итерацию.

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

Данная практика способствует тому, что вся команда (и product owner, если он присутствует) одинаково понимает, что именно будет сделано и в чём суть каждой задачи. Так же снижаются риски связанные с поздним тестированием.

Метрики – качество оценки

noreply@blogger.com (Alexey Pavlov) — Tue, 27 Apr 2010 05:36:00 +0000

Одна из полезных метрик, которую мы собираем на проектах, которые идут у нас по SCRUM – это подсчёт отношения запланированного на реализацию задачи времени к реально потраченному на них времени.

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

Пример такие действий: выделение отдельной задачи на интеграционное тестирование или включение в историю задачи по предварительному исследованию предметной области.

Kanban – ещё раз о том, когда и где применять

noreply@blogger.com (Alexey Pavlov) — Wed, 18 Nov 2009 07:46:00 +0000

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

Недавно на сайте Константина Быченкова прочёл заметку под названием «Обратная сторона канбан», в которой Константин описывает то, что обязательно нужно учитывать при выборе данного подхода УП.

Согласен со всеми, что описал Константин в случае, если речь идёт о работе над проектом (в классическом его понимании). В этом случае решение о применении Kanban должно быть очень взвешенным и продуманным.

Но, хочу поделиться небольшим опытом применения Kanban в компании, в которой я сейчас работаю. Нам удалось успешно использовать Kanban на проекте, который больше похож на операционную деятельность: постоянные небольшие доработки уже внедрённого продукта. При этом заказчик хорошо знает, что он хочет, знает с какими ограничениями и рисками работает команда проекта, знает и принимает правила, по которым идёт “игра”, а главное, что между командой и заказчиком есть доверие. К тому же на этом проекте мы с заказчиком работаем по схеме "time and material", поэтому заказчик волен в любое время менять приоритеты своих запросов на изменения и доработку, а у разработчиков и менеджера нет истерии по поводу выхода за рамки бюджета или срыва сроков. Все довольны.

Так что применение Kanban, на мой взгляд, может быть вполне оправданным и эффективным в одних случаях, и крайне опасным и даже вредным в других… собственно, как и любой другой подход или методология УП =)

“Синтетические” методы оценки программных проектов

noreply@blogger.com (Alexey Pavlov) — Tue, 17 Nov 2009 09:52:00 +0000

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

В прошлой заметке я писал о том, что перед недавно созданным офисом управления проектами (PMO) были поставлены ряд задач. С задачами 1 и 3, а именно планированием ресурсов и переходом сотрудников из проекта в проект, мы временно разобрались. Вернее сделали первые простые шаги, в конце месяца по результатам сделаем корректировку.

Далее я решил замахнуться на то, что до меня так никто и не осилил – освоить, внедрить и научить других, применять одну из методик численной оценки программных проектов с которыми нам приходится работать (особенно на этапах пресейла, когда высокой точности достигнуть невозможно в принципе). Необходимость наличия такой методики я описывал в пункте 4 предыдущей заметки. Вообще говоря, для некоторых новых проектов, которые по своей сути были очень похожи на те, что мы уже реализовывали ранее с командой, и в которых технологические риски были минимальны, я вполне точно делал и продолжаю делать оценки на основании исторических данных. Зная производительность конкретно взятой команды, а так же метрические показатели других схожих проектов соотнесённые с фактическими трудозатратами и длительностью, получается достаточно точно оценить будущий проект (итоговое расхождение оценки и фактических затрат зачастую равняется +/- 10%). Но для проектов, в которых планируется использовать новые технологии, команда для которых ещё не сформирована и при этом приходится вникать в предметную область бизнеса нового заказчика, такой подход не подходит по понятным причинам.

Так вот… Собрал я всё PMO, помозгоштурмили, подумали с какого конца подойти к решению данной задачи и на каких методиках остановиться. В итоге решили следующее: взять три уже законченных проекта, по которым имеется хорошие исторические данные, а именно:

начальные требования заказчика в том виде, в котором они к нам поступили, когда мы делали оценку;
наша начальная оценка;
реальные трудозатраты и время, потраченное на реализацию и закрытие проекта с разбивкой по задачам и людям;
извлечённые уроки;

Каждый менеджер берёт по проекту (только не тому, над которым он сам работал) и на основании первоначальных требований от заказчика рассчитывают ожидаемую трудоёмкость по двум методикам: классический метод оценки по функциональным точкам и его модификация - Mark 2. Затем на очередной встрече PMO мы посмотрим как “синтетические” оценки соотносятся с оценками, сделанными нами ранее до начала проекта, а так же с фактическими результатами. По результатам такого сравнения и анализа того, как были сделаны “синтетические” оценки, можно будет откалибровать расчётные коэффициенты и, возможно, немного модифицировать методику под специфику наших проектов.

О результатах напишу позже.

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

Офис управления проектами - начало

noreply@blogger.com (Alexey Pavlov) — Tue, 03 Nov 2009 08:10:00 +0000

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

Совсем недавно меня назначили руководителем офиса управления проектами… В связи с этим передо мной возникла задача построения самого офиса управления проектами, т.к. до сих пор такой структуры в нашей компании не было. Исходя из всего того, что я читал про офис управления проектами (project management office или кратко PMO) я начал по методу набегающей волны разрабатывать планы по построению этого самого PMO внутри нашей компании.

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

Улучшить процедуру планирования ресурсов компании на ближайший месяц.
Т.к. часть проектов работает по схеме fixed price, а часть по time and material, необходимо очень чётко понимать, когда, кто и сколько будет работать на каком проекте и кто будет за него платить.
Собрать метрики по всем существующим проектам в одно место и привести их, по возможности, к единому виду.
Это значительно упростит и ускорит их использование при оценке новых проектов (пресейлы), а так же при извлечении уроков по проекту после его завершения.
Наладить надёжный процесс перехода работников из проекта в проект (от менеджера к менеджеру), что бы исключить ситуации, при которых разработчики, аналитики, тестировщики и т.д., закончившие работать над задачами в одном проекте, «простаивают» какое-то время из-за того, что не знают, чем им дальше заниматься. А такое хоть и редко, но случается.

Создать единую для компании методологию для оценки новых проектов.
Это нужно, прежде всего, для того, что бы на этапе пресейла минимизировать время, которое затрачивается ведущими разработчиками, архитекторами и менеджерами для оценки потенциального проекта. Порой на это тратится неоправданно много времени.
Наладить постоянный надёжный процесс обмена положительным и отрицательным опытом между всеми командами в компании.
Сейчас некоторые менеджеры после сдачи проекта проводят, как это называется в SCRUM’е, demo-показы, на которые приглашаются все желающие и на которых показывается продукт, над которым работала команда, рассказывается вкратце о его функционале, применённых технологиях, об успешном опыте и возникших проблемах. Думаю внедрить эту практику во всех командах.

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

С первым и третьим пунктом я уже начал разбираться и кое-что мы уже изменили и пробуем (посмотрим, как оно будет работать дальше). Остальным пока заняться не успел, т.к. никто не снимал с меня задачи менеджера проекта, так что я продолжаю заниматься всеми своими проектами, как говорится, «в полный рост» =)

Если у вас есть опыт по решению проблем, описанных мной в этих пяти пунктах – пишите, буду рад советам!

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

Конференция Software People 2009

noreply@blogger.com (Alexey Pavlov) — Wed, 27 May 2009 11:15:00 +0000

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

Недавно меня пригласили на конференцию Software People 2009, которая проходила 21-22 мая.

Если кратко, то лично я ожидал от этого мероприятия большего.

Мне понравился доклад, описывающий возможности Windows Azure для разработчиков, а так же перспективы использования Windows Azure для бизнеса.

После рассказа про возможности интеграции TFS с MS Project я понял для себя, что пока точно не буду использовать эти два продукта в связке – сыровато и неудобно.

Из доклада по Continues Integration узнал несколько полезных штук. Например, о том, что в систему автосборки можно вставить модуль от BlackDuck по проверке кода, используемых модулей и библиотек на предмет их лицензии – полезно для тех, кто разрабатывает коммерческие продукты при этом используя open source. Подробнее смотри на http://www.blackducksoftware.com/. Из того же доклада я почерпнул идею о т.н. fly builds. Идея в том, что перед тем, как система хранения кода разрешает разработчику сделать check in в общий репозиторий, проводится билд модуля, в который внесены изменения и в случае, если билд не прошёл, код не чекинится.

Доклад под названием “Эффективное определение и описание требований как необходимое условие успеха проекта” оказался обычной (по правде говоря, скучноватой) демонстрацией продукта IBM Rational Requirements Composer, который позволяет собирать требования и прототипировать GUI будущего приложения.

Было несколько рассказов и докладов по Agile, но ничего нового для себя на них я, к сожалению, не услышал.

Резюмируя, могу сказать, что скучно не было, но и ничего сверх интересного тоже.

С программой конференции, некоторыми материалами и презентациями можно ознакомиться на сайте http://www.softwarepeople.ru/

PMBOK Guide 4th Edition уже доступен в виде PDF файла для участников PMI

noreply@blogger.com (Alexey Pavlov) — Wed, 20 May 2009 12:21:00 +0000

Привет!

Всем зарегистрированным участникам PMI доступен полный PMBOK Guide четвёртого издания на английском языке. На русском – только часть.

Я уже скачал и уже читаю. Примечательно, что скаченный PDF-файл именной и запаролен моим паролем от сайта PMI.

Да, чуть не забыл, PMBOK Guide 4th Edition на английском, русском и других языках можно скачать отсюда:

http://www.pmi.org/Resources/Pages/Members/Library-of-PMI-Global-Standards-Projects.aspx

Скачивайте и наслаждайтесь (те, у кого есть доступ =)

SCRUM и XP - успехи внедрения и планы на будущее

noreply@blogger.com (Alexey Pavlov) — Tue, 19 May 2009 10:48:00 +0000

Привет!

Прошедшие два месяца занимались с командой переходом на “методологию” SCRUM. Не забавы ради, а по необходимости.

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

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

Проанализировав сложившуюся ситуацию мы решили – SCRUM спасёт отца русской демократии!

Начал я с того, что разослал всем членам команды на прочтение замечательную книгу “Scrum и XP: заметки с передовой”. Сам прочитал её три раза. Вообще говоря, эта книга в первый месяц была моей настольной и очень мне помогла не наступить на различные грабли, которые валялись то тут, то там на нашем пути ) Спасибо авторам и переводчикам!

В итоге мы успешно завершили два спринта, и я начал приучать наших заказчиков к периодичности выпуска версий – раз в три недели. Сейчас получается так, что я являюсь и SCRUM-мастером и product-owner’ом в одном флаконе. Собираю требования со всех стейкхолдеров, аккумулирую их, организую серию встреч на которых проставляется Важность каждого требования (user story). Затем, всё по писанному…

Более того, мне, наконец, удалось подвести команду к тому, что бы они сами предложили внедрить две замечательные, на мой взгляд, практики из экстремального программирования – парное программирование и TDD. Верите или нет, но у нас получилось внедрить парное программирование! =) Сам до сих пор поверить не могу =) С TDD тоже дело идёт на лад.

Следующая задача для меня – внедрить SCRUM в головы членов команды. Вот что я имею в виду. Раньше, при прежнем процессе, в команде было очень чёткое распределение ролей – дизайнеры, тестировщики, аналитики, архитектор, разработчики, менеджер. В случае, если аналитики что-то не успевали описывать для разработчиков или описывали не полностью, то разработчики кивали на аналитиков, дескать, они нам не подготовили, и сидели, ждали, когда будет обновлена спецификация (ТЗ). По SCRUM’у – вся команда ответственна за результаты спринта. Разделение ролей у нас сохранилось, пока сохранилось и отношение, с чем я всеми силами борюсь. Т.е. не должно быть ситуации, когда на мой вопрос (как product owner’a =) “почему до сих пор не готова эта user story в самой большой важностью” дев лид отвечает “тестировщики поганцы, не протестили! Иди (менеджер) попинай их!”. Я глубоко уверен в том, что за тестирование должен нести ответственность главный тестировщик, за архитектуру – архитектор, за аналитику – аналитик, за весь проект в целом – менеджер (это убеждение как-то глубоко во мне укоренилось и расставаться с ним я пока не спешу =). Но вот отношение к своим обязанностям, я считаю, нужно менять. Если нужно – я сам сижу и занимаюсь аналитикой, пишу техническую документацию для разработчиков, обсуждаю архитектуру, тестирую, помогаю с простой вёрсткой. Но со мной понятно – я менеджер. А вот когда внутри команды разработчики, видя прорехи в тестировании, самостоятельно предлагают помощь тестировщикам или, зная о системе больше юзабилити аналитика, подкидывают ему идеи, как можно реализовать то или иное требование более изящно и просто – это есть счастье для любого менеджера!

Вот к этому и идём =)

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

noreply@blogger.com (Alexey Pavlov) — Fri, 17 Oct 2008 14:20:00 +0000

Привет.

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

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

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

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

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

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

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

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

noreply@blogger.com (Alexey Pavlov) — Thu, 16 Oct 2008 06:37:00 +0000

Привет!

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

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

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

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

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

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

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

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

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

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

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

noreply@blogger.com (Alexey Pavlov) — Tue, 30 Sep 2008 07:37:00 +0000

Привет!

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

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

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

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

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

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

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

“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 для всех своих проектов в которой расписал промежуток времени в течении которого я работал над каждым проектом и количество часов, потраченных мной на каждую группу процессов. У меня получилось, что на каждую группу процессов в каждом проекте я в среднем тратил следующее количество времени (в процентах) от всего времени проекта:

Initiating	Planning	Executing	Monitoring and Controlling	Closing
12%	26%	29%	23%	10%

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

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

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

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

Если всё заполнено и вся введенная информация верна, ставьте галку “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” – всё можно отредактировать.

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

Удачи!

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

noreply@blogger.com (Alexey Pavlov) — Thu, 04 Sep 2008 13:39:00 +0000

Привет!

В этой заметке привожу свой вольный перевод статьи “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. А если вы уже сдали экзамен, то никаких изменений вашего статуса не будет, только потому, что вышла новая версия руководства.

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

noreply@blogger.com (Alexey Pavlov) — Tue, 02 Sep 2008 13:47:00 +0000

Анекдот из жизни.

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

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

<Архитектор филосовски>: Архитектура есть - просто она очень простая...

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

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

noreply@blogger.com (Alexey Pavlov) — Tue, 02 Sep 2008 06:59:00 +0000

Привет!

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

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

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

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

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

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

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

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

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

noreply@blogger.com (Alexey Pavlov) — Fri, 29 Aug 2008 14:14:00 +0000

Привет!

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

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

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

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

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

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

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

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

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

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

noreply@blogger.com (Alexey Pavlov) — Mon, 25 Aug 2008 11:22:00 +0000

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

Ключом к ответам на вопросы PMI является:
- Объективное понимание материала. Не думайте, что данный экзамен проверяет память; он проверяет знания, практический опыт и умение анализировать! Вы должны понимать части этой книги (моё прим.: Рита пишет о своей книге, в которой приведены эти советы), как они используются в реальном мире и как они работают при взаимодействии друг с другом.

Иметь реальный опыт использования всех основных инструментов и методов управления проектами.

Прочесть PMBOK Guide.

Понять области знаний, которым PMI придаёт особое значение (моё прим.: PMI-isms, не знаю, как адекватно перевести, разве что PMI-измы =)

Быть хорошо знакомыми с типами вопросов (моё прим.: которые встретятся на экзамене).

Практиковаться в интерпретации двусмысленных вопросов и вопросов с большим количеством информации.

Практиковаться в выборе ответа среди, казалось бы, двух или трёх правильных ответов.

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

Контролируйте экзамен, не давайте ему контролировать вас. Что вы почувствуете, если, прочитав первый вопрос, вы не будете знать на него ответ? Если тоже самое случится со вторым вопросом? И с третьим? По многим причинам это может случиться! Вот что нужно делать. Если вы не можете сразу дать ответ на вопрос, используйте функцию Mark for Review и вернитесь к нему позже. Это будет означать, что ваш первый проход по вопросам экзамена будет очень быстрым. Теперь вы более подготовлены? Представьте, как хорошо вы будете себя чувствовать, когда всё, что вам останется сделать – это просмотреть несколько вопросов, которые смутили вас ранее. Запомните это. Это может послужить большим облегчением для вас на экзамене.
Контролируйте ваше волнение. Вы можете быть не согласны с некоторыми вопросами на этом экзамене. Вы так же можете быть удивлены тому, сколько вопросов вы пометили для последующего просмотра. Если вы всё ещё думаете о вопросе 20, в то время как достигли 120 вопроса, то вы получите 100 вопросов, о которых вы недостаточно хорошо подумали. Побеспокойтесь о том, что бы контролировать своё волнение.
Отвечайте на вопросы с точки зрения PMI, а не с точки зрения вашего личного жизненного опыта. Если же данный подход не поможет вам выбрать правильный ответ, полагайтесь на ваше обучение и, в последнюю очередь, на ваш жизненный опыт.
Первым делом среди представленных в вопросе слов выделите сам вопрос (зачастую им является последнее предложение), затем прочтите остальную информацию. Отметьте тему, о которой идёт речь в вопросе и ключевые слова (например, “за исключением”, “включая”, “не является примером…”). Это поможет вам понять, о чём спрашивается в вопросе и уменьшит потребность в повторном чтении вопроса. Определите, каков должен быть ваш ответ и только потом смотрите на представленные варианты ответов.
Одна из основных причин, по которой люди отвечают неверно - это то, что они не читают все четыре варианта ответа. Не допускайте этой ошибки! Практикуйтесь читать вопрос и все четыре варианта ответа, когда готовитесь к экзамену. Лучше всего практиковаться в чтении вариантов ответов с конца (сначала D, затем C и т.д.). Такого рода практика позволит вам выбрать ЛУЧШИЙ ответ.
Практикуйтесь быстро исключать ответы, которые являются очевидно неверными. Многие вопросы имеют только два наиболее вероятных варианта ответа и два очевидно неверных варианта.
Может быть более одного “правильного” ответа на каждый вопрос, но только один “ЛУЧШИЙ” ответ. Практикуйтесь в поиске ЛУЧШЕГО ответа.
Будьте готовы к тому, что информация из одного вопроса иногда может использоваться в другом вопросе. Записывайте вещи, которые вы не поняли в ходе экзамена. Используйте оставшееся время в конце экзамена для возврата к этим вопросам.
Были предприняты попытки сделать все варианты ответов примерно одной длинны. Поэтому не следуйте старому правилу гласившему, что наиболее длинный вопрос является правильным.
Были затрачены усилия на использования в вопросах “отвлекалок” – выделяйте то, что отвлекает вас от правильного ответа. Это могут быть внешне правдоподобные варианты ответа, которые могут выбрать слабо подготовленные люди. Такие отвлекающие вещи могут привести к тому, что может показаться, что у некоторых вопросов есть два или более правильных ответов. Многим людям кажется, что есть лишь тень разницы между вариантами ответа. Обращайте внимание на такого рода вопросы, когда практикуетесь в ответах на экзаменационные вопросы.
Обращайте внимание на такие слова, как “первый”, “последний”, “следующий”, “лучший”, “никогда”, “всегда”, “за исключением”, “не является”, “наиболее вероятно”, “наименее вероятно”, “в первую очередь”, “изначально”, “наиболее” и т.д. Удостоверьтесь в том, что вы внимательно прочитали вопрос и заметили эти слова, иначе вы ответите на вопрос неверно! На экзамене будет много вопросов, которые потребуют от вас понимания процессов управления проектами и их применение в реальном мире.
Остерегайтесь вариантов ответа, которые являются истинными утверждениями, но не являются ответом на поставленный вопрос.
Остерегайтесь вариантов ответа, которые содержат общие ошибки в области управления проектами. Они намеренно используются, что бы определить действительно ли вы знакомы с управлением проектов. Поэтому, вы можете не знать, что ответили на вопрос неправильно! Следите за своими ошибками и практикуйтесь по мере чтения этой книги. (Смотрите лист “Общие ошибки и заблуждения в управлении проектами” в конце этой главы.)
Варианты ответа, которые представляют собой обобщения, как правило, бывают неверными, так что следите за словами “всегда”, “никогда”, “должны”, “полностью” и так далее. С другой стороны, варианты ответов, которые являются аккуратными и компетентными, являются, как правило, правильными, так что следите за словами “обычно”, “иногда”, “может быть”, “возможно” и ”в общем”.
Когда в вопросе требуется заполнить пустое место, правильный ответ может находиться в неверной грамматической форме после того, как будет вставлен в предложение.
Как только вам выдадут бумагу, когда вы придёте на экзамен, запишите на неё всё, что вам тяжело держать в голове. Это освободит ваш разум, поскольку информация, о которой вы беспокоились, будет записана на листе.
Посетите место проведения экзамена до даты самого экзамена, что бы определить сколько времени вам потребуется для того, что бы добраться туда и для того, что бы посмотреть как выглядит комната, где вы будете сдавать экзамен. Это особенно хорошо помогает в случае, если вы сильно нервничаете при сдаче экзаменов.
Не ожидайте, что в помещении, где вы будете сдавать экзамен, будет тихо. Студент с моего курса PMP Exam Prep в течении трёх часов сдавал экзамен под звуки оркестра, игравшего под окнами тестового центра. Другие студенты рассказывают о том, что рядом с ними сдавали экзамены, которые требовали интенсивного печатания на клавиатуре. Многие тестовые центры имеют наушники, подавляющие шум (моё прим.: я брал с собой ушные затычки, продающиеся в аптеках).
Следите за т.н. “rah, rah” (моё прим.: я так понял, что это что-то типа нашего “вах, вах” =) вопросами (например, “Менеджер проекта так важен”, “ИСР так важна”).
Хорошенько расслабьтесь и выспитесь в ночь перед экзаменом. НЕ УЧИТЕСЬ! Вам потребуется время, что бы обработать всё, что вы выучили, для того, что бы вспомнить это на экзамене.
Побеспокойтесь о том, что бы вам было удобно во время экзамена. Оденьтесь в свободную одежду и возьмите с собой свитер, на который вы сможете сесть в случае, если стул будет вам неудобен.
Возьмите с собой что-нибудь перекусить! Вы не сможете взять еду с собой в комнату, где будет проходить экзамен, но осознание того, что еда рядом, может облегчить муки голода (моё прим.: ох уж эти американцы, четыре часа без еды и начинаются невыносимые муки голода =).
Используйте технику глубокого дыхания для того, что бы расслабиться. Это особенно полезно, если вы сильно нервничаете перед или во время экзамена, замечая, что перечитываете вопрос два или три раза.
Используйте всё время экзамена. Не уходите до тех пор, пока не просмотрите каждый вопрос дважды.
Помните, что это нормально изменять ответы, если у вас есть на это весомые причины.
Создайте план прохождения экзамена и придерживайтесь его. Это может значить “Я передохну 10 минут после каждого 50-ого вопроса потому что я быстро устаю”, или “Я отвечу на все вопросы как можно быстрее, а потом передохну и снова просмотрю свои ответы”.

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

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

noreply@blogger.com (Alexey Pavlov) — Fri, 15 Aug 2008 06:38:00 +0000

Привет!

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

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

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

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

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

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

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

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

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

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

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

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

noreply@blogger.com (Alexey Pavlov) — Thu, 14 Aug 2008 05:56:00 +0000

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

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

Москва, 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 предоставляется скидка.

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

noreply@blogger.com (Alexey Pavlov) — Mon, 11 Aug 2008 06:58:00 +0000

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

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

Итак…

PMBOK Guide Third Edition: Внимательно прочитать PMBOK вплоть до 77 страницы – до Главы 4, Управление интеграцией проекта.
PMBOK Guide Third Edition: Выучить наизусть (ВНИМАНИЕ – ЭТО ОЧЕНЬ ВАЖНО!!!) таблицу 3-45 на стр. 70 (“Соответствие между процессами управления проектами и группами процессов управления проектом и областями знаний”). Эта страница – фундамент дальнейшего обучения. Это карта, которая в дальнейшем позволит не запутаться в процессах, входах и выходах 44-х процессов. Чем раньше вы выучите данную таблицу, тем лучше. Эта таблица станет первым memory dump’ом, который вы будете использовать на экзамене. Выучить данную таблицу достаточно просто (хотя с первого взгляда так не кажется). Очень полезно (и необходимо!) раз в пару тройку дней воспроизводить эту страницу на чистом листе по памяти.
PMBOK Guide Third Edition: Внимательно прочитать Приложение F (стр. 337) – “Краткое изложение областей знаний по управлению проектами”.
PMBOK Guide Third Edition: В ознакомительном режиме, быстро прочитать остальную часть PMBOK, т.е. не стараясь запомнить входы, выходы, названия и определения.
PMBOK Guide Third Edition: Распечатать, разложить по квартире, в сумки и рюкзаки и постоянно почитывать Глоссарий (разделы “Принятые сокращения”, стр. 348 и “Определения”, стр. 350).
Затем прочитать книгу “PMP Exam Prep” Fifth edition by Rita Mulcahy, PMP. Важно проходить все тесты и выполнять все задания для каждой главы.
После первого прочтения книги Риты необходимо заново от начала до конца прочитать PMBOK. Весь. Целиком. На этот раз, внимательно читая определения, обращая внимания на входы, выходы, инструменты и методы.
Затем снова, с самого начала необходимо прочитать книгу “PMP Exam Prep” Fifth edition by Rita Mulcahy, PMP. Снова пройти все тесты. Очень важно прочитать эту книгу несколько раз, т.к. с каждым прочтением элементы “мозаики” УП встают на своё место.
Параллельно пунктам 7 и 8 необходимо проходить все доступные тесты. Из коммерческих я очень рекомендую программу Project Management IQ 9.0, в которой есть более тысячи вопросов по всем областям знаний, несколько режимов (в том числе и режим экзамена), а так же объяснения и комментарии к ответам.
Так же есть множество бесплатных ресурсов, в которых можно найти много тестовых вопросов. При прохождении тестов очень важно записывать, в каких именно областях знаний и группах процессов у вас есть пробелы. Какие именно вопросы вызывают у вас затруднения. Какие определения для вас незнакомы. Всё это лучше записывать в специальную рабочую тетрадь. Далее, при повторном прочтении PMBOK, книги Риты или любой другой подготовительной литературы, необходимо уделять особое внимание тем областям, в которых у вас имеются пробелы.
Будете смеяться, но опять нужно от начала и до конца прочитать PMBOK. Внимательно! Уделяя особое внимание пунктам в вашей рабочей тетради, которые возникли после прохождения тестов.
И в последний раз прочесть “PMP Exam Prep” Fifth edition by Rita Mulcahy, PMP.
Параллельно пунктам 6-11 полезно читать различную подготовительную литературу (я читал книгу М. Ньюэла, см. предыдущее сообщение), а так же слушать обучающие подкасты (я выбрал Project Management PrepCast by Cornelius Fichtner, PMP – лучший, на мой взгляд, подкаст для подготовки к экзамену PMP, к тому же дешёвый, всего 49$).
Хотя бы раз до экзамена сесть и пройти тест из 200 вопросов в режиме экзамена, т.е. без подсказок, обращений к справочному материалу и долгих пауз. Засечь, сколько на это понадобилось времени и когда возникала необходимость в отдыхе. Я отдыхал 5 минут после 90-ого вопроса, 5 минут после 180-ого и 5 минут после 200 перед тем, как пройтись по всем отмеченным мной в процессе экзамена вопросам.
Создать второй memory dump (первый – это таблица со стр. 70 PMBOK, о которой я говорил в п. 2). Второй memory dump будет содержать все (или почти все) необходимые формулы, которые могут понадобиться на экзамене. Зачем именно нужен memory dump я расскажу в одной из следующих заметок, а так же выложу свою версию memory dump’а с формулами.

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

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

Новости PMI

noreply@blogger.com (Alexey Pavlov) — Thu, 07 Aug 2008 05:13:00 +0000

Привет!

Несколько новостей от PMI, с которыми можно ознакомиться как на сайте PMI, так на сайте pmexpert.ru

Программа подтверждения аттестата РМР (Continuing Certification Requirements program — CCR)

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

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

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

Материал взят из рассылки pmexpert.ru

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

noreply@blogger.com (Alexey Pavlov) — Wed, 06 Aug 2008 05:35:00 +0000

Привет.

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

Книгу PMBOK Guide Third Edition v1.3
Книгу “PMP Exam Prep” Fifth edition by Rita Mulcahy, PMP
Книгу "Управление проектами. Руководство по подготовке к сдаче сертификационного экзамена (PMP)", М. Ньюэл.
Подкаст Project Management PrepCast (подкасты для подготовки к сдаче на PMP) by Cornelius Fichtner, PMP.
Бесплатные тесты, доступные в Интернет.

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

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

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

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

Если есть вопросы - задавайте!

PMP passed

noreply@blogger.com (Alexey Pavlov) — Sat, 02 Aug 2008 08:09:00 +0000

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

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

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

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

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