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

Управление проектами в ИТ – 10 противоречий и 10 способов их решения

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

Каждый, кто хоть раз управлял проектом в области информационных технологий, знает что уникальные и не очень методологии управления, разнообразные подходы и практики, мощнейшие инструменты управления проектами — все это как будто и не приближает к решению основного вопроса управления проектами — как не превысить бюджет, выдержать сроки и выдать продукт требуемого качества. Предлагаем вашему вниманию подборку из статей о десяти проектных противоречиях, решение которых дает шанс проекту быть успешно завершенным. Итак, Art of Project Management  – on spec, on time, on budget.

Противоречие первое. План – всему голова. Но планируем не через голову.

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

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

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

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

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

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

Если у вас нет технического задания на проект или спецификации, лучше всего начать искать новую работу уже сейчас

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

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

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

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

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

Как это можно сделать: спросить архитектора системы, спросить ведущего разработчика или провести мини-брифинг во время кофе-брейка с 2-3 основными разработчиками. Чего делать не следует: не следует организовывать совещание с повесткой дня, протоколом и заранее назначенным временем проведения, не следует совещаться с топ-менеджментом. Причины очевидны и останавливаться на них не будем

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

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

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

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

Итог проделанной работы: вы составили реальный план выполнения проекта, хотя он и не полный с точки зрения функциональности разрабатываемой системы. Его главное достоинство на данный момент – он реален, и работы по нему начаты. Первое противоречие управления проектами устранено.

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

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

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

http://www.prjman.ru

Copyright © IT-Artel.