MyPlainText

Анализ и расстановка приоритетов рисков - это следующие после "Определения" этапы в цикле управления рисками . Сам анализ предполагает 2 этапа: Определение вероятности свершения каждого риска. Можно использовать набор величин: 10%, 25%, 50%, 75%, 90%. Вполне естественны затруднения на этом этапе даже при выборе из пяти дискретных значений. Для достижения объективной оценки вероятности свершения можно использовать такой прием: проводить оценку вероятности свершения рисков всей командой или частью команды. Сначала проводить оценку рисков индивидуально и анонимно. После чего обсуждать результаты, приходя к общему мнению.        2. Оценка воздействия на проект в случае свершения риска.В простейшем случае предлагается оценка от 1 до 5, где 1 - незначительное 2 - малозначительное 3 - среднезначительное 4 - значительное 5 - сильнозначительное. В более сложных вариациях возможны варианты оценки воздействия риска на проект по следу...

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

Предыстория С началом работы над крупным проектом в нашей небольшой команде встал вопрос о том, чтобы планировать итерации разработки, выбирать задачи и оценивать их объёмы. Кроме бэк-энд разработчика, пришедшего вместе со мной, никто такого опыта не имел: ни дизайнер, ни верстальщик, ни фронт-энд разработчик - отсюда и результат: 1-ая итерация клиентской разработки затянулась на 2 недели, относительно оценки. А 2 недели эти сложились очень быстро: - Сперва дизайнер что-то не учел на пару-тройку дней - Эти же пара дней сказались на работе верстальщика с дополнительным коэффициентом, ввиду того, что сверстать более трудоёмко - Ну и в завершение - Front-end разработчику приходилось ждать вёрстку  Чтобы оценить: 2 недели задержки при, скажем, 1000 руб/час это 80 000 руб. /*1000 руб/час взял условно*/ После таких  грустных расчетов я вспомнил о суперсиле риск-менеджмента! Очевидно, что стоило изначально учесть неопытность членов команды в та...