Создание и апробация новых процессов
Принцип поэтапности призывает не делать "революций" в совершенствовании процессов. Любая новация, описание которой найдено в литературе, заимствована из опыта коллег или разработана лично вами, должна пройти испытание на вашей команде и ваших проектах. Известный неполиткорректный принцип "что русскому хорошо - то немцу смерть" на языке современного менеджмента IT-проектов звучит, как "учет системы ценностей, принятых в команде разработчиков" [14.5].
Апробация на реальных задачах - единственный гарантированный способ проверить - годится ли тот или иной инструмент для вашей команды. Чтобы не вовлекать в масштабные эксперименты значительные ресурсы существует способ пилотных (пробных) проектов.
К.Вигерс предлагает следующие методические приемы при апробации новых процессов:
· выбирайте для участия в пробных проектах людей, которые будут относиться к новым приемам беспристрастно и смогут дать им оценку. Это могут быть как сторонники, так и скептики, но они не должны быть ярыми противниками предлагаемых приемов;
· чтобы результаты было легко истолковать, определите количество критериев, по которым команда будет оценивать пробный проект;
· определите заинтересованных лиц, которых следует проинформировать о том, что представляет собой пробный проект и почему он выполняется;
· подумайте о возможности испытания новых процессов по частям в разных пробных проектах. Так вам удастся вовлечь в испытание больше людей, что увеличивает осведомленность, количество откликов и сторонников;
|
|
|
· для более полной оценки поинтересуйтесь у участников пилотных проектов, что бы они почувствовали, если бы им пришлось вернуться к существующим приемам работы.
Оценка результатов и принятие решений
Оценка результатов апробации новых процессов должна показать - достигнуты ли поставленные цели, стоит ли осуществлять широкомасштабное внедрение новаций, апробированных на пилотном проекте, либо "овчинка выделки не стоит".
Среди ключевых вопросов в области оценки результатов можно выделить следующие [14.3].
· Насколько гладко прошли пробные проекты и как эффективно они разрешили неопределенности в отношении новых процессов?
· Собираетесь ли вы менять что-либо в следующих пилотных проектах?
· Как прошло общее внедрение новых технологических процессов?
· Удалось ли вам довести до сведения каждого информацию о пользе новых процессов или шаблонов?
· Смогли ли участники понять и эффективно применить новые процессы?
· Собираетесь ли вы менять что-либо при проведении следующего внедрения?
При оценивании результативности достижения поставленных целей следует различать мероприятия, польза от которых проявляется сразу и те, выгода от которых проявится через значительное время. Необходимо учитывать эффект "кривой обучения" (learning curve) [14.3]: производительность падает, пока люди приспосабливаются к новым способам работы. Кратковременное падение производительности, иногда называемое "лощиной отчаяния" - в - это часть необходимого вклада, который ваша организация вносит в совершенствование процессов.
|
|
|
Невзирая на все возможные трудности, мероприятия по улучшению качества при внимательном к ним отношении неизбежно приведут к повышению эффективности работы команды.
Требования в управлении проектом
Чтобы определить сметную стоимость и продолжительность работ по проекту автоматизации без грубых ошибок, необходимо выявить и проанализировать требования, а также сформировать архитектурную основу, крайне желательно создать прототипы. И это - как минимум. Иными словами, для того, чтобы создать АИС, сначала нужно проанализировать возможность создания.
Такая постановка вопроса вполне логична и обоснована, это подтвердит любой Разработчик. Однако, она вызывает много вопросов, например:
|
|
|
· Где найти Заказчика, который согласится ждать 2-3 месяца, пока Разработчик составит для него коммерческое предложение?
· Кто оплатит работы по анализу требований? (очевидно, Заказчик)
· Как быть, если цена вопроса окажется непомерной и от проекта придется отказаться - кто возместит Заказчику убытки на проведение исследований?
Разумный Заказчик сможет найти выход из этого непростого положения, например:
· подыскав Разработчика, обладающего богатым опытом выполнения подобных проектов, который сможет дать требуемую оценку значительно быстрее (но риск ошибки при этом остается);
· взяв на себя риски возможного прекращения проекта на ранних стадиях, в случае, если выявится его несоответствие бюджетным ограничениям (в сложных рискованных проектах лучше потерять 5% или 10% от закладываемого бюджета, чем все 100%, как это было в "каскадных" схемах разработки) - путь прогнозирующих методологий
· разделив с Разработчиком ответственность за конечный продукт, приготовившись день за днем работать с ним рука об руку вплоть до появления результата - путь гибких (Agile) методологий.
От рамок проекта к экспресс-планированию
Начальную, самую грубую оценку проекта можно сделать на основании документа "Видение". Так, шаблон Vision/Scope MSF содержит список ключевых характеристик/функций, критерии приемлемости и (что очень важно) перечень характеристик/функций, которые лежат "вне рамок" проекта. Параллельно с проработкой концепции, первая фаза MSF содержит работы по анализу рисков: выявляются и оцениваются главные риски проекта.
|
|
|
Чтобы сделать первое приближение плана и сметы проекта на ранних этапах анализа, в [15.1] предлагается следующий подход:
· Выделить 25 - 99 функций, характеризующих систему (совместно, Заказчик и Разработчик);
· Установить приоритеты для каждой из функций (Заказчик);
· Оценить трудозатраты (Разработчик);
· Оценить риски (Разработчик, возможно привлечение Заказчика);
Все оценки делаются по 3-балльной шкале (высокий, низкий, средний; критический, важный, полезный и т.п.) и сводятся в таблицу:
| № пп. | Функция | Приоритет | Трудоемкость | Риск |
Затем, в процессе консультаций Заказчика и Разработчика на основе полученной информации определяется набор функций, который войдет в базовую версию проекта.
Результаты планирования на концептуальном уровне, проделанные, например, на основе вышеуказанного шаблона, позволяют дать первую оценку размерам проекта. Такая оценка не отличается особой точностью, но при определенных условиях (опыт решения Разработчиком аналогичных задач; доверительные отношения между Заказчиком и Разработчиком) может служить отправной точкой для заключения контракта на всю систему.
Планирование проекта на основе требований, путь RUP
RUP поддерживает двухуровневую схему планирования работ над проектом, разделяя план проекта и план итерации. Исходя из базовой концепции планирования итерационных проектов, план проекта разбивается на фазы:
· Начало,
· Уточнение,
· Конструирование,
· Переход.
Исходя из рекомендаций методологии по декомпозиции работ проекта в зависимости от степени сложности проекта и квалификации команды, в каждой фазе выделяется одна или более итераций.
Назначаются даты главных вех (окончания фаз):
· целей жизненного цикла (конец фазы начала, рамки проекта и его бюджет);
· архитектуры жизненного цикла (конец фазы уточнения, законченная архитектура);
· начальной работоспособности (конец фазы конструирования, бета-версия продукта);
· выпуска изделия (конец фазы перехода и полного цикла разработки).
Назначаются даты малых вех, приуроченные к окончанию итераций и их главные цели. Основные цели итераций - выпуск релизов, демонстрируемых, либо передаваемых Заказчику, однако не всякая итерация приводит к выпуску релиза.
План проекта создается как можно раньше в начальной фазе и модифицируется по мере необходимости.
Что это означает на практике:
1. укрупненный план работ составляется "как можно раньше", например - через месяц после начала работ;
2. бюджет появляется лишь к окончанию первой фазы (а она, в зависимости от сложности проекта может длиться месяц, а может и полгода);
3. как план, так и бюджет проекта представляют собой лишь прогноз, который может корректироваться на протяжении работ над проектом;
4. на момент появления плана и бюджета должно появиться подробное описание лишь 20% ключевой функциональности системы и "широкое, но неглубокое" [15.2] описание 80% функциональности.
Таким образом, концепция укрупненного планирования в RUP, как типичном представителе класса прогнозирующих методологий, предполагает базировать отношения между Заказчиком и Разработчиком на прогнозах, степень достоверности которых зависит от таких факторов, как качество проработки требований, квалификация команды Разработчика, сложность и новизна проекта.
Более конкретная информация представлена в плане итерации. Основные его особенности:
1. План итерации базируется на функциональных требованиях. К моменту начала итерации совершенно точно известно, какие требования должны быть обработаны (детализированы, спроектированы, запрограммированы) в данной итерации.
План итерации составляется, исходя из сформулированных выше оценок требований - приоритетности, степени риска, трудоемкости.
2. План итерации имеет жесткие сроки. В случае проявления незапланированных рисков удовлетворительным вариантом является достижение договоренности о реализации требований данной итерации не в полном объеме, либо переносе требований в следующую итерацию; переносить сроки текущей итерации не рекомендуется;
3. Точный план составляется на одну, очередную итерацию. К моменту окончания текущей итерации должен быть сверстан план очередной итерации. Такой подход позволяет более гибко работать с рисками.
Таким образом, следует отметить, что требования являются решающим фактором в планировании итерационного проекта.
Дата добавления: 2021-03-18; просмотров: 91; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!