Благодарности

Выражаю благодарность моим друзьям и коллегам, внесшим вклад в создание данной книги, в особенности Дмитрию Письману – аналитику и руководителю проектов компании «С-Консалт».

Будем ли привлекать подрядчиков?

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

Некоторые из «лучших проектных практик» рекомендуют такой подход:

Обязательно использовать субподряды:

Если это снижает риски проекта

Можно использовать субподряды:

Если мы бережем (читай «испытываем дефицит») собственных ресурсов Если мы пытаемся повысить управляемость проекта Если сталкиваемся с необходимостью использовать патенты / сертификаты и т.п.

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

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

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

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

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

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

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

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

Выходы:

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

Что такое проект?

Одно из самых простых определений гласит: проект это все, что имеет «начало, конец и цель».

Таким образом, когда в вашей организации предполагают запуск нового ПРОЕКТА – речь всегда идет о чем-то «конечном» и имеющим цель. «Разрабатывать программные продукты» – это не проект. Проект это, например, «создание и внедрение информационной системы XXY к 1 декабря следующего года».

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

Еще один аспект – масштабы проекта. Существует множество взглядов на этот вопрос. Согласно одному из них (которого я буду придерживаться в этой книге) менеджер, как обособленная фигура, обычно нужен на проектах, продолжительность которых превышает несколько месяцев, бюджет – хотя бы 50.000 долларов, а команда состоит не менее чем из 4-5 человек. Проекты меньшего размера, нередко, могут прекрасно обходиться «тим-лидерами». Если вам предлагают взять управление маленьким проектом – обязательно поинтересуйтесь, почему возникла такая необходимость и какова потенциальная роль в нем ПМ.

Что такое риски проекта?

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

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

Риск – это вероятностное событие, которое может оказать положительное или отрицательное влияние на проект.

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

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

Работу с рисками можно представить в виде набора последовательных процессов (шагов).

Что такое «содержание проекта»?

Содержание проекта – описание работ, которые необходимо выполнить, чтобы получить продукт.

Для описания ВСЕХ необходимых работ по проекту нужно: определиться с требованиями и ожиданиями заказчика, разобраться, какие из них реально выполнимы, и что для этого понадобится.

На языке нашей методологии данные шаги звучат следующим образом:

Собрать и финализировать требования Сформировать концепцию Создать ИСР (WBS)

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

Первый шаг (собрать и финализировать требования) неявно включает в себя два компонента: выявление заинтересованных лиц и собственно сбор требований. Об этом подробнее мы поговорим ниже.

Дело 1. Отслеживать выполнение работ

Главная задача ПМ – удержать проект в треугольнике. В фазе начального планирования мы приложили немало усилий, чтобы уточнить его границы (сформировали ИСР, расписание и бюджет).

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

Сбор показателей прогресса

Специализированное ПО, которое мы используем для ведения ИСР, расписания и бюджета – обычно удобно использовать для «отметок о прогрессе». Однако не заставляйте команду использовать его, если не уверены, что так будет удобнее ВСЕМ! Всегда можете запросить отчет по электронной почте, а результат самостоятельно ввести в программу (или поручить это помощнику).

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

Порой, члены команды сопротивляются любым отчетам (что предсказуемо, ведь они прекрасно понимают – за свои оценки потом придется отвечать перед ПМ). Кроме того, достоверность оценок на ИТ-проектах всегда является предметом споров (как можно измерить умственную, творческую работу? как, занимаясь написанием или отладкой программного обеспечения с уверенностью утверждать, что проделано, скажем, 30% или 80% от общего объема?).

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

Проектные практики предполагают несколько вариантов «измерения прогресса»:

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

Вариант 2. – «правила». Данный подход предполагает использование определенного правила для измерения всех незавершенных работ (например, « 20/80» или «0/100»), чтобы «хоть как-то измерять неизмеримое». Это худший способ – избегайте его, по возможности, и используйте лишь как последний способ «что-то измерять».

Так, при использовании правила «20/80», – как только работа начата, мы сразу считаем ее выполненной на 20% (и можем внести соответствующие пометки в свое расписание). Мы не отслеживаем реальный прогресс и ни о чем не спрашиваем исполнителя. Лишь, получив от него уведомление, что работа завершена – добавляем 80% в свой график и считаем работу оконченной.

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

Пример – метод «ожидаемой стоимости задач» (estimated activity value), который, на основании ряда индексов и диапазонов, позволяет определить – насколько эффективно проект соблюдает расписание и бюджет.

Анализ показателей и внесение корректив в расписание

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

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

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

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

Анализ показателей и внесение корректив в предельную стоимость проекта

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

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

Дело 2. Управлять рисками

Управление рисками осуществляется в течение всего проекта, до его закрытия.

Работа ведется на основании реестра рисков, который мы сформировали в главе X. С его помощью:

отслеживаются триггеры риска и приводится в действие План Б (силами «хозяев рисков») выявляются новые риски (силами команды и прочих заинтересованных лиц) переоцениваются старые рисков (силами команды)

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

Дело 3. Управлять изменениями

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

Изменения призваны обеспечить проекту «самонаведение» на цель (внося корректировки в «траекторию» – в состав работ). Но в чрезмерном количестве они приводят к обратному эффекту – исчерпав ресурсы проект вовсе «не долетает» до цели.

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

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

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

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

Дело 4. Управлять ожиданиями заказчика

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

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

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

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

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

Представляйте процесс «сдачи продукта» с самого первого дня. Используйте тот же прием, что и в управлении рисками – спрашивайте себя «что будет, КОГДА придется сдавать проект».

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

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

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

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

Дело 5. Мотивировать и развивать проектную команду

Мотивируем сотрудников

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

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

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

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

Развиваем команду

В профессиональное развитие команды серьезный вклад вносят «хозяева ресурсов». Именно «начальники отделов» призваны следить за тем, чтобы квалификация подчиненных соответствовала поставленным задачам и постепенно росла, а непосредственно в работе корректно использовались эффективные методики.

Однако и руководитель проекта вносит свой вклад в развитие коллектива. Его задача – тим-билдинг.

Тим-билдинг – организация эффективной командной работы.

Во-многих организациях этот термин дискредитирован корпоративными вечеринками или нелепыми (с точки зрения многих сотрудников) тренингами.

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

Обратите внимание на еще один, важнейший аспект тим-билдинга – совместное планирование. Мы неоднократно использовали этот прием в ходе первоначального планирования проекта, и стоит продолжать это делать в течение всего проекта. Вовлечение членов команды в формирование ИСР, расписания и прочих элементов плана значительно повышает эффективность их взаимодействия.

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

Дело 6. Отчитываться о выполнении проекта

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

Проявите инициативу. Предложите спонсору форму простого ежемесячного отчета (например, в формате графика вех – см. главу VIII). Держите его в курсе событий.

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

Выходы:

Запросы на изменения Изменения плана управлением проекта Отчеты о выполнении Продукт проекта Запросы на изменения

Для чего нужны планы?

Устав подписан. «Хвост удава» миновал. Следующий наш шаг – планирование. Ему в проектном управлении отводится особое место. Одна из парадигм гласит – «если это нельзя спланировать, это нельзя и сделать».

