Цикл управления проектом

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

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

Планы и планирование

При обсуждении концептуальной базы проекта мы говорили о том, что направляющей силой, ведущей проект к достижению цели, является общий план проекта. Рассмотрение его как метода проектной деятельно­сти указывает на его другой аспект: регламенты и соглашения о том, как предполагается достигать цели. Однако если цели определены нечетко, если они меняются под воздействием внешних обстоятельств, то можно ли говорить о планах вообще? Не будем оригинальными в цитировании, но еще раз вспомним об Эйзенхауэре, который говорил: «Готовясь к дра­ке, я всегда обнаруживал, что все планы совершенно бесполезны. А вот без планирования просто не обойтись» [45]. Иными словами, планирова­ние как род деятельности — это то, без чего любой сложный процесс, ско­рее всего, превратится в хаос. Точки зрения на планирование, представ­ленные разными методологиями, отличаются очень сильно.

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

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

Консервативная позиция итеративного направления предписывает требование создания на текущей итерации базы для последующего разви­тия. Иными словами, нужно планировать к реализации еще и те средства, которые потребуется использовать в будущем, а реализацию отобранных сценариев строить таким образом, чтобы она допускала развитие без пе­реписывания кода. Эта позиция во многом мотивирована осуществимо­стью ее поддержки объектно-ориентированными средствами программи­рования и проектирования. Разрабатываются специальные приемы про­ектирования, использование которых способствует независимости частей системы и, как следствие, простоте наращивания без переделок [10]. Ес­ли рассмотреть консервативную позицию по существу, то становится по­нятно, что она, как и в случае последовательных проектов, ориентирует­ся на предсказуемое развитие и, как последовательные методологии, яв­ляется монументальной.

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

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

По сути дела, главная причина различий отношений к планам про­екта — различия гипотез о степени изменчивости и непредсказуемости требований.

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

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

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

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

Отдельного рассмотрения требует понятие контрольной точки, играю­щее важную роль в традиционном планировании. Разумеется, для метода ве­дения проекта, когда каждая планируемая итерация занимает от одной до трех недель, специальных контрольных точек, отличных от начала и завер­шения итерации, не нужно. К тому же локализованный в этих точках конт­роль и при традиционном подходе эффективен только тогда, когда он выяв­ляет отклонения траектории от планируемой. Только в этом случае необхо­димы воздействия, которые и оправдывают смысл контрольных мероприя­тий. Но отклонение могло произойти еще до контроля, а значит, для своевременного воздействия момент упущен. В то же время контроль сроков выполнения заданий необходим для того, чтобы постоянно вносить коррек­тивы в развивающийся план. Вслед за Беком и Фаулером мы придерживаем­ся позиции, согласно которой перенос сроков следует считать чрезвычайной ситуацией (см. раздел «Управление рисками» лекции 16). Если корректиров­ка необходима, то лучше производить ее по объемам работ, запланированных к контрольной точке. Но выявлять нарождающуюся необходимость коррек­тировки нужно всегда как можно раньше. Отсюда следует, что при любой ме­тодологии требуется постоянное текущее наблюдение за ходом развития эта­па проекта. А для задач, решаемых в контрольных точках, разумно оставить лишь оценку соответствия планируемых и полученных результатов, на осно­ве которого корректируется план. Если угодно, это можно считать корректи­ровкой целевой области и траектории планировочной деятельности.

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

