Связи проекта

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

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

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

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

• использование общих разделяемых ресурсов;

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

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

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

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

Кроме контроля над изменениями, есть еще одна причина, по кото­рой целесообразно вести документ, явно фиксирующий связи проекта. Это необходимость обучения персонала. Обучение нужно для подключе­ния нового исполнителя к работе, начатой ранее, для восстановления со­стояния дел отложенной работы, для передачи опыта данного проекта, т.е. для переиспользования проектных рабочих продуктов. Не так давно на эффективность явного описания связей обращали мало внимания. Большинство зависимостей фиксировалось лишь в голо­вах менеджера, архитектора проекта и ведущих разработчиков, оставаясь вне компетенции остальных исполнителей проекта. Практика показыва­ет нерациональность такого положения дел. Документальная фиксация связей очень помогает организационно: с ее помощью распространение изменений становится вполне технологичной процедурой, а изучение ма­териалов проекта — сугубо индивидуальной деятельностью, не отвлекаю-шей других разработчиков для консультаций.

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

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