Текст книги "Проджект-менеджмент. Как быть профессионалом"

Что делает руководитель проекта

Менеджер проекта выполняет роль единой точки контакта. Его задача – привести цель проекта в соответствие со стратегией и целью компании, спонсора и команды.

Менеджер отвечает за все:

● анализ и осмысление содержания проекта, работу с требованиями к результатам поставки проекта и критериями приемки, а также с критериями успеха проекта;

● обработку и структурирование имеющейся информации, преобразование информации в план управления проектом;

● оценку стоимости отдельных задач и всего проекта;

● управление рисками проекта;

● построение реалистичного расписания проекта;

● выполнение операций для обеспечения результатов проекта;

● измерение и мониторинг всех аспектов исполнения проекта, а также осуществление необходимых действий для достижения целей проекта;

● лидерство, вдохновение и мотивацию команды проекта на выполнение поставленных задач в ограниченных временных рамках;

● коммуникации: руководитель проекта тратит порядка 90 % рабочего времени на общение с другими людьми;

● четкую работу с изменениями по ходу проекта;

● использование верных инструментов, таких как Trello, Jira, MS Project и прочих;

● управление ожиданиями заинтересованных сторон: проект можно считать успешным, если заказчик доволен, даже если он получил не то, что задумывалось изначально;

● и, конечно, яркое и запоминающееся завершение проекта.

Выводы

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

Однажды друзья рассказали интересный пример, иллюстрирующий важность этого подхода. Дело было в одной международной компании, занимающейся производством продуктов питания. В России у нее свой завод, логистическая инфраструктура и налаженные продажи по всей стране. Из логистических центров товар распространяется по магазинам. Графики и маршруты поездок формируются директорами логистических центров на местах.

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

«Ура! – сказали программисты. – Это же стандартная транспортная задача. Сейчас будем экономить километры пробега и топливо».

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

Изменение реализовали, и проект запустили. На запуск приехали владельцы компании и признали проект провалившимся. Оказывается, целью проекта было пресечение воровства среди директоров логистических центров. Они специально планировали неоптимальные маршруты, а машины отправляли по оптимальным, воруя таким образом топливо. В общем, проект переделали. Теперь маршруты и расписания стали приходить строго из головного офиса. Большинство директоров логистических центров уволились, и их места заняли новые люди. Воровство прекратилось. Если бы руководитель проекта знал, в чем состоит реальная бизнес-цель проекта, то он никогда бы не утвердил изменение, которое запросили директора, и сразу бы привел проект к успеху.

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

Глава 3
Карьера: как заставить себя учиться?

Теория, полученная на курсах, – это хорошо, но практика лучше! Или нет? Жизнь всегда резко отличается от книжной теории.

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

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

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

Идеальный и самый простой путь в обучении – найти себе наставника, который будет мотивировать собственным примером и объяснять тонкости профессии. Но такого наставника у меня не оказалось. Нужно было искать другие способы получать знания, но тут возникли две проблемы:

1) собственная мотивация к обучению;

2) трудность с обоснованием руководству, зачем нужны какие-либо дополнительные курсы по проектному управлению, ведь все и так работает.

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

Сертификация имеет ряд преимуществ и для сотрудника, и для работодателя.

Для сотрудника это хороший «орден», подтверждающий соответствие знаний и навыков в управлении проектами международным стандартам. Кроме того, сертифицированный специалист стоит дороже на рынке труда.

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

Как выбрать сертификацию

В целом мне стало понятно, куда двигаться. Осталось выбрать, какую именно сертификацию пройти. На тот момент варианты были следующие:

● американский PMP (Project Management Professional);

● швейцарский IPMA (International Project Management Association), который активно продвигали в России;

● английский Prince2 (PRojects IN Controlled Environments).

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

Что такое PMP

В США существует институт Project Management Institute. Он занимается тем, что создает, поддерживает и распространяет в сфере управления проектами стандарты, аналогичные нашим ГОСТам. Стандарт по управлению проектами называется PMBOK (Project Management Body of Knowledge). Он достаточно объемный и представляет собой справочник по управлению проектами: что и когда должен делать руководитель.

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

«Это то что надо!» – подумал я и задался целью за год подготовиться к сдаче экзамена.

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

