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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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