Embed Size (px)
Citation preview
Риски проекта:жизнь до и после
Наталья Желнова
Об авторе доклада
• Наталья Желнова:– С 1997 года занимается сбором,
систематизацией и управлением требованиями в проектах по разработке ПО.
– 6 лет участия в консалтинговых проектах (постановка процессов разработки ПО).
– Автор нескольких курсов по управлению требованиями, управлению рисками в проектах по разработке ПО.
– Редактор сайта Software People.
Риски в проекте, цель которого:разработка нового программного продукта или
системы «с нуля»
• Как их идентифицировать • Как их количественно измерять
Зачем знать о рисках?
• Вовремя узнавать о проблемах и искать пути их устранения
• Принимать управленческие решения
• Учиться на ошибках (в т.ч. чужих, а не только своих)
Основные проблемы идентификации рисков
• Источники информации о рисках не определены, не полны или не дают полезных сведений
• Формальный подход к идентификации рисков (делаем «для галочки»)
• Управленческий хаос в планировании и отчетности
Как идентифицировать риски?
• Формальный и неформальный диалог с командой
• Экспертные оценки• Контрольные списки• SWOT-анализ• Метод аналогии• ...
• Регулярные данные об измеряемых показателях проекта
Метрики. Зачем они нужны?
• Индикаторы событий рисков• Возможность управлять
ожиданиями• Индикаторы для управления
качеством• Возможность учиться на ошибках
Метрики. Мифы о них
• Метрики – это рычаг для управления (на самом деле – инструмент анализа ситуации)
• Собранные данные предназначены только для руководства
• Чем больше метрик, тем яснее картина• Цифры никогда не врут!• Инструменты – это главное в процессе
сбора и анализа метрик
Первостепенные факторы риска
• Текучесть кадров• Ограничения по срокам, бюджету, времени• Ограничения, налагаемые требованиями к
качеству• Политические факторы• Недостаточный уровень технологической
экспертизы в команде• Люди, избегающие ответственности• Низкий уровень организационной зрелости в
компании• Ухудшение отношений с заказчиком
Основные типы метрик
• Показатель текучести кадров• Показатель утилизации ресурсов
(людских, материальных)• Показатели, позволяющие оценить
риски, связанные со сроками, бюджетом проекта
• Показатели, позволяющие оценить качество продукта
• Интегральные показатели прогресса проекта
Анализ состояния проекта
• Упреждающий анализ• Диагностические метрики• Ретроспективные метрики
Упреждающий анализ
• Запланированный объем работ, бюджет, ресурсный план
• Сравнение с другими проектами• Фактор сложности проекта• Суммарный риск, связанный с расписанием• Общий риск, связанный с бюджетом• Сложность плана проекта• Плотность проекта• Независимость проекта
Диагностические метрики
Соотношение запланированных и фактических показателей:
• Скорость разработки• Изменчивость требований• Числом реализованных требований в сравнении с
общим числом требований в проекте• Показатели качества:
– плотность дефектов по фазам – метрики, связанные с реализацией нефункциональных
требований
Диагностические метрики
Соотношение запланированных и фактических показателей:
• Дисперсия издержек (разность между запланированным бюджетом работ и бюджетом выполненных работ)
• Дисперсия календарного плана (разность между запланированным объемом работ и объемом фактически выполненных работ)
• Объем непредвиденных расходов и незапланированных работ по проекту
Ретроспективные метрики
• Отношение фактической производительности к запланированной
• Процент трудозатрат, приходящихся на фазу проекта, итерацию
• Показатели качества– метрики, связанные с реализацией нефункциональных
требований– плотность дефектов– проблемы клиента, связанные с эксплуатацией
поставленного продукта– степень удовлетворенности заказчика
Ретроспективные метрики
• Число изменений в требованиях в масштабах проекта
• Отношение объема работ в тестировании к общему объему работ
• Сравнение производительности в завершенном проекте с другими аналогичными характеристиками в проектах
• Суммарная стоимость устранения дефектов
Метрики качества поддержки продукта
• Среднее время отклика на сообщение о дефекте• Среднее время исправления дефекта • Процент неисправленных дефектов, входящих в
обязательства, принятые на себя разработчиком
Примеры из жизни: Motorola
• Подход Goal/Question/Metric • Примеры метрик
Goal/Question/Metric
• Метод, предложенный Базилем и Вейссом (Basili and Weiss) в 1984г.: идентификация целей, формулирование вопросов и определение измеряемых критериев, постановка метрик.
• Цели и области измерений формулируются в документе Политика качества в разработке ПО
Определение целей
1: Улучшить планирование проектов (снизить риски, связанные с планированием)2: Ограничить распространение дефектов (снизить риски, связанные с качеством, и риски расписания)3: Повысить надежность системы (снизить риски, связанные с отказами системы)4: Понизить плотность дефектов (снизить риски качества продукта)5: Улучшить качество пользовательской поддержки (снизить риски недовольства пользователей)6: Снизить риск несоответствия продукта заявленным характеристикам7: Повысить производительность труда в проекте (снизить риски расписания)
Параметры оценок
• Дефекты в поставленном продукте и дефекты в поставленном продукте, соотнесенные с масштабом продукта
• Общая эффективность процесса• Соблюдение графика• Точность оценок• Число открытых проблем, инициированных жалобами
клиентов• Время, в течение которого проблема оставалась
нерешенной• Стоимость несоответствия продукта заявленным
характеристикам• Надежность ПО
Метрики
• Цель 1: Улучшить планирование проекта• Вопрос 1.1: Какова была точность календарного
планирования проекта?• Метрика 1.1 : Точность оценки в календарном
планировании (SEA)SEA = Продолжительность проекта(факт)/Планируемая продолжительность проекта
• Вопрос 1.2: Какова была точность планирования трудозатрат?
• Метрика 1.2 : Точность планирования трудозатрат (EEA) EEA = Трудозатраты (факт)/планируемые трудозатраты
Метрики
• Цель 2: Ограничить распространение дефектов• Вопрос 2.1: Какова текущая эффективность
обнаружения дефектов до выпуска очередной версии?
• Метрика 2.1: Общий коэффициент ограничения распространения дефектов (TDCE) TDCE = число дефектов, обнаруженных до выпуска очередной версии/(число дефектов, обнаруженных до выпуска очередной версии + число дефектов, обнаруженных после выпуска очередной версии)
Метрики
• Цель 3: Повысить надежность программы• Вопрос 3.1: Какова частота отказов, как она
изменяется со временем?• Метрика 3.1: Коэффициент отказов (FR)
FR = число отказов/время исполнения
Метрики
• Цель 4: Понизить плотность дефектов• Вопрос 4.1: Каково нормализованное число отказов в
процессе, как оно соотносится с числом дефектов в итерации?
• Метрика 4.1a: число отказов в итерации (IPF)• IPF = Число отказов в данной итерации/Общий объем
кода (приведенный к эквиваленту на Assembler)• Метрика 4.1b: число дефектов в итерации (IPD)
IPD= Число дефектов в данной итерации / Общий объем кода (приведенный к эквиваленту на Assembler)
Метрики
• Вопрос 4.2: Каково нормализованное число ошибок в продукте, доставленном клиенту, в отношении к общему объему продукта, приведенному к эквиваленту на Assembler?
• Метрика 4.2a: Общее число дефектов в выпущенной версии (TRD) totalTRD = Число дефектов в поставленной версии / Общий объем кода (приведенный к эквиваленту на Assembler)
• Метрика 4.2b: Общее число дефектов (TRD) deltaTRD = Число дефектов в поставленной версии, для итерации / Общий объем кода (приведенный к эквиваленту на Assembler)
Метрики
• Вопрос 4.3: Каково число дефектов, обнаруженное пользователями в поставляемых материалах, отнесенное к объему кода продукта?
• Метрика 4.3a: Число обнаруженных пользователями дефектов (CFD) totalCFD = Число обнаруженных пользователями дефектов / Общий объем кода (приведенный к эквиваленту Assembler)
• Метрика 4.3b: Число обнаруженных пользователями дефектов (CFD) deltaCFD = Число обнаруженных пользователями дефектов, для итерации / Общий объем кода (приведенный к эквиваленту Assembler)
Метрики
• Цель 5: Улучшить обслуживание пользователей• Вопрос 5.1 Каково число новых проблем, открытых за
месяц?• Метрика 5.1: Число новых проблем (NOP)
NOP = Число новых проблем• Вопрос 5.2 Каково общее число открытых проблем на
конец месяца?• Метрика 5.2: Общее число открытых проблем (TOP)
TOP = Общее число проблем, открытых на конец месяца
Метрики
• Вопрос 5.3: Каков средний возраст проблем, оставшихся открытыми на конец месяца?
• Метрика 5.3: Средний возраст открытых проблем (AOP) AOP = Общее время проблем после выхода версии, оставшихся открытыми на конец месяца, в котором они были открыты / Число проблем, оставшихся открытыми на конец месяца
Метрики
• Вопрос 5.4: Каков средний возраст проблем, закрытых в течение месяца?
• Метрика 5.4: Средний возраст закрытых проблем (ACP)ACP = Общее время проблем после выхода версии, закрытых на конец месяца, в котором они были открыты / Число проблем, закрытых в течение месяца
Метрики
• Цель 6: Снизить стоимость несоответствия продукта заявленным характеристикам
• Вопрос 6.1: Какова была стоимость устранения проблем после входа версии?
• Метрика 6.1: Стоимость устранения проблем (CFP)CFP = Стоимость устранения вех проблем в течение месяца (в долларовом эквиваленте)
Метрики
• Цель 7: Повысить производительность труда• Вопрос 7.1: Какова была производительность в
проектах по разработке ПО (исходя из объема кода)?• Метрика 7.1a: Общая производительность при
разработке (SP total)SP = Объем кода (приведенный к эквиваленту Assembler) / Трудозатраты по разработке ПО
• Метрика 7.1b: Прирост производительности (SP delta)SP = Прирост объема кода (приведенный к эквиваленту Assembler) / Трудозатраты по разработке ПО
Метрики собраны. Что дальше?
• Управленческие решения• Кризис управления• Две стороны силы
«Любимые игры» менеджеров
• Игнорирование рисков и проблем• «Преступное бездействие» в критические моменты• Перенос ответственности• «Yes»-менеджмент• Наказание невиновных и награждение
непричастных• Давление на команду («мативация»)• «Ретуширование» действительности, боязнь
ошибок, приукрашивание результатов• «Позитивный» подход: не говорим и не думаем о
плохом• Манипуляции с людьми и цифрами
К чему это приводит?
• Недовольство команды• Отсутствие инициативы• Цинизм и равнодушие• Снижение производительности• «Итальянская забастовка»• Нелояльность персонала• «Бунт на корабле»
Что делать?
• Думать• Искать причины проблем, а не пытаться
устранить симптомы• Не ограничиваться решениями, дающими
эффект в краткосрочной перспективе• Устранять причины проблем, а не
«разбираться» с исполнителями• Всегда помнить, что:
– Включение мозга – очень энергозатратный процесс– Мысль не включается по команде «подъем»
Case study: «провал проекта на ровном месте»
Где, когда и как это было?
• 1999 год• Россия• Команда, насчитывающая менее 100 человек• Разработка корпоративного портала для
внешнего заказчика– 1-й проект: успешно завершен– 2-й проект: провал проекта
• Fixed time, fixed budget
Какие риски рассматривались?
• Риск ухода человека из команды– Средняя зарплата по рынку (по областям компетенции)– Среднее время работы сотрудника на аналогичной
должности
• Риски расписания– Среднее число дней нетрудоспособности в году (на
человека) в данной команде
• Ограничения по срокам, бюджету, времени• Ограничения, налагаемые требованиями к
качеству– Метрики качества кода– Метрики качества продукта
Что происходило?
• Трудность «входа» новичка в команду– 30% вновь принятых на работу не проходили
испытательный срок
• Незапланированные работы– Серьезные рабочие перегрузки
• Незаменимые люди в команде– Перегруженность незаменимых людей– Внезапный уход незаменимых людей
• Ухудшение качества кода• Устойчивый рост числа ошибок
Что делали?
• «Гасили пожары»• Устраивали авралы• Перегружали людей, бравших на себя
высокую степень ответственности• Не пытались провести более детальный
анализ причин, почему это происходит