Для методологий, предполагающих организацию производства как процесс, допускающий внешнее отслеживание, общий план развития проекта как сумма планов процессов (по-нашему — деятельностей, реали­зующих производственные функции), которые должны осуществляться в ходе выполнения проектной деятельности в целом, является обязатель­ным, документально оформленным руководством разработчиков. Его корректировка допускается, но весьма регламентированная: в контроль­ных точках (заранее спланированных!) и в ходе откликов на риски. Конеч­но, если в результате наблюдения выясняется, что текущий этап проекта не может быть выполнен до конца или запланированное выполнение не имеет смысла и что целесообразно изменить содержание проектных или этапных задач, то материалы для такой корректировки готовятся в момент выявления отклонения. Они согласуются с заказчиком, чтобы в контроль­ной точке ограничиться лишь юридическими аспектами и утверждением новых условий продолжения работ. Роль планирования ставится очень вы­соко, а потому общий план и его составляющие рассматриваются как глав­ные документы проекта. Например, стандарт РМВОК [48, 49] из 39 про­цессов, которые он фиксирует в проектной деятельности, 18 процессов от­носит к группе планирования (см. лекцию 4). Последняя версия стандар­та не требует обязательного составления всех этих планов, но должна сохраняться возможность доказать, что при выполнении проекта все обозначенные в них процессы должны быть предусмотрены.

Наблюдения и контроль

Если планы рассматривать как основу организации работ, то конт­роль — это текущая деятельность, которая осуществляется для того, что­бы компенсировать неизбежные отклонения от планов. Способы контро­ля могут быть совершенно разными. Некоторые из них мы уже рассмат­ривали, когда обсуждали мотивацию каскадной модели жизненного цик­ла и функциональное измерение модели Гантера (см. лекции 7 и 9) Причины различий — и специфика проектов и коллективов, и выбрана* методология процесса разработки. Они являются предметом специально­го рассмотрения. Здесь же укажем лишь на то, что правильный, разумно-организованный контроль со стороны менеджера должен сбалансирован­но сочетать в себе два противоречивых аспекта:

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

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

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

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

• анализ кода программ и данных автоматического мониторинга с помощью специальных инструментов;

• специальное, т.е. со стороны наблюдателя, тестирование;

• опрос работников (что означает не устный отчет, а свободный раз­говор, в ходе которого выясняется, как идут дела);

• простые и короткие вопросы по сути: как было принято то или
иное решение, от чего пришлось отказаться, что не удалось преду­смотреть и т.д.;

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

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

