Читать книгу Управление проектами. Правильный путь для начинающих - Петр Дикий - Страница 11

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

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

Термины «качество» и «одобрение клиента» определяются тремя факторами, между которыми руководитель проекта и проектная команда всегда должны держать проект в балансе между стоимостью, временем и объемом. Проектная команда с руководителем проекта не могут однозначно предсказать стоимость и время, необходимые для реализации проекта, но они действительно могут контролировать его объем. А вот уже исходя из объема можно установить сроки проекта и стоимость. Конечно, это грубое приближение к реальности, но суть верна. Объем определяет, за что отвечает проектная команда и, что не менее важно, за что она не отвечает. Только после того, как объем работ установлен, тогда цели, задачи и сроки могут быть четко определены. Попробую пояснить на примере, так как логика может быть не явно видна. У вас появился новый проект (иногда говорят «зашел» проект), из описания только «хотелки» клиента, а это значит конкретики, что делать и какова область применения (поговорим чуть ниже о ней) нет и, естественно, о сроках речи быть не может. Вы сначала формируете описание проекта, изучив которое можно спрогнозировать, какой может быть функционал проекта и его особенности, сколько может потребоваться времени на реализацию такого функционала (плюс риски), разбить на блоки и составить приблизительный план разработки проекта. После согласования проекта с клиентом можно будет приступить к проработке технического задания, а далее согласовать с клиентом. Функциональные блоки, в свою очередь, разбивают на задачи и подзадачи. Далее следует оценка задач с учетом рисков и временем на проверку, и тестирование. Руководитель проекта собирает их в список, планирует последовательность и расставляет приоритеты, далее следует этап проставления сроков (ведь мы понимаем, что временная оценка не равна сроку, через который будет сдача задачи заказчику). На этом этапе идет проставление сроков реализации с учетом отпусков, других проектов (если сотрудник задействован еще где-то) и рисков на пропуски рабочих дней (отгулы, болезнь и так далее). И вот тут, имея финальный объем работ и ресурсы, руководитель проекта может понять сроки на разработку проекта.

Хочу вернуться к важному параметру, который упомянул выше – «Область применения», обычно она определяется на первом этапе. Наиболее важной целью области применения является то, что она устанавливает ограничения на функционал в проекте (а иногда и больше). Замечу, что все, что находится за пределами области применения и допустимого объема работ, может оказать негативное влияние на результат проекта.

Давайте опишу еще одну проблему – появление новой и незапланированной работы в середине итерации или проекта. Подобное явление называют – «ползучесть области».

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

1. Новая задача обычно должна вводиться только во время планирования Спринта (Sprint).

2. Новая задача, которая имеет приоритет над текущей задачей, требует раннего завершения текущего Спринта и возврата к планированию нового Спринта.

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