Цитаты из книги «Проджект-менеджмент. Как быть профессионалом»

Стоит ли нам участвовать в тендере? Сколько денег необходимо для бюджета этого проекта? Какова трудоемкость создания продукта? Все это важнейшие вопросы, ответы на которые помогает найти процедура оценки проекта. Оценка — это процесс определения трудоемкости, длительности и стоимости элементов ИСР. Здесь же определяется перечень специалистов, которые потребуются для выполнения пакетов работ. Обычно проект оценивается в деньгах или трудоемкости, например в человеко-часах. В крупных проектах трудоемкость может оцениваться в человеко-месяцах или человеко-годах. Оценка начинается с вопроса, какой должна быть ее точность. Оценка — это вероятностная величина. Нельзя заранее точно определить время, которое займет выполнение проекта. Однако чем точнее будет оценка, тем меньше будет разброс временного интервала. Например, если, по нашим подсчетам, выполнение задачи займет месяц плюс-минус неделю — это грубая оценка. Если задача займет месяц плюс-минус день — это точная оценка. Чем выше требования к точности оценки, тем больше времени на нее требуется. В зависимости от обстоятельств оценка может быть приблизительной или точной. Если нужно быстро принять решение об участии в тендере, то у менеджера будет всего несколько часов. Как правило, в этом случае работа сводится к тому, что сначала создается высокоуровневая ИСР, а затем грубо, с низкой точностью, оценивается стоимость работ. Для точной оценки, когда проект уже утвержден и планируется, менеджеру понадобится детальная ИСР, декомпозированная до уровня пакетов работ. Такая оценка отнимет намного больше времени. Таким образом, важно в самом начале узнать наверняка, какова цель оценки, ее сроки и какой уровень точности требуется.

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

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

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

При создании ИСР руководитель проекта должен декомпозировать работы до того уровня, когда он сможет управлять ими. Работы, находящиеся на нижнем уровне ИСР, называются пакетами работ. О пакете работ менеджер должен знать три вещи: 1) кто его будет выполнять; 2) сколько времени на это понадобится; 3) как проверить, что работа готова. Этих знаний менеджеру достаточно, чтобы эффективно контролировать исполнение. Обратите внимание, что создание ИСР — это лишь перечисление дел, которые нужно сделать в проекте. На этом этапе еще не важна оценка времени или бюджета, а также последовательность выполнения операций. Ответы на эти вопросы будут получены на этапе оценки и составления расписания проекта.

ИСР — это основа планирования проекта. Если у менеджера нет четкого списка работ, то он не может посчитать, сколько будет стоить проект и сколько времени на него понадобится. ИСР помогает структурировать и определить все содержание проекта. ИСР можно создавать в формате структурированного списка, как в нашем примере, или в виде дерева (рис. 11).

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

Описание содержания продукта (Product scope description) — это текстовый документ, который последовательно (сначала на высоком уровне, а потом более детально) уточняет характеристики продукта, услуги или результата, описанного в уставе проекта. Критерии приемки (Acceptance criteria) — четкий перечень условий, которые должны быть выполнены, чтобы результаты проекта могли быть приняты заказчиком. Это чек-лист, согласно которому заказчик будет принимать работу и проверять, насколько она соответствует его требо-ваниям. Поставляемый результат (Deliverable) — любой уникальный и поддающийся проверке продукт, результат или способность оказывать услугу, которые необходимо произвести для завершения процесса, фазы или проекта. Это указание в явном виде на то, какие артефакты проекта мы должны передать заказчику в итоге. Например, если в проекте разрабатывается мобильное приложение, то результатами поставки может быть не только само мобильное приложение, но и документация, исходный код, обученные сотрудники или специалисты, подготовленные для сопровождения и поддержки приложения. Исключения из проекта (Project exclusions) — формулировка того, что именно находится вне содержания проекта. Проще говоря, это описание того, что в проект не входит. Иногда действительно очень полезно прописать то, чего в рамках проекта делать не нужно. Давайте представим такую ситуацию: менеджер обсуждает с заказчиком готовый устав проекта автоматизации кофейни. Вдруг директор по маркетингу со стороны заказчика выдвигает идею о том, что было бы здорово запустить сайт, где можно сделать предзаказ кофе.

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

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