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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

Недавно меня пригласили на конференцию 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

Привет!

Всем зарегистрированным участникам 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 - успехи внедрения и планы на будущее

Привет!

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

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

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

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

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

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

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

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

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

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

Привет.

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

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

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

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

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

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

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

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

Привет!

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

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

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

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

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

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

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

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

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

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

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

Привет!

Мне уже не в первый раз приходят письма от читателей, в которых меня спрашивают как я подавал заявку на сдачу экзамена 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” – всё можно отредактировать.

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

Удачи!