Для чего нам нужны планы:

Чтобы не забыть что-то существенное во время выполнения проекта Чтобы любой член команды сам, не «дергая» менеджера, в любой момент времени ПОНИМАЛ, «что ему делать сейчас» Чтобы общаться.

Для чего планы не нужны:

Для наказания Как самоцель.

Необходимо осознать что планы – это средство коммуникации.

Значимость коммуникаций неизмерима, а сбой – всегда бедствие.

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

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

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

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

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

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

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

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

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

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

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

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

Другие элементы плана

«План управления проектом» не ограничивается перечисленными выше элементами.

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

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

Управление изменениями

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

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

Управление конфигурациями

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

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

Более того, сотрудник должен ЗНАТЬ, какой документ последний и как это проверить. Изучая, скажем, реестр рисков – читатель должен быть уверен, что видит перед собой актуальный перечень, что пополняя его – он не делает «пустую работу» (если где-то хранится более свежая версия, уже заполненная на ту же тему кем-то другим).

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

Неважно, используете ли вы централизованно опубликованный файл электронной таблицы, или развернутое в многопользовательском режиме специализированное ПО, или деревянную доску в переговорной (ежедневно пришпиливая кнопками распечатки актуальных версий). Главное – позаботьтесь о том, чтобы каждый ваш сотрудник был УВЕРЕН – он имеет доступ к актуальной информации. Не стоит недооценивать разрушительную силу подозрений «может я работаю со старым документом?…».

План закупок

В главе VII мы говорили о том, что, возможно, станем использовать подрядчиков на проекте.

Если данное намерение реализовалось – не забудьте, что контролировать закупки на проекте – это ваша головная боль. Занимайте активную позицию по отношению к другим службам. Заранее узнавайте- как устроен процесс закупок и поиск подрядчиков ,и сколько времени он может занять. Помните, если «они» провалят вам закупки – это будет проблема ВАШЕГО проекта, а значит и ваша ответственность.

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

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

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

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

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

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

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

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

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

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

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

ФИО ПМ

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

Срок Бюджет Содержание работ по проекту (укрупненно)

Заинтересованные лица (самые ключевые – как минимум спонсор и заказчик)

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

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

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

I. О чем эта книга?

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

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

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

Книга основана на адаптации стандарта PMBoK 4-th edition (свод знаний Международного некоммерческого института управления проектами) к реальному применению на ИТ-проектах. Одна из целей – показать, как используются основные положения стандарта в практике руководителя, в чем возможности «настройки» системы под себя и как все это может работать.

Специфика данной книги:

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

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

энтузиазм	«Я изучу подходы от наиболее авторитетных авторов и буду использовать их в своем проекте»
разочарование	«Как можно управлять ожиданиями, если контракт уже подписан? Мои планы все равно никто не читает»
агрессия	«Не говорите мне о проектном менеджменте – книги о нем пишут те, кто не видел в глаза ни одного проекта»
удивление	«Ого, я, кстати, изобрел такой же документ, что описывается в PMBoK; да и изменениями мы управляем точно также»
принятие	«Интересно, зачем я изобретал велосипед?»

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

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

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

По ходу повествования будут вводиться специальные термины и сокращения – их общий список приведен в конце книги (раздел «Глоссарий»).

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

Входы:

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

IX. Планируем ответственность, коммуникации, качество

Входы:

Концепция проекта ИСР (WBS) и ресурсы, распределенные по работам Команда проекта

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

VI. Планируем содержание

Входы:

устав проекта состав «плана управления проектом»

VIII. Планируем время и стоимость с использованием специализированного ПО

Входы:

Концепция проекта Матрица требований Список ресурсов Команда проекта (ключевые сотрудники по списку ресурсов)

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

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

Сразу подчеркнем:

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

Конкретный программный продукт не имеет значения. В настоящий момент на рынке существует множество платных и бесплатных решений, самые распространенные из них: MS Project, Spider Project, Primavera, Prince.В настоящей книге мы будем использовать иллюстрации на базе MS Project 2010.

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

X. Планируем и работаем с рисками

Входы:

ИСР и ИСР-словарь Расписание Оценки предельной цены проекта Список ресурсов проекта

XIII. Закрытие проекта

Входы:

устав концепция проекта продукт проекта

Закрытие проекта – это процесс в самой «голове удава». Проект близок к окончанию. В этой фазе нам предстоит:

Провести сдачу-приемку продукта (проект закончен для заказчика) Высвободить ресурсы (проект закончен для спонсора) Задокументировать и сделать доступной всю важную информацию по проекту (проект закончен для ПМ)

XIV. Что дальше?

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

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

Изучите методологическую специфику управления программами и портфелями – рано или поздно вам придется столкнуться с управлением несколькими, как-то взаимосвязанными проектами.

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

Удачи вам в ваших проектах!

Глоссарий

Балансировка требований – отбор требований, реализация которых предполагается в рамках проекта. Бюджет проекта – это сумма предельной цены проекта (cost baseline) и управленческих резервов (management reserves). Определяется спонсором. Веха – это работа с нулевой длительностью (используется при создании расписания проекта, чтобы обозначить значимый этап). Грубые оценки (ROM-estimate) – предполагают отклонение до 50%. Применимы в фазе инициации проекта. Заинтересованные лица проекта – все персоны, на интересы которых влияет реализация проекта (положительным или отрицательным образом). Золотая сервировка (gold platting) – добавление в продукт возможностей и функциональности, которая хоть и приятна заказчику, но не была им запрошена и не является необходимой для закрытия работ. Иерархическая структура работ (ИСР) (WBS) – поставко-ориентированная, иерархическая декомпозиция работ, выполняемых командой проекта для достижения целей проекта и необходимых результатов поставки. Качество – это уровень выполнения работ, при котором создаваемый продукт удовлетворяет предъявленным требованиям. Качественный анализ рисков – это субъективная оценка выявленных рисков. Мы должны определить – как сильно тот или иной угрожает проекту. Количественный анализ рисков – это форма объективной оценки риска. Ему подвергаются только «значимые» риски, отобранные в ходе предыдущего шага. Критический путь – отражает самый длинный путь в сетевой диаграмме и самое короткое время, за которое можно выполнить проект. У одного проекта может быть более одного критического пути. Ожидание – «умозрительная картинка будущего». Как правило – достаточно широкая. Ожидание нельзя включить в состав проекта, не преобразовав в требование. Пример ожидания: «чтобы производительность отдела возросла после внедрения ИТ-системы»; или «чтобы внедрение проекта не сильно сказалось на работе соседнего департамента». План управления проектом – это совокупность всех проектных планов. ПМ – проектный менеджер (аббревиатура) Предельная цена проекта (cost baseline) – это сумма себестоимости всех работ по проекту и стоимости всех резервов на непредвиденные случаи (contingency reserves). Определяется менеджером проекта. Продукт – результат (или набор результатов) поставки по контракту. Продукт, это то, что хочет получить заказчик. Проект – это процесс создания продукта. Это то, что делает команда, чтобы выдать заказчику продукт. Заказчику, обычно, проект не интересен. Риск – это вероятностное событие, которое может оказать положительное или отрицательное влияние на проект. Содержание проекта – описание работ, которые необходимо выполнить, чтобы получить продукт. Список ресурсов – совокупность договоренностей о выделении ресурсов на проект. Спонсор проекта – это фигура, обеспечивающая проект финансовыми ресурсами. . Требование – конкретный, измеримый, проверяемый запрос заинтересованного лица. Пример требования: «система должна позволять проходить все пользовательские сценарии без использования манипулятора «мышь»».

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