Мероприятия в контрольных точках проводятся, во-первых, для то­го, чтобы доказать, что определенные заранее локальные цели проекта до­стигнуты, — контрольные функции, а во-вторых, чтобы узнать качество ра­бочих продуктов и процесса, — оценочные функции. Мероприятия в конт­рольных точках должны обеспечивать уверенность доступных инициато­ров работ в правильности стратегической линии и принятых решений, а также в том, что результаты удовлетворяют заранее фиксированным кри­териям. Когда наблюдение организовано правильно, специальных дейст­вий для контрольных функций, скорее всего, не потребуется. Но если на материале наблюдений цель контроля остается недостигнутой, а также в тех контрольных точках, которые заранее определены для независимой инспекции, приходится прибегать к верификации и аттестации как явным процедурам. Мы достаточно подробно рассмотрели суть этих процессов, когда обсуждали каскадную модель (см. лекцию 7). Если оставить в сторо­не конкретные методики их организации (для восполнения этого пробела можно рекомендовать, например, книгу [271), то остается добавить только сведения о том, когда целесообразно планировать их активизацию.

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

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

Оценка выполнения проектных заданий

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

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

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

• Оценка продукта безотносительно его производства. Определяется его
эффективность с точки зрения автоматизации пользовательской деятельности. Целесообразно при выработке этой оценки брать за ос­нову мнения пользователей и других заинтересованных лиц.

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

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

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

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

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

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

Полученные оценки дополняются оцениванием процесса разработки и ее планирования. Эта работа рассматривается в следующих аспектах.

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

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

проекта и команде исполнителей. По мере того как проект прохо-' дит все большее число итераций, данная оценка становится вся более точной.

• Оценка коллектива осуществляется по следующим параметрам:

—квалификация сотрудников;

—рост квалификации сотрудников;

—стабильность кадров;

—слаженность;

—распределение обязанностей и разделение труда.

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

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

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

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

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

• постановка задач — определение заданий для разработчиков, про­верка понимания заданий и другие действия, необходимые для ре­шения задачи текущего периода;

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

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

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

• оптимизация процесса разработки — коррекция расстановки кадров, априорных решений и планов.

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

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

Вариант 1

Из каких предпосылок исходит план последовательно развивающегося проекта?

□ заранее известны все требования к проекту и все условия его
выполнения

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

□ развитие проекта можно рассматривать как предсказуемый процесс

□ проект начинается с анализа требований, который предопре­деляет стратегию развития проекта

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

Допускается ли корректировка планов последовательного проекта, когда выясняется, что какой-либо из этапов не укладывается в сроки и ресурсы?

Q это нормальное явление, которое интерпретируется как необ­ходимость настройки плана в связи с изменением обстоя­тельств

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

□ это невозможно, так как. при корректном проведении анализа
требований и квалифицированном планировании развитие
проекта является детерминированным

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

□ это иногда допускается, но с учетом ужесточения условий вы­полнения последующего этапа, корректирующего ситуацию по срокам и ресурсам

Внешняя оценка результатов проектной деятельности ха­рактеризуется:

□ направленностью на улучшение качества процесса производ­ства, роста квалификации исполнителей и других подобных параметров

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

□ направленностью на улучшение качества субподрядных работ

□ тем, что она отражает достоверность прогнозов о качестве
снабжения ресурсами и надежности финансирования

□ тем, что она отражает потребность рынка в разрабатываемо
программном изделии

Вариант 2

1. Из каких предпосылок исходит план любого итеративно
развивающегося проекта?

□ планируется к реализации на итерации то, что заведомо не бу­дет переделываться на последующих итерациях

П установка на полное выполнение этапов жизненного цикла действует только в пределах фиксированной для итерации за­дачи

□ в качестве критериев отбора, реализуемых на итерации требо­ваний и сценариев, используется только один: актуальность задачи для пользователя

□ задачи последующих итераций учитываются как возможные,
весьма вероятные перспективы

□ планированию итерации предшествует отбор требований и сценариев, которые должны быть реализованы на этой итерации

2. Допускается ли корректировка планов итеративно разви­ваемого проекта, когда выясняется, что очередная итера­ция не укладывается в сроки и ресурсы?

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

□ это возможно и используется постоянно как превентивная ме­ра до начала итерации, что интерпретируется как адаптация плана к уточненным условиям

□ это нормальное явление, которое интерпретируется как необходимость настройки плана в связи с изменением обстоя­тельств

Q это возможно только как превентивная мера до начала итера­ции, что интерпретируется как устранение ошибки плана

□ это невозможно, так как при корректном проведении анализа требований для итерации и квалифицированном ее планиро­вании развитие работ итерации является детерминированным

3. Внутренняя оценка результатов проектной деятельности характеризуется:

□ тем, что она отражает отношение к проектной деятельности

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

□ направленностью на улучшение квалификации сотрудников и точности ее соответствия разделению труда в проекте

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

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

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

Вариант 3

1. Первоочередная работа по составлению планов проекта —

это:

□ определение для проекта в целом объемов работ, сроков и при­влекаемых финансов

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

□ анализ требований к разрабатываемому программному изделию

□ выбор методологической стратегии развития проекта

Текущее наблюдение за ходом развития проекта — это:

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

□ ежедневный отчет сотрудников о проделанной работе и затра­ченных ресурсах

□ ежедневные собрания сотрудников с целью выяснения теку­щего состояния развития проекта

□ ежедневный опрос сотрудников о ходе развития проекта

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

3. Что должен сочетать в себе правильный и хорошо сбалансированный контроль хода проектных работ со стороны
менеджера?

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

□ необходимо добиваться, чтобы исполнители точно и в срок от­
читывались о проделанной работе, не скрывая проблем, кото­рые возникают при ее выполнении

□ необходимо добиваться знания абсолютно точной картины то­
го, как выполняются порученные исполнителям работы

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

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

Дата добавления: 2014-01-06