Двухслойная модель управления проектами

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

О чем речь вообще?

Речь в первую очередь о том, что результатом проекта является не только продукт, и даже не столько продукт, сколько удовлетворенный Заказчик и полученные от него деньги. Удовлетворение Заказчика достигается поставкой качественного продукта в срок, тогда Исполнитель вправе ожидать денег. Все это достигается соответствующим управлением.

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

В чем разница?

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

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

Суть можно понять из картинки, любезно позаимствованной из книги С.А. Мишина «Проектный бизнес».

ЖЦ разработки включено в ЖЦ проекта. И можно вспомнить, что ЖЦ продукта включает ЖЦ проекта (по ГОСТ 12207 например). Следовательно, качество управления определяет качество дальнейшей жизни продукта.

Так и к чему всё это?

К тому, что именно управление проектом, а не процессом разработки продукта, определяет успех проекта. Просто следовать, например, Agile — это не проектная технология, а пошаговая. Проект, который включает в себя планирование, уже обладает как минимум двумя элементами Waterfall, а именно Планирование и Исполнение. Зачем нужно планирование, и чем пошаговая технология хуже? Это можно проиллюстрировать еще одной картинкой из книги «Проектный бизнес».


На самом деле, всё упирается в то определение проекта, которое Вы даете своим (корпоративным) проектам. Если это временной предприятие по достижению результатов (по PMBOK) — то это и будет временным предприятием по достижению результата. Если проекты достаточно похожи друг на друга, и следуют определенной технологии разработки продукта, то и определять можно более точно. С этой точки зрения, Agile — это технология разработки продукта, а стандарт управления проектом — отдельно.

Заключение

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

В общем, взвешивайте все за и против, когда решаете как разрабатывать продукт. Спасибо за внимание, не забывайте писать в планах управленческие активности, и удачи Вам в совершенствовании!