Управление ИТ-проектом.
Эффективная система «с нуля» в любой организации

Селиховкин Иван
Санкт-Петербург – 2010

Назад Содержание Вперёд

Глава III. Как определиться с подходом к проектному управлению?

Входы:

• решение об участии в проекте

Нужна ли нам методология?

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

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

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

Выбираем методологию

В настоящий момент, к числу наиболее распространенных практик и подходов к управлению в ИТ-проектами можно отнести:

Название	Автор	Предметная область
Методология PMI	Международный некоммерческий институт управления проектами	Не привязана к предметной области
Методология IPMA	Международная ассоциация управления проектами	Не привязана к предметной области
Методология PRINCE2	Центральное компьютерное и телекоммуникационное агентство Великобритании	В настоящий момент не привязана к предметной области (исходно ориентирована на ИТ-проекты)
Методология MSF	Корпорация Майкрософт	Ориентирована на разработку ПО
Методология RUP	Корпорация Rational Software	Ориентирована на разработку ПО
Группа методологий Agile	Альянс agile (глобальная некоммерческая организация)	Ориентированы на разработку ПО
Набор моделей CMMI	Университет Карнеги-Мелона	Ориентированы на разработку ПО

Как уже говорилось, «опорной» методологией для данной книги является PMI, основные положения которой изложены в соответствующем своде знаний (PMBoK). От сравнительного анализа методологий мы воздержимся, отметив лишь, что многие из них схожи между собой (в особенности «универсальные» PMI, IPMA и PRINCE2).

Компоненты проекта

Мы уже говорили об ответственности менеджера проекта (за «треугольник» и за «проект в целом»). Настало время точнее определить оба тезиса и пояснить саму сущность проекта

Введем два термина: «продукт» и «проект».

Продукт – результат (или набор результатов) поставки по контракту. Продукт- это то, что хочет получить заказчик.

Проект – это процесс создания продукта. Это то, что делает команда, чтобы выдать заказчику продукт. Заказчику, обычно, проект не интересен.

Любой проект предпринят с целью получить продукт.

Заказчик согласен заплатить и подождать. Причем и то и другое – в ограниченном количестве.

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

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

Таким образом, некоторые блоки работы ПМ становятся интуитивно понятны сразу же:

1. Управление временем (мы должны уложиться в срок)
2. Управление стоимостью (мы не должны превысить бюджет)
3. Управление содержанием (нам нужно уточнить желания заказчика и правильно их реализовать)

Другие – менее очевидны:

4. Управление качеством
5. Управление рисками
6. Управление закупками (если мы используем субподрядчиков)
7. Управление персоналом
8. Управление коммуникациями
9. Управление интеграцией

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

Два других важных аспекта, которые часто ускользают от внимания ПМ-, но имеют прямое отношение к успеху проекта: «удовлетворенность заказчика» и «документирование лучших практик».

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

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

Жизненный цикл проекта

Начало проекта принято называть «инициацией», а окончание – «закрытием».

Между этими двумя событиями располагаются (нелинейно) планирование, выполнение работ и «мониторинг и управление». Нелинейность в том, что данные процессы последовательны, но итеративны (т.е. повторяются). Так, единожды спланированный проект начинает выполняться и «отслеживаться», однако по мере выполнения работ отслеживание выявляет накопившиеся «потребности в изменениях». Первоначальные планы корректируются, разработка и дальнейший мониторинг ведется уже по ним. И так далее.

Таким образом, жизненный цикл проекта можно представить в виде «удава»:

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

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

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

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

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

Осматриваемся вокруг

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

Для простоты мы будем придерживаться представления о том, что вы работаете в средней ИТ-компании (численность до 200 человек), с матричной структурой, а сколько-нибудь сложившихся проектных практик не используется.

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

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

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

Выходы:

• определен подход к управлению проектами

Глава IV. Начинаем управлять проектом – инициация

Входы:

• определен подход к управлению проектами
• информация по предстоящему проекту от заинтересованных лиц

Определяем спонсора проекта

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

Давайте сейчас введем понятие «спонсора».

Спонсор проекта – это фигура, обеспечивающая проект финансовыми ресурсами. Задумаемся над этим определением.

