Читайте также статьи и материалы о технологиях Rational и Microsoft в блоге Новичкова Александра и Шамрая Александра

Оценка состояния проекта: часть первая

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

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

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

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

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

Измерения и цели

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

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

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

Вариативность и цели

«Предсказывать очень трудно, особенно будущее.» — Нильс Бор

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

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

Рисунок 1: Нормальная функция плотности вероятности, отображающая, что фактические результаты наблюдения могут отклоняться от ожидаемого (или среднего) значения

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

Измерение и итеративная разработка

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

Рисунок 2: Итеративный подход к разработке, снижающий вариативность на протяжении всего проекта

Линия, отмеченная «x», представляет собой ожидаемое значение предварительных расчетов, а пунктирные линии над ней и под ней отражают ожидаемое отклонение от этих предварительных расчетов. На протяжении всего проекта вариативность снижается по мере уменьшения рисков, как показано на рисунке 3.

Рисунок 3: Риск, который в значительной степени способствует вариативности и непредсказуемости, со временем снижается в итеративном проекте

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

Когда измерение происходит неправильно

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

• Проект запускается, и руководитель проекта первым делом создает план проекта. На основе неполных данных о том, какие проблемы должны быть решены и какие расплывчатые цели должны быть достигнуты, руководитель проекта делает все от него зависящее, чтобы «догадаться», какими будут затраты и график работ.
• Не смотря на все предостережения о том, что план является очень условным, он воплощается в жизнь без изменений. Вышестоящие руководители теряют из виду тот факт, что заблаговременные планы в действительности являются лишь размышлениями, не более достоверными, чем предположения, на которых они основаны. И этот план становится чем-то вроде прогноза об успешности проекта, и оплошность управляющего персонала заключается в том, что они концентрируют все свое внимание на измерении отклонений от плана, вместо того, чтобы направить проект в правильном направлении, которое приведёт к успеху. И план становится своего рода ярмом на шее руководителя проекта. ¹
• Члены команды, работающей над проектом, лишены права действовать вне рамок плана, даже если всем понятно, что план является полной выдумкой, оторванной от реальности самого проекта. Хотя в теории план мог быть и достоверным, но в реальности всегда присутствует большая степень вероятности, что он на самом деле не будет таковым. Если такой план не в состоянии точно спрогнозировать будущее, те руководители, которые слепо ему следуют, часто приводят свои команды и проекты к провалу.
  
  Если план не соответствует реальности, то единственным логичным решением будет отклониться от плана. Но если система управления наказывает за отклонения от плана, то это часто ставит команду в безвыходную ситуацию, и ей приходится создавать иллюзию того, что она следуют плану, даже если это не так. Такое поведение не приводит ни к чему хорошему.

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

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

Что не так в детальной двусторонней проработке проекта?

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

• Нереально ожидать от руководителя проекта понимания всех технических подробностей, необходимых для определения проектных операций и временных затрат на техническую работу над проектом. Могут быть определены этапы и цели, но реальная работа, необходимая для достижения этих целей, находится вне технической компетенции руководителя проекта. Техническая экспертиза, необходимая для планирования на любом из значимых уровней точности, требует гораздо большего участия команды разработчиков, а любое «планирование», осуществляемое руководителем проекта, скорее всего, будет в лучшем случае умозрительным.
• Неопределенность конкретных направлений деятельности на ранних стадиях проекта достаточно высока, так что даже подробные планы, созданные командой разработчиков, весьма приблизительны. Первые дни и недели проекта характеризуются нехваткой надежной информации о том, какие именно проблемы необходимо решить и какие цели должны быть достигнуты. Детальное планирование при отсутствии такой информации — это просто пустая трата времени.
• Если детальное планирование является напрасной тратой времени, то оценка в соответствии с детальным планом, созданным на ранних этапах проекта, опасна и зачастую обрекает проект на провал. Ответственность людей за ошибочные планы препятствует осуществлению правильных действий при появлении необходимой информации, и даже может заставить выполнять неверные действия, потому что так указано в плане, или, что встречается еще чаще, заставляет их создавать «два комплекта документов»: один для «реальной» проектной работы и один, более близкий к изначальному, но ошибочному плану, так как по нему их оценивают. В любом случае, подробный план, созданный на ранних этапах проекта, поощряет неправильное поведении.

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

Решаем, что именно оценивать — от стадии к стадии

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

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

Рисунок 4: Цели и задачи, связанные с каждой из четырех стадий жизненного цикла

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

Что измерять на начальной стадии?

Перед начальной стадией ставятся следующие цели:

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

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

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

На данной стадии все оценки нацелены на получение ответов на следующие вопросы:

• В чем заключается коммерческая выгода проекта?
• Каковы ожидаемые затраты на получение коммерческой выгоды?
• Стоит ли реализовывать проект до конца?

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

Оценка экономической целесообразности

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

Коммерческая выгода обычно выражается в терминах чистой приведенной стоимости (NPV), которая учитывает как стоимость полученных денег с учётом будущего дохода, так и риски. Математически это выглядит так:

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

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

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

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

Оценка технической надежности и расчет общей стоимости проекта

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

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

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

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

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

Определение жизнеспособности проекта

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

