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

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

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

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

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

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

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

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

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

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

• Тестирования и оценивания рабочих продуктов;
• измерения качества и других показателей продуктов и процесса развития проекта.

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

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

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

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

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

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

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

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

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

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