Изменения в проектах могут не ограничиваться единицами. Напротив, они могут процветать и размножаться. Это создает необходимость записи, нумерации и координации потока изменений и проекте (см. рис. 11.4). Подобный мониторинг процесса изменений обеспечивается журналом изменений проекта. Администрируемый координатором, PLC фиксирует каждый запрос на внесение изменения в проект и присваивает ему номер, обеспечивая, чтобы решение, принятое по данному запросу, был ли он утвержден или отклонен органом по изменениям, также было зафиксировано. Когда запрос одобрен, а изменение реализовано, эта информация становится частью PCL.

Рис. 11.4.Пример журнала изменений проекта

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

Подготовка исходной информации.Упорядоченный и стабильный процесс применения PCL требует наличия следующих 4 информационных элементов.

•План контроля изменений (см. раздел «Констатация содержания» главы 5) обеспечивает полное понимание необходимых для ведения журнала правил работы с изменениями в проекте.

•Для администрирования (ведения) PCL должен быть назначен подходящий координатор.

•Матрица координации изменений обеспечивает последовательность шагов, через которые проходит изменение. Без этого не может существовать практически ни один PCL.

•Запрос на внесение изменения в проект является предметом администрирования PCL.

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

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

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

Фиксирование факта одобрения / отклонения PCR и даты, на которую намечена его реализация.Решение о судьбе запроса может пойти обоими путями. Если он не одобрен, необходимо вписать «Нет» в столбец «Одобрен?» и вычеркнуть всю запись, обеспечив ее читаемость. В противном случае, когда PCR одобряется, необходимо вписать «Да» в столбец «Одобрен?» и заполнить столбец «Дата выпуска», обозначив тем самым факт официального выпуска наряда на реализацию изменения.

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

Алан ДеФазио был инженером-компьютерщиком и не имел никакого опыта работы в контрактных проектах. Когда он узнал, что вендор компьютеров для проекта приказал долго жить, он просто заказал более хорошее и более дорогое оборудование у другого вендора, имевшего более устойчивую репутацию. В конце концов, именно так он уже не раз поступал, когда речь шла о внутренних нуждах компании. «Все будут довольны, ведь все любят хорошее компьютерное оборудование», – думал он. Четыре месяца спустя, когда оборудование было поставлено, все члены проектной команды были более чем рассержены на Алана. Его менеджер проекта кричал: «Алан, почему ты изменил технические условия на компьютерное оборудование, не пройдя через процедуру подачи запроса на внесение изменения в проект?» Хуже того, менеджер проекта со стороны владельца отказался оплачивать разницу в цене между первоначальным и новым оборудованием, сказав: «У меня в бюджете нет денег для оплаты этого оборудования, и чтобы изыскать их, мне придется пустить по миру моего финансового директора. Никак не возможно!» Каков же эпилог? Несколько месяцев спустя, пройдя через чувство разочарования и неудовлетворенности, владелец все же одобрил изменение, чем спас Алана и его менеджера проекта от увольнения. Мораль истории такова: наличие процедуры подачи запроса на внесение изменения ничего не знасит, если только люди не обучены использовать эту процедуру.

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

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

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

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

Кельвину Пику нравилась его работа по одновременному управлению 7 или 8 проектами информационных систем. Его не волновало, что его рабочий день продолжался 12 часов. Ему просто нравился быстрый темп и нравилось множество изменений на пути. Что ему не нравилось, так это отслеживать все эти изменения. Не потому, что относился к тому типу людей, которые терпеть не могут документирование, а потому, что его график был настолько заполнен действиями, что он просто не мог найти в нем дополнительное время для ведения журнала. И вот однажды он наткнулся на Palm Pilot. Из его груди вырвался вздох облегчения – ведь теперь он мог использовать его для отслеживания изменений, расходуя на это лишь минуту-другую из своего рабочего времени. Когда один из коллег показал ему, как можно обеспечить взаимодействие Pilot и Excel и мгновенно вводить информацию из журнала изменений в электронную таблицу, доступную членам команды, Кельвин был уверен: «Это оно! Это то самое, что мне нужно!»

(Мы не утверждаем, что это наилучший способ ведения журнала изменений. Но это один из способов, и он работает.)

Преимущества и недостатки.К преимуществам PCL относятся:

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

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

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

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

Убедитесь, что журнал изменений имеет надлежащую конфигурацию. Этот журнал должен:

• быть основан на необходимой исходной информации;

• нумеровать, кратко описывать и датировать запрашиваемые изменения;

• отмечать факт одобрения / отклонения запроса;

• фиксировать дату одобрения запроса и выпуска его на исполнение;

• фиксировать дату выполнения изменения;

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

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