Тел.: +38 044 495 45 37
Линия консультации: +38 044 360 41 19

Управление проектами в ИТ – 10 противоречий. Противоречие второе.

Во второй статье из цикла «Project Management – on spec, on time, on budget» рассматривается проблема самовольного замедления движения проекта и предлагаются методы ее решения.

Противоречие второе. Все что-то делают. Но проект не движется.

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

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

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

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

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

Мы рассмотрели возможные последствия развития ситуации в условиях возникновения технической проблемы в проекте. Что можно сделать, чтобы избежать начавшегося торможения проекта и возниконовения последующих проблем? В данной ситуации приветствуется любая деятельность, направленная на преодоление пробуксовки проекта – здесь важно понимать что бездействие недопустимо. Даже неверное решение менеджера проекта теперь будет лучше чем никакого решения. Самым простым и возможно самым действенным методом будет пересмотр ближайшей цели, и установка на выпуск промежуточной версии включающей проблемную область. Весьма вероятно, это будет единственной целью данной версии – добавить в проект функцию, которая неявно тормозит все остальные работы и пассивно вносит дезорганизующее начало в проектную группу.

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

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

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

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

Продолжение следут.

Автор: Вадим Печерица, специально для сайта Искусство управления проектами.

При перепечатке ссылка на источник обязательна.

http://www.prjman.ru

Copyright © IT-Artel.