Задачи управления проектами

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

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

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

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

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

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

Поскольку каждый проект проводится в рамках какой-то организации, то принятая в ней система ценностей влияет и на оценку каждого конкретного проекта (см.

далее).
Основные виды ресурсов, используемых в любом проекте, следующие.

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

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

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

Создаваемые программы нематериальны. Это порождает проблемы двух видов.
- Программы обладают потрясающей гибкостью, они не оказывают сопротивления воздействиям, как физические материалы. Все знают, что построить дом можно из твердого и плотного материала, а чтобы сделать батут нужно использовать материал мягкий, гибкий и прочный. В мире же программ можно построить все, что угодно, из одних и тех же базовых конструкций.
  Поэтому иногда кажется, что раз суть требуемых изменений в программе понятна, на их воплощение нужно немного усилий. Это не так. Работа с элементами программ в этом аспекте не слишком отличается от работы с кирпичами и строительными блоками.
  
  А если эти блоки еще и стоят кое-как, то при попытке передвинуть их программиста вообще может "завалить" — отладка полученной программы потребует колоссальных усилий.
- Движение к нужному результату при разработке ПО очень тяжело проконтролировать. При возведении здания или постройке корабля можно непосредственно наблюдать за тем, как продвигается работа. При создании сложной программной системы силами многих разработчиков нужно аккуратно подбирать индикаторы того, как идут дела, иначе легко впасть в заблуждение относительно истинного положения вещей.
Программные системы практически всегда уникальны.
Каждая из них обладает своим набором характеристик (включая все реализуемые функции, производительность при их выполнении, все элементы пользовательского интерфейса и т.п), так или иначе отличающихся от характеристик других программ, даже делающих "то же самое". Если обладающая нужными свойствами (в том числе и подходящей ценой) программа уже имеется, незачем создавать ее заново — достаточно приобрести ее или взять ее код и скомпилировать. Поэтому практически каждая разрабатываемая программа уникальна — она должна иметь такие характеристики, которыми не обладает ни одна уже созданная.
- Тем самым, почти каждый проект по разработке ПО включает элементы творчества, создания того, чего еще никто не делал. Крупные же проекты требуют решения сразу нескольких ранее не решенных задач. Управление проектами с элементами творческой деятельности очень сильно отличается от управления проектами, в которых заранее ясно, что именно надо делать и как.
- Другое следствие этой уникальности ПО — отсутствие стандартных процессов разработки. Нет целостных подходов к созданию ПО, которые годились бы для всех случаев, а не только для определенного вида проектов. Кроме того, для хорошо определенных процессов, таких как RUP, XP, Microsoft Solution Framework или DSDM (Dynamic Systems Development Method, Метод разработки динамичных систем), недостаточно четко очерчены области их применимости.
  
  Каждый раз менеджеру проекта приходится только на основании своего опыта и советов экспертов принимать решение о том, какой процесс разработки использовать и как его модифицировать для достижения большей эффективности в конкретном проекте.
Есть много аргументов в пользу того, что программный код является проектом, а не конечным продуктом.
При разработке ПО переход от проекта к продукту почти полностью автоматизирован — требуется лишь скомпилировать код и развернуть систему в том окружении, где она будет работать. А само программирование гораздо больше напоминает разработку проекта здания, чем его строительство по уже готовому проекту. То же, что в разработке ПО обычно называется проектом или дизайном, представляет собой лишь набросок окончательного проекта, определяющий основные его черты и требующий дальнейшей детализации. Таким образом, разработка программ отличается от других инженерных видов деятельности тем, что в основном состоит из проектирования, а не изготовления продукта.
Это еще одна причина того, что программирование всегда включает элемент творчества. Кроме того, проблемы, с которыми сталкивается руководитель проекта разработки ПО, гораздо более похожи на проблемы периода проектирования здания, самолета или корабля, чем на проблемы периода их постройки.

Все публикации раздела