Сейчас составляю план на первую итерацию нового проекта. Аналитика проведена, описание содержания проекта готово и согласовано с заказчиком (у нас это называется Спецификацией). Составили на днях высокоуровневый WBS и провели предварительную оценку трудозатрат.
Сейчас я составляю высокоуровневый календарный план (вернее его заготовку), который потом будет уточняться и согласовываться со всей командой. После оценки трудозатрат на первую итерацию я заложил 10% на риски и 10% на управленческий резерв. При защите плана проекта перед спонсором необходимо обосновать каждый пункт плана, т.к. заказчики деньги считают. Для обоснования времени, выделенного на риски данной фазы я взял 5 основных рисков программных проектов, описанных в книге Тома ДеМарко и Тимоти Листера “Вальсируя с медведями: управление рисками в проектах по разработке программного обеспечения” и проанализировал их с точки зрения вероятности возникновения и возможного урона при наступлении события риска. Вот список этих рисков с моими комментариями в скобках:
Очень рекомендую всем, кто ещё не занимается управлением рисков в своих проектах, оценивать хотя бы эти пять основных рисков. Это очень освежает =)
Про остальные десятки рисков, которые уже вошли в реестр рисков этого проекта я писать не буду, т.к. они достаточно специфичны. Но если у кого-то возникнут проблемы с придумкой рисков для своего программного проекта – обращайтесь, генерю риски по цене один доллар за штуку =)))
Сейчас я составляю высокоуровневый календарный план (вернее его заготовку), который потом будет уточняться и согласовываться со всей командой. После оценки трудозатрат на первую итерацию я заложил 10% на риски и 10% на управленческий резерв. При защите плана проекта перед спонсором необходимо обосновать каждый пункт плана, т.к. заказчики деньги считают. Для обоснования времени, выделенного на риски данной фазы я взял 5 основных рисков программных проектов, описанных в книге Тома ДеМарко и Тимоти Листера “Вальсируя с медведями: управление рисками в проектах по разработке программного обеспечения” и проанализировал их с точки зрения вероятности возникновения и возможного урона при наступлении события риска. Вот список этих рисков с моими комментариями в скобках:
- Внутренние изъяны календарного планирования (подразумевается, что нет идеальных планов и в любом случае, что-то пойдёт не так, этот риск является одним из основных).
- Изменение требований (заказчик захотел “зелёный бант” и что бы “оно пело и плясало” в середине проекта).
- Текучесть кадров (можно его назвать ещё просто – Кадры и в качестве подпунктов включить Текучесть кадров и всякого рода Отпуски, неожиданные отгулы, болезни и т.д. – так я и сделал).
- Нарушение спецификаций (имеется ввиду двусмысленное их понимание. Т.е. есть описанная в спецификации функциональность, которая утверждена заказчиком. Заказчик думает, что под этой функциональностью подразумевается одно, а команда проекта подразумевает другое. И обе стороны могут даже не догадываться о различиях в понимании… пока не наступит фаза приёмки =)
- Низкая производительность команды (Программисты, тестировщики, аналитики, менеджеры или кто-то ещё пинают балду и не работают с предполагаемой производительностью. Или предполагаемая производительность была завышена при оценках – такое тоже часто бывает).
Очень рекомендую всем, кто ещё не занимается управлением рисков в своих проектах, оценивать хотя бы эти пять основных рисков. Это очень освежает =)
Про остальные десятки рисков, которые уже вошли в реестр рисков этого проекта я писать не буду, т.к. они достаточно специфичны. Но если у кого-то возникнут проблемы с придумкой рисков для своего программного проекта – обращайтесь, генерю риски по цене один доллар за штуку =)))
Комментариев нет:
Отправить комментарий