Руководитель проекта без иллюзий. Как начать, не утонуть в хаосе и довести проект до результата

1.5.1. ЭТАП «ИНИЦИАЦИЯ»

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

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

По-хорошему, основным результатом этого этапа является более подробный документ — устав проекта, который содержит:

— Требования, удовлетворяющие потребности, пожелания и ожидания заказчика, спонсора и других заинтересованных сторон проекта.

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

— Цели (по сути, это обоснование проекта).

— Сведения о руководителе проекта, проектной команде (включая роли и обязанности).

— Данные по клиенту, представители клиента и контактные данные.

— Основные этапы проекта.

— Риски и возможные проблемы.

— Список заинтересованных сторон и их участие в проекте.

— Функциональные подразделения организации и их участие в проекте (если есть деление).

— Ограничения, накладываемые организацией, окружением и внешней средой.

— Обоснование проекта, включая бизнес-обоснование и данные о ROI (Return on Investment).

— Суммарный бюджет проекта.

Готовую структуру такого документа можно посмотреть в приложении А.1. «Устав проекта: структура». Она поможет не начинать устав с пустого листа и не забыть базовые разделы: цели, границы, роли, риски, ограничения и ключевые параметры проекта.

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

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

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

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

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

1.5.2. ЭТАП «ПЛАНИРОВАНИЕ»

Основная цель этого этапа — составить детальный план действий.

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

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

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

Задача руководителя проекта — не просто один раз создать план, а регулярно сравнивать его с фактическим состоянием задач. Для этого удобно использовать систему управления задачами: Jira, Redmine или другой инструмент, принятый в компании.

Основной план будет включать в себя несколько подпланов, отражающих конкретные аспекты проекта:

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

— праздники,

— отпуски,

— возможные отгулы,

— больничные (вы работаете с людьми, знаете их и сможете спрогнозировать, как часто в месяц они отсутствуют),

— риски (например, задержки у клиента в предоставлении обратной связи),

— занятость на проектах (задействованы ли на других проектах и в каком объёме).

Этот список можно продолжать, но для старта достаточно и этих пунктов. Может возникнуть вопрос: «Зачем так много сложностей?» На самом деле это не сложности, а нормальная подготовка. Чем лучше вы понимаете ресурсы на старте, тем меньше неожиданностей получите в ходе проекта. Перечислю, что зависит от ресурсного плана:

— прибыль компании от проекта,

— успех проекта (люди работают над проектом),

— своевременный найм сотрудников (а это работа HR),

— подготовка рабочего места (а это работа поддержки),

— эффективность работы компании.

— Финансовый план. Этот план основывается на ресурсном плане и служит для детализации суммы денежных средств, которая потребуется для реализации проекта. Основная цель финансового плана — обеспечить основу для сравнения общего бюджета проекта и его фактической стоимости (сколько потратили на реализацию). Давайте рассмотрим основные пункты финансового плана:

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

— Зарплата сотрудников. Нужно учесть зарплаты всех участников проекта с учётом тех, кого вы ещё планируете нанять или тех, кого вы планируете привлекать разово.

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

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

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

Обязательно обсудите с заказчиком ожидания по дизайну, фирменному стилю, упаковке, сайту, фотографиям, рекламе и другим смежным работам. Часто клиент считает, что «дизайн продукта» уже включает всё: фирменный стиль, материалы для продвижения, фотографии, тексты и оформление. На практике это могут быть отдельные работы, отдельные сроки и отдельный бюджет.

Такие расходы лучше проговорить на старте и заложить хотя бы 5—10% на непредвиденные затраты. Дизайн, фирменный стиль, подбор фотографий и рекламные материалы редко согласовываются с первого раза. И лучше честно учесть это в плане, чем потом делать вид, что никто не ожидал задержек.

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

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

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

К плану приёмки полезно подготовить «Сопроводительное письмо». Используйте его, когда передаёте заказчику промежуточную сборку, макет, документ, модуль или другой результат для проверки.

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

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

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

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

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

Уточнение:

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

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

— ТЗ определяет и уточняет тип работ, тип поставщика, ресурсы (необходимые команде), график сроков и копию условий оплаты.

— Далее идёт документ запроса информации (RFI). Этот документ помогает команде определить потребности.

— После запроса информации запрашивают документ с предложениями (RFP), он поможет команде выбрать лучшего поставщика, опираясь на конкретные предложения.

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

— Наконец, команде потребуются тендерные формы для отслеживания всего, что происходит в процессе выбора поставщиков.

Заключительным блоком работ этапа планирования является ещё один обзор проекта. В данном блоке работ в форме обзора проекта следует указать:

— планируется ли завершить проект в срок;

— соответствует ли он бюджету на сегодняшний день;

— устранены или нет какие-либо существующие препятствия и риски.

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

Подробно планирование разберём в следующей главе.

1.5.3. ЭТАП «ИСПОЛНЕНИЕ»

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

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

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

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

— сроками и графиком работ;

— затратами и фактическими расходами;

— качеством результата;

— изменениями требований и объёма работ;

— рисками;

— поставщиками и подрядчиками;

— коммуникациями;

— приёмкой промежуточных результатов;

— состоянием и мотивацией команды.

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

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

1.5.4. ЭТАП «ЗАКРЫТИЕ»

Мы подошли к завершающей стадии процесса управления проектом, заключительному этапу.

Этот этап позволяет руководителю проекта и команде официально закрыть проект, передать итоговую информацию руководству и зафиксировать результат работы.

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

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

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

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

Подробно этап закрытия разберём в главе 9.

1.6. ВЫБОР МЕТОДОЛОГИИ И РАБОТА С ПОДХОДОМ К ПРОЕКТУ

1.6.1. МИР МЕТОДОЛОГИЙ: КЛАССИКА (WATERFALL) VS ГИБКОСТЬ (AGILE/SCRUM)

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

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

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

Но на практике не менее важно не только понимать этапы, но и выбрать, как именно вы будете проходить эти этапы. Что делать, если заказчик сам не до конца понимает, какой продукт ему нужен? Что делать, если рынок быстро меняется, а требования уточняются уже по ходу работы? В таких ситуациях помогают гибкие подходы, или Agile. Самая известная из гибких методологий — Scrum.

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

Ключевые отличия Waterfall и Scrum для новичка представлены в таблице 1.

Таблица 1 — Ключевые отличия Waterfall и Scrum для новичка

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