1. Риски проекта
Наталья Желнова
Жизнь до и после

2. Риски в проекте, цель которого:
разработка нового программного
продукта или системы «с нуля»
• Как их идентифицировать
• Как их количественно измерять

3. Зачем знать о рисках?
• Вовремя узнавать о проблемах и искать
пути их устранения
• Принимать управленческие решения
• Учиться на ошибках (в т.ч. чужих, а не
только своих)

4. Основные проблемы идентификации
рисков
• Источники информации о рисках не
определены, не полны или не дают полезных
сведений
• Формальный подход к идентификации рисков
(делаем «для галочки»)
• Управленческий хаос в планировании и
отчетности

5. Как идентифицировать риски?
• Формальный и неформальный диалог с командой
• Экспертные оценки
• Контрольные списки
• SWOT-анализ
• Метод аналогии
• ...
• Регулярные данные об измеряемых
показателях проекта

6. Метрики. Зачем они нужны?
• Индикаторы событий рисков
• Возможность управлять ожиданиями
• Индикаторы для управления качеством
• Возможность учиться на ошибках

7. Метрики. Мифы о них
• Метрики – это рычаг для управления (на самом
деле – инструмент анализа ситуации)
• Собранные данные предназначены только для
руководства
• Чем больше метрик, тем яснее картина
• Цифры никогда не врут!
• Инструменты – это главное в процессе сбора
и анализа метрик

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

9. Основные типы метрик
• Показатель текучести кадров
• Показатель утилизации ресурсов (людских,
материальных)
• Показатели, позволяющие оценить риски,
связанные со сроками, бюджетом проекта
• Показатели, позволяющие оценить качество
продукта
• Интегральные показатели прогресса проекта

10. Анализ состояния проекта
• Упреждающий анализ
• Диагностические метрики
• Ретроспективные метрики

11. Упреждающий анализ
• Запланированный объем работ, бюджет, ресурсный
план
• Сравнение с другими проектами
• Фактор сложности проекта
• Суммарный риск, связанный с расписанием
• Общий риск, связанный с бюджетом
• Сложность плана проекта
• Плотность проекта
• Независимость проекта

12. Диагностические метрики
Соотношение запланированных и фактических
показателей:
• Скорость разработки
• Изменчивость требований
• Числом реализованных требований в сравнении с общим
числом требований в проекте
• Показатели качества:
– плотность дефектов по фазам
– метрики, связанные с реализацией нефункциональных требований

13. Диагностические метрики
Соотношение запланированных и фактических
показателей:
• Дисперсия издержек (разность между запланированным
бюджетом работ и бюджетом выполненных работ)
• Дисперсия календарного плана (разность между
запланированным объемом работ и объемом фактически
выполненных работ)
• Объем непредвиденных расходов и незапланированных работ
по проекту

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

15. Ретроспективные метрики
• Число изменений в требованиях в масштабах проекта
• Отношение объема работ в тестировании к общему
объему работ
• Сравнение производительности в завершенном проекте с
другими аналогичными характеристиками в проектах
• Суммарная стоимость устранения дефектов

16. Метрики качества поддержки
продукта
• Среднее время отклика на сообщение о дефекте
• Среднее время исправления дефекта
• Процент неисправленных дефектов, входящих в
обязательства, принятые на себя разработчиком

17. Примеры из жизни: Motorola
• Подход Goal/Question/Metric
• Примеры метрик

18. Goal/Question/Metric
• Метод, предложенный Базилем и Вейссом (Basili and
Weiss) в 1984г.: идентификация целей, формулирование
вопросов и определение измеряемых критериев,
постановка метрик.
• Цели и области измерений формулируются в документе
Политика качества в разработке ПО

