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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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