Результативность программистской проектной деятельности

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

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

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

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

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

Рабочие продукты

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

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

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

Прежде чем обсуждать их, рассмотрим одну любопытную точку зрения (метафору) на программный проект, высказанную еще в конце семидесятых годов Ф.Я. Дзержинским [13]. Суть ее в том, что любая документация оказывалась бы ненужной, если бы можно было сопровождать каждую поставку программы ее автором. Иными словами, идеальная документация - это разработчик программного продукта; он в состоянии давать адресные и самые квалифицированные консультации, конструктивно отвечать на вопросы пользователей. Таким образом, в точке зрения Дзержинского отражен взгляд на документацию как на заместителя разработчика при используемой программе. Отсюда следует и критерий качества документации: она тем лучше, чем точнее имитирует непосредственное взаимодействие разработчиков с пользователями. Взгляд на документацию как на заместителя разработчика позволяет сделать явным разграничение между видами документов для разных вариантов использования: в разных ситуациях требуются различные консультации и разъяснения.

Подобная точка зрения на документацию высказывалась и ранее (см., например, [2]), но потом была почему-то забыта. И очень часто на составление документов, сопутствующих программам, смотрят как на обузу, заслуживающую внимания лишь постольку, поскольку она требуется стандартами приемки программ. Нередки высказывания о том, что сегодня система помощи заменяет документацию. Но даже если оставить в стороне качество систем помощи, то все равно очевидно, что она в принципе не решает вопросы познаваемости процесса производства и отвечает требованию познаваемости продукта лишь в той части, которая касается непосредственного применения.

В первом приближении можно указать на следующие виды рабочих продуктов проекта.

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

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

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

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

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

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

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

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