учебники, программирование, основы, введение в,

 

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

В предыдущей лекции мы рассмотрели вопросы определения методологического основания программного проекта и показали необходимость осознанного формирования концептуальной базы проекта. В частности, было указано, что эта база служит основой выработки общего плана проекта, составляющими которого являются планы по направлениям проектной деятельности. Мы рассмотрели части концептуальной базы, без которых проект как целенаправленная деятельность невозможен, – концепция развития проекта и план релизов. В данной лекции будут обсуждаться работы системы деятельностей проекта (см. лекцию 4), которые призваны обеспечивать устойчивость траектории развития. Без осознанного их выполнения достижение целей проектов весьма сомнительно. Речь пойдет об управлении рисками, управлении качеством и отслеживании связей. Эти виды деятельности тесно взаимосвязаны. Без специальной упреждающей заботы о реакции разработчиков на рискованные ситуации невозможно организовать качественный процесс, а следовательно, трудно ожидать и приемлемого качества получаемых результатов. В свою очередь, взаимосвязанность и переплетение деятельностей проекта есть фактор риска, и отслеживание связей в одном из аспектов можно рассматривать как инструмент снижения рисков. В то же время эти три деятельности целесообразно рассматривать по отдельности, поскольку каждая из них имеет свое содержание, которое не сводится к обслуживанию других.
В той или иной форме управление рисками, управление качеством и отслеживание связей реализуются в любом проекте, а потому явное или стихийное понимание того, как они организованы, занимает свое место в концептуальной базе проекта. Ниже мы рассмотрим принципиальный аспект организации этих деятельностей, оставляя детали и методики в качестве предмета конкретных методологий.
Управление рисками
Понятие риска в бытовом смысле чаще всего связывается с негативным влиянием на какую-либо деятельность. В то же время иногда говорят и о позитивном влиянии рисков: «Без риска нет успеха». По-видимому, правильнее всего говорить о том, что с риском связывается некая неопределенность в развитии событий, которая способна оказывать влияние на результативность процессов. Применительно к программным проектам рисками называют неопределенные события, негативно, позитивно влияющие или не влияющие на ход развития проекта (нейтральные). И единственное, в чем сходятся все трактовки поведения в рисковых ситуациях, это то, что к ним нужно готовиться заранее. Управление рисками проекта (Project Risk Management) включает в себя процессы, обеспечивающие планирование возможности рисков, их идентификацию, анализ, разработку откликов и контроль в течение жизненного цикла проекта.
Для позитивных рисков подготовленность означает рациональное использование появляющегося резерва (времени или ресурсов). Неподготовленность к негативным и нейтральным рискам — это всегда потеря возможностей.
Крайняя степень потерь — это ситуации, когда проект прерывается вопреки желанию менеджера продолжать его. Ситуации, когда проект прекращается для менеджера, но, возможно, продолжается с другим менеджером или завершается в связи с причинами, на которые нельзя повлиять, здесь не рассматриваются, поскольку разумная целевая установка менеджера — преодоление негативной рисковой ситуации с минимальными потерями и продолжение проекта. В соответствии с этой установкой менеджер должен еще до начала основных работ проанализировать, из-за чего данный проект может быть сорван, и понять, как он и его фирма могут и должны поступать, чтобы исключить или хотя бы минимизировать риски. В частности, результатом такого анализа может стать отказ от проекта еще до его начала. С другой стороны, т.е. с точки зрения заказчика, риск невыполнения проекта является одной из причин, из-за которых он может отказаться от разработки с данным менеджером, коллективом, фирмой.
Позитивные риски рассматривать как объект управления тоже полезно, но, если задача проекта ставится как достижение его целей без оптимизации расходов, то можно ограничиться обсуждением лишь негативных рисков. Так чаще всего и поступают в конкретных методологиях программистской проектной деятельности. Хотя это и определенное ограничение, в дальнейшем мы в основном будем обсуждать негативные риски. Оправданием позиции может служить не ссылка на традиции, а тот факт, что оперирование нейтральными и позитивными рисками во многом подобно тому, что приходится планировать и отслеживать при работе с рисками срыва проектных работ.
Причины возможного срыва работ весьма разнообразны, они зависят от конкретных условий и не сводятся лишь к техническим аспектам. Разработчики должны учитывать, с одной стороны, такие особенности ведения проекта, как техническая политика руководства фирмы и заказчика, их компетентность, их расчет на удачу, а с другой — кредитоспособность, репутацию тех, кто предлагает заказ. Риск невыполнения проекта может быть связан и с изменением рыночной конъюнктуры. Ненадежность подрядчиков — еще один пример проектного риска. Наконец, есть чисто внутренние причины рисков: сбои в используемом окружении (программном и техническом), неточность предъявляемых требований, ненадежность кадров (принятый на ключевую роль сотрудник может отказаться от контракта в самый неподходящий момент).
Чтобы снизить влияние рисков на развитие проекта, менеджер должен разработать специальный план, называемый далее планом управления рисками. Содержание этого плана — идентификация рисков данного проекта и мероприятия, снижающие зависимость его от рисков. Мы не будем обсуждать методики разработки плана управления рисками, поскольку они всегда завязаны на конкретные методологии. Более того, лишь немного упрощая, можно сказать, что любая методология строится как способ преодоления рисков. Отношение к рискам можно использовать в качестве критерия для классификации методологий, а также для выбора методологии реального проекта с учетом того, какие риски в данном проекте рассматриваться как существенные. Остановимся на общих положениях, которых целесообразно придерживаться при организации работ для минимизации рисков.
При составлении плана управления рисками нужно быть совершенно уверенным в том, что рассматриваются только подлинные риски, а не известные проблемы или условия, т.е. причины беспокойства за проект, которые не влияют на достижение целей проекта. Таким образом, нужно различать:

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

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