Готовимся к запуску работ

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

Время браться за работу!

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

Выходы:

Окончательный «план управления проектом»

Как писать правильные планы?

Создавая планы – важно правильно к ним относится.

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

Планируйте с «диапазоном». Не выдавайте (и не требуйте) точную оценку там, где ее дать нельзя. Донесите до всех членов команды и экспертов, которые помогают вам планировать проект, что вы не просите с них клятву «уложиться к определенной дате», вам нужна реалистичная оценка и возможные отклонения от нее. Однако настаивайте на реалистичности оценок. Говоря об инициации проекта, мы отмечали, что приемлемой является «грубая» оценка (с диапазоном колебания до +/-50%). В ходе планирования такая точность нас не устраивает. В зависимости от того как глубоко мы продвинулись – приемлемым диапазоном может быть +25/-10% или +/-10% и так далее.

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

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

Как планировать качество?

Планирование данной сферы предполагает ответы на главные вопросы: «что есть качество на нашем проекте?» и «как мы будем его достигать?».

На первый вопрос помогут ответить документированные требования (концепция проекта + ИСР + Словарь ИСР) и компетентные мнения нашей команды.

Документированные требования позволяют нам понять ожидание заказчика и пользователей, а командные усилия – найти способ их достижения. Как построить работы, чтобы действительно выдать заказчику систему, функционирующую в режиме 24*7*365, как он и просил? Как реализовать информационный обмен и устранение коллизий между распределенными системами, в объеме доступных нам спецификаций? На подобные вопросы ищут ответы эксперты вашей команды (возможно, при помощи «хозяев ресурсов»).

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

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

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

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

Выходы:

Дополнительные документы, описывающие ответственность (матрица ответственности / текстовые описания) Договоренности об отчетах (устно или письменно) Представление о способах контроля качества Запросы на изменения

Какие ресурсы потребуются?

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

Для проведения таких оценок нам потребуется хорошо спланированное содержание проекта (см. главу VI) и понимание доступных вам ресурсов и возможностей внутри организации (с этим могут помочь устав и общение со спонсором и хозяевами ресурсов).

Остановимся подробнее на оценке ресурсов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы правда этого хотим?

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

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

Выходы:

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

Новая должность

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

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

Помните, выбор у вас есть (даже если ваше назначение носит форму приказа). Всегда рассматривайте ваше назначение как предложение и реагируйте на него осознанно!

Что нужно знать, принимая назначения на должность?

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

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

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

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

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

Об авторе

Селиховкин Иван занимается управлением ИТ-проектами с 2005 года.

Участвовал в реализации десятков проектов в сфере заказной разработки и бизнес-консалтинга. Осуществлял работы для таких заказчиков как: Администрация Санкт-Петербурга, Федеральные службы и агентства (ФМС, Росздравнадзор и прочие), ГУП «Топливно-энергетический комплекс» Санкт-Петербурга, ОАО «Преображенская база тралового флота», Tieto Corporation.

Специализируется на систематизации и внедрении проектных практик на предприятиях.

PMP.

Оцениваем свои полномочия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выходы:

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

«План управления проектом»

Введем новый термин

План управления проектом – это совокупность всех проектных планов.

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

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

Определимся с составом плана управления проектом.

Помните «области знаний» (из главы III)? Над каждой из них нам придется поразмыслить и описать в составе собственного элемента плана с разумной подробностью. Кроме того, потребуется дополнительно описать общие правила реализации проекта (сюда относятся, например, правила управления конфигурациями).

Возможный состав плана управления проектом:

План управления содержанием План управления временем План управления стоимостью План управления рисками План управления качеством План управления закупками План управления коммуникациями План управления сотрудниками

План управления конфигурациями Описание общих принципов «как мы будем планировать»

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

А вот процесс первоначальной разработки плана может быть точно регламентирован и предполагает четкую последовательность шагов. Один из вариантов «лучшей практики» приведен ниже.

Возможный алгоритм планирования:

Определить, как будет строиться планирование

 

Собрать и финализировать требования

 

Сформировать концепцию (scope)

 

Принять решение «что закупаем»?

 

Определить команду

 

Создать ИСР (иерархическую структуру работ) (WBS)

 

Создать перечень действий (activity list)

 

Создать сетевую диаграмму (network diagram)

 

Оценить требуемые ресурсы

 

Оценить продолжительность действий и стоимость

 

Сформировать расписание

 

Создать бюджет

 

Планировать качество – создать метрики

 

Создать план улучшения процессов

 

Распределить роли и ответственности

 

Создать план коммуникаций

 

Спланировать управление рисками, идентифицировать риски, качественный анализ, количественный анализ, планировать реагирование на риски

 

Все повторить

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

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

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

«План управления проектом» и контракт

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

В ходе планирования мы последовательно уточняем первичные оценки, корректируем их. При этом, для ПМ существенным моментом является соотношение проектной документации и договорной.

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

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

увеличить

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

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

Выходы:

определен состав «плана управления проектом»

Планируем качество

Что означает термин «качество»?

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

Качество – это некий уровень выполнения работ, при котором создаваемый продукт удовлетворяет предъявленным требованиям.

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

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

«Золотая сервировка» является злом, причем в сфере ИТ, часто – трудноискоренимым. Разработчикам, аналитикам и прочим членам команды свойственно увлекаться своими делами, или (того хуже) переключаться с «трудных задач» на «интересные».

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

Планируем коммуникации

Распределяя ответственность – самое время договориться о коммуникациях.

Этот, во многом интуитивно-понятный аспект управления проектом, по некоторым данным, отнимает у ПМ до 90% его рабочего времени. Правильно спланированные коммуникации помогут вам серьезно снизить собственные трудозатраты.

Очень существенным является выбор метода. Будет ли общение на ту или иную тему вестись устно или письменно? В последнем случае – требуются ли согласовательные подписи (и чьи) или можно ограничиться сообщением по электронной почте? Важен ли формат такого письма?

Руководствуйтесь здравым смыслом.

Наиболее существенные аспекты коммуникаций, которые всегда стоит оговаривать в любом проекте это:

Отчеты команды о выполненных работах Методы коммуникаций с представителями заказчика и пользователями Коммуникации со спонсором

Отчеты команды о выполненных работах.

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

Однако, есть несколько общих правил, которых стоит придерживаться на любом проекте:

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

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

Методы коммуникаций с заказчиком

Правила таких коммуникаций важны не только для «фиксации договоренностей», но и для соблюдения субординации.

Аналитику понадобилось съездить на объект и еще раз переговорить с пользователем – можно ли ехать сразу? Или позвонить пользователю и уточнить удобное время? Или обязательно каждый раз договариваться с его начальником?