19. Определение целей
1: Улучшить планирование проектов (снизить риски, связанные с
планированием)
2: Ограничить распространение дефектов (снизить риски, связанные с
качеством, и риски расписания)
3: Повысить надежность системы (снизить риски, связанные с
отказами системы)
4: Понизить плотность дефектов (снизить риски качества продукта)
5: Улучшить качество пользовательской поддержки (снизить риски
недовольства пользователей)
6: Снизить риск несоответствия продукта заявленным
характеристикам
7: Повысить производительность труда в проекте (снизить риски
расписания)

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

21. Метрики
• Цель 1: Улучшить планирование проекта
• Вопрос 1.1: Какова была точность календарного
планирования проекта?
• Метрика 1.1 : Точность оценки в календарном планировании
(SEA)
SEA = Продолжительность проекта(факт)/Планируемая
продолжительность проекта
• Вопрос 1.2: Какова была точность планирования
трудозатрат?
• Метрика 1.2 : Точность планирования трудозатрат (EEA)
EEA = Трудозатраты (факт)/планируемые трудозатраты

22. Метрики
• Цель 2: Ограничить распространение дефектов
• Вопрос 2.1: Какова текущая эффективность обнаружения
дефектов до выпуска очередной версии?
• Метрика 2.1: Общий коэффициент ограничения
распространения дефектов (TDCE)
TDCE = число дефектов, обнаруженных до выпуска
очередной версии/(число дефектов, обнаруженных до
выпуска очередной версии + число дефектов, обнаруженных
после выпуска очередной версии)

23. Метрики
• Цель 3: Повысить надежность программы
• Вопрос 3.1: Какова частота отказов, как она изменяется со
временем?
• Метрика 3.1: Коэффициент отказов (FR)
FR = число отказов/время исполнения

24. Метрики
• Цель 4: Понизить плотность дефектов
• Вопрос 4.1: Каково нормализованное число отказов в
процессе, как оно соотносится с числом дефектов в
итерации?
• Метрика 4.1a: число отказов в итерации (IPF)
• IPF = Число отказов в данной итерации/Общий объем кода
(приведенный к эквиваленту на Assembler)
• Метрика 4.1b: число дефектов в итерации (IPD)
IPD= Число дефектов в данной итерации / Общий объем кода
(приведенный к эквиваленту на Assembler)

25. Метрики
• Вопрос 4.2: Каково нормализованное число ошибок в
продукте, доставленном клиенту, в отношении к общему
объему продукта, приведенному к эквиваленту на Assembler?
• Метрика 4.2a: Общее число дефектов в выпущенной версии
(TRD) total
TRD = Число дефектов в поставленной версии / Общий
объем кода (приведенный к эквиваленту на Assembler)
• Метрика 4.2b: Общее число дефектов (TRD) delta
TRD = Число дефектов в поставленной версии, для итерации
/ Общий объем кода (приведенный к эквиваленту на
Assembler)

26. Метрики
• Вопрос 4.3: Каково число дефектов, обнаруженное
пользователями в поставляемых материалах, отнесенное к
объему кода продукта?
• Метрика 4.3a: Число обнаруженных пользователями
дефектов (CFD) total
CFD = Число обнаруженных пользователями дефектов /
Общий объем кода (приведенный к эквиваленту Assembler)
• Метрика 4.3b: Число обнаруженных пользователями
дефектов (CFD) delta
CFD = Число обнаруженных пользователями дефектов, для
итерации / Общий объем кода (приведенный к эквиваленту
Assembler)

27. Метрики
• Цель 5: Улучшить обслуживание пользователей
• Вопрос 5.1 Каково число новых проблем, открытых за месяц?
• Метрика 5.1: Число новых проблем (NOP)
NOP = Число новых проблем
• Вопрос 5.2 Каково общее число открытых проблем на конец
месяца?
• Метрика 5.2: Общее число открытых проблем (TOP)
TOP = Общее число проблем, открытых на конец месяца

28. Метрики
• Вопрос 5.3: Каков средний возраст проблем, оставшихся
открытыми на конец месяца?
• Метрика 5.3: Средний возраст открытых проблем (AOP)
AOP = Общее время проблем после выхода версии,
оставшихся открытыми на конец месяца, в котором они
были открыты / Число проблем, оставшихся открытыми на
конец месяца