Есть тенденция, что разложение риска на цели субъективно и наилучший результат получается от увеличения вариативности расчетов — по сути, расширения «границ ошибок». Большинство расчетов на данной стадии в действительности является чрезвычайно субъективным, что может быть исправлено с помощью широкого диапазона ошибок. Наиболее важный вопрос о расчетах заключается не в том, «насколько они точны», а в том, «насколько широк возможный диапазон значений» В качестве альтернативы, вариативность в расчетах может быть компенсирована увеличением коэффициента окупаемости капиталовложений в проект в расчетах NPV. Обычно для определения значений NPV для предполагаемого и самого неблагоприятного случаев проводят анализ нескольких сценариев. Зачастую решение о продолжении проекта основывается на том, находится ли NPV самого неблагоприятного случая в приемлемых пределах.

Как только решение развернуто, рассчитанная NPV становиться значимым в качестве показателя, с которым сравниваются все реальные результаты.

Другие показатели

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

• Субъективные показатели, например:
  Удовлетворение запросов потребителей. Удовлетворена ли финансирующая организация достигнутым результатом?
  Моральный дух. Удовлетворена ли команда проекта достигнутым результатом? Уверены ли они (хотя бы с осторожностью) в его успешности?
• Объективные показатели, например:
  Абсолютный успех. Оценивается на основе того, была ли завершена стадия в ожидаемые временные сроки.
  Стабильность требований. Рассчитывается на основе того, насколько изменились цели проекта на данной его стадии. Большое количество изменений означает, что цели проекта до сих пор могут быть расплывчатыми. Из этого следует, что расчеты NPV могут быть частично или полностью сомнительными.
  Стабильность рисков. Рассчитывается на основе ещё обнаруживаемых рисков проекта. Сложно знать то, чего вы не знаете. Таким образом, это тоже в некоторой степени субъективный показатель. Хотя если новые крупные риски все еще обнаруживаются довольно часто, это свидетельствует о том, что у вас недостаточно ясное представление о решении или деловых потребностях.

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

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

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

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

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

Заключение

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

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

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

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

Дополнительная литература

Данная статья основана на материале, изначально представленном в книге Управление проектами итеративной разработки ПО, написанной Куртом Биттнером и Иеном Спенсом и опубликованной в 2006 году издательством Addison-Wesley.

Сноски

¹ Если вас смущает ссылка, я предлагаю прочесть «Поэму о старом моряке», написанную Самуэлом Тейлором Кольриджем (Samuel Taylor Coleridge).

² Например, модели CoCoMo II, крупномодульный широкополосный Delphi (то есть оценки на основе согласованности) и балльная функциональная оценка (в том числе «баллы use-case»).

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

25.02.2008

Комментарии

• rONtfavUCiPAsZU
  Автор: lrCHOz vkmgybjplupp  ·  25.09.2011 21:13:41
  lrCHOz vkmgybjplupp
• TkawXjzQWJUyXk
  Автор: FWzlSw , [url=http://mwlxnybucqrd.com/]mwlxnybucqrd[/url], [link=http://mwejzqblrdfw.com/]mwejzqblrdfw[/link], http://qlcbmofhodbo.com/  ·  23.09.2011 17:30:05
  FWzlSw , [url=http://mwlxnybucqrd.com/]mwlxnybucqrd[/url], [link=http://mwejzqblrdfw.com/]mwejzqblrdfw[/link], http://qlcbmofhodbo.com/
• OEHXvVJCrsHp
  Автор: j9suM5 svwrlucqmqvj  ·  22.09.2011 20:49:50
  j9suM5 svwrlucqmqvj
• SiQXgEOrewHeKFNSrG
  Автор: I really neeedd to find this info, thank God!  ·  21.09.2011 13:21:21
  I really neeedd to find this info, thank God!
• TsJvOcPtLsrl
  Автор: OzrQkY , [url=http://etzsmexynicj.com/]etzsmexynicj[/url], [link=http://weeoebiaowkm.com/]weeoebiaowkm[/link], http://tvxesiszwmbn.com/  ·  11.07.2011 19:08:31
  OzrQkY , [url=http://etzsmexynicj.com/]etzsmexynicj[/url], [link=http://weeoebiaowkm.com/]weeoebiaowkm[/link], http://tvxesiszwmbn.com/
• LoIZjBNIPFZz
  Автор: HkDSq1 mfcxcwnzletw  ·  11.07.2011 14:46:41
  HkDSq1 mfcxcwnzletw
• rwmjMTWZXJ
  Автор: RbZphv , [url=http://quvosupmzbga.com/]quvosupmzbga[/url], [link=http://rcsmtlwqzvov.com/]rcsmtlwqzvov[/link], http://ibfvdqcwmfuj.com/  ·  10.07.2011 15:14:04
  RbZphv , [url=http://quvosupmzbga.com/]quvosupmzbga[/url], [link=http://rcsmtlwqzvov.com/]rcsmtlwqzvov[/link], http://ibfvdqcwmfuj.com/
• pQSCgWgLOGnIfiL
  Автор: PRpAk2 scsgmbxgewfg  ·  09.07.2011 18:27:52
  PRpAk2 scsgmbxgewfg
• QzGhIGbzQDLDCWtLp
  Автор: A mliloin thanks for posting this information.  ·  09.07.2011 18:27:52
  A mliloin thanks for posting this information.
• UZnVMTthJsImHWuvs
  Автор: These pieces rlaely set a standard in the industry.  ·  09.07.2011 05:12:49
  These pieces rlaely set a standard in the industry.

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО:
E-mail:
Тема:
Комментарий:
Оценка:
Код подтверждения:

Читайте также статьи и материалы о технологиях Rational и Microsoft в блоге Новичкова Александра и Шамрая Александра

Новости и пресс-релизы СМ-Консалт

Архив "Новости и пресс-релизы СМ-Консалт"