Posts tagged риски

Воздушная атака на неопределнность оценок

0

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

Вот что по этому поводу советует из своего опыта руководитель проектов Киевстар Евгений Петров:

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

Что сделали:
1) Разделили мигрируемые данные на 3 категории (простой, средний, сложный);
2) Провели пилот. Несколько специалистов проводили миграцию разной сложности контента, скажем по 2 единицы каждой сложности. Данные усреднили по исполнителям. Получились оценки длительности миграции каждого типа сложности контента. Например Простой 1 день, средний – 2, Сложный – 5 дней.
3) Умножив оценку на количество, получили общий объем трудозатрат
4) Назначаем ресурсы, получаем длительность
5) Закладываем резерв после оценки рисков:
- переменная загрузка специалистов
- больничные
- инструменты миграции могут сбоить
- и т.д.
6) Коммуницируем спонсору и заказчику риски, договариваемся, что будем делать в случае их наступления
7) Начинаем работать!”

Из своего опыта работы по аналогичному сценарий могу добавить что после пункта (2) был сделан вывод что мы можем рассмотреть варианты

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

Компоненты информационной среды управления проектами

0

Для более менее крупных проектов мы задумываемся о построении информационной системы для управления проектами. Прежде чем говорить – да у нас есть MS Project – и в северном варианте (Project Server) он будет очень классно покрывать все нужды – не спешите. Давайте рассмотрим основные компоненты такой среды и какие потенциальные компоненты могут подойти.

Коммуникации - сайт проекта, форум, рассылка, группы. Это может быть как сайт на SharePoint так и любая WiKi/Wordpress/LinkedIn группа. Для небольшого бизнеса вполне удобно создавать закрытые группы в социальных сетях и использовать их как готовые платформы для проектных коммуникаций.

Документы проекта – минимум файловый сервер. Лучше всего – сразу SharePoint или аналогичное средство с функционалом управления версиями. Если документы проекта будут готовиться исключить в веб форме – то вам также отлично подойдут Wiki системы. В них очень легко контролировать версии документов (но несколько сложнее научиться писать их с использованием внутренней разметки)

Записи проекта - это различные типы записей – структура работ, запросы на изменения, вопросы, дефекты, риски, требования, тесты, результаты выполнения тестов. Кроме фиксации самих записей важно чтобы работали хотя бы простые workflow по организации работы над записями – это даже крайне желательно. Для управления такого рода записями нужна система с удобным конструктором как новых записей так и процессов, удобными формами. SharePoint в базовой конфигурации для этого не очень хорошо подходит (но вполне терпимо для малых проектов). Хорошим кандидатом сюда – Microsoft Dynamics CRM  2010, SharePoint + Nintex + кастомные решения для организации документооборота. Также могут подойти ваши существующие ERP системы (в них легко создавать новые сущности и формы но менее просто решаются вопросы по автоматизации процессов)

Календарь проекта и Фактические данные – тут рулит Microsoft Project.

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

 

Набросок рисков прoекта

0

Нашел небольшой но на практике очень актуальный перечень рисков ИТ проекта.

  • Выбор неверной архитектуры
  • Устаревание технологических решений
  • Потеря ключевых разработчиков (других ролей в коллективе)
  • Некомпетентность сотрудников подрядчика
  • Сбой аппаратного обеспечения подрядчика
  • Нехватка трудовых ресурсов подрядчика
  • Неверная оценка сложности проекта
  • Слабый менеджмент проекта
  • Несоответствие продукта ожиданиям заказчика
  • Изменение масштаба проекта
  • Устаревание аппаратного обеспечения к моменту старта эксплуатации проекта
  • Отказ от поддержки технологий вендорами
  • Срыв сроков поставки вендором
  • Сбой аппаратного обеспечения вендора
  • Некомпетентность заказчика
  • Нежелание среднего и младшего звеньев заказчика сотрудничать
  • Неверный выбор фич заказчиком, неверная их приоретизация
  • Запоздалые пожелания заказчика
  • Недостаточность технической базы заказчика для эксплуатации проекта
  • Превышение заказчиком договоренного объёма работ
  • Консервативность любых звеньев заказчика при формулировании требований
  • Консервативность среднего и младшего звеньев заказчика при тестировании и внедрении
  • Гиперактивность заказчика при тестировании (обычно после пассивности во время ТЗ включается «а прикрыть задницу?»)
  • Вымогательство среднего и младшего звеньев заказчика
  • Неготовность заказчика к принятию продукта
  • Переезд заказчика
  • Изменение бизнес процессов или структуры заказчика после утверждения объёмов работ
  • Сложности коммуникации со смежными к заказчику контрагентами
  • Срыв сроков оплаты заказчиком
  • Приостановка финансирования проекта
  • Смена руководства заказчика

Взято из комментариев к статье http://habrahabr.ru/company/softline/blog/124213/

PS Считаю что нужно составить реестр рисков и актуализировать его.

Простая модель оценки рисков

0

Возьмем на вооружение самый простой метод оценки рисков:
* Вероятность – Высокая(3), Средняя(2), Низкая(1)
* Ущерб – Высокий(3), Средний(2), Низкий(1)

Перемножая вероятность на ущерб получаем оценку ри!ка от 1 до 9. Соответственно максимальный приоритет уделяем иисуса с оценкой 9 и 6.

Microsoft Solutions Framework Risk Management Discipline

0

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=721

Taxonomy-Based Risk Identification

0

Интересный SEI отчет по идентификации рисков:

This report describes a method for facilitating the systematic and repeatable identification of risks associated with the development of a software-dependent project. This method, derived from published literature and previous experience in developing software, was tested in active government-funded defense and civilian software development projects for both its usefulness and for improving the method itself. Results of the field tests encouraged the claim that the described method is useful, usable, and efficient. The report concludes with some macro-level lessons learned from the field tests and a brief overview of future work in establishing risk management on a firm footing in software development projects

Подробнее смотри тут

Go to Top