Фактически PMBOK – это справочник, разбитый на области знаний. Если по ходу работы возникает вопрос, то можно обратиться к нему, быстро найти нужную тему и посмотреть, как в этом случае рекомендуют поступать лучшие руководители проектов.

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

Алексей Минкевич

Глава 4
Устав проекта

Устав проекта (Project charter) – это короткий документ, который «в крупную клетку» описывает детали проекта, формально авторизует его существование, закрепляет за ним руководителя, которому предоставляет полномочия использовать ресурсы компании для работы над проектом.

Устав проекта – это не единственное название документа. В разных компаниях его могут называть по-разному: «карточка проекта», «one-pager», «executive summary», «описание проекта» и т. д.

Начнем с начала. На каком этапе менеджер узнает о своем назначении на проект?

Этап идеи – это, как правило, этап внутренних проектов. Начальник вызывает менеджера и говорит: «Слушай! Есть идея!» У таких проектов обычно только один спонсор – непосредственный руководитель менеджера.

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

Этап победы в тендере – обычно выглядит так: к менеджеру подбегает радостный сотрудник отдела продаж и говорит: «Отличные новости! Мы тут продали одному клиенту такой огромный проект! В общем, нужно еще и CRM им сделать. Короче, на все у тебя две недели. Удачи!» В этом случае у менеджера еще остается возможность обсудить с заказчиком содержание работ, составить расписание и сверстать бюджет проекта.

Этап подписанного контракта – как правило, менеджер попадает в проект, где уже оговорены конкретные сроки, четко прописан объем работ, все обещания уже даны. В этом случае менеджеру проекта нужно убедиться, что все реалистично и работы укладываются в оговоренные сроки и бюджет. Если это не так, то нужно немедленно обсудить ситуацию со спонсором проекта.

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

Итак, что нужно в первую очередь сделать менеджеру на старте независимо от того, на каком этапе находится проект?

Конечно же, познакомиться с проектом и найти ответы на простые, но самые важные вопросы:

● Для чего нужен проект?

● Что именно должно быть сделано?

● К какому сроку все должно быть готово?

● Сколько денег выделено на проект?

● Кто может оказать существенное влияние на реализацию проекта?

Чтобы помочь найти ответы на эти вопросы, существует классный инструмент – устав проекта.

Что должно быть в уставе

1. Бизнес-цель проекта. Как уже было сказано в начале книги, руководителю проекта очень важно знать, какую цель преследует бизнес своим проектом и какую проблему он хочет решить с его помощью. Иногда бывает сложно докопаться до сути сразу, и происходят примерно такие диалоги: «Вячеслав, зачем мы автоматизируем бухгалтерию?» – «Для того, чтобы автоматизировать…» – «Хорошо, а для чего мы ее автоматизируем? Что вы хотите получить в итоге от проекта? Какова цель бизнеса?»

Автоматизация как таковая никогда не является целью бизнеса. Автоматизирован процесс или нет – бизнесу все равно. До тех пор, пока всех все устраивает. Обычно при помощи автоматизации бизнес хочет улучшить управляемость, получить прозрачность, ускорить процессы, повысить уровень удобства для клиента или снизить расходы. Вернемся к примеру с банком. Для него бизнес-цель, прописанная в уставе, будет выглядеть следующим образом.

Бизнес-цель: увеличение базы клиентов банка на 1 млн человек за год.

2. Цель проекта. Описание того, каким образом будут достигнуты бизнес-цели проекта. Бизнес принимает решение о запуске конкретного проекта, проанализировав различные альтернативы и выбрав один вариант. В примере с банком таким решением может быть, например, приложение, помогающее выдавать мини-кредиты. Оно служит единственной бизнес-цели – увеличить базу клиентов банка. Решение должно быть задокументировано кратко и на высоком уровне. Это своеобразная карта, по которой нужно двигаться, чтобы помочь бизнесу достичь цели. Как это прописать в уставе? Примерно так.

Решение: необходимо разработать мобильное приложение под Android, которое умеет фотографировать паспорт потенциального клиента, отправлять фото паспорта и обмениваться информацией с серверами банка. Приложение должно позволить сотруднику банка выполнить следующие действия:

● пройти авторизацию в приложении;

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

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

Важным требованием является возможность работы приложения в условиях медленного мобильного интернета (на тот случай, если в населенном пункте нет 3G).

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

