Цитаты из книг автора «Сергей Дерцап»

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

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

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

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

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

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

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

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

Приведенная выше схема описывает идеальную ситуацию. И в таком мире я хотел бы жить: мы встречаемся со спонсорами, определяем, что именно будем делать, и подписываем договор. Далее я иду к архитектору, и мы разрабатываем план проекта. Спланировали, расписали, что и как будем делать, и с первой попытки заказчик утвердил наш план. Мы собираем команду и начинаем работать. Работаем. Заканчиваем. Сдаем проект с первого раза. Запускаем новый. Реальность же совсем иная: обычно работать нужно быстро. Поэтому, как правило, нет времени выполнять все процессы управления проектами последовательно. Чтобы сэкономить время, мы начинаем выполнять процессы параллельно, и они накладываются друг на друга. Например, спонсоры еще обсуждают условия контракта, а мы уже начинаем детально планировать проект, собирать команду и запускаем первые работы. В этом подходе есть большой плюс: проект завершается быстрее. Но есть и большой минус: если работы начались, а стороны так и не договорились, то все было зря. Это та плата, которую бизнес должен быть готов заплатить за скорость.

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