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

 

Планирование и контроль развития проекта. Цикл управления проектом

Планы и планирование
При обсуждении концептуальной базы проекта мы говорили о том, что направляющей силой, ведущей проект к достижению цели, является общий план проекта. Рассмотрение его как метода проектной деятельности указывает на его другой аспект: регламенты и соглашения о том, как предполагается достигать цели. Однако если цели определены нечетко, если они меняются под воздействием внешних обстоятельств, то можно ли говорить о планах вообще? Не будем оригинальными в цитировании, но еще раз вспомним об Эйзенхауэре, который говорил: "Готовясь к драке, я всегда обнаруживал, что все планы совершенно бесполезны. А вот без планирования просто не обойтись". Иными словами, планирование как род деятельности — это то, без чего любой сложный процесс, скорее всего, превратится в хаос. Точки зрения на планирование, представленные разными методологиями, отличаются очень сильно.
Для последовательного проекта план исходит из того, что каждый из этапов жизненного цикла программного обеспечения в принципе может быть выполнен полностью, поставляя результаты для следующего этапа. Поэтому задачи, которые требуется решать на каждом этапе, диктуются сразу всеми задачами проекта. Именно эту позицию называют монументальностью последовательных проектов. Такие проекты могут претендовать на успех только в том случае, если можно предсказать, какое развитие будет иметь данная разработка. Иными словами, речь идет о предсказуемых проектах.
Для итеративных проектов план рассматривается по-другому: установка на полное выполнение каждого из этапов жизненного цикла действует только в пределах фиксированной для итерации задачи. Задачи последующих итераций учитываются лишь как возможные перспективы. Отсюда планированию работ итерации предшествует отбор требований и сценариев, которые должны быть решены на этой итерации. Точки зрения на критерии отбора и на оставляемые для реализации на других итерациях задачи разделяют подходы, которые относятся к методологиям итеративного развития проектов. Практически все сходятся лишь в том, что в качестве текущих задач должны быть выбраны те, решение которых реализует наиболее актуальные для пользователей сценарии. В остальном же взгляды расходятся, что вполне объяснимо спецификой позиций разработчиков по отношению к предсказуемости развития проектов.
Консервативная позиция итеративного направления предписывает требование создания на текущей итерации базы для последующего развития. Иными словами, нужно планировать к реализации еще и те средства, которые потребуется использовать в будущем, а реализацию отобранных сценариев строить таким образом, чтобы она допускала развитие без переписывания кода. Эта позиция во многом мотивирована осуществимостью ее поддержки объектно-ориентированными средствами программирования и проектирования. Разрабатываются специальные приемы проектирования, использование которых способствует независимости частей системы и, как следствие, простоте наращивания без переделок . Если рассмотреть консервативную позицию по существу, то становится понятно, что она, как и в случае последовательных проектов, ориентируется на предсказуемое развитие и, как последовательные методологии, является монументальной.
Радикальная позиция итеративного направления представлена в рамках методологического направления быстрого развития программных проектов, в частности в случае экстремального программирования. Здесь вовсе не пытаются заглядывать вперед, далее задачи текущей итерации, которая определяется исключительно актуальностью реализуемых сценариев для пользователей. Вместо планирования как процесса, диктуемого внешней постановкой проектного задания, используется так называемая игра в планирование, в ходе которой разработчики и заказчики в диалоге определяют, что можно реализовать в ближайшей версии системы. Все остальное отбрасывается, и работы ведутся так, как будто они в любой момент могут быть направлены по совершенно непредсказуемому пути.
Последовательный и экстремальный подходы — это две крайние позиции по отношению к планам. Реальность такова, что обе эти позиции следует считать идеализацией. Первая обыкновенно нарушается, причем не только в связи с ошибками этапов, предшествующих текущим работам. Вторая не может не рассчитывать на гипотезы о продолжении, о том, как проект будет развиваться, и разработчики всегда готовятся ко всем возможным поворотам. Перспективному планированию экстремальное программирование отдает должное, но в этом подходе изменение плана считается нормой и на деле оно постоянно происходит. Это не значит, что с появлением новой актуальной для реализации пользовательской истории или со сменой приоритетов кто-то переписывает некий документ, утверждает его, производит другие "ритуальные" бюрократические манипуляции. Корректируется представление работников о перспективах, а как и когда оно материализуется — другой вопрос.
По сути дела, главная причина различий отношений к планам проекта — различия гипотез о степени изменчивости и непредсказуемости требований.
Мы придерживаемся отношения к планам, которое исходит из разбиения проекта на две части: ближайшую и перспективные задачи. Для ближайшей задачи неопределенность развития должна быть сведена к минимуму, пусть даже за счет ошибочных предположений о перспективах. Следовательно, планирование решения ближайшей задачи не только возможно, но и целесообразно. Для перспективных задач должна быть определена стратегия, которую мы не хотим считать жестко фиксированной. При такой установке последовательное и экстремальное развитие проектов смыкаются: различия только в масштабе ближайшей задачи проекта и в отношении к одинаково неопределенной гипотезе о продолжении. В первом случае любое продолжение есть новый проект, а во втором имеется в виду настолько широкий спектр продолжений, что ориентация на какое-либо из них считается бессмысленной.
Все итеративные методологии укладываются в эту схему, если принять, что при определении ближайшей задачи часть требований сознательно откладывается до последующих итераций. Скорее всего, но совсем необязательно, эта часть будет реализовываться в дальнейшем среди других требований, которые, возможно, появятся в течение развития проекта. И опять крайние позиции смыкаются: для последовательных проектов откладываемая часть требований считается пустой (ничто не откладывается), а для быстрых — это требования, которые не удовлетворили критерию пользовательской актуальности, понимаемой строго на момент выбора реализуемых сценариев.
Для большинства методологий считается, что основой планирования программной разработки является принятая для проекта модель жизненного цикла. Как правило, выполняемые работы укладываются в основные (общие для выбранной методологии) этапы. Конкретные проекты чаще всего требуют введения в планы дополнительных этапов и контрольных точек, которые отражают начало и завершение важных или ответственных работ, события, существенные для проекта. Конкретизация схемы жизненного цикла — это первоочередная работа по составлению планов проекта. И уже на этом уровне видно, что выполнение ее для большинства основных этапов зависит от результатов предыдущих этапов. Наглядный пример тому — невозможность конкретного планирования этапа программирования без проведения архитектурных работ, определяющих декомпозицию системы, которая служит базой для выставления заданий разработчикам подсистем. Зависимость работ, выполняемых в ходе развития проекта, требует своих методов преодоления трудностей конкретизации планов. На уровне первичного планирования это принцип подмены конкретных проектных заданий стратегическими установками, которые уточняются, когда для этого появляется информация.
Положения о связи планирования с жизненным циклом сформировались в традиционных методологиях, и, может быть, по этой причине они, как и все традиционное планирование, отвергаются быстрыми подходами. В то же время, с учетом различий типов жизненных циклов быстрых и традиционных методологий, эти связи сохраняются, хотя и приобретают некоторую специфику. Так конкретизация схемы жизненного цикла для быстрых подходов для долгосрочной перспективы оказывается планом релизов. С этого, как и при традиционном подходе, начинается планирование, а точнее — ориентировочное прогнозирование проекта, без которого просто немыслимо получить заказ. Последовательная зависимость итераций друг от друга в этом подходе, безусловно, предполагается, хотя не ей, а другим критериям (актуальности для пользователя) отдается предпочтение при распределении работ по итерациям. Есть место и оценкам плана: априорным, до его выполнения, когда разработчики договариваются с заказчиком о том, что из пользовательских историй и за какие сроки они будут реализовывать на предстоящей итерации, и апостериорным, одна их целей которых - корректировка предположений о процессе на основании полученного опыта.
Отдельного рассмотрения требует понятие контрольной точки, играющее важную роль в традиционном планировании. Разумеется, для метода ведения проекта, когда каждая планируемая итерация занимает от одной до трех недель, специальных контрольных точек, отличных от начала и завершения итерации, не нужно. К тому же локализованный в этих точках контроль и при традиционном подходе эффективен только тогда, когда он выявляет отклонения траектории от планируемой. Только в этом случае необходимы воздействия, которые и оправдывают смысл контрольных мероприятий. Но отклонение могло произойти еще до контроля, а значит, для своевременного воздействия момент упущен. В то же время контроль сроков выполнения заданий необходим для того, чтобы постоянно вносить коррективы в развивающийся план. Вслед за Беком и Фаулером мы придерживаемся позиции, согласно которой перенос сроков следует считать чрезвычайной ситуацией (см. раздел "Управление рисками" лекции 16). Если корректировка необходима, то лучше производить ее по объемам работ, запланированных к контрольной точке. Но выявлять нарождающуюся необходимость корректировки нужно всегда как можно раньше. Отсюда следует, что при любой методологии требуется постоянное текущее наблюдение за ходом развития этапа проекта. А для задач, решаемых в контрольных точках, разумно оставить лишь оценку соответствия планируемых и полученных результатов, на основе которого корректируется план. Если угодно, это можно считать корректировкой целевой области и траектории планировочной деятельности.
Мы намеренно изложили эти рекомендации без привязки к какой бы то ни было методологии. В самом деле, они действительно не зависят даже от методологической стратегии и указывают на целесообразность принципа выяснения отклонений и быстрой корректировки (см. лекцию 5), лишь слегка его конкретизируя. Дальнейшая конкретизация того, как осуществлять текущее наблюдение, безусловно, необходима, но это уже зависит от выбранной для проекта методики.
Для методологий, предполагающих организацию производства как процесс, допускающий внешнее отслеживание, общий план развития проекта как сумма планов процессов (по-нашему — деятельностей, реализующих производственные функции), которые должны осуществляться в ходе выполнения проектной деятельности в целом, является обязательным, документально оформленным руководством разработчиков. Его корректировка допускается, но весьма регламентированная: в контрольных точках (заранее спланированных!) и в ходе откликов на риски. Конечно, если в результате наблюдения выясняется, что текущий этап проекта не может быть выполнен до конца или запланированное выполнение не имеет смысла и что целесообразно изменить содержание проектных или этапных задач, то материалы для такой корректировки готовятся в момент выявления отклонения. Они согласуются с заказчиком, чтобы в контрольной точке ограничиться лишь юридическими аспектами и утверждением новых условий продолжения работ. Роль планирования ставится очень высоко, а потому общий план и его составляющие рассматриваются как главные документы проекта. Например, стандарт PMBOK из 39 процессов, которые он фиксирует в проектной деятельности, 18 процессов относит к группе планирования (см. лекцию 4). Последняя версия стандарта не требует обязательного составления всех этих планов, но должна сохраняться возможность доказать, что при выполнении проекта все обозначенные в них процессы должны быть предусмотрены.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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