Концептуальная база проекта: управление рисками и качеством, отслеживание связей

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

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

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

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

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

Внутрипроектные связи можно типизировать следующим образом:

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

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

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

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

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

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

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

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

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

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

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

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

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

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