Юрий Волщуков - Успешный руководитель проекта Страница 11

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

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

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

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

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

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

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

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

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

Набор документов руководителя проектов

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

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

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

В этом случае у Вас только описание требований к парку может занять более сотни листов А4.

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

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

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

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

Чем выше самостоятельность, тем выше ответственность. Соответственно, чем меньше у вас ответственности, тем меньше и самостоятельности. Если вы самостоятельно не принимаете кадровых решений, значит, вы вынуждены к кому-то обратиться за помощью. Это будет, например, руководитель группы, в которой вы хотите заменить людей. Если вы не можете самостоятельно принять решение об изменении суммы закупки каких-то комплектующих, то вам снова придется искать «помощника». В результате вы начнете терять свою самостоятельность.

Зачем вообще руководителю проекта такая огромная самостоятельность?

Для того, чтобы это представить, сделаем рисунок: на одной оси «самостоятельность» от максимума до ноля, на другой – «компетенции руководителя». По мере того как у вас убывает самостоятельность, у вас теряется статус руководителя проекта, вы становитесь просто менеджером, у которого регламентирована функциональность, расписан весь план работ.

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

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