3. Требования / результаты поставки. Здесь нужно описать крупные результаты поставки проекта и основные требования к ним. В итоге должен получиться список дел, «to do» проекта. Если все пункты этого списка выполнены, проект успешно завершен.

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

Список результатов поставки для примера с банком:

● разработать мобильное приложение для телефона Lenovo P780 с функционалом, описанным в целях проекта;

● обновить банковское серверное решение для поддержания работы приложения;

● закупить 200 телефонов Lenovo P780;

● разработать обучающие видеоматериалы по работе с приложением;

● провести обучение 30 представителей банка;

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

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

4. Ограничения и допущения. Ограничения проекта – это перечисление факторов, которыми в проекте нас ограничивает заказчик. Есть решения, которые уже приняты, и мы их не можем менять. В нашем банковском примере есть всего одно ограничение.

Ограничения: решение должно работать на телефоне Lenovo P780 под управлением Android 5.1.

Допущения проекта – это факторы, которые для целей планирования считаются верными, реальными или определенными без предоставления доказательств или демонстрации (такое определение дает нам PMBOK). Если коротко, то это предположения, которые можно считать фактом на данном этапе работ. Без них мы не сможем продолжить планирование проекта.

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

5. Ключевые и контрольные события. В уставе проекта оговариваются ключевые и контрольные события – важные события в проекте – и то, когда они должны произойти.

Например, проект начинается 6 июля. Менеджер планирует, что backend-разработчики должны сделать серверную часть по проверке фотографий из паспортов к октябрю. Для этого нужно успеть за месяц согласовать контракты API между сервером и мобильным приложением. Если удастся, то только в этом случае можно будет закончить мобильное приложение к ноябрю.

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

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

Ключевые и контрольные события:

● проект запущен: 6 июля;

● API между мобильным приложением и сервером согласованы: 5 сентября;

● разработка серверного решения завершена и протестирована: 10 октября;

● разработка мобильного приложения завершена: 4 ноября;

● тестирование решения завершено: 2 декабря;

● проект успешно завершен: 12 декабря.

Обратите внимание, что ключевые события указываются в прошедшем времени, что дает менеджеру четкое понимание того, выполнены эти задачи или нет. Если писать в настоящем времени («Разработка мобильного приложения: 4 ноября»), не будет понятно, что имелось в виду: мы планировали начать разработку, вести разработку или закончить разработку к 4 ноября. Прошедшее время четко дает понять, что работа должна быть завершена к соответствующей дате.

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

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

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

Мы рекомендуем совмещать список заинтересованных сторон с матрицей ответственности, то есть не просто узнать, кто влияет на проект, но и зафиксировать, кто и за что будет отвечать. Пример приведен в таблице 1.

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

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

По методологии устав проекта должен создавать заказчик. Но в нашей практике этим часто занимался руководитель проекта. Это короткий документ, который легко прочитает и спонсор со стороны заказчика, и начальство менеджера. Этим документом руководитель проекта как бы переспрашивает: «Все ли я понял верно?» Если вдруг на этапе подготовки устава что-то упущено или понято не так, то это может привести к большим изменениям в проекте и, соответственно, большим дополнительным затратам. Если же менеджер получил письменное подтверждение того, что все понято верно, то проект пойдет в нужном направлении.

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

Устав может корректироваться в ходе реализации проекта. Почему? Например, у бизнеса поменялись цели. Такое бывает: время не стоит на месте, рынок меняется. В управлении проектами нет документов, которые «ламинируются». Любые планы нужно будет обновлять согласно новым вводным. Обратите внимание, что такая же история происходит и со стартапами. Очень редко стартап становится успешен со своей оригинальной идеей. Обычно только в ходе работы становится понятно, что именно нужно рынку. И успеха добиваются те, кто способен быстро адаптировать свою идею под нужды рынка или, если потребуется, полностью изменить ее. Например, YouTube начинался как сайт знакомств, фишкой которого была возможность записать короткое видео о себе. А сейчас это крупнейший провайдер видеоконтента.

Устав проекта стоит пересмотреть и утвердить заново в том случае, когда вас как менеджера ставят управлять уже идущим проектом. Если у существующего проекта нет устава, начните с его создания.

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

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

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