Заметки проектному менеджеру:проект, продукт, процесс

Проектный менеджер в нашем Агентстве работает с тремя основными сущностями: Процесс, Проект и Продукт.

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

Процесс

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

Процессы бывают разных уровней.

Процессы первого уровня. Это процессы стратегического управления или процесс управления персоналом.

Процессы второго уровня. Например, в процессе управления персоналом есть девять подуровней:

1. Управление наймом
2. Управление обучением
3. Адаптацией
4. Удержанием
5. Знаниями
6. Оценкой
7. Компенсацией
8. Брендом работодателя
9. Внутренними коммуникациями

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

Процессы четвертого уровня. Например, как конкретно написать вакансию.

Процессы пятого уровня. Это уже пошаговые инструкции, чек-листы и т. д.

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

Процесс с точки зрения изобразительного искусства — это квадраты, соединенные линиями, в логике проектного менеджмента — это таймлайн, или action plan проекта.

Если представить что стрелки начнут соответствовать какой-то хронологии, описывая цикл работ, то выяснится, что внешний вид процесса ничем не отличается от таймлайна проекта!

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

Продукт

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

Состав договора не равен тому, что клиент покупал. Если мы исполним договор, бухгалтерия будет удовлетворена и нам оплатят работы. Но если будет достигнут только состав договора, кроме бухгалтерии никто не будет удовлетворен, поэтому Клиент больше нам платить не станет.

Передать реальную потребность Клиента в договоре невозможно. Клиент всегда ждет чего-то еще, кроме того, что записано в договоре.

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

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

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

Проект

Мы понимаем, что каждый ПРОЕКТ представляет собой какой-то конечный ПРОДУКТ (или их группу), для произведения которого нам нужно исполнить определенный ПРОЦЕСС.

Пусть у нас стоит задача произвести 2 неких продукта, состоящих из группы процессов.
Условно назовем процессы, ведущие к Продукту 1, Процессной группой 1; а процессы, ведущие к Продукту 2, — соответственно, Процессной группой 2.

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

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

1 Задачи класса Finish-to-start. Это значит, что как только кончается одна задача — разблокируется другая. Самый классический и простой способ обеспечения связности между операциями.

2 Finish-to-finish. Означает что две операции в идеале должны быть завершены одновременно; как только завершается одна задача — завершается и другая. Пример: завершился рабочий день — заверши подачу электричества в верхний световой контур, или, говоря проще, «Уходя — гаси свет!»

3 Start-to-start. Как только начинается одна задача — тут же должна начаться и другая задача. Как только мы запостили пост — мы включаем на него промо

4 Start-to-finish. Как только что-то началось — что-то должно закончиться. Например, как только устроился в PP — больше не ношу на работу шапку. Новый пост появился — со старого сними промо. Когда началось само мероприятие — останавливаешь его рекламу

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

Теперь вы знаете, из каких сущностей состоит проект, как он структурируется