А что если возникли вопросы к самому заказчику (скажем, директору крупного завода)? Удобно ли ему позвонить на мобильник? Или через секретаря? Или послать вопрос почтой? Или по всем вопросам за заказчика решения принимает его заместитель, и директора лучше вовсе не беспокоить?

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

Коммуникации со спонсором

Главное, что интересует спонсора в ходе выполнения проекта – укладывается ли тот в треугольник сейчас и сохранится ли это по окончании проекта? Как правило, нюансы хода работ спонсора не очень волнуют (для этого он нанял вас).

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

Подводя итог под уточнением треугольника

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

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

Грань «содержание»: Концепция + ИСР (WBS) + словарь (WBS Dictionary) Грань «время»: расписание Грань «стоимость»: предельная цена проекта (cost baseline)

Обратите внимание – планы никогда не должны противоречить уставу в ущерб интересам спонсора (т.е. можно сделать работы дешевле, но не дороже; быстрее, но не медленнее и т.п.).

Выходы:

ИСР (WBS) Сетевая диаграмма Перечень действий Ресурсы, распределенные по работам Оценки продолжительности работ и методики их расчета Оценки стоимости работ и методики их расчета Расписание Предельная цена проекта Запросы на изменения

ndash; Реестр заинтересованных лиц

Инструкции по заполнению реестра заинтересованных лиц:

NB: строки "проект" и "PM" обязательны для заполнения (соответственно – вносится название проекта и фамилия и имя менеджера проекта)

Поле	Алгоритм заполнения
ID	Уникальный идентификатор требования (st + инкремент)
Имя	Фамилия и имя заинтересованного лица
Роль в проекте	Проектная роль (пользователь, эксперт, спонсор, член команды и т.п.)
Должность	Занимаемая заинтересованным лицом должность
Отдел / департамент	Подразделение, где работает заинтересованное лицо
Непосредственный начальник	Прямой начальник заинтересованного лица
Контактная информация	Телефон, e-mail и прочее – ВСЯ известная контактная информация
Предпочитаемый вид коммуникаций	Электронная почта / телефон / совещания и т.п.
Главные ожидания	Главные ожидания заинтересованного лица по проекту
Главные требования	Главные требования заинтересованного лица по проекту (или ID в матрице требований, если были внесены туда)
Влияние на проект	Влияние на проект по в баллах по шкале 1 – 10 (где 1 – минимальное влияние; 10 – максимальное влияние)
Отношение к проекту	Противник / Сторонник / Нейтрал
Интерес к проекту	Возможно, заинтересованное лицо ХОЧЕТ принять участие в проекте как эксперт или в иной форме.
Комментарий	Любые комментарии

ndash; Матрица требований

Инструкции по заполнению матрицы требований

NB: строки "проект" и "PM" обязательны для заполнения (соответственно – вносится название проекта и фамилия и имя менеджера проекта)

Поле	Алгоритм заполнения
ID	Уникальный идентификатор требования (s + инкремент)
Описание требования	Подробное описание требования (функциональные и не функциональные характеристики)
Автор	Автор требования (т.е. тот, кто НАЗВАЛ требование команде, а не тот, кто записал названное в настоящий файл)
Дата	Когда требование впервые стало известно команде
Документ выявления	Документ, формализовавший названное требование (отчет об интервью, протокол совещания и т.д.)
Статус требования	Открыто / закрыто / отменено
Заменено на (ID)	Если настоящее требование изменилось – оно "закрывается" (отметка в столбце "статус требования"), заводится новое , с новым ID (он указывается и в данном столбце)
Последователь чего? (ID)	Если настоящее требование это результат изменения предыдущего, то в данном столбце указывается ID предшественника
Спецификация (ID)	Если формировался технический документ по реализации данного требования – то указать его ID
Модуль	Название модуля ПО, в который войдет реализуемое требования (назвать или перечислить через запятую)
Дата реализации	Дата внутренней приемки (внутри команды проекта)
Дата приемки	Дата приемки заказчиком
Документ приемки (ID)	Документ, подтверждающий приемку заказчиком
Дополнительные комментарии	Любые комментарии

ndash; Реестр рисков

Инструкции по заполнению реестра рисков