Ведь мы с вами отныне смотрим на проект газами ПМ. Значит спонсором для нас является тот, кто НАМ утверждает стоимость проекта (а также что за эту стоимость стоит сделать). Спонсором может выступать сам заказчик (если нам поручили непосредственно договариваться с ним о цене, с поправкой на ожидаемую прибыль компании). Нередко спонсором выступает и высший или средний менеджмент нашей организации (например, когда проект уже продан без нас, а директор лишь поручает нам его выполнить, объявляя о доступном финансировании и сроках).

Всегда определяйте спонсора на проекте! Это знаковая фигура для вас, как для ПМ.

Договариваемся со спонсором проекта

Итак, мы получили приглашение на совещание со спонсором (кем бы он ни был). О чем нам стоит позаботиться?

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

Помните, о чем говорилось в главе II – ответственность ПМ лежит в рамках «проектного треугольника». Создавайте его. Не позволяйте сделать вас ответственным за проект, не имеющий рамок, или фиксируйте их отсутствие.

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

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

Грубые оценки (ROM-estimate) – предполагают отклонение до 50%.

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

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

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

Формируем устав проекта

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

Устав проекта, обычно, не регламентирует отношений между вашей организацией и заказчиком. Устав проекта – это то, до чего вы договорились со спонсором (помните – спонсором может быть, например, ваш директор).

Фундаментальное свойство устава – его неизменность. Это самый стабильный документ проекта (именно потому, что он задает базовые рамки). Нередко, когда у спонсора или у команды возникает необходимость «поменять устав» – принимается решение просто закрыть текущий проект и запустить новый (с новым уставом).

Почему устав так важен? Причин две.

Причина первая: устав наделяет полномочиями менеджера проекта. Именно благодаря уставу ПМ может требовать себе на проект нужное количество разработчиков, тестировщиков, аналитиков и так далее, а, зачастую, еще и настаивать на определенной квалификации кадров. Это крайне важно, если в вашей организации выполняется множество проектов одновременно и, скажем, начальник отдела разработки вовсе не заинтересован отдать своего лучшего программиста вам на 5-6 месяцев.

Причина вторая: устав фиксирует треугольник. Вы ПМ и вы договорились со спонсором. Условия устава должны совпадать с условиями контракта (который ваша компания заключит с заказчиком), или, по крайней мере, не противоречить им. Представьте, что через несколько месяцев спонсор-директор, от лица вашей компании заключил с заказчиком дополнительный договор (расширяющий рамки проекта). Вас это не волнует! У вас есть устав. Новые договоренности могут стать предметом нового проекта (возможно «вашего нового проекта», если вы согласитесь в нем участвовать). Устав позволяет отделить ваши обязательства по проекту от обязательств вашей компании по контракту.

Кто пишет устав?

Лучшие практики гласят: устав создается ПМ и утверждается спонсором. Как будет показано ниже – руководитель проекта максимально заинтересован в уставе (а с ним и вся команда, которой он руководит). Посему создание устава – дело ваших рук; если не проявите инициативу – документ не появится.

Как вам написать свой устав проекта? Один из возможных примеров приведен в Приложении 1. Многие аспекты пояснены внутри самого шаблона.

Некоторые разделы устава могут оказаться неактуальными на вашем проекте. Другие – стоит заполнять всегда , перечислим их:

1. ФИО ПМ

2. Тройственное ограничение:

   1. Срок
   2. Бюджет
   3. Содержание работ по проекту (укрупненно)
3. Заинтересованные лица (самые ключевые – как минимум спонсор и заказчик)

Пункты 2 и 3 иллюстрируют, что вклад в планирование проекта начинается задолго до его начала.

Заинтересованные лица проекта – все люди, интересы которых затрагивает реализация проекта (положительным или отрицательным образом).

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

Чего не стоит делать в ходе инициации проекта

Специфика фазы инициации в том, что решения даются легко, но стоят дорого. Перечислим некоторые возможные ошибки менеджера проекта в данной фазе:

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

Нельзя использовать раздувание оценок (padding). Как бы ни была сложна ваша оценка – не перестраховывайтесь, завышая ее. Оцените проект как можете и назовите диапазон колебания (+/-50%). Если диапазон получается больше – ищите способ повысить точность оценок, или предложите спонсору разбить его на несколько подпроектов. Не бойтесь давать оценку с диапазоном. Это на много лучше, чем назвать конкретную цифру, не явно завысив ее на «на всякий случай». Подобное поведение называется padding и является не этичным для менеджера проектов.

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

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

Выходы:

• спонсор утвердил руководителя проекта
• объявлено о запуске проекта
• утвержден устав проекта

Назад Содержание Вперёд