Риски проекта:жизнь до и послеНаталья Желнова
Об авторе доклада• Наталья Желнова:– С 1997 года занимается сбором,систематизацией и управлением требованиямив проектах по...
Риски в проекте, цель которого:разработка нового программного продуктаили системы «с нуля»• Как их идентифицировать• Как и...
Зачем знать о рисках?• Вовремя узнавать о проблемах и искатьпути их устранения• Принимать управленческие решения• Учиться ...
Основные проблемы идентификациирисков• Источники информации о рисках неопределены, не полны или не дают полезныхсведений• ...
Как идентифицировать риски?• Формальный и неформальный диалог с командой• Экспертные оценки• Контрольные списки• SWOT-анал...
Метрики. Зачем они нужны?• Индикаторы событий рисков• Возможность управлять ожиданиями• Индикаторы для управления качество...
Метрики. Мифы о них• Метрики – это рычаг для управления (на самомделе – инструмент анализа ситуации)• Собранные данные пре...
Первостепенные факторы риска• Текучесть кадров• Ограничения по срокам, бюджету, времени• Ограничения, налагаемые требовани...
Основные типы метрик• Показатель текучести кадров• Показатель утилизации ресурсов (людских,материальных)• Показатели, позв...
Анализ состояния проекта• Упреждающий анализ• Диагностические метрики• Ретроспективные метрики
Упреждающий анализ• Запланированный объем работ, бюджет, ресурсныйплан• Сравнение с другими проектами• Фактор сложности пр...
Диагностические метрикиСоотношение запланированных и фактическихпоказателей:• Скорость разработки• Изменчивость требований...
Диагностические метрикиСоотношение запланированных и фактическихпоказателей:• Дисперсия издержек (разность между запланиро...
Ретроспективные метрики• Отношение фактической производительности кзапланированной• Процент трудозатрат, приходящихся на ф...
Ретроспективные метрики• Число изменений в требованиях в масштабах проекта• Отношение объема работ в тестировании к общему...
Метрики качества поддержки продукта• Среднее время отклика на сообщение о дефекте• Среднее время исправления дефекта• Проц...
Примеры из жизни: Motorola• Подход Goal/Question/Metric• Примеры метрик
Goal/Question/Metric• Метод, предложенный Базилем и Вейссом (Basili andWeiss) в 1984г.: идентификация целей, формулировани...
Определение целей1: Улучшить планирование проектов (снизить риски, связанные спланированием)2: Ограничить распространение ...
Параметры оценок• Дефекты в поставленном продукте и дефекты впоставленном продукте, соотнесенные с масштабомпродукта• Обща...
Метрики• Цель 1: Улучшить планирование проекта• Вопрос 1.1: Какова была точность календарногопланирования проекта?• Метрик...
Метрики• Цель 2: Ограничить распространение дефектов• Вопрос 2.1: Какова текущая эффективность обнаружениядефектов до выпу...
Метрики• Цель 3: Повысить надежность программы• Вопрос 3.1: Какова частота отказов, как она изменяется современем?• Метрик...
Метрики• Цель 4: Понизить плотность дефектов• Вопрос 4.1: Каково нормализованное число отказов впроцессе, как оно соотноси...
Метрики• Вопрос 4.2: Каково нормализованное число ошибок впродукте, доставленном клиенту, в отношении к общемуобъему проду...
Метрики• Вопрос 4.3: Каково число дефектов, обнаруженноепользователями в поставляемых материалах, отнесенное кобъему кода ...
Метрики• Цель 5: Улучшить обслуживание пользователей• Вопрос 5.1 Каково число новых проблем, открытых за месяц?• Метрика 5...
Метрики• Вопрос 5.3: Каков средний возраст проблем, оставшихсяоткрытыми на конец месяца?• Метрика 5.3: Средний возраст отк...
Метрики• Вопрос 5.4: Каков средний возраст проблем, закрытых втечение месяца?• Метрика 5.4: Средний возраст закрытых пробл...
Метрики• Цель 6: Снизить стоимость несоответствия продуктазаявленным характеристикам• Вопрос 6.1: Какова была стоимость ус...
Метрики• Цель 7: Повысить производительность труда• Вопрос 7.1: Какова была производительность в проектах поразработке ПО ...
Метрики собраны. Чтодальше?• Управленческие решения• Кризис управления• Две стороны силы
«Любимые игры» менеджеров• Игнорирование рисков и проблем• «Преступное бездействие» в критические моменты• Перенос ответст...
К чему это приводит?• Недовольство команды• Отсутствие инициативы• Цинизм и равнодушие• Снижение производительности• «Итал...
Что делать?• Думать• Искать причины проблем, а не пытаться устранитьсимптомы• Не ограничиваться решениями, дающими эффект ...
Case study: «провал проекта наровном месте»
Где, когда и как это было?• 1999 год• Россия• Команда, насчитывающая менее 100 человек• Разработка корпоративного портала ...
Какие риски рассматривались?• Риск ухода человека из команды– Средняя зарплата по рынку (по областям компетенции)– Среднее...
Что происходило?• Трудность «входа» новичка в команду– 30% вновь принятых на работу не проходили испытательныйсрок• Незапл...
Что делали?• «Гасили пожары»• Устраивали авралы• Перегружали людей, бравших на себя высокуюстепень ответственности• Не пыт...
СпасибоНаталья Желноваnzhelnova@teamcit.ruhttp://www.linkedin.com/in/nzhelnova
Upcoming SlideShare
Loading in …5
×

DUMP-2013 Управление разработкой - Метрики в проектах по разработке нового программного продукта - Желнова Наталья

1,413 views

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,413
On SlideShare
0
From Embeds
0
Number of Embeds
451
Actions
Shares
0
Downloads
27
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Сравнение с другими проектами: ожидаемое общее количество человеко-часов в сравнении с другими, уже завершенными проектами (сильные вариации должны указывают на проблемы).Фактор сложности проекта: величина, характеризующая общий объем всех внешних артефактов проекта, умноженная на коэффициент сложности.Суммарный риск, связанный с расписанием: суммарная величина, отражающая изменения в проекте, основанная на вероятности возникновения непредвиденных ситуаций, помноженной на среднее ожидаемое число таких ситуаций. Включает Суммарный запас времени: общий запас (резерв) времени для всех запланированных работ.Сложность плана проекта: коэффициент связей между различными работами.Плотность проекта: отношение суммарной продолжительности всех работ при их последовательном выполнении к сумме ее же и общего запаса (резерва) времени для всех запланированных работ.
  • DUMP-2013 Управление разработкой - Метрики в проектах по разработке нового программного продукта - Желнова Наталья

    1. 1. Риски проекта:жизнь до и послеНаталья Желнова
    2. 2. Об авторе доклада• Наталья Желнова:– С 1997 года занимается сбором,систематизацией и управлением требованиямив проектах по разработке ПО.– 6 лет участия в консалтинговых проектах(постановка процессов разработки ПО).– Автор нескольких курсов по управлениютребованиями, управлению рисками впроектах по разработке ПО.– Редактор сайта Software People.
    3. 3. Риски в проекте, цель которого:разработка нового программного продуктаили системы «с нуля»• Как их идентифицировать• Как их количественно измерять
    4. 4. Зачем знать о рисках?• Вовремя узнавать о проблемах и искатьпути их устранения• Принимать управленческие решения• Учиться на ошибках (в т.ч. чужих, а нетолько своих)
    5. 5. Основные проблемы идентификациирисков• Источники информации о рисках неопределены, не полны или не дают полезныхсведений• Формальный подход к идентификации рисков(делаем «для галочки»)• Управленческий хаос в планировании иотчетности
    6. 6. Как идентифицировать риски?• Формальный и неформальный диалог с командой• Экспертные оценки• Контрольные списки• SWOT-анализ• Метод аналогии• ...• Регулярные данные об измеряемыхпоказателях проекта
    7. 7. Метрики. Зачем они нужны?• Индикаторы событий рисков• Возможность управлять ожиданиями• Индикаторы для управления качеством• Возможность учиться на ошибках
    8. 8. Метрики. Мифы о них• Метрики – это рычаг для управления (на самомделе – инструмент анализа ситуации)• Собранные данные предназначены только дляруководства• Чем больше метрик, тем яснее картина• Цифры никогда не врут!• Инструменты – это главное в процессе сбораи анализа метрик
    9. 9. Первостепенные факторы риска• Текучесть кадров• Ограничения по срокам, бюджету, времени• Ограничения, налагаемые требованиями к качеству• Политические факторы• Недостаточный уровень технологической экспертизыв команде• Люди, избегающие ответственности• Низкий уровень организационной зрелости вкомпании• Ухудшение отношений с заказчиком
    10. 10. Основные типы метрик• Показатель текучести кадров• Показатель утилизации ресурсов (людских,материальных)• Показатели, позволяющие оценить риски,связанные со сроками, бюджетом проекта• Показатели, позволяющие оценить качествопродукта• Интегральные показатели прогресса проекта
    11. 11. Анализ состояния проекта• Упреждающий анализ• Диагностические метрики• Ретроспективные метрики
    12. 12. Упреждающий анализ• Запланированный объем работ, бюджет, ресурсныйплан• Сравнение с другими проектами• Фактор сложности проекта• Суммарный риск, связанный с расписанием• Общий риск, связанный с бюджетом• Сложность плана проекта• Плотность проекта• Независимость проекта
    13. 13. Диагностические метрикиСоотношение запланированных и фактическихпоказателей:• Скорость разработки• Изменчивость требований• Числом реализованных требований в сравнении с общимчислом требований в проекте• Показатели качества:– плотность дефектов по фазам– метрики, связанные с реализацией нефункциональных требований
    14. 14. Диагностические метрикиСоотношение запланированных и фактическихпоказателей:• Дисперсия издержек (разность между запланированнымбюджетом работ и бюджетом выполненных работ)• Дисперсия календарного плана (разность междузапланированным объемом работ и объемом фактическивыполненных работ)• Объем непредвиденных расходов и незапланированных работпо проекту
    15. 15. Ретроспективные метрики• Отношение фактической производительности кзапланированной• Процент трудозатрат, приходящихся на фазу проекта,итерацию• Показатели качества– метрики, связанные с реализацией нефункциональных требований– плотность дефектов– проблемы клиента, связанные с эксплуатацией поставленногопродукта– степень удовлетворенности заказчика
    16. 16. Ретроспективные метрики• Число изменений в требованиях в масштабах проекта• Отношение объема работ в тестировании к общемуобъему работ• Сравнение производительности в завершенном проекте сдругими аналогичными характеристиками в проектах• Суммарная стоимость устранения дефектов
    17. 17. Метрики качества поддержки продукта• Среднее время отклика на сообщение о дефекте• Среднее время исправления дефекта• Процент неисправленных дефектов, входящих вобязательства, принятые на себя разработчиком
    18. 18. Примеры из жизни: Motorola• Подход Goal/Question/Metric• Примеры метрик
    19. 19. Goal/Question/Metric• Метод, предложенный Базилем и Вейссом (Basili andWeiss) в 1984г.: идентификация целей, формулированиевопросов и определение измеряемых критериев,постановка метрик.• Цели и области измерений формулируются в документеПолитика качества в разработке ПО
    20. 20. Определение целей1: Улучшить планирование проектов (снизить риски, связанные спланированием)2: Ограничить распространение дефектов (снизить риски, связанные скачеством, и риски расписания)3: Повысить надежность системы (снизить риски, связанные сотказами системы)4: Понизить плотность дефектов (снизить риски качества продукта)5: Улучшить качество пользовательской поддержки (снизить рискинедовольства пользователей)6: Снизить риск несоответствия продукта заявленнымхарактеристикам7: Повысить производительность труда в проекте (снизить рискирасписания)
    21. 21. Параметры оценок• Дефекты в поставленном продукте и дефекты впоставленном продукте, соотнесенные с масштабомпродукта• Общая эффективность процесса• Соблюдение графика• Точность оценок• Число открытых проблем, инициированных жалобамиклиентов• Время, в течение которого проблема оставалась нерешенной• Стоимость несоответствия продукта заявленнымхарактеристикам• Надежность ПО
    22. 22. Метрики• Цель 1: Улучшить планирование проекта• Вопрос 1.1: Какова была точность календарногопланирования проекта?• Метрика 1.1 : Точность оценки в календарном планировании(SEA)SEA = Продолжительность проекта(факт)/Планируемаяпродолжительность проекта• Вопрос 1.2: Какова была точность планированиятрудозатрат?• Метрика 1.2 : Точность планирования трудозатрат (EEA)EEA = Трудозатраты (факт)/планируемые трудозатраты
    23. 23. Метрики• Цель 2: Ограничить распространение дефектов• Вопрос 2.1: Какова текущая эффективность обнаружениядефектов до выпуска очередной версии?• Метрика 2.1: Общий коэффициент ограниченияраспространения дефектов (TDCE)TDCE = число дефектов, обнаруженных до выпускаочередной версии/(число дефектов, обнаруженных довыпуска очередной версии + число дефектов, обнаруженныхпосле выпуска очередной версии)
    24. 24. Метрики• Цель 3: Повысить надежность программы• Вопрос 3.1: Какова частота отказов, как она изменяется современем?• Метрика 3.1: Коэффициент отказов (FR)FR = число отказов/время исполнения
    25. 25. Метрики• Цель 4: Понизить плотность дефектов• Вопрос 4.1: Каково нормализованное число отказов впроцессе, как оно соотносится с числом дефектов витерации?• Метрика 4.1a: число отказов в итерации (IPF)• IPF = Число отказов в данной итерации/Общий объем кода(приведенный к эквиваленту на Assembler)• Метрика 4.1b: число дефектов в итерации (IPD)IPD= Число дефектов в данной итерации / Общий объем кода(приведенный к эквиваленту на Assembler)
    26. 26. Метрики• Вопрос 4.2: Каково нормализованное число ошибок впродукте, доставленном клиенту, в отношении к общемуобъему продукта, приведенному к эквиваленту на Assembler?• Метрика 4.2a: Общее число дефектов в выпущенной версии(TRD) totalTRD = Число дефектов в поставленной версии / Общийобъем кода (приведенный к эквиваленту на Assembler)• Метрика 4.2b: Общее число дефектов (TRD) deltaTRD = Число дефектов в поставленной версии, для итерации/ Общий объем кода (приведенный к эквиваленту наAssembler)
    27. 27. Метрики• Вопрос 4.3: Каково число дефектов, обнаруженноепользователями в поставляемых материалах, отнесенное кобъему кода продукта?• Метрика 4.3a: Число обнаруженных пользователямидефектов (CFD) totalCFD = Число обнаруженных пользователями дефектов /Общий объем кода (приведенный к эквиваленту Assembler)• Метрика 4.3b: Число обнаруженных пользователямидефектов (CFD) deltaCFD = Число обнаруженных пользователями дефектов, дляитерации / Общий объем кода (приведенный к эквивалентуAssembler)
    28. 28. Метрики• Цель 5: Улучшить обслуживание пользователей• Вопрос 5.1 Каково число новых проблем, открытых за месяц?• Метрика 5.1: Число новых проблем (NOP)NOP = Число новых проблем• Вопрос 5.2 Каково общее число открытых проблем на конецмесяца?• Метрика 5.2: Общее число открытых проблем (TOP)TOP = Общее число проблем, открытых на конец месяца
    29. 29. Метрики• Вопрос 5.3: Каков средний возраст проблем, оставшихсяоткрытыми на конец месяца?• Метрика 5.3: Средний возраст открытых проблем (AOP)AOP = Общее время проблем после выхода версии,оставшихся открытыми на конец месяца, в котором онибыли открыты / Число проблем, оставшихся открытыми наконец месяца
    30. 30. Метрики• Вопрос 5.4: Каков средний возраст проблем, закрытых втечение месяца?• Метрика 5.4: Средний возраст закрытых проблем (ACP)ACP = Общее время проблем после выхода версии, закрытыхна конец месяца, в котором они были открыты / Числопроблем, закрытых в течение месяца
    31. 31. Метрики• Цель 6: Снизить стоимость несоответствия продуктазаявленным характеристикам• Вопрос 6.1: Какова была стоимость устранения проблемпосле входа версии?• Метрика 6.1: Стоимость устранения проблем (CFP)CFP = Стоимость устранения вех проблем в течение месяца(в долларовом эквиваленте)
    32. 32. Метрики• Цель 7: Повысить производительность труда• Вопрос 7.1: Какова была производительность в проектах поразработке ПО (исходя из объема кода)?• Метрика 7.1a: Общая производительность при разработке (SPtotal)SP = Объем кода (приведенный к эквиваленту Assembler) /Трудозатраты по разработке ПО• Метрика 7.1b: Прирост производительности (SP delta)SP = Прирост объема кода (приведенный к эквивалентуAssembler) / Трудозатраты по разработке ПО
    33. 33. Метрики собраны. Чтодальше?• Управленческие решения• Кризис управления• Две стороны силы
    34. 34. «Любимые игры» менеджеров• Игнорирование рисков и проблем• «Преступное бездействие» в критические моменты• Перенос ответственности• «Yes»-менеджмент• Наказание невиновных и награждение непричастных• Давление на команду («мативация»)• «Ретуширование» действительности, боязнь ошибок,приукрашивание результатов• «Позитивный» подход: не говорим и не думаем о плохом• Манипуляции с людьми и цифрами
    35. 35. К чему это приводит?• Недовольство команды• Отсутствие инициативы• Цинизм и равнодушие• Снижение производительности• «Итальянская забастовка»• Нелояльность персонала• «Бунт на корабле»
    36. 36. Что делать?• Думать• Искать причины проблем, а не пытаться устранитьсимптомы• Не ограничиваться решениями, дающими эффект вкраткосрочной перспективе• Устранять причины проблем, а не «разбираться» сисполнителями• Всегда помнить, что:– Включение мозга – очень энергозатратный процесс– Мысль не включается по команде «подъем»
    37. 37. Case study: «провал проекта наровном месте»
    38. 38. Где, когда и как это было?• 1999 год• Россия• Команда, насчитывающая менее 100 человек• Разработка корпоративного портала для внешнегозаказчика– 1-й проект: успешно завершен– 2-й проект: провал проекта• Fixed time, fixed budget
    39. 39. Какие риски рассматривались?• Риск ухода человека из команды– Средняя зарплата по рынку (по областям компетенции)– Среднее время работы сотрудника на аналогичнойдолжности• Риски расписания– Среднее число дней нетрудоспособности в году (начеловека) в данной команде• Ограничения по срокам, бюджету, времени• Ограничения, налагаемые требованиями к качеству– Метрики качества кода– Метрики качества продукта
    40. 40. Что происходило?• Трудность «входа» новичка в команду– 30% вновь принятых на работу не проходили испытательныйсрок• Незапланированные работы– Серьезные рабочие перегрузки• Незаменимые люди в команде– Перегруженность незаменимых людей– Внезапный уход незаменимых людей• Ухудшение качества кода• Устойчивый рост числа ошибок
    41. 41. Что делали?• «Гасили пожары»• Устраивали авралы• Перегружали людей, бравших на себя высокуюстепень ответственности• Не пытались провести более детальный анализпричин, почему это происходит
    42. 42. СпасибоНаталья Желноваnzhelnova@teamcit.ruhttp://www.linkedin.com/in/nzhelnova

    ×