29. Метрики
• Вопрос 5.4: Каков средний возраст проблем, закрытых в
течение месяца?
• Метрика 5.4: Средний возраст закрытых проблем (ACP)
ACP = Общее время проблем после выхода версии, закрытых
на конец месяца, в котором они были открыты / Число
проблем, закрытых в течение месяца

30. Метрики
• Цель 6: Снизить стоимость несоответствия продукта
заявленным характеристикам
• Вопрос 6.1: Какова была стоимость устранения проблем
после входа версии?
• Метрика 6.1: Стоимость устранения проблем (CFP)
CFP = Стоимость устранения вех проблем в течение месяца
(в долларовом эквиваленте)

31. Метрики
• Цель 7: Повысить производительность труда
• Вопрос 7.1: Какова была производительность в проектах по
разработке ПО (исходя из объема кода)?
• Метрика 7.1a: Общая производительность при разработке (SP
total)
SP = Объем кода (приведенный к эквиваленту Assembler) /
Трудозатраты по разработке ПО
• Метрика 7.1b: Прирост производительности (SP delta)
SP = Прирост объема кода (приведенный к эквиваленту
Assembler) / Трудозатраты по разработке ПО

32. Метрики собраны. Что
дальше?
• Управленческие решения
• Кризис управления
• Две стороны силы

33. «Любимые игры» менеджеров
• Игнорирование рисков и проблем
• «Преступное бездействие» в критические моменты
• Перенос ответственности
• «Yes»-менеджмент
• Наказание невиновных и награждение непричастных
• Давление на команду («мативация»)
• «Ретуширование» действительности, боязнь ошибок,
приукрашивание результатов
• «Позитивный» подход: не говорим и не думаем о плохом
• Манипуляции с людьми и цифрами

34. К чему это приводит?
• Недовольство команды
• Отсутствие инициативы
• Цинизм и равнодушие
• Снижение производительности
• «Итальянская забастовка»
• Нелояльность персонала
• «Бунт на корабле»

35. Что делать?
• Думать
• Искать причины проблем, а не пытаться устранить
симптомы
• Не ограничиваться решениями, дающими эффект в
краткосрочной перспективе
• Устранять причины проблем, а не «разбираться» с
исполнителями
• Всегда помнить, что:
– Включение мозга – очень энергозатратный процесс
– Мысль не включается по команде «подъем»

36. Case study: «провал проекта на ровном
месте»

37. Где, когда и как это было?
• 1999 год
• Россия
• Команда, насчитывающая менее 100 человек
• Разработка корпоративного портала для внешнего
заказчика
– 1-й проект: успешно завершен
– 2-й проект: провал проекта
• Fixed time, fixed budget

38. Какие риски рассматривались?
• Риск ухода человека из команды
– Средняя зарплата по рынку (по областям компетенции)
– Среднее время работы сотрудника на аналогичной
должности
• Риски расписания
– Среднее число дней нетрудоспособности в году (на
человека) в данной команде
• Ограничения по срокам, бюджету, времени
• Ограничения, налагаемые требованиями к качеству
– Метрики качества кода
– Метрики качества продукта

39. Что происходило?
• Трудность «входа» новичка в команду
– 30% вновь принятых на работу не проходили испытательный
срок
• Незапланированные работы
– Серьезные рабочие перегрузки
• Незаменимые люди в команде
– Перегруженность незаменимых людей
– Внезапный уход незаменимых людей
• Ухудшение качества кода
• Устойчивый рост числа ошибок

40. Что делали?
• «Гасили пожары»
• Устраивали авралы
• Перегружали людей, бравших на себя высокую
степень ответственности
• Не пытались провести более детальный анализ
причин, почему это происходит

41. Спасибо
Наталья Желнова
(nzhelnova@teamcit.ru)