Почему проекты умирают. Из ПМ-ов в администраторы
Я могу ошибаться, но в реакции на предыдущую публикацию, посвященную этой теме (Как херятся проекты) проскочила такая нотка, что руководителю проекта не обязательно знать продукт, который делает команда. Мол, для этого у него есть лиды и архитектор.
Давайте в этом месте поподробнее остановимся.
Информационная система имеет некоторый жизненный цикл, который она проходит на протяжении своего создания, развития и использования с момента возникновения идеи до снятия с эксплуатации и утилизации. Туда много чего входит, всякие там приёмо-сдатка, развёртывание, интеграция, миграция и прочие вещи. Отдельные компоненты системы имеют свои жизненные циклы, существующие внутри жизненного цикла ИС.
Проект — это некоторый процесс, направленный на реализацию этапа (этапов) жизненного цикла системы или ее компонентов.
Это с одной стороны. С другой — есть Заказчик со своим бизнесом и приоритетами его развития. Это диктует роадмэп создания системы (вот эти фичи нужны летом, а те — осенью, и т.п.).
Отсюда вытекает, что управление проектом — это не просто про план, как софт написать и галочки расставить сделано — не сделано.
Это про понимание бизнеса, ожидаемых им поставок, возможоности реализации поставок фичей в той последовательности, которую просит бизнес, план внедрения и выхода в эксплуатацию, интеграцию и много чего такого, что без понимания продукта и его архитектуры из полезных вещей превращается в беспомощный набор таблиц с галочками, ведением которых будут заниматься лиды вместо того, чтобы заниматься продуктом и связанными с ним активностями.
А потом есть еще момент: весь этот отчётошлак еще надо Заказчику объяснить, обосновать и согласовать с ним. Это не просто сделать, когда не понимаешь, почему так и по каждому вопросу бегаешь в команду за консультацией.
К чему все это приводит? Менеджер становится проектным администратором, искусно владеющим экселем, а проектная команда вынуждена самоорганизоваться ради скорейшего избавления от проекта.
Давайте в этом месте поподробнее остановимся.
Информационная система имеет некоторый жизненный цикл, который она проходит на протяжении своего создания, развития и использования с момента возникновения идеи до снятия с эксплуатации и утилизации. Туда много чего входит, всякие там приёмо-сдатка, развёртывание, интеграция, миграция и прочие вещи. Отдельные компоненты системы имеют свои жизненные циклы, существующие внутри жизненного цикла ИС.
Проект — это некоторый процесс, направленный на реализацию этапа (этапов) жизненного цикла системы или ее компонентов.
Это с одной стороны. С другой — есть Заказчик со своим бизнесом и приоритетами его развития. Это диктует роадмэп создания системы (вот эти фичи нужны летом, а те — осенью, и т.п.).
Отсюда вытекает, что управление проектом — это не просто про план, как софт написать и галочки расставить сделано — не сделано.
Это про понимание бизнеса, ожидаемых им поставок, возможоности реализации поставок фичей в той последовательности, которую просит бизнес, план внедрения и выхода в эксплуатацию, интеграцию и много чего такого, что без понимания продукта и его архитектуры из полезных вещей превращается в беспомощный набор таблиц с галочками, ведением которых будут заниматься лиды вместо того, чтобы заниматься продуктом и связанными с ним активностями.
А потом есть еще момент: весь этот отчётошлак еще надо Заказчику объяснить, обосновать и согласовать с ним. Это не просто сделать, когда не понимаешь, почему так и по каждому вопросу бегаешь в команду за консультацией.
К чему все это приводит? Менеджер становится проектным администратором, искусно владеющим экселем, а проектная команда вынуждена самоорганизоваться ради скорейшего избавления от проекта.
