К основному контенту

Почему проекты умирают. Из ПМ-ов в администраторы

Я могу ошибаться, но в реакции на предыдущую публикацию, посвященную этой теме (Как херятся проекты) проскочила такая нотка, что руководителю проекта не обязательно знать продукт, который делает команда. Мол, для этого у него есть лиды и архитектор.

Давайте в этом месте поподробнее остановимся.

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

Проект — это некоторый процесс, направленный на реализацию этапа (этапов) жизненного цикла системы или ее компонентов.

Это с одной стороны. С другой — есть Заказчик со своим бизнесом и приоритетами его развития. Это диктует роадмэп создания системы (вот эти фичи нужны летом, а те — осенью, и т.п.).

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

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

А потом есть еще момент: весь этот отчётошлак еще надо Заказчику объяснить, обосновать и согласовать с ним. Это не просто сделать, когда не понимаешь, почему так и по каждому вопросу бегаешь в команду за консультацией.

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

Комментарии

Популярные сообщения из этого блога

Драйв

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

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

Проект - он как лестница. По нему надо карабкаться вверх, к результату. Не надо вокруг него прыгать. Это бессмысленно.

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

Карта компетенции аналитика

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

Первое, с чем сталкиваешься при попытке определить требования к аналитику, является тот момент, что эти требования разваливаются на три большие категории - требования к теоретическим знаниям, требования к практическим навыкам и требования к опыту использования знаний и навыков.

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

Оценка эффективности работы руководителя проектов

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


Постановка задачи

Необходимо оценить эффективность работы руководителей проектов, выполняющихся по схеме time & material. Сразу оговорюсь, что на мой взгляд предлагаемая методика подходит и для схем fixed coast.

Цель оценки – понять, кто успешно ведет проект самостоятельно, а за кем надо попристальнее присматривать.

Критерии успешности хода проекта:
• Соблюдение бюджета
• Соблюдение плана выполнения проекта
• Отсутствие критических проблем, способных зааффектить бюджет и календарь
• Удовлетворенность Заказчика (субъективно, по отзывам)


В чем идея 

Идея основывается на еженедельной оценке хода проекта по трехбальной системе: красный (проект идет неуспешно), желтый (есть риск завалить проект в красную зону) и зеленый (проект идет успешно).

Успешность проекта оценивается по критериям, изложенны…