Лекция 15. Концептуальная база проекта как основа его развития

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

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

При разработке программного проекта возникают весьма разнооб­разные отношения участников (субъекта-исполнителя и всех других ини­циаторов работ) в связи с процессом производства продукта, его распро­странения, использования и других сопутствую и их деятельностей. Эти отношения влияют на траекторию проектной деятельности по-разному что в результате может уводить ее из области допустимости. Но если даже формирование целевой области в течение заметного периода не является определенным по результатам, то что уж тогда говорить обо всей систем; деятельностей проекта! Ясно, что в данном случае необходимо согласова­ние интересов всех инициаторов работ и что такое согласование целесооб­разно выделить как специальную деятельность системы. При стихийно» характере ее выполнения — а так или иначе выполнять согласование при­ходится всегда — возникает опасность сделать не то, что нужно, или во­все не сделать ничего. Мы говорим, что в ходе деятельности согласовано формируется концептуальная база проекта, которая организует актив­ность исполнителей проекта таким образом, что намерения успешного выполнения проекта превращаются в конкретные виды согласованно* активности, продвигающей работы проекта к конкретизируемым по мере развития проекта целям.

Концептуальная база проекта складывается из очень многих состав­ляющих, большинство из которых остаются на неосознанном уровне. Их роль и место в проекте по большей части определяется спецификой про­екта и условиями его выполнения, но есть сведения, без явной фиксации которых в том или ином виде никакое развитие проекта невозможно. Это та часть концептуальной базы, которая определяет общий план проекта. На языке теории деятельности общий план следует рассматривать как ме­тод (см. лекцию 4), поскольку его назначение — предписывать и регла­ментировать процесс выполнения «глобальной» деятельности проекта. Общий план отражает соглашение о динамике развития проекта и о том, какие траектории его выполнения считаются допустимыми. Из этого, в частности, следует, что для определения общего плана необходимо, чтобы между инициаторами работ было достигнуто соглашение о целевой обла­сти операционных маршрутов деятельности проекта. Понятно, что из-за неопределенности с требованиями к большинству программных проек­тов это соглашение не может быть сформулировано ни до начала проек­та, ни в ходе его развитии, пока не будут точно определены потребности деятельностей, использующих результаты. А поскольку потребности раз­виваются, говорить об определенности планирования в большинстве слу­чаев не приходится*. Тем не менее соглашение о принципах планирова­ния, о том, каким должен быть план в его исходном представлении, как он может и должен развиваться, и как он будет контролироваться, необ­ходимо. Это сведения концептуальной базы проекта.

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

План и концептуальная база

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

* Именно об этом говорится в соответствующем тезисе Agile Manifesto (см. раздел «Жесткие и гибкие стратегии в методологиях программирования» в лекции 5). Именно эта причина обусло­вливает тот факт, что в радикальных методологиях быстрого развития (например, в экстре­мальном программировании) говорят не об общем плане проекта, а об игре в планирование, ко­торая предпринимается между разработчиками и заказчиками с целью выяснения того, что можно и нужно реализовывать в качестве решения ближайшей задачи проекта.

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

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

В качестве пояснения места общего плана среди всех материалов проекта приведем метафору проектной деятельности, которой следуют в Центре объектно-ориентированных технологий компании IBM [46]. Со­гласно этой метафоре, весь проект представляется как большая рабочая книга, разделы которой отражают суть рабочих продуктов всей проектной деятельности. Вводная часть представляет концептуальную базу проекта. Она построена в соответствии со структурой концептуальной базы. Главы основной части отражают сведения о релизах. Они структурируются так же, как выполнение итераций. Заключительная часть представляет дея­тельность по опенке выполненного проекта. Разделы «пишутся» по мере выполнения рабочих продуктов. Таким образом, общий план развития проекта — это содержание рабочей книги. Представленная метафора за­мечательна в том отношении, что она отражает параллель между проект­ной деятельностью и тем, что делает технический писатель, составляя до­кументацию по проекту. При желании, можно считать, что рабочая книга действительно пишется по ходу выполнения проектной деятельности, и это есть одна из методических рекомендаций данного подхода.

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

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

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

• Концепции развития проекта — описание системы деятельностей проекта как единого целого, связанного с окружением.

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

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

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

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

• Тестирования и оценивания рабочих продуктов;

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

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

• соглашение об отслеживаемых существенных связях.

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

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

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

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

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

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

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

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

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