Автоматизация бизнес-процессов продажи билетов ООО "Зритель"

(t (Рn) -- длительность работы n) выполнить все планируемые работы невозможно. Это так называемый критический операционный маршрут, т.е. такой маршрут, суммарное время прохождения которого является предельным для выполнения всех работ графика.

Возможно, что длительность работ жестко не фиксируется, в частности, когда она рассматривается как функция от используемых ресурсов (к примеру, некоторая работа выполняется за время t1 силами k1 исполнителей, и за t2 при использовании k2 исполнителей). Тогда правомерно ставить задачу перераспределения ресурсов и построения критического операционного маршрута, оптимального с точки зрения того или иного критерия.

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

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

§ максимально возможная ресурсная потребность;

§ минимально необходимое время выполнения работы (при условии полной ее ресурсной обеспеченности).

Следующие характеристики каждой работы определяются после построения сетевого графика:

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

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

В ходе выполнения проекта определяются и указываются на графике:

§ время фактического начала работы;

§ время текущего планового завершения работы;

§ время фактического завершения работы.

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

§ текущая ресурсная обеспеченность (как доля максимально возможной потребности);

§ объем работы, выполненный и оставшийся к текущему моменту времени.

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

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

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

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

§ время возможного начала работы,

§ время допустимого конца работы,

§ время фактического начала работы,

§ время фактического конца работы,

§ текущий момент выполняемой в настоящее время работы.

2.1.3 Характеристика архитектуры разрабатываемого проекта

Архитектура разрабатываемого проекта содержит, прежде всего, ряд основных элементов и связей между ними (Рис. 2.5).

Рис. 2.5. Общая архитектура разрабатываемого проекта

Характеристика структурных единиц информации исходных сообщений, при такой архитектуре, приведена в табл. 2.2.

Таблица 2.2.

Характеристика структурных единиц информации исходных сообщений

2.1.4 Характеристика этапа внедрения разрабатываемого проекта

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

Зачем нужно тестировать промежуточные рабочие продукты? Ответ на этот вопрос заключается в двух положениях:

· во-первых, обнаружение ошибок как можно раньше позволяет избавиться от напрасной реализации неправильных решений, от использования неправильных (а потому переделываемых в дальнейшем) компонентов, от обременительных возвратов к уже пройденному;

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

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

· какие результаты тестируются, каким методом и как определяется, что тестирование выполнено;

· как для деятельности данного вида определяется период тестирования -- время, отводимое для тестирования в плане итерации;

· какие кадровые и технические ресурсы требуются для каждого из периодов тестирования;

· какие инструменты используются при тестировании данного вида деятельности.

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

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

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

· тесты для проверки функциональности;

· тесты для проверки корректности преобразований данных;

· интерфейсные тесты;

· специфичные для данного проекта (итерации) тесты.

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

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

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

· высокий -- требует выделения для тестирования времени 95% и более из суммарного времени, отведенного для работ данной итерации;

· средний -- для тестирования требуется от 20% до 50% из суммарного времени работ данной итерации;

· низкий -- для тестирования отводится порядка 5% суммарного времени работ данной итерации.

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

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

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

указать причину ошибки;

определить, что надо исправить и оценить ресурсы, которые необходимо выделить на исправление;

установить когда исправление будет сделано.

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

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

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

2.1.5 Характеристика этапа эксплуатации разрабатываемого проекта и возможных работ

Основной характеристикой этапа эксплуатации проекта является выпуск релизов по анализу этапа.

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1.6 Ожидаемые риски на этапах жизненного цикла и их описание

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

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

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

Преодоление рисков может осуществляться на нескольких уровнях:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· задержка начала проекта никогда не компенсируется;

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

· если пользовательский интерфейс не является интуитивно понятным и превышает уровень компетенции потребителя изделия, продукт будет плохо распространяться;

· упущенные возможности требуют дополнительных усилий при их более поздней реализации и увеличивают затраты;

· не протестированный продукт снижает репутацию разработчиков;

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

2.1.7 Оценка стоимостных параметров проекта автоматизации

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

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

· по минимальной границе цен,

· по максимальной границе цен,

· по средней величине между максимальной и минимальной ценой или

· по средневзвешенной величине.

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

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

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

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

Приведение поздних затрат к ценам начального периода развития проекта осуществляется путем введения поправочного коэффициента дисконтирования:

Дt = (1 + б) t,

гдеб--дисконт (число из интервала 0…1),

t--время платежа, указываемое от начала проекта.

Этот коэффициент показывает, что сегодняшняя покупка билета за p единиц эквивалентна покупке его за (1 + б) t * p через t лет при условии сохранения сегодняшних денег в банке с банковским процентом б в течение t лет. Примерно в таком соотношении и происходят инфляционные процессы. Величина коэффициента дисконтирования зависит от экономической ситуации, а не условий заключения контракта. В частности, по этой причине невозможно точно сказать, какие сроки проекта характеризуют его как длительный.

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

Страницы: 1, 2, 3, 4, 5