ID	Уникальный идентификатор риска (rs + инкремент)
Статус риска	"Открыт" для рисков, которые актуальны; "закрыт" для рисков, более не актуальных на проекте (реализовавшихся, ставших невозможными и т.п.)
Влияние риска	Элемент качественной оценки риска ("высокое / среднее / низкое") (выделение цветом автоматическое, соответственно: красный / желтый / зеленый)
Вероятность риска	Элемент качественной оценки риска ("высокая / средняя / низкая") (выделение цветом автоматическое, соответственно: красный / желтый / зеленый)
Уровень риска	Интегральная качественная оценка риска ("красный" – для самых опасных и приоритетных рисков, "желтый" – для умеренных", "зеленый" – для наименее существенных). Оценка формируется автоматически, на основании данных столбцов «влияние риска» и «вероятность риска. Соответственно: (зеленый + зеленый) = зеленый уровень риска (зеленый + желтый) = зеленый уровень риска (желтый + желтый) = желтый уровень риска (желтый + красный) = красный уровень риска (красный + красный) = красный уровень риска
Описание риска	Тезисно – в чем суть (причина, содержание) риска
Влияние на проект	Тезисно – в чем суть влияния риска на проект
Область риска	Общее название группы, к которой можно отнести данный риск
План А (contingency plan)	Что будем делать для того, чтобы реализовать стратегию обработки риска
Триггеры	Условия для запуска действий по плану Б (одновременно – признак того, что риск реализовался)
Тип стратегии обработки риска	Для позитивных рисков: "использование / усиление / разделение"; для негативных рисков: "предотвращение / смягчение / перенос"; для обоих видов риска: "принятие"
Хозяин риска	Лицо ответственное за мониторинг триггера и запуск contingency плана
План Б (fallback plan)	Что будем делать, если риск реализовался (не заполняется, если тип стратегии обработки риска – "принятие")

ndash; Перечень ресурсов (команда)

Инструкции по заполнению перечня ресурсов

ID	Уникальный идентификатор требования (hr + инкремент)
ФИО сотрудника	ФИО сотрудника, привлекаемого в команду проекта
Отдел	Название отдела, к которому относится привлекаемый сотрудник
Прямой руководитель	Хозяин ресурса (прямой руководитель сотрудника)
Период привлечения и объем загрузки	Период привлечения на проект и объем загрузки – указывается один или несколько интервалов (даты с… – по…) в течении которого сотрудник будет выделен на проект, а также объем его загрузки в % (100% если сотрудник работает только на данном проекте)
Роль на проекте	Роль сотрудника как члена команды проекта
Договоренности	Дата и форма договоренностей
Комментарии	Любые комментарии, в том числе пояснения к столбцу «период привлечения и объем загрузки», если его содержимое не полностью уточнено.

Приложения

Перечень:

Приложение 1 – Устав проекта Приложение 2 – Реестр заинтересованных лиц Приложение 3 – Матрица требований Приложение 4 – Концепция проекта Приложение 5 – Реестр рисков Приложение 6 – Перечень ресурсов (команда)

Эффективное использование приведенных шаблонов предполагает их модификацию и доработку под нужды вашей организации и/или проекта по необходимости. Приложения данной книги 0 лишь одним из способов адаптировать «лучшие практики» методологии PMBoK к управлению ИТ-проектами

Проводим сдачу-приемку продукта

Этот процесс мы проводим для заказчика.

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

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

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

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

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

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

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

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

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

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

Распределяем ответственность

Что мне делать дальше?

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

Если вы действительно привлекали команду к формированию ИСР (WBS) и прочим элементам планирования – то каждый сотрудник уже «в курсе», за какие работы ему придется взяться и в какие сроки уложиться. Не думайте, что ПМ на этом можно остановиться!

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

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

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

Помните, раздавать поручения в фазе исполнения проекта – не работа ПМ!

Я еще за что-то отвечаю?

Помимо самих работ – обратите внимание на распределение ответственностей за то, что не находит отражения в ИСР (WBS).

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

Фиксируйте договоренности. Сделайте это для каждой области знаний или для каждой роли вашей команды.

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

Матрица ответственности может выглядеть, следующим образом:

	Член команды:	Олег	Василий	Петр
Работа:
Выявление и отслеживание рисков		Г	В
Контроль качества продукта		В	Г
Ведение переговоров в фазе инициации	В	Г
…

Г – главный ответственный, В – вспомогательный ответственный

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

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

Рекомендованная литература

«Руководство к своду знаний по управлению проектами», Project Management Institute, 496 стр. «Вальсируя с медведями: управление рисками в проектах по разработке программного обеспечения» ДеМарко Т., Листер Т., 304 стр. «Путь камикадзе» Эдвард Йордон, 290 стр. «Управление высокотехнологичными проектами» Арчибальд Рассел Д., 464 стр. «Мифический человеко-месяц» Брукс Фредерик, 196 стр. «Как привести дела в порядок. Искусство продуктивности без стресса» Ален Дэвид «Человеческий фактор. Успешные проекты и команды» ДеМарко Т., Листер Т., 256 стр. «Project Management Institute Practice Standard for Work Breakdown Structures, Second Edition», Project Management Institute, 123 стр.

Роль и ответственность менеджера проекта

Роль менеджера (для краткости будем иногда использовать для его обозначения аббревиатуру ПМ – «проектный менеджер») можно описать двумя фразами:

ПМ отвечает за то, чтобы проект уложился в рамки тройственного ограничения ПМ несет ответственность за проект в целом

Тройственное ограничение – это «сроки», «стоимость» и «содержание работ» проекта. Говоря о нем – нередко рисуют треугольник, чтобы подчеркнуть взаимосвязь всех его граней. Изменение бюджета неизбежно повлияет на сроки и состав работ; обратное справедливо и для остальных граней.

Иногда внутри треугольника пишут еще одно условие – «удовлетворенность заказчика».

Вся работа ПМ сводится к тому, чтобы проект «не выскочил» за грани (сами грани согласовываются до начала работ, и этому будет посвящено несколько глав).

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

Что считать успехом проекта? Если к моменту закрытия работ ни одна из граней не нарушена (мы уложились в срок, не перебрали бюджет, мы сделали все, о чем просил заказчик), а сам заказчик доволен результатом – ваш проект успешен и это неоспоримо. Считайте такую перспективу маловероятной? Задумайтесь, прежде чем принимать назначение «менеджером проекта».

Сбор требований

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

Чтобы справиться с ней – необходимо понять «кто?» является источником требований на проекте и «что?» конкретно он хочет получить по окончании работ.

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

Лучшие проектные практики гласят:

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

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

Выявляем заинтересованных лиц

Эту работы мы начали еще в фазу инициации (определив самых основных персон)? теперь работа продолжается. Результатом ее должен стать «реестр заинтересованных лиц». Пример такого документа приведен в Приложении 2.

Даже на небольшом проекте (с бюджетом в несколько миллионов рублей и командой порядка 10 человек) такой реестр должен содержать десятки (хорошо, если сотни) фамилий.

По какому принципу мы называем того или иного человека «заинтересованным лицом»?

Во-первых, это каждый, кто прямо вовлечен в проект (заказчик, спонсор, команда).

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

В третьих, не забывайте о боссах членов вашей команды.

В четвертых, помните о тех, кто напрямую не связан с проектом, но, так или иначе, оказывает на него влияние.

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

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

Готовимся к сбору требований

По мере того, как список «заинтересованных лиц» формируется – мы приступаем к сбору требований.

Введем два термина: «требование» и «ожидание».

Ожидание – «умозрительная картинка будущего». Как правило – достаточно широкая. Пример ожидания: «чтобы производительность отдела возросла после внедрения ИТ-системы»; или «чтобы внедрение проекта не сильно сказалось на работе соседнего департамента». Ожидание нельзя включить в состав проекта, не преобразовав в требование.

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

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

Выбирая методы, необходимо тщательно взвесить наши потребности в информации и способности второй стороны ее предоставить.

Из наиболее распространенных можно выделить:

Интервью Опросники Мозговые штурмы (в различных вариациях) Прототипирование

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

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

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

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

Собираем требования



К сбору требований мы приступаем, определившись с методами и вооружившись реестром заинтересованных лиц.

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

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

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

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

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

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

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

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

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

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

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

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

Балансировка требований



Балансировка требований – отбор требований, реализация которых предполагается в рамках проекта.

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

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

Позже, когда себестоимость и продолжительность работ будет оценена, мы сможем вернуться к этой части плана и скорректировать ее (возможно, от каких-то требований придется отказаться или пересмотреть). Однако важно понимать – процесс балансировки требований не должен противоречить уставу проекта. Если в уставе, скажем, прописано как одно из главных требований к продукту – скорость реакции интерфейса не более чем за 0,5 секунды, то мы не можем выбросить подобное требование из реестра (его невыполнение похоронит проект).

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

Обратите внимание еще на такой аспект: в нашем проекте мы не используем термин «техническое задание» (ТЗ)

Де-факто, матрица требований (а также схемы и описания, на которые она ссылается) как раз и представляет собой техническое задание. Однако на практике ТЗ – это статичный документ, который является неотъемлемой частью некоторых видов контрактов.

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

Если вы все же столкнулись с необходимостью разработать ТЗ (или привлечены к его разработке) – адаптируйте информацию матрицы требований и позаботьтесь о том, чтобы в документе появились подробные описания процедуры уточнения требований (особенно формальной ее стороны). Приведем один из примеров подобных процедур: «Список используемых в системе справочников и классификаторов приведен в приложении №101. Данный список может изменяться в сторону его увеличения или сокращения, но не более чем на 10 позиций. При необходимости внести изменения в список справочников, заказчик уведомляет о такой необходимости исполнителя не позднее, чем до 1 декабря 2010 года и предоставляет описание… По результатам поведенного исполнителем анализа составляется акт на основе шаблона в приложении №102.»

Планирование управления рисками

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

Поэтому, подходы мы выработаем самостоятельно.

Идентификация рисков

Кто выявляет риски?

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

Распространенный подход гласит- «к идентификации рисков привлекаются все».

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

Источники информации о рисках

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

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

Какая информация о рисках важна?

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

Как уже было сказано – информацию о рисках удобно хранить в формате таблицы. Назовем ее «реестр рисков». Один из возможных форматов документа представлен в Приложении 5.

Данную таблицу мы будем заполнять в течение управления рисками (вплоть до закрытия проекта).

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

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

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

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

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

Качественный анализ

Риски собраны и внесены в реестр. Время приступить к их оценке и сортировке.

Качественный анализ – это субъективная оценка выявленных рисков. Мы должны определить – как сильно тот или иной риск угрожает проекту.

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

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

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

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

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

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

Количественный анализ

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

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

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

Среди методов количественного анализа выделяют:

Сбор экспертных мнений Анализ Монте-Карло (мы коротко говорили о нем в разделе, посвященном формированию расписания – глава VIII шаг 6) Оценку стоимости риска (оценивается как произведение количественной оценки вероятности риска на его влияние).

Остановимся подробнее на последнем методе.

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

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

Сравниваем стоимость риска по каждому из сценариев:

Для сценария 1 = 1500 * 1 = 1500 долларов

Для сценария 2 = 100.000 * 0,05 = 5000 долларов.

Вывод – сценарий 1 выгоднее для проекта (т.к. его стоимость риска ниже).

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

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

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

Планирование реагирования на риск

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

«Как изменить уровень риска на проекте (увеличить / уменьшить)?» «Что делать, если мероприятия пункта 1 окажутся неэффективными, и риск все-таки произойдет?»

Содержимое пункта 1 будем называть «Планом А» (общепринятые названия – «план реагирования на непредвиденные ситуации» или contingency plan).

Содержимое пункта 2 назовем «Планом Б» (в методологиях он часто называется «планом отступления» или fallback plan).

Создаем «План А» (contingency plan)

Главный элемент «Плана А» для каждого риска – это стратегия. Выделяют четыре вида стратегии для положительных и отрицательных рисков:

Отрицательный риск	Положительный риск
Нивелирование	Использование
Ослабление	Усиление
Перенос	Разделение
Принятие

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

Пример для негативного риска: неопытный член команды может завалить работу. План А – заменить сотрудника на более опытного.

Пример для позитивного риска: закупаемое для проекта лицензионное ПО, может достаться нам со скидкой, если все закупки будут проведены до конца года. План А – провести закупки ПО до конца года.

Стратегия «Ослабление» / «Усиление» нацелена на изменение вероятности или влияния рисков.

Пример для негативного риска: неопытный член команды может завалить работу. План А – заранее провести тренинг для сотрудника.

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

Стратегия «Перенос» / «Разделение» нацелена на то, чтобы либо переложить бремя риска на третью сторону (например, субподрядчика или страховую компанию); либо наоборот, поделиться возможностями с теми же субподрядчиками, если это принесет удачу проекту в целом.

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

Пример позитивного риска: Результаты проекта будут знаковыми не только для нашей организации, но и для потенциальных поставщиков лицензионного ПО (они смогут гордиться, что именно на их платформах создана столь масштабная система). План А – провести переговоры с поставщиками (возможно, кто-то из них, заинтересовавшись, предложит нам льготные условия поставки или иную помощь)
Стратегия «Принятие» предполагает бездействие, «смирение» с обстоятельствами. Это наиболее пассивная из всех стратегий. Она может быть использована для неснижаемых рисков, предотвратить которые дороже, чем дождаться их наступления. Остерегайтесь применения такой стратегии, следите, чтобы такой тип реагирования применялся не более чем для 10% рисков на любом проекте, а по возможности – стремился к нулю.
Пример: неопытный член команды может быть уволен из организации за провал на другом проекте (при этом он покинет и ваш проект). План А – уточняем риски у «хозяина ресурсов» и бездействуем.
Зафиксируйте выбранную стратегию в реестре – опишите ее вид и действия «Плана А». Определение вида стратегии очень важно для самоконтроля. Классифицируя намеченный «план действий» – проверьте себя. Зная, что наилучшим сценарием будет нивелирование / использование риска, а худшим – принятие, убедитесь, что выбран был действительно наилучший способ реагирования из доступных.
Помимо стратегии, важнейшая задача данного шага – определить «хозяина риска», если таковой не был назначен в ходе идентификации (шаг 2). По умолчанию, хозяином всех рисков является ПМ – избегайте такой ситуации.
Общее правило – хозяином становится тот, кто находится «на передовой» (т.к. именно он будет проверять, что определенные действия в рамках Плана А выполнены).
В работе «хозяина» крайне важны правильно определенные «триггеры риска».
Триггеры риска – признаки, по которым «хозяин риска» поймет, что превентивные действия не сработали и пора «отступать» (использовать План Б). Это еще один резон не становиться хозяином всех рисков – пусть хозяином будет тот, кто первым заметит триггер.
Создаем «План Б» (fallback plan)
План Б будет использоваться «хозяевами рисков», если План А окажется недостаточно эффективен.
Для негативных рисков это будет означать, что превентивные меры не помогли, и риск все же начал реализовываться, для положительных – что, не смотря на приложенные усилия, мы все же упускаем удачную возможность.
Заполняя данный раздел реестра, используйте эффективный прием: задавайтесь вопросом не «что делать, если…», а «что делать, КОГДА риск произойдет». Таким образом, можно сделать гипотетическую картинку на много ярче и реалистичнее.

Изменяем планы и определяем резервы

Прорабатывая планы

Оба плана (в особенности «План А») в зависимости от выбранной стратегии – предполагают какие-то действия с нашей стороны.

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

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

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

«Резервам на непредвиденные случаи» иногда противопоставляют «управленческие резервы» (они целиком планируются и распределяются спонсором проекта и ПМ не известны).

Обратите внимание – резервы не удорожают проект! Сумейте, при необходимости, донести до своего руководства.

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

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

И еще один совет – сформировав план управления рисками ,просмотрите его еще раз. Подумайте, не породили ли ваши запланированные действия в рамках «резервов на непредвиденные случаи» – дополнительных рисков (их принято называть вторичными). Если да – внесите их в реестр (как идентифицированные) и повторите процедуру. Чем полнее окажется реестр рисков, тем лучше для проекта.

Выходы:

Реестр рисков Запросы на изменения

четвертый. Определяем ресурсы

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

С составом команды проекта мы определились в главе VI. Более того, я надеюсь, что многие члены команды уже привлечены к планированию проекта. Определите, насколько это возможно, кто и за какую работу будет браться в проекте.

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

увеличить

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

назад

Означенный нами в главе V сценарий планировании пройден.

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

Возможный алгоритм планирования:	Кто планирует	Название шаблона / представления в специализированном ПО	Шаблон / ПО
Определить, как будет строиться планирование			n/a
Собрать и финализировать требования		Реестр заинтересованных лиц, матрица требований
Сформировать концепцию (scope)		Концепция проекта
Принять решение «что закупаем»?			n/a
Определить команду		Перечень ресурсов
Создать ИСР (WBS)		ИСР и словарь ИСР
Создать перечень действий (activity list)		Перечень действий
Создать сетевую диаграмму (network diagram)		Сетевая диаграмма
Оценить требуемые ресурсы		Ресурсы, распределенные по работам
Оценить продолжительность действий и оценить стоимость		Оценки сроков и стоимости
Сформировать расписание		Расписание
Определить предельную цену проекта		Предельная цена проекта
Планировать качество – создать метрики			n/a
Создать план улучшения процессов			n/a
Распределить роли и ответственности			n/a
Создать план коммуникаций			n/a
Спланировать управление рисками, идентифицировать риски, качественный анализ, количественный анализ, планировать реагирование на риски		Реестр рисков
Все повторить			n/a

– ПМ осуществляет планирование в одиночку.

– ПМ привлекает к планированию коллег (команда, «хозяева ресурсов» и прочие)

– Для планирования требуется специализированное ПО

– Для планирования используются шаблоны

n/a – Для планирования используются неформальные договоренности (или корпоративные документы)

Настало время совершить «шаг назад» и вернуться к разделам, требующим уточнения.

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

первый: формируем ИСР (WBS)

Возвращаемся к планированию содержания. Наша задача – разбить общий результат поставки проекта (описанный в «концепции») на более мелкие соподчиненные блоки «результатов работ». Для этого мы создадим иерархическую структуру работ (или work breakdown structure) – сокращенно ИСР (WBS).

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

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

Помните – ИСР создается совместно с командой! Это очень существенный момент. Как бы организационно вы не подошли к данному вопросу (будете ли сами создавать некий «черновик» и потом «утверждать» его вместе с командой, или с самого начала соберетесь все вместе) – главное найти способ привлечь сотрудников к планированию. Это повысит достоверность планов и, в то же время, сплотит команду (см. главу IX).

О чем следует помнить, создавая ИСР?

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

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

Основные признаки пакета работ:

Относительно короткий Работы по созданию пакета могут быть выполнены без прерывания Работы по созданию пакета могут быть выполнены на аутсорсинге

Обратите внимание на слова «относительно короткий» и «без прерывания». Это вовсе не означает, что пакетом является то, что можно успеть сделать до ближайшего перекура или в течение одного дня. Под прерыванием понимается вынужденная остановка работ (например, для проведения других действий или получения согласования). Так, нельзя назвать пакетом работы по созданию «макета и шаблона сайта», если мы знаем, что нарисованный макет нужно сперва предъявить заказчику и, только получив его согласие, можно приступать к формированию шаблона.
Источником данных для создания WBS служит концепция проекта. А вот наиболее удобным местом хранения введенных данных выступает специализированное ПО. Любой из перечисленных продуктов позволяет хранить информацию о работах в следующем виде:

увеличить
Иногда, составление полной детализированной ИСР оказывается невозможной или нецелесообразной (например – слишком трудоемкой). В таком случае прибегают к методу «набегающей волны». Суть его состоит – в детализации лишь самых ближайших к выполнению элементов (забегая вперед – в нашем примере это работы связанные с макетом (пакеты работ № 3 и 4). Остальные элементы ИСР обознаются только на верхнем уровне (в нашем примере – можно было бы указать только создание Главной страницы, без декомпозиции на пакеты № 6, 7, 8, 9).
Важнейшим элементом ИСР служит так называемый «словарь ИСР» (WBS-dictionary). Словарь позволяет подробнее описать то, что мы имели в виду под скупой формулировкой в ИСР. В нашем сценарии роль «словаря» могут выполнять ссылки на данные результатов обследования (глава VI). При использовании специализированного ПО элементы словаря можно создавать и хранить разными способами, например – в виде специальных «заметок», привязанных к каждому элементу ИСР.
Информация словаря должна быть доступна всем членам команды – для использования при выполнении собственных работ.

пятый. Определяем продолжительность и стоимость.

Сейчас нам предстоит уточнить продолжительность и стоимость работ.

Грубые (ROM) предположения были ранее включены в устав. Сейчас нам требуются намного более точные прогнозы. Потребителем таких оценок будет уже не спонсор / заказчик, а непосредственные исполнители, команда. То, что мы сделаем сейчас, станет мерилом их успешности на проекте. Поэтому, приготовьтесь к напряженному процессу.

Оцениваем время

Мы не будем углубляться в техники и приемы оценки времени, а перечислим лишь некоторые из них и главные рекомендации

Среди основных методов оценки времени иногда называют:

Оценку одним человеком Оценку по аналогу Параметрическую оценку PERT Эвристическую оценку Анализ резервов

Метод оценки одним человеком нужно использовать с осторожностью (в силу его субъективности) и никогда не делать основным.

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

Методы параметрических и эвристических оценок порождают огромное количество споров и дискуссий в разных профессиональных сообществах (корректно ли оперировать «строчками кода в день», верно ли утверждение что «тестирование занимает 1/3 разработки») и так далее. К какому бы лагерю спорщиков вы не относились – не пренебрегайте данными оценками, но относитесь к ним критично.

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

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

Согласно PERT предполагаемая длительность (или EAD) составит:

EAD = (P + 4M +O) / 6

где P – «пессимистичная оценка» , O – «оптимистичная оценка», M – «наиболее вероятная оценка».

С помощью PERT можно дополнительно уточнить и сам диапазон допущения вот таким способом:

возможное отклонение (SD) составит:
SD = (P-O) / 6
диапазон колебания (range) составит:
Самый оптимистичный прогноз = EAD - SD
Самый пессимистичный прогноз = EAD + SD
Используйте и комбинируйте методы оценки времени. По-возможности – привлекайте экспертов (внутри или вне компании), используйте сложившиеся корпоративные практики (если таковые существуют).
Помните, точность создаваемых сейчас оценок должна быть достаточно высокой (с погрешностью от 5 до 25%, или даже меньше, в зависимости от характера вашего проекта).
Полученные результаты мы вносим для каждого действия в специализированное ПО.

увеличить
В соответствующих столбцах появляются отметки о продолжительности работ. Также становятся доступны дополнительные виды диаграмм, например, диаграмма Ганта.

Диаграмма Ганта помогает наглядно оценить продолжительность работ.
Оцениваем стоимость
Сделаем сразу оговорку – не на всех проектах ПМ явно управляет бюджетом. Иногда, эту функцию берет на себя спонсор, от которого руководитель проекта получает информацию лишь в количестве выделенных ему на определенный срок ресурсов. В таком случае ПМ как бы «покупает» (а, вернее, «берет в пользование») ресурсы компании, не задумываясь об их цене.
Мы рассмотрим случай, когда бюджет является головной болью руководителя проекта. В таком случае, нам понадобится оценить, сколько будут «стоить» действия внутри пакетов.
Многие из методов, описанных в предыдущем разделе, посвященном оцениванию времени, могли бы нам пригодиться. Это и оценка одним человеком, и оценка по аналогу, и параметрическая оценка, и тот же PERT (оперирующий вместо прогнозов времени – деньгами).
Однако одним из наиболее удобных и наглядных способов является оценка «снизу вверх», описанием которой мы и ограничимся.
Себестоимость ИТ-проектов, в массе своей, складывается из себестоимости их ресурсов. Перечень ресурсов мы завели в специализированное программное ПО во время шага 4. Теперь можем просто задать правила начисления их зарплаты (будь то ставки в час, зарплата в месяц, повышенные сверхурочные и т.п.). Все расчеты произведет ПО

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

седьмой. Определяем предельную цену проекта (cost baseline)

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

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

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

Предельная цена проекта (cost baseline) – это сумма себестоимости всех работ по проекту и стоимости всех резервов на непредвиденные случаи (contingency reserves). Определяется менеджером проекта.

Бюджет проекта – это сумма предельной цены проекта (cost baseline) и управленческих резервов (management reserves). Определяется спонсором.

Предельная цена проекта – это одна из граней тройственного ограничения. Неотъемлемым ее компонентом является стоимость резервов, которая определяется в ходе управления рисками. Об этом мы будем подробно говорить в главе X. Все, что нам доступно прямо сейчас – грубый прогноз такой стоимости резервов (ROM-оценка), используя который мы можем получить представление о «предельной цене».

Процесс планирования итеративен. Выполнив этап планирования реагирования на риски, мы сможем вернуться, в том числе, и к данному шагу, скорректировав свои оценки.

Бюджет проекта содержит «управленческие резервы» и поэтому является компетенцией спонсора, и нас абсолютно не интересует (немного подробнее об этом – также в главе X)

шестой. Создаем расписание

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

Задаем точку старта

В уставе зафиксированы даты начала и окончания проекта. Используя специализированное ПО, мы задаем точку старта проекта и видим предполагаемую дату окончания. Укладывается ли результат в сроки, указанные в уставе? Возможно.

увеличить

В этот момент нам удобно ввести понятие «вех».

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

Добавим в наше расписание значимые для нас вехи. Допустим, в уставе прописано, что до 10 сентября необходимо согласовать с заказчиком макет, а весь проект завершить не позже 15-го. Укажем в перечне задач соответствующие вехи.

увеличить

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

Сетевой анализ расписания

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

Сетевой анализ включает в себя:

анализ и выравнивание ресурсов анализ критического пути сжатие расписания (crashing и fast track) анализ Монте-Карло

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

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

Укладываемся ли мы в ограничения сроков из устава теперь? Возможно. Но с огромной вероятностью – нет (такова природа проектов вообще и ИТ-проектов в частности). Будем работать над расписанием дальше.

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

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

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

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

Сжатие расписания всегда имеет целью ускорить выполнение работ по проекту.

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

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

Используйте методы сжатия расписания, осознавайте риски, которые за ними стоят.

Анализ Монте-Карло – термин из теории игр. Этот вид анализа основан на задании исходных условий и дальнейшем моделировании возможных ситуаций. Осуществляется с использованием особого ПО (наше, «проектное» для этих целей не подходит, иногда пользуются электронными таблицами excel с преднастроенной логикой). В настоящей книге мы не будем останавливаться на нем подробно.

Урезание расписания

Сетевой анализ расписания иногда противопоставляют «урезанию» содержания работ (cutting scope). Порой, соблазн ПМ состоит в том, чтобы «выкинуть» некоторые работы из проекта, дабы получить более удобное расписание. Удержитесь от того, чтобы сделать это «тайком».
Помните, что проект всегда реализуется в интересах клиента. Если сетевой анализ не позволяет вам добиться реалистичного расписания к искомой дате без ущерба к конечному продукту – обсудите эту проблему со спонсором, предложите ему увеличить сроки проекта или позволить вам «выкинуть» определенные работы (по сути, вы просите переписать устав). Возможно, вам придется признать свою ошибку при грубом (ROM) планировании в фазе инициации. Не бойтесь этого. Не бойтесь поступать этично.
Итоговое расписание.
Результатом наших усилий должно стать реалистичное расписание. Такое, которое не противоречит уставу, обеспечено ресурсами, и по которому команда проекта действительно готова выполнить работы в соответствие с графиком.
Помните, расписание должно быть доступно заинтересованным лицам. Команде необходимо иметь доступ к подробной иерархии работ, спонсору же достаточно видеть основные вехи. Позаботьтесь о том, чтобы результаты планирования не остались у вас на компьютере – обеспечьте актуальной информацией всех, кто в ней нуждается любым приемлемым способом (письма, распечатки, и проч.).

третий. Определяем последовательность действий.

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

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

увеличить

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

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

второй. Определяем перечень действий.

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

Внимание! Пакет был поставко-ориентирован, в качестве пакета могли выступать экранные формы, элементы интерфейса, хранимые процедуры, структуры базы данных и т.д.

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

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

увеличить

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

Руководствуйтесь здравым смыслом, советуйтесь с командой. Декмопозируйте до тех пор, пока вам это помогает, не делайте работу ради работы.

Сохранить информацию по проекту

Сохранение информации по проекту – это закрытие проекта с точки зрения менеджера проекта.

Лучшие практики и «извлеченные» в ходе выполнения проекта уроки – важнейший актив вашей компании.

Вспомните, как вы запускали проект. Мы условились, что вам пришлось «с нуля» формировать перечень и шаблоны документов, выбирать методики оценок, нащупывать тот или иной способ выполнения работ.

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

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

Не пишите много, сконцентрируйтесь только на важной (с вашей точки зрения) информации.

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

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

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

Выходы:

документы, подтверждающие приемку продукта скорректированные шаблоны типовых документов извлеченные уроки

Создаем концепцию (scope) проекта

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

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

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

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

Что вы ему дадите? Контракт? Не факт, что тот уже подписан, да и создается он, нередко, юристами для юристов.

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

Матрица требований? Тоже неплохо, но она объясняет «что сделать», а не «как работать».

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

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

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

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

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

Выходы:

Реестр заинтересованных лиц Матрица требований Концепция проекта

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

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

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

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

«Выбиваем» ресурсы

Итак, в ходе общения с хозяевами ресурсов мы определили: «Кто нужен?», «Кто есть?» и «Кого дают?» нам в рамках проекта. Мы также определились с целесообразностью привлечения подрядчиков. Теперь надо сформировать «список ресурсов».

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

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

Построение конструктивных взаимоотношений с «хозяином ресурсов» очень важно. Для этого:

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

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

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

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

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

Фамилию и имя сотрудника (избегайте указывать только должность) Период и объем занятости (например, «доступен с 1 сентября по 31 декабря 2010 года, занятость – 50%» – если речь идет о привлечении сотрудника, который будет делить время между вашим и другим проектом).

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

Все, кто оказался в списке ресурсов, автоматически становятся членами команды проекта (не забудьте об этом на следующих этапах).

Выходы:

Решение «что покупаем» (устно или письменно) Список ресурсов

Высвобождаем ресурсы

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

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

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

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

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

Запускаем работы

Запуск работ – не более чем наша «отмашка» команде проекта: «начинаем». С точки зрения заказчика – проект давно уже идет. Да и мы с командой успели немало поработать (в рамках планирования).

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

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

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

Далее мы разберем, чем занят менеджер проекта на данной стадии.

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

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

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

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

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

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

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

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

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

---

---