В результате (по причине) <определенное событие>

— вместо этого нужно подставить конкретную причину идентифицируемого риска

может случиться <риск>

— нужно подставить наименование риска

что может привести к <воздействие>

— нужно подставить варианты того, что может произойти

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

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

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

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

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

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

  1. Уменьшение риска (mitigate). Если риск не может быть исключен, можно постараться уменьшить вероятность его появления на практике (оперирование причинами). Продолжая пример с увольнением сотрудника, для снижения вероятности этого следует предугадать причины поступка и постараться создать для сотрудника более комфортные условия (повысить заработную плату, создать льготы и т.п.). Нужно, чтобы подобные решения делались не в ответ на заявление об увольнении, а заранее. Это сохранит определенную стабильность в коллективе, которая сама по себе является методом уменьшения риска.

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

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

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

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

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

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

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

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

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

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

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

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

Этот недостаток с трудом поддается измерению. Тем не менее для его преодоления в плане управления качеством полезно предусматривать процедуру сравнения вариантов интерфейсных решений;

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

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

  • Неадекватная реакция на системные ошибки (ошибки разработчиков).

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

Связи проекта
Связи в проекте существуют всегда. Они подразделяются на внешние (зависимость проекта от поставок, финансирования, используемых разработок и др.) и внутренние (зависимость рабочих продуктов проекта друг от друга). Оба вида связей являются постоянной заботой менеджера, разделяемой с руководством фирмы, лидером коллектива и другими ответственными работниками. Задача менеджера в области отслеживания связей — указание на реально существующие зависимости и использование их для направленного развития проекта, своевременная нейтрализация нежелательных влияний и воздействий. Для ее решения необходимо максимально полно представлять себе взаимосвязь процессов развивающегося проекта.
Наиболее простыми с точки зрения отслеживания являются внешние связи. Они довольно полно определяются в ходе распределения ресурсов проекта. Чтобы качественно отслеживать их, достаточно явно фиксировать связи, отражая их документально в качестве материалов, сопутствующих плану-графику проекта.
В большинстве случаев менеджер не в состоянии влиять на материальные и информационные потоки внешних связей проекта. Это означает, что для критических ситуаций зависимости от внешних связей менеджер должен предусматривать альтернативные пути развития проекта. Так, если необходимые поставки запаздывают, это не должно стать неожиданностью для менеджера. Его деятельность состоит в том, чтобы не допустить простоя исполнителей, предложив им нужную работу, которая может выполняться в текущих условиях. Идентификация подобных ситуаций должна быть обеспечена заранее, чтобы соответствующие меры приводили к приемлемым результатам.
В план работы с внешними связями, который составляет менеджер при подготовке к началу проекта, следует включить все критические ситуации и возможные альтернативные действия для коллектива (ссылки на них). Обязательным в этом плане является перечень работ, которые откладываются или срываются в критической ситуации. Реально сведения об откладываемых и альтернативных работах можно указать точно только после разработки плана итераций, т.е. в период после второй контрольной точкой жизненного цикла «Общие требования и общий план составлены» и третьей «Требования к очередной итерации утверждены» (см. лекцию 9). План работы с внешними связями менеджер корректирует всякий раз, когда реализуется критическая ситуация, а также на этапе оценки каждой итерации.
Внутрипроектные связи можно типизировать следующим образом:

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

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

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

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

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика