Юрий Волщуков - Успешный руководитель проекта
Руководитель проекта отвечает за то, чтобы по ходу исполнения проекта была подготовлена соответствующая документация, подписывались нужные протоколы, сдавались промежуточные акты, чтобы в дальнейшем можно было зафиксировать и подтвердить исполнение тех или иных работ.
Давайте формализуем и конкретизируем перечень документов, который руководитель проекта должен контролировать.
Мы говорили о том, что в самом начале фиксируются требования заказчика, которые часто называются «Техническое задание». Однако стоит отметить, что техническому заданию должны предшествовать технические требования. В техническом задании уже расписывается, что должно получиться в итоге, критерии оценки результата, который должен быть достигнут при завершении и сдаче проекта.
Например, если вам дали задание на разработку автомобиля, вам не расписывают, какой должен быть автомобиль. Вам выдвигают требование – создать новый автомобиль. Он должен иметь возможность разгоняться по прямой до определенной скорости, иметь определенную грузоподъемность. На основании этих требований вы расписываете функционал, технические особенности нового автомобиля, организационные моменты ведения проекта, как будет проводиться испытание и так далее. Вы, по сути, детализируете процесс реализации этого проекта.
Первый пункт – это техническое задание. Ему должны предшествовать технические требования, далее – договор. Если вы соглашаетесь работать без договора, на честном слове, то можете поставить на себе крест как на руководителе проекта. Может быть, один раз, например, с кем-то из знакомых, у вас получится решить вопрос, но постоянно работать и развивать бизнес так не получится. Ни один крупный проект не делается на честном слове. У вас должен быть формализован договор, где прописано, что является результатом исполнения договора, какие обязанности и права у заказчика, какие – у исполнителя. Самое главное, к этому договору должен быть приложен календарный план, где у вас расписывается состав работ, сроки исполнения и стоимость всех этапов. С помощью договора мы формализуем наши отношения с заказчиком.
Итак, договор подписан. Можно начинать работать… Как вы помните, следующим этапом у нас является первое установочное совещание. Вероятно, что у вас будет множество встреч по ходу проекта, так как возникнут отклонения, появятся вопросы по изменениям, технические и организационные неувязки. Вам нужно будет собираться и с командой проекта, и с командой заказчика для того, чтобы эти вопросы решать. Все эти решения вы должны оформлять в виде протокола. В нем фиксируйте все, что обсуждали, и варианты принятых решений. Любой протокол имеет следующую форму: наименование, номер, дата, место оформления, присутствующие участники от заказчика и исполнителя, перечень обсуждаемых вопросов, принятые решения по всем вопросам.
Нужно оформить вопросы и принятые по ним решения в одном разделе: вопрос и тут же предлагаемое решение. Такая форма повышает эффективность работы, ведь в этом случае вы начинаете сверять исполнение тех или иных пунктов в момент просмотра задачи и варианта решения. После оформления протокола очень важно получить подписи.
Стандарты руководителя проекта
Как мы говорили, важность подготовки протокола встреч сложно переоценить. Это нужно для того, чтобы не только вы, как руководитель проекта, владели информацией о том, что происходит на проекте, но и другие участники процесса вместе с вами участвовали в обсуждении и были вовлечены в систему оценок состояния проекта. На вас лежит большая организационная работа, а конкретные действия находятся на уровне исполнителя. Ваша задача как руководителя проекта в этом протоколе подводить промежуточный результат, оговаривая, кто какие действия принимает и какие следующие итоги вы собираетесь получить.
Таким образом, вся команда – и заказчик, и исполнитель – владеет информацией о текущем состоянии проекта.
Давайте поговорим о возможных стандартных шаблонах документов. Одним из вопросов является формализация документов, которые руководитель проекта должен составлять и которые в дальнейшем будут помогать в его деятельности.
Существенную помощь в подготовке своих шаблонов окажет выбор методологии управления проектом. Их много разных. Я рекомендую не пожалеть времени и изучить наиболее часто используемые. Стандарты регламентируют и формализуют методологию управления проектами. Подходы к управлению и требования к людям, которые должны обладать теми или иными навыками, умениями, знаниями, постепенно трансформировались в правила, общие для участников проекта. В процессе развития деятельности человека правила переросли в стандарт. В разных группах, странах, видах деятельности сформировались свои стандарты. Они не являются чем-то статическим, по мере изменения общества, накопления знаний они меняются, дополняются, объединяя в себе лучшие практики профессионального сообщества.
Классика реализации проектов – стандарт PMBOOK. Он описывает 11 разделов знаний и сфер управления проектом. Это те 11 разделов, управляя которыми руководитель проекта гарантированно может исполнить проект. Это грамотный документ. Тот, кто считает, что его стезя – это управление проектами, кто хочет быть квалифицированным руководителем проекта, просто обязан изучить данный стандарт.
Согласно данному стандарту, существуют такие понятия, как устав проекта и иерархический состав работ.
Это, пожалуй, основополагающие документы, с которых руководитель проекта должен начинать работу в том случае, если успешно прошел стадию «пресейла», нашел заказчика, договорился о работах, согласовал сумму (пока вы не согласовали бюджет и не согласовали сумму, бесполезно заниматься реализацией проекта).
Редко используемый в нашей стране стандарт, утвержденный правительством Великобритании, – PRINCE2. Очень многое говорит его название – PRINCE (PRojects IN Controlled Environments). Перевод звучит следующим образом: «Проекты в управляемой среде». Как видите, акцент делается на тот факт, что проект не развивается сам по себе. Должно быть управляемое окружение. В отличие от PMBOOK, является менее формализованным, позволяющим адаптировать его под свои внутренние процессы. На мой взгляд, в изменчивой среде данный стандарт в большей степени обеспечивает гибкость взаимодействия в рамках проекта. Однако он требует и большей гибкости мышления от руководителя проектов.
Любой проект – это, как мы говорили, ограниченная во времени деятельность человека с определенным бюджетом для достижения целей. Когда мы говорим слово «продукт», нужно понимать, что проект – это тоже «продукт». Наша деятельность – это процесс. А результат любой деятельности – это продукт, ради которого затевается эта проектная деятельность.
