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

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

Введение В существующих программах управления проектами (УП) и совокупностями проектов выбор ресурсов осуществляется обычно без учета зависимости качества получаемых конечных результатов от состава (набора) планируемых к применению ресурсов. Однако на практике выбор ресурсов (как трудовых, так и материальных) может существенно влиять на качество выполнения отдельных работ и результаты по проекту (группе проектов) в целом, хотя формальные цели реализации проектов достигаются во всех случаях. Например, при разработке программного средства (ПС) при формальном обеспечении заданной, т. е. отраженной в техническом задании (ТЗ), функциональности разработки ее качество может определяться такими факторами, как скорость работы ПС; его требования к оперативной памяти и иным ресурсам ПЭВМ; удобство (интуитивность) интерфейса с пользователем; вероятность наличия в ПС логических ошибок, не выявленных при тестировании и приемосдаточных испытаниях; наглядность представления результатов работы ПС; уровень информационной безопасности в процессе жизненного цикла эксплуатации ПС и пр. [1]. Таким образом, качество разработки ПС при формальном соблюдении условий успешного завершения проекта с позиций ее пользователей будет влиять на «полезность» ПС, риски при ее внедрении [2, 3], эксплуатации и пр. Поэтому целью нашего исследования был анализ комплекса вопросов, связанных с влиянием качества выполнения работ на «полезность» достигаемых результатов и риски с позиций различных групп юридических и физических лиц, связанных с планированием и реализацией проектов. Краткий литературный обзор по теме статьи В существующей русскоязычной литературе по УП наряду с учебными руководствами (обычно жестко ориентированными на использование программы Microsoft Project) есть и достаточно много научных публикаций - как по управлению одним проектом, так и их группой (портфелем) [4-6]. В последнем случае предполагается, что по крайней мере часть ресурсов потенциально может использоваться в разных проектах. Отметим, что за последние годы поисковая система elibrary (www.elibrary.ru) по тематике «Управление портфелем проектов» выдает преимущественно русскоязычные публикации, причем такое же преобладание наблюдается и в списках источников, цитируемых в этих публикациях. В общем случае по заинтересованности в проектах (результатах проектов) можно выделить следующие группы физических и юридических лиц: организации, в которых работают специалисты по УП; специалисты, непосредственно осуществляющие УП; исполнители работ, привлекаемые к реализации проектов (включая руководителей групп); организации/подразделения, заинтересованные в использовании результатов, полученных при реализации проектов. Последними могут быть как «внешние» заказчики (организации), так и «внутренние подразделения» тех организаций, в которых реализуются проекты [7]. У каждой из перечисленных групп физических и юридических лиц есть некоторые ожидаемые положительные эффекты от реализации проектов; предполагаемые затраты на их реализацию; ожидаемые уровни качества и сроков выполнения работ; риски, связанные с реализацией проектов (они могут быть оценены в денежных единицах). Важно отметить, что в большинстве имеющихся публикаций в отношении результативности выполнения проектов эти группы лиц не разделяются, хотя такая дифференциация представляется целесообразной. Очевидно, что проще осуществить «согласование интересов» в том случае, когда проекты носят «внутренний» для организации характер [7]. В общем случае решение вопросов «согласования интересов» носит компромиссный характер. В учебных руководствах для анализа взаимосвязей между стоимостью, сроками и качеством работ обычно приводится так называемый «проектный треугольник», в котором риски вообще не фигурируют. Результаты анализа с использованием этого треугольника носят качественный характер и в практическом отношении малополезны. Можно считать, что и для лиц, осуществляющих УП, и для заказчиков качество выполнения работ влияет на два основных фактора - положительные эффекты и риски. Типичные постановки задач оптимизации планов проектов обычно ориентированы на минимизацию продолжительности «критического пути» проекта при соблюдении ограничений на его «бюджет» [8]. Возможности такой оптимизации в автоматическом режиме существуют уже во многих ПС УП. При этом обычно выполняется совершенствование (по сравнению с первоначальным планом) «распараллеливания работ» в проектах с соблюдением ограничений на «бюджет» и «доступность ресурсов». Оптимизация по комбинированным критериям (например, в виде «линейной комбинации» стоимости и продолжительности с разными весовыми коэффициентами) в ПС как правило не реализованы. Однако это иногда можно сделать с использованием собственных программ, написанных на встроенном в ПС языке программирования. Цель максимально полного «задействования» (использования) доступных ресурсов, по крайней мере в качестве «основной», как правило, не ставится, но иногда учитывается как вспомогательная. Чаще всего планирование проектов рассматривается с позиций лиц, осуществляющих УП. При этом задачи повышения «доходности» от реализации проектов (разница между полученными средствами и фактической себестоимостью выполнения работ) обычно не ставятся, а максимальные объемы затрат по проектам - фиксируются. Для групп (портфелей) проектов задачи оптимизации планов могут ставиться по-разному. (1) Проекты не являются взаимосвязанными в том смысле, что результаты одних проектов не используются в других. Тогда «распараллеливание» использования доступных ресурсов обычно преследует цель минимизации времени реализации каждого из проектов. (2) Совокупность планируемых проектов преследует общую цель, которая достигается только при успешном выполнении (независимом) всех проектов. Тогда минимизировать следует период от начала реализации группы проектов до их полного завершения. При этом моменты начала и конца могут относиться к разным проектам, а длительность выполнения отдельных проектов может быть «неоптимальной» по отношению к случаю, когда такие проекты планируются как автономные. (3) Проекты взаимосвязаны по результатам так, что некоторые проекты могут начинаться только после окончания одного или большего количества других проектов, что в наглядной форме соответствует ориентированному графу. Такую совокупность проектов с позиций оптимизации может быть удобнее представить в виде единого проекта. Отметим, что возможность выбора наилучшего «набора проектов» для реализации одновременно с оптимизацией подбора ресурсов для них в существующих ПС УП не предусматривается. Планирование использования трудовых (и некоторых иных видов ресурсов) осуществляется в нормо-часах, при этом зависимость продолжительности работ от «качества ресурса» (например, квалификации программиста-разработчика) обычно не учитывается. Риски в ПС УП в лучшем случае учитываются формально, причем без привязки к планируемым «единицам ресурсов» для работ и затратам, связанным с предотвращением и устранением (компенсацией) результатов реализации неблагоприятных событий. Иными словами риски рассматриваются отдельно от затрат, хотя по сути они взаимосвязаны. Задачи «управления качеством» в отношении проектов также отражены в существующих публикациях [1, 9], но они в большей мере относятся к управлению качеством планирования и реализации проектов, чем к «результатам самих проектов». Отсутствие в существующих публикациях анализа выгодности (полезности) проектов с позиций заказчиков приводит к тому, что «фактическое качество» не фигурирует при оценке рентабельности проектов - по крайней мере в явной форме. Следует также отметить отсутствие анализа для проектов взаимосвязей типа «качество - риски», хотя вопросам оценки рисков и уделяется определенное внимание [1, 10, 11]. В типичных случаях в учебниках и научных статьях по УП выделяются три группы ресурсов: трудовые (ресурсы человеческого труда); материальные (оборудование и материалы); финансовые. При этом трудовые ресурсы планируются в проектах исходя из «категорий должностей», а конкретные фамилии исполнителей обычно не указываются. Рассмотрение в существующей литературе вопросов «персонализации» трудовых ресурсов носит достаточно редкий характер [12]. Исполнительская дисциплина отдельных работников (в основном - в отношении сроков); доли времени, когда они находятся в нетрудоспособном состоянии; качество выполнения ими работ; их «совместимость в команде проекта»; степень надежности единиц оборудования могут учитываться в отдельных базах данных (БД), т. к. в существующих ПС УП хранение такой информации не предусмотрено. Обеспечение программных интерфейсов таких внешних ПС с ПС УП представляет собой достаточно сложную задачу. Априорные оценки совместимости исполнителей в конкретном проекте потенциально могут учитываться при определении рисков с позиций лиц, осуществляющих УП. Общая характеристика видов ресурсов, используемых в проектах, и возможностей детализации требований к ним Профессиональная специализация планируемых «единиц» трудовых ресурсов в планах проектов может указываться косвенно - через категорию должности (например, «web-программист», хотя нередко нужно и более точное указание специализации). Необходимая квалификация исполнителей (фактически - уровень их интеллектуального потенциала) не всегда может быть задана с помощью должности. Так, например, квалификационные характеристики для программистов в планах проектов обычно не указываются, т. к. для них (в отличие от рабочих профессий) «тарифно-квалификационных разрядов», по крайней мере на общероссийском уровне, нет. Указание величины почасовой оплаты может служить косвенной характеристикой квалификации «единиц трудовых ресурсов», хотя и не всегда. В рамках приведенной выше классификации (материальные, трудовые и финансовые ресурсы) информационные ресурсы, необходимые для реализации проекта или группы проектов, приходится относить к материальным. Однако они могут и не иметь «вещественного воплощения», т. е. быть представленными только в электронной форме, в т. ч. и на дистанционных Интернет-ресурсах. Качество информационных ресурсов определяется актуальностью, достоверностью, точностью информации. Бизнес-решения (в том числе и связанные с УП) по российскому законодательству не рассматриваются как объекты авторского права и, следовательно, не имеют правовой защиты. Программы для ЭВМ и БД, используемые на основании «неисключительных лицензий» или распространяемые на бесплатной основе, также приходится относить к «материальным ресурсам» - даже если речь идет только о копиях, существующих в электронной форме и размещенных на ПЭВМ или серверах организаций. Для ПС, распространяемых по модели SaaS, затраты на их использование осуществляются вообще без установки копий на сервера или ПЭВМ организаций. Качество ПС как ресурсов определяется в основном их функциональностью и удобством использования. В рамках планирования/реализации проектов могут применяться и такие объекты, как изобретения, права на которые защищены с помощью действующих патентов. Это касается как разработки устройств (предназначенных для единичного изготовления или серийного выпуска изделий), так и создания ПС - заказных или предназначенных для тиражирования. В последнем случае возможность использования «запатентованных решений» обычно лицензируется у владельцев прав интеллектуальной собственности на эти объекты. Интересно, что в зарубежной практике (особенно в США) оригинальные решения по ПС очень широко патентуются и такие патенты рассматриваются как важнейшее конкурентное преимущество фирм ИТ-сферы. В России же алгоритмы не являются объектами авторского права, а патентование их в виде «способов» решения каких-то задач распространено слабо. В то же время ПС рассматриваются как объекты авторского права и права на их использование защищаются законодательно. В практическом отношении важна официальная регистрация ПС в Федеральном институте промышленной собственности. С позиций «бухгалтерского учета» права на объекты интеллектуальной собственности (ОИС) рассматриваются как «нематериальные активы». В то же время в рамках решения задач УП их приходится относить к «материальным ресурсам» - за неимением ничего более подходящего. При этом использование (или неиспользование) ОИС в проектах может значительно влиять не только на результаты работ, но и на саму возможность их успешного завершения. В отношении планирования использования ресурсов оборудования для проектов целесообразно отметить следующее: в разрабатываемых с использованием ПС планах проектов обычно учитывается производительность оборудования, но не качество изготавливаемых объектов (при условии, что оно не хуже приемлемого); физический износ оборудования учитывается через «затраты на использование», однако моральное старение (в том числе и неприменяемого оборудования) никак не учитывается; энергозатраты на использование оборудования учитываются косвенно - через стоимость использования (однако реализация политики энергосбережения может требовать и отдельного учета потребления энергии как ресурса). Объемы отходов, соответствующие различным вариантам технологических процессов для проектов, также могут учитываться лишь косвенно (через затраты на использование оборудования). Однако в рамках реализации природоохранной политики лимитирование объемов и токсичности отходов может требовать их отдельного учета как ресурсов. Для групп проектов в большинстве существующих ПС не предусмотрен учет затрат (средств и времени) на перемещение оборудования между «объектами» (например, строительными), которые соответствуют различным проектам. Формально такой учет может быть сделан путем введения «дополнительных задач». Однако при этом возникают следующие сложности: не всегда ясно, к каким именно проектам следует относить соответствующие затраты времени и средств; само по себе наличие этих дополнительных задач в планах УП (и потребность их в транспортных ресурсах) будут зависеть от распределения ресурсов между объектами. Отметим, что существующие ПС УП при оптимизации планов проектов возможность «включения» и «исключения» такого рода задач не предусматривают. Приведенные соображения говорят в пользу расширения номенклатуры объектов, рассматриваемых как «ресурсы» при планировании проектов и их реализации. Кроме того, при планировании ресурсов для реализации проектов необходимо рассматривать влияние замены одних однотипных ресурсов на другие с позиций качества результатов. Анализ понятия «качество результатов» проекта и методов управления им с различных позиций С точки зрения физического лица (или группы лиц), непосредственно осуществляющих УП, качество реализации проекта обычно определяется следующими факторами: самим фактом завершения проекта или его прекращения; соблюдением необходимых сроков завершения проекта (или степенью их нарушения); соблюдением бюджетных ограничений (или величиной их превышения). С позиций лиц, осуществляющих УП, «инструментами управления» (в том числе и в отношении сроков/качества работ) могут быть следующие: распределение (перераспределение) ресурсов между проектами/работами, в т. ч. и в рамках материального поощрения исполнителей; организационные и административные меры; юридические меры и др. Если некоторые качественные характеристики проекта, оговоренные в ТЗ или контракте, достигнуты не в полном объеме, то это формально может рассматриваться как «срыв реализации проекта». В таких случаях заказчик может сделать следующее: отказаться принимать работу и потребовать вернуть перечисленные средства (плюс, возможно, неустойку - если она оговорена в контракте); принять работу вместе с «гарантийным письмом» об обязательном устранении недочетов в оговоренные сроки; принять работу (проект) с частичным уменьшением оплаты и пр. В ряде случаев, например при создании ПС, качество реализации разработки (при соблюдении формальных требований к ней) может значительно влиять на ее «полезность» для заказчика. Поэтому заказчик обычно стремится по возможности отразить в ТЗ (или аналогичном документе) некоторые качественные и количественные характеристики разработки - с учетом располагаемых финансовых средств, ресурсов времени, доступности ресурсов, а также факторов рыночной конкуренции между разработчиками и пр. Сложность состоит в том, что если заказчик является «внешним» по отношению к организации (физическому лицу, осуществляющему УП), то последние часто заинтересованы лишь в формальном соблюдении требований, указанных в ТЗ, но не в «максимальной пользе» результатов работ для эксплуатантов выполненной разработки. Для объективности отметим, что и сам «заказчик проекта» не всегда полностью понимает состав необходимых требований к проекту - с учетом длительности его жизненного цикла и возможностей появления новых требований в процессе эксплуатации, роста угроз информационной безопасности и пр. Следовательно, его оценка «качества реализации проекта» может быть не только субъективной, но и нечеткой. Математические модели оптимизации подбора ресурсов Модель оптимизации выбора с позиций лица (или группы лиц), осуществляющего УП. Примем, что это лицо потенциально располагает набором «единиц» ресурсов, часть из которых являются взаимно заменяемыми с точки зрения возможностей выполнения отдельных видов работ. Для простоты можно считать, что единицы ресурсов распределены на G групп, в каждой из которых имеется единиц ресурсов, причем каждый из них может выполнять только единственный тип работ (на практике многие ресурсы - как трудовые, так и оборудования - часто могут выполнять различные виды работ). Таким образом, мы имеем набор групп ресурсов. За рассматриваемый период (период планирования проекта) ограничения на суммарные объемы использования для рассматриваемых «единиц» ресурсов описываются вектором . Будем считать, что количество проектов, которые потенциально могут быть приняты к реализации за рассматриваемый период планирования, равно Мmax. В общем случае в план реализации из-за ограничений по ресурсам и по другим причинам может быть включено и меньшее количество проектов, т. е. . Следовательно, в качестве альтернатив наборов проектов формально могут рассматриваться все проекты по отдельности плюс все попарные сочетания проектов плюс все сочетания проектов по три и т. д. - вплоть до сочетания всех Мmax проектов. Примем, что количество таких потенциально возможных сочетаний равно . Примем также, что для m-го проекта потенциально возможное количество вариантов планируемых «наборов ресурсов» (т. е. их сочетаний) составляет Im. При этом предполагается, что каждый из наборов ресурсов достаточен для выполнения m-го проекта в полном объеме и с соблюдением необходимых сроков. Понятно, что в сколько-нибудь сложных проектах величины могут быть весьма велики. Ожидаемое «качество» реализации m-го проекта, соответствующее i-му варианту планируемого набора ресурсов, оценим как . Соответственно, ожидаемые (оцениваемые) положительные эффекты Е, затраты Z и риски R для лица, осуществляющего УП, можно оценить в виде векторов , , , (1) где . Для простоты мы далее не будем учитывать необходимость дисконтирования затрат, доходов и величин рисков, связанных с инфляционными процессами, хотя для проектов, имеющих большую «временную протяженность», это и может быть целесообразным. С позиций лиц, осуществляющих УП, ограничения «сверху» для отдельных проектов по затратам и рискам будем считать определяемыми векторами , а уровням качества (ограничения «снизу») - вектором . Соответственно, для рассматриваемых наборов проектов (т. е. их совокупностей) ограничения по затратам и рискам составляют . Риски по проектам для лиц, осуществляющих УП, могут включать в себя следующие компоненты, отличающиеся по времени: при планировании группы проектов; при их реализации; при сдаче работ заказчику; в пределах «гарантийных сроков» по проекту - если они предусмотрены контрактом. Общие затраты по набору ресурсов в варианте получаются суммированием произведений «стоимостей всех задействованных ресурсов» на «объемы их использования» в рамках варианта. Положительные эффекты и риски могут оцениваться, например, экспертно. Оптимизация выбора совокупности проектов и ресурсов для них (абсолютный критерий) состоит в получении , (2) где - индекс «сочетания вариантов реализации для проектов» в их наборе (для каждого проекта в очередное сочетание отбирается только один вариант его реализации). При этом, естественно, должны соблюдаться ограничения: по «доступности ресурсов», в т. ч. и тех, которые задействованы более чем в одном проекте; в отношении затрат (по отдельным проектам и их совокупности); в отношении рисков (также по отдельным проектам и их совокупности); в отношении качества отдельных проектов (если оно оценивается отдельно). Таким образом, оптимизация в принципе имеет два взаимосвязанных «направления»: (1) планирование отдельных проектов; (2) выбор совокупности проектов для реализации (для простоты вопросы последовательности реализации проектов мы не рассматриваем). Видно, что в такой постановке задача требует проверки на соблюдение «суммарных» ограничений по доступности ресурсов и оценок очень большого количества вариантов. Решение задачи оптимизации на основе указанной постановки в принципе возможно с использованием следующих технологий (подходов). (Т1) Полностью «ручное» планирование вариантов (в т. ч., возможно, с использованием стандартных ПС УП) и отбор из них наилучшего - по результатам сформированных планов. (Т2) Ручное планирование с автоматической индикацией по мере формирования плана (для лица, осуществляющего УП), показателей затрат и рисков, использования ресурсов - для отдельных проектов и их совокупностей. В существующих ПС УП просмотр (контроль) этих показателей требует специальных действий. (Т3) Полуавтоматическая генерация вариантов (частично ресурсы для работ задает лицо, осуществляющее УП, а частично - ПС) с индикацией показателей для отдельных вариантов. (Т4) Оптимизация с помощью ПС плана проекта (группы проектов), который создало лицо, осуществляющее УП, по некоторым заданным критериям. (Т5) Полностью автоматический (только работа ПС) подбор оптимального решения. Перед тем как рассмотреть возможные направления использования алгоритмических решений, перечислим «условия отбраковки» вариантов - эти условия будем считать «жесткими». Последовательность применения «условий отбраковки» в рамках выбора оптимальных планов (с позиций алгоритмической эффективности) требует отдельного обсуждения, выходящего за рамки статьи. (U1) По превышению сроков реализации отдельных проектов или их совокупностей. (U2) По превышению бюджетов отдельных проектов и их совокупности. (U3) По «превышению доступности» хотя бы по одному ресурсу для варианта набора ресурсов, планируемых для совокупности проектов (превышение доступности ресурса возможно как в пределах одного проекта, так и по их совокупности). (U4) По рискам - для отдельных проектов и их совокупности. (U5) По качеству - для отдельных проектов и, возможно, по средневзвешенному значению качества. В последнем случае необходимы «взвешивающие» коэффициенты - наиболее просто принять их обратно пропорциональными суммарным затратам по проектам. (U6) По уровню «полезности» для лица (лиц), осуществляющих УП (для исключения «маловыгодных» проектов, например с низкой рентабельностью). Для оценки абсолютной «полезности» (A) для планируемого i-го набора ресурсов в m-м проекте может быть использована формула (3) где E, Z, R, как и ранее, означают «положительные эффекты», затраты и риски для каждого из вариантов наборов ресурсов для m-го проекта (таким образом, абсолютная «полезность» будет измеряться в денежных единицах). Использование показателя относительной полезности (4) позволяет выделить малорентабельные (с учетом рисков) варианты. В принципе возможны и комбинации критериев типа (3) и (4), но это потребует нормирования (3) для получения безразмерных величин. Переходим к характеристике (анализу) возможных алгоритмических подходов при выборе оптимального набора проектов и распределения ресурсов между ними. При описании алгоритмов количество знаков «-» перед фразами показывает иерархический уровень (подчиненность операции). Такое описание алгоритмов более экономично по сравнению с блок-схемами или «псевдокодами», которые потребовали бы расшифровки всех обозначений. (v1) Набор проектов для реализации заранее не фиксирован, а оптимизация осуществляется по критерию вида «максимум суммы показателей» типа (3). v1-0. Примем, что для каждого из m проектов ( создано вручную, сгенерировано полуавтоматически или автоматически (см. выше) некоторое количество вариантов наборов ресурсов, относящихся к каждому из проектов; исключены варианты, не удовлетворяющие условиям U1…U6; сделаны оценки оставшихся вариантов по критерию типа (3). v1-1. Выполним ранжирование вариантов по степени убывания «полезности» в каждой из совокупностей вариантов, относящихся к одному проекту. v1-2. «Очистим» корзину с набором отобранных для реализации проектов. v1-3 Из всех оставшихся проектов, не включенных в набор, выберем проект, в котором есть вариант с максимальным значением показателя типа (3) - для определенности. v1-4 Проверим, что с учетом вновь отобранного варианта совокупность проектов в корзине удовлетворяет ограничениям U1…U6. Если удовлетворяет, то: - включаем проект (с соответствующим вариантом) в «корзину»; - помечаем все оставшиеся варианты для данного проекта как не подлежащие рассмотрению; - проверяем, что остались «еще не включенные в корзину» проекты (Если они есть, то переходим на v1-3. Если их нет, то «Конец алгоритма»). Если с учетом вновь добавленного варианта совокупность проектов в корзине не удовлетворила хотя бы одному ограничению из U1…U6, то: - вариант помечается как не подлежащий дальнейшему рассмотрению; - следует возврат на v1-3 (при этом последующая попытка отбора варианта может осуществляться уже из вариантов для другого проекта). Отметим, что такие «пометки» могут привести к тому, что для проекта не останется ни одного «непомеченного варианта». Этот алгоритм можно считать относящимся к классу «жадных», и он может давать не лучшие результаты - в том числе и потенциально снижать количество проектов, отобранных в «портфель для реализации». (v2) Это аналог алгоритма v1, но с предопределенной (заданной) последовательностью отбора проектов в порядке убывания их приоритетности. Шаги v2-0, v2-1 и v2-2 примем аналогичными v1-1 и v1-2. v2-3. Для очередного по приоритетности проекта проверяем, есть ли для него «непомеченные варианты». Если есть, то выберем вариант с максимальным значением показателя типа (3) и перейдем на v2-4. Если нет, то, следовательно, данный проект не может быть отобран. Увеличиваем счетчик (номер) проекта и переходим на v2-3. v2-4 Проверяем, удовлетворяет ли, с учетом вновь отобранного варианта, совокупность проектов в корзине ограничениям U1…U6. Если удовлетворяет, то: - включаем проект (с соответствующим вариантом) в «корзину»; - исключаем данный проект из попыток дальнейшего отбора; - проверяем, остались ли «еще не включенные в корзину» проекты (если они есть, то переходим на v2-3, если их нет, то «Конец алгоритма»). Если с учетом добавленного проекта их набор в корзине не удовлетворил хотя бы одному ограничению, то: - вариант помечается как не подлежащий дальнейшему рассмотрению; - следует возврат на v1-3 для выбора очередного варианта в текущем проекте. Для этого алгоритма задание «приоритетности» отбора проектов резко снижает количество сочетаний для перебора. (v3) Использование метода типа «ветвей и границ», в котором проект соответствует иерархическому уровню поиска (узел), а номер варианта сочетаний ресурсов в данном проекте - номеру ветви, исходящей из этого узла. Для этого алгоритма «критерий» типа «сумма значений по формулам типа (3) является предпочтительным по сравнению с использованием сумм по (4). С целью экономии места мы не будем описывать алгоритм детально (это достаточно громоздко), а остановимся лишь на наиболее существенных моментах. Спуск по «дереву» необходимо реализовывать из всех узлов, соответствующих последовательным номерам проектов, расположенных на первом иерархическом уровне. Попытка добавления ветвей (ведущих к нижележащим узлам, т. е. проектам) осуществляется последовательно - по схеме «сверху вниз». При этом из последнего по иерархии проекта также выходит несколько ветвей (соответствуют вариантам его реализации), которые уже не ведут к узлам. Отсечение очередной ветви, а также соответствующего ей нижележащего узла и всех исходящих из него ветвей осуществляется при нарушении условий U1…U6. Если при спуске по очередной ветви условия U1…U6 не нарушены, то оценивается значение «критерия», соответствующего «накопленной» совокупности проектов, т. е. включенных в корзину. Если этот критерий лучше ранее достигнутого, то значение текущего максимального «критерия» переопределяется, а совокупность проектов и вариантов их реализации запоминается как «оптимум». При этом «оптимум» может достигаться не только при включении в корзину последнего по порядку следования проекта, но и на более высоком иерархическом уровне (в том числе с отсечением всех исходящих из него ветвей). Недостаток алгоритма: поскольку набор проектов с их вариантами реализации (наборами ресурсов) инвариантен по отношению к порядку следования проектов в наборе (корзине), то «оптимумы» могут встречаться неоднократно. Модификация алгоритма для исключения таких ситуаций возможна, но представляется вычислительно неэффективной, т. к. надо будет хранить и проверять достаточно много ранее просчитанных вариантов. (v4) Применение «агентных технологий» для «захвата» необходимых ресурсов по проектам [8, 13], при этом процесс захвата может быть «рандомизирован». Тогда для каждого полученного очередного набора «проекты - варианты их реализации» осуществляется проверка «критерия» (см. выше). Так же, как и в v3, если этот критерий лучше ранее достигнутого, то значение текущего максимального «критерия» переопределяется, а совокупность проектов и вариантов их реализации запоминается как «оптимум». При достаточно большом количестве «генераций наборов» может быть получено оптимальное или близкое к нему решение. (v5) Использование алгоритмов типа генетических [8, 14], которые позволяют получить достаточно хорошее решение при разумных затратах вычислительных усилий. При этом для получения «начального состояния» может быть применен набор «проекты - варианты их реализации», подготовленный вручную, по варианту «v4», и т. д. (v6) В ряде случаев задача выбора «состав проектов - наборы вариантов их реализации» может также решаться как задача «линейного программирования», в которой используется абсолютный «критерий» оптимизации, аналогичный применяемому в v3, и ограничения типа U1…U6. При этом в качестве оптимизируемых «параметров» будут выступать сочетания «номер проекта - номер варианта реализации - номер единицы ресурса», а в качестве оптимизированных значений этих параметров - объемы использования «единиц» ресурсов. Такая оптимизация в принципе может быть выполнена не только с использованием соответствующей программы, но и на основе средства «Поиск решения», которое есть в большинстве ПС типа «электронных таблиц». Отметим также, что по крайней мере в Microsoft Excel «поиск решения» допускает и нелинейные постановки задач. Представляется, что с помощью рабочих листов электронных таблиц так можно оптимизировать лишь распределение ресурсов между проектами, но не между отдельными работами. Причина - роль параметров будут играть сочетания «номер проекта - номер варианта реализации - номер работы - номер единицы ресурса», и таких сочетаний будет очень много. С использованием программных средств такие алгоритмы реализовать можно, тем более что по методам «линейного программирования» существуют апробированные библиотеки прикладных программ. Подчеркнем, что для описанных подходов типа (v6) задачи распределения работ в проектах по времени уже считаются решенными, осуществляется только оптимизация назначения ресурсов для этих работ. Вычислительная эффективность [15] рассмотренных алгоритмов связана со следующими показателями: «размер задачи», зависящий от количества проектов в ней, объемов работ в проектах, количества «единиц» ресурсов; требований к тому, насколько качественно будет осуществлена оптимизация по «критерию»; допустимые объемы вычислительных и иных затрат при выборе оптимального варианта. Априорно оценить, какой из подходов окажется наиболее эффективным, сложно, т. к. построить какую-либо аналитическую формулу для оценки эффективности затруднительно. Модель оптимизации выбора с позиций заказчиков. По умолчанию будем предполагать, что у каждого проекта - свой заказчик и они действуют независимо друг от друга. Аналогично тому, что принималось ранее, будем считать: для заказчика положительные эффекты Е, затраты Z и риски R оценены в виде векторов , , где . Для заказчика m-го проекта оптимальным по абсолютному критерию является выбор , (5) а по относительному - . (6) Поскольку для (5) и (6) речь идет о единственном проекте, то задача существенно проще, чем для выбора «группы проектов» с позиций лиц, осуществляющих УП. Однако она усложняется, если заказчикам нужно согласовывать свой выбор в условиях ограничений на ресурсы «общего доступа». При этом в качестве весовых коэффициентов «силы влияния» заказчиков на принимаемые решения можно взять величины, обратно пропорциональные максимальным значениям P для заказчиков по (5). Модель оптимизации выбора «набор проектов - варианты их реализации». Реализуется с учетом интересов как лиц, осуществляющих УП, так и заказчиков проектов. В простейшем случае можно пытаться максимизировать сумму «пользы» лица (лиц), осуществляющих УП, и совокупности заказчиков. Тогда вместо формулы (2) будем иметь формулу , (7) где - общее количество сочетаний «набор проекта - номер варианта их реализации», а определяется по Отметим, что если в «набор проектов для реализации» какие-то проекты для планируемого периода включены не будут, то у их заказчиков могут возникать потери, которые также может быть необходимым добавить в формулу (7). Еще один вариант модификации (7) связан с учетом различных «сил влияния» заказчиков и лица, осуществляющего УП, - с помощью весовых коэффициентов. Заключение Итак, сделаем выводы. 1. Целесообразно расширение номенклатуры видов ресурсов, которые должны учитываться при планировании проектов. 2. При оптимизации планирования реализации совокупности проектов может быть целесообразно учитывать интересы не только управляющих проектами, но и «заказчиков». 3. Практическая реализация предложенных моделей выбора требует оптимизации «вычислительных подходов», что обычно не может быть сделано априорно. На практике такой выбор осуществляется на основе опыта лиц УП, их представлений о важности проектов и их рисках. 4. Предложенные модели выбора оптимальных решений могут быть обобщены на случай нечеткого (в том числе и интервального) оценивания положительных эффектов, затрат, рисков и вероятного качества реализации проектов.

1. Айдаров Ю. Р. Управление качеством IT-проектов / Ю. Р. Айдаров // Менеджмент сегодня. 2008. № 5. С. 298-303.

2. Борисов С. А. Особенности управления проектами в области информационных систем / С. А. Борисов, А. Ф. Плеханова // Фундаментальные исследования. 2014. № 9 (ч. 3). С. 625-629.

3. Песоцкая Е. Ю. Управление рисками при внедрении ИТ-проектов / Е. Ю. Песоцкая // Успехи современного естествознания. 2008. № 1. С. 34-35.

4. Аньшин В. М. Управление портфелем проектов: сравнительный анализ подходов и рекомендации по их применению / В. М. Аньшин, В. Д. Бархатов //Управление проектами и программами. 2012. № 1. С. 20-40.

5. Суетин С. Н. Управление портфелем проектов: стратегический уровень проектного управления / С. Н. Суетин, С. А. Титов // Экономика и предпринимательство. 2014. № 5 (ч. 2). С. 509-515.

6. Ходоровский М. Я. Управление рисками портфеля проектов / М. Я. Ходоровский, В. О. Никонов // Вестн. Урал. федер. ун-та. Сер.: Экономика и управление. 2006. № 7. С. 116-122.

7. Смаржевский И. А. Особенности управления «внешним» и «внутренним» по отношению к исполняющей организации проектом / И. А. Смаржевский // Национальные интересы: приоритеты и безопасность. 2012. № 7. С. 23-32.

8. Будыльский А. В. Составление расписания проекта в условиях ограниченных времени и стоимости / А. В. Будыльский, И. Ю. Квятковская // Вестн. компьютерных и информационных технологий. 2014. № 10 (124). С. 16-22.

9. Попова О. В. Управление качеством проекта: роль человеческого ресурса / О. В. Попова // Вестн. Сибир. гос. автомоб.-дорож. акад. 2014. № 3 (37). С. 111-115.

10. Брумштейн Ю. М. Анализ моделей и методов выбора оптимальных совокупностей решений для задач планирования в условиях ресурсных ограничений и рисков / Ю. М. Брумштейн, Д. А. Тарков, И. А. Дюдиков // Прикаспийский журнал: управление и высокие технологии. 2013. № 3. С. 169-179.

11. Ноздрина Л. В. Управление рисками E-Learning проектов / Л. В. Ноздрина // Образовательные технологии и общество. 2012. Т. 15, № 1. С. 395-413.

12. Savin I. I. Methods and tools of information personalization in project and process management systems / I. I. Savin // Innovative Information Technologies: Materials of the International scientific-рractical conference. Part 3. Prague-2014, April 21-25. M.: HSE, 2014. P. 417-419.

13. Будыльский А. В. Управление проектами разработки программного обеспечения с использованием агентных технологий / А. В. Будыльский, И. Ю. Квятковская // Прикаспийский журнал: управление и высокие технологии. 2013. № 3. С. 169-179.

14. Бабаев И. А. Управление проектами и программами: генетический подход / И. А. Бабаев // Управление проектами и программами. 2008. № 3 (15). С. 176-189.

15. Krasavina A. K. Computational complexity of the task assignment in project management system / A. K. Krasavina // Innovative Information Technologies: Materials of the International scientific-рractical conference. Part 3. Prague-2014, April 21-25. M.: HSE, 2014. P. 392-393.