«Чем больше система, тем больше ответственность… размер выгоды тщательно проверяется, потому что будущие схемы финансирования расходов могут быть сокращены из-за невыполнимых обещаний…
Всегда есть ситуация, когда заявку делает «правильный» человек. В каждой организации есть несколько индивидуумов, которые легко получают то, что хотят, в силу их значимости для компании».
Кристина Дэвис, раньше работавшая в TI и Raytheon
«[работа без оценивания ценности] вынуждает принимать решения на основании лишь тестостерона[30]. Мой опыт подсказывает, что принятие решений, диктуемое тестостероном, не дает положительных результатов, если проследить их ценность в долгосрочной перспективе. На самом деле я считаю, что этот подход в лучшем случае портит карьеру…
Я также встречал весьма странное отношение к ответственности, выглядящее примерно так: «У проекта был полный успех (после того, правда, как мы переопределили понятие успеха)». Это обычно следует после одного из совещаний на поздних стадиях проекта, где «срезают функциональность». Это похоже на сэндвич: в начале проекта — ломоть хлеба, в конце — тот же ломоть хлеба, а в середине кусок какого-то мяса (вы надеетесь, что это мясо, но близко его рассматривать не стоит)».
Син Джексон, Howard Hughes Medical Insulate
«[должно быть] равенство ответственности у разработчиков и заказчиков. Заказчики отвечают за то, чтобы убедиться в том, что ожидаемая выгода получена. [Но] постоянно в своих обзорах мы обнаруживаем, что компании не отслеживают по факту, была ли получена ожидаемая выгода».
Роб Остин (Austin), профессор Гарвардской школы бизнеса
«Показатели экономии также классифицируют по тому, являются ли они сокращением или избежанием расходов. Это различие важно. Сокращение — это вычеты из текущего уже принятого бюджета. Вы (менеджер, делающий заявку на финансирование) уже получили эти деньги: вы соглашаетесь отказаться от них, если получите деньги на новую систему. Избежание расходов выглядит так: „Если у меня не будет этой системы, мне придется дополнительно нанять <столько-то> <таких-то работников> в <будущем году>. Но если у меня будет эта система, я обойдусь без этих расходов“. Это — любимый тип выгоды для тех, кто делает заявку на новую систему: одни обещания, никаких реальных жертв. Ловушка в том, что нет оснований верить, что вы бы получили средства для найма этих дополнительных работников. Вы меняете средства на будущие операционные расходы, которых вы могли бы и не получить вовсе, на основные фонды сегодня. Очень соблазнительно, но большинство из тех, кто распределяет бюджет, и рассматривает финансовые заявки, чуют это за версту. Корректной проверкой выгоды, связанной с избежанием затрат, является вопрос о неизбежности предполагаемых затрат. Другими словами, была бы непременно удовлетворена будущая бюджетная заявка. Это суровая проверка, но реальная выгода, связанная с избежанием затрат, может пройти ее и пройдет».Картинка, возникшая из этих неформальных мнений, сама похожа на сэндвич, упомянутый в одной из цитат, но все же можно проследить пару занятных тенденций:
Стив МакМенамин, Atlantic Systems Guild
1. Организации, применяющие передовые практики, нацелены на проведение оценки выгоды, хотя могут менять ее форму от проекта к проекту.
2. Многие из них следуют схеме сокращения финансовых потоков, идущих сверху вниз, исходя из размера ожидаемой выгоды, что имела в виду Кристина, говоря, что «будущие схемы финансирования расходов могут быть сокращены из-за невыполнимых обещаний».
Наконец, даже эти организации в некоторых случаях удовлетворяются гарантиями стоимости типа «Поверьте мне, это сделать выгодно», но чаще всего это проходит, когда ответственность за затраты и за выгоду оказывается в руках одного заказчика.
Глава 20
Анализ чувствительности
Щепетильный предмет, которому посвящена данная глава, — увеличившаяся ответственность заказчика. Мы уже высказывались в пользу необходимости переложить ответственность за предсказание выгоды и измерение реально полученной выгоды на пользователей системы и заказчиков (причем с той же степенью точности, что и оценка затрат и фактические затраты). Теперь мы хотели бы привлечь внимание к некоторому использованию инкрементного метода в этом расчете выгоды. Щепетильность вопроса состоит в том, что вы не можете просто обязать своих клиентов к такой ответственности. Вы должны это выманивать лестью, уговаривать и просить об одолжении. Хотите ли вы действительно тратить, какой бы то ни было, политический капитал, который у вас может иметься, на эти кажущиеся невразумительными цели? В этой главе мы постараемся убедить вас, что вы этого хотите.
Не стоит ручаться за то, что их ценность равна. Наш опыт (да и ваш, признайтесь) подсказывает, что ценность очень неравномерно распределена по системе. Основных денег система стоит из-за определенных ключевых функций, осуществляемых «в самом сердце» продукта или около него.
Иногда эта область, концентрирующая в себе основную ценность, составляет не более 10% кода. А остальное… ну, что это может быть? Иногда — необходимое инфраструктурное обеспечение, а в другой раз — явно «прибамбасы», маскирующиеся под необходимую инфраструктуру. Анализ чувствительности и состоит в том, чтобы прорубиться через это маленькое заблуждение.
<……>заказчиком, показала бы ложность предположения об однородности распределения выгод по системе в целом.
У одних компонентов отношение «выгоды/затраты» будет иметь высокий показатель, и это будут кандидаты на более раннюю готовность. Советуем вам составлять план версий, выбирая для более ранних версий компоненты, у которых показатели этого отношения выше. При поставке версии n все или большинство участников могут обнаружить, что среднее значение отношения «выгоды/затраты» еще не готовых частей незначительно. Это вполне может вызвать массовый энтузиазм по поводу соглашения о завершении проекта, признав его исключительно успешным, что позволит перейти к другим делам. И все это без необходимости занимать непопулярную позицию по поводу того, что любимая функция такого-то была чистой подачкой его самолюбию и ни черта не давала для общей выгоды.
Если при увеличении размера продукта обнаруживается и соответствующее возрастание усилий по его разработке, то уменьшение размера продукта дает возможность соответствующей их экономии. Отказ от частей системы в которых отношение «выгоды/затраты» мало, возможно, представляет собой легчайший и наилучший способ ослабить ограничения по времени и бюджету. Странно, что разработчики программного обеспечения должны поверить, что «создавать меньше программного обеспечения» должно стать частью их молитвы, но преимущества этого очевидны.
Может быть, вам и не придется. Польза от частичных данных «выгоды/затраты» состоит в том, что они позволяют упорядочить компоненты для включения в версии. Получить точные оценки было бы отлично, но если их приобрести нельзя, то не устроит ли вас вместо этого упорядочение?
Сам факт, что вы собираетесь сдавать проект по частям, дает вам рычаг для получения инструкций по упорядочению даже от самых упрямых заказчиков. В конце концов, некоторые части системы обязательно придется внедрять после каких-то других. Одни части будут первыми, а другие — последними. Если вы отдадите это решение в руки своим заказчикам, они кинутся рассказывать вам о порядке осуществления. Все знают, что порой системы опаздывают и «первые» части могут оказаться готовыми к изначально определенному сроку, а вот «последние» еще не будут готовы. Редкий пользователь не сумеет воспользоваться преимуществами этого дополнительного уровня управления, несмотря на то, что использование этого является признанием неравномерной концентрации ценности в разных частях системы.
Если это — решение, то что является проблемой?
Проблема, на которую мы здесь нацелились, состоит в том, что большинство проектов разработки программного обеспечения по своей природе комплексные. Проект получает финансирование на основе какой-то ценности — либо имеющей явное количественное выражение, либо нет — которую должен принести полученный в результате продукт. Теперь стоит задать несколько вопросов: «В чем ценность этого продукта? Равномерно ли она распределена между всеми компонентами системы? Одинакова ли ценность этого модуля объемом в сто строк и того модуля (тоже из 100 строк), который восстанавливает конфигурацию после потери питания?»Не стоит ручаться за то, что их ценность равна. Наш опыт (да и ваш, признайтесь) подсказывает, что ценность очень неравномерно распределена по системе. Основных денег система стоит из-за определенных ключевых функций, осуществляемых «в самом сердце» продукта или около него.
Иногда эта область, концентрирующая в себе основную ценность, составляет не более 10% кода. А остальное… ну, что это может быть? Иногда — необходимое инфраструктурное обеспечение, а в другой раз — явно «прибамбасы», маскирующиеся под необходимую инфраструктуру. Анализ чувствительности и состоит в том, чтобы прорубиться через это маленькое заблуждение.
Инкрементный анализ выгод и затрат
Как только мы разбили систему на куски (скажем, функции в период спецификации или модули в период разработки), возможно и разумно распределить предполагаемые затраты по карте этого разбиения. Так, доля системы, стоящая порядка $235000, могла бы иметь график затрат такого вида:<……>заказчиком, показала бы ложность предположения об однородности распределения выгод по системе в целом.
У одних компонентов отношение «выгоды/затраты» будет иметь высокий показатель, и это будут кандидаты на более раннюю готовность. Советуем вам составлять план версий, выбирая для более ранних версий компоненты, у которых показатели этого отношения выше. При поставке версии n все или большинство участников могут обнаружить, что среднее значение отношения «выгоды/затраты» еще не готовых частей незначительно. Это вполне может вызвать массовый энтузиазм по поводу соглашения о завершении проекта, признав его исключительно успешным, что позволит перейти к другим делам. И все это без необходимости занимать непопулярную позицию по поводу того, что любимая функция такого-то была чистой подачкой его самолюбию и ни черта не давала для общей выгоды.
Экономичность и неэкономичность за счет масштаба
То, что выгода неоднородна внутри системы, дает полезный тактический инструмент IT-менеджеру. Системные проекты отличаются проявлением отрицательных последствий, обусловленных изменением масштаба: при удвоении размера системы следует ожидать, что усилия для ее создания возрастут больше, чем вдвое. Эта нелинейность усилий по отношению к размеру системы хорошо документирована Боэмом[31] и другими:Если при увеличении размера продукта обнаруживается и соответствующее возрастание усилий по его разработке, то уменьшение размера продукта дает возможность соответствующей их экономии. Отказ от частей системы в которых отношение «выгоды/затраты» мало, возможно, представляет собой легчайший и наилучший способ ослабить ограничения по времени и бюджету. Странно, что разработчики программного обеспечения должны поверить, что «создавать меньше программного обеспечения» должно стать частью их молитвы, но преимущества этого очевидны.
Обратно в реальный мир
Ладно, посмотрим фактам в лицо: заставить заказчиков предсказывать выгоды — все равно, что удалять зубы. Это большой объем работы, открывающий дверь дополнительному уровню ответственности, причем усилия тех, кто подставляет себя под удар и занимается количественной оценкой, явно не окупятся. Если среди полезных функций затесались «прибамбасы», то люди, которые должны сделать количественную оценку, вполне могут оказаться теми, кто потеряет свои любимые игрушки. Можно ожидать практически от любого заказчика яростных возражений и уверений самым серьезным тоном, что «все это необходимо для поддержки основной функциональности, честное слово». Это та же самая старая и надоевшая песня про равномерно распределенную стоимость, но не рассчитывайте их в этом убедить.Может быть, вам и не придется. Польза от частичных данных «выгоды/затраты» состоит в том, что они позволяют упорядочить компоненты для включения в версии. Получить точные оценки было бы отлично, но если их приобрести нельзя, то не устроит ли вас вместо этого упорядочение?
Сам факт, что вы собираетесь сдавать проект по частям, дает вам рычаг для получения инструкций по упорядочению даже от самых упрямых заказчиков. В конце концов, некоторые части системы обязательно придется внедрять после каких-то других. Одни части будут первыми, а другие — последними. Если вы отдадите это решение в руки своим заказчикам, они кинутся рассказывать вам о порядке осуществления. Все знают, что порой системы опаздывают и «первые» части могут оказаться готовыми к изначально определенному сроку, а вот «последние» еще не будут готовы. Редкий пользователь не сумеет воспользоваться преимуществами этого дополнительного уровня управления, несмотря на то, что использование этого является признанием неравномерной концентрации ценности в разных частях системы.
Глава 21
Выгоды возмещают риски
Насколько мы готовы рисковать в данном проекте? Какой бы ответ вы ни дали, он должен учитывать потенциальную выгоду, которую он мог бы принести. Ни одна рабочая теория риска не может игнорировать выгоду. Когда ставки высоки, стоит идти даже на серьезные риски. Когда игра не стоит свеч, практически никакой риск не является допустимым.
Если предыдущий абзац показался вам убедительным, вы относитесь к меньшинству. Кажется, что вся IT-отрасль поддерживает практически противоположный взгляд: Рискуйте много, когда выгода ничтожна. Как еще мы сумеем снизить затраты настолько, чтобы оправдать этот нестоящий проект?
Это мышление — порождение одного из самых распространенных, но постыдных стилей работы в нашей отрасли…
Оправдание этих жертв всегда апеллирует к важности проекта: это так важно и необходимо, что требует предела возможного от персонала проекта. Но есть нечто загадочное в этом утверждении. Если этот проект так важен, почему компания не может потратить время и деньги необходимые для его нормального осуществления?
По нашему опыту, единственной общей характеристикой таких проектов является низкая ожидаемая выгода. Это — проекты, нацеленные на выпуск продуктов монументальной незначительности. Единственным реальным обоснованием проектов на выживание является то, что выгода столь мала, что нормальное выполнение проекта явно привело бы к затратам, которые будут больше выгоды. Только героическими усилиями можно надеяться заставить свинью летать.
Второй характеристикой проекта на выживание является одурачивание людей, чтобы заставить их принести свою личную жизнь в жертву компании, убедив, что только это может привести к успеху, поскольку выгода столь крохотная, что осмысленными будут только самые низкие затраты.
Третья характеристика такого проекта состоит в том, что они почти всегда кончаются полным фиаско, не создав ничего или почти ничего (обычно при затратах выше среднего) и заставив всех чувствовать себя одураченными и озлобленными. Должен быть выход лучше.
Реальное обоснование проекта (вы всегда знали это в глубине сердца) требует сбалансированности риска и выгоды, как показано на рисунке:
Здесь есть техническая проблема: как решить, перевешивает ли выгода, показанная на левой стороне, риски, показанные справа. Поскольку и выгода, и риски являются до некоторой степени неопределенными, следует ожидать, что и баланс тоже будет в некоторой степени неопределенным. Если призвать на помощь сложную математику, то получим диаграмму неопределенности, показывающую одновременное воздействие неопределенной выгоды и неопределенного риска. Однако без вычислений наилучшим подспорьем является симуляция с помощью RISKOLOGY, показывающая чистую выгоду для ряда из 100 смоделированных проектов. Система дает гистограмму, которую можно аппроксимировать гладкой кривой, как показано на этом рисунке:
Если предыдущий абзац показался вам убедительным, вы относитесь к меньшинству. Кажется, что вся IT-отрасль поддерживает практически противоположный взгляд: Рискуйте много, когда выгода ничтожна. Как еще мы сумеем снизить затраты настолько, чтобы оправдать этот нестоящий проект?
Это мышление — порождение одного из самых распространенных, но постыдных стилей работы в нашей отрасли…
Проекты на выживание
В этих случаях непоколебимая жертвенность непреложно требуется от всех до одного участников проекта. Проект требует забросить личную жизнь, бесконечно работать сверхурочно, проводя субботы и воскресенья в офисе, отдалиться от семьи и т.д. Неприемлемо ничто меньшее, чем полное посвящение себя проекту.Оправдание этих жертв всегда апеллирует к важности проекта: это так важно и необходимо, что требует предела возможного от персонала проекта. Но есть нечто загадочное в этом утверждении. Если этот проект так важен, почему компания не может потратить время и деньги необходимые для его нормального осуществления?
По нашему опыту, единственной общей характеристикой таких проектов является низкая ожидаемая выгода. Это — проекты, нацеленные на выпуск продуктов монументальной незначительности. Единственным реальным обоснованием проектов на выживание является то, что выгода столь мала, что нормальное выполнение проекта явно привело бы к затратам, которые будут больше выгоды. Только героическими усилиями можно надеяться заставить свинью летать.
Второй характеристикой проекта на выживание является одурачивание людей, чтобы заставить их принести свою личную жизнь в жертву компании, убедив, что только это может привести к успеху, поскольку выгода столь крохотная, что осмысленными будут только самые низкие затраты.
Третья характеристика такого проекта состоит в том, что они почти всегда кончаются полным фиаско, не создав ничего или почти ничего (обычно при затратах выше среднего) и заставив всех чувствовать себя одураченными и озлобленными. Должен быть выход лучше.
Рискуйте, только если это оправдано выгодой
Лучший выход состоит в том, чтобы руководствоваться ожидаемой выгодой при решении, на какое количество рисков отважиться. В ретроспективе, главной причиной того, что мы раньше этого не делали, была нехватка дисциплины, чтобы заставить количественно оценить выгоду. В особенности по не очень выгодным проектам, мы стойко отказывались количественно оценить выгоду, поскольку это было единственным способом сохранять сколько-нибудь приличный вид всей затеи. Без объявленных ожиданий стоимости можно было опираться только на сокращение расходов на разработку. Обоснование преимущественно было таким: «Мы так снизим затраты, что они наверняка будут меньше, чем любая полученная выгода».Реальное обоснование проекта (вы всегда знали это в глубине сердца) требует сбалансированности риска и выгоды, как показано на рисунке:
Здесь есть техническая проблема: как решить, перевешивает ли выгода, показанная на левой стороне, риски, показанные справа. Поскольку и выгода, и риски являются до некоторой степени неопределенными, следует ожидать, что и баланс тоже будет в некоторой степени неопределенным. Если призвать на помощь сложную математику, то получим диаграмму неопределенности, показывающую одновременное воздействие неопределенной выгоды и неопределенного риска. Однако без вычислений наилучшим подспорьем является симуляция с помощью RISKOLOGY, показывающая чистую выгоду для ряда из 100 смоделированных проектов. Система дает гистограмму, которую можно аппроксимировать гладкой кривой, как показано на этом рисунке:
Глава 22
Уточнение правил управления рисками
Вернемся к правилам, впервые изложенным в главе 10, чтобы добавить некоторые уточнения. Начнем здесь с пересмотра первого раздела этой главы «Что понимают под управлением рисками».
1. Используйте процесс идентификации рисков (подробности в главе 14) для составления перечня рисков, которые грозят вашему проекту
2. Убедитесь, что все главные риски проектирования программного обеспечения (подробности в главе 13) представлены в вашем перечне.
3. Проведите всю указанную предварительную подготовку по каждому из рисков:
• Дайте наименование риску и присвойте ему уникальный номер.
• Проведите мозговой штурм для выявления показателей наступления события риска.
• Оцените влияние наступления риска на стоимость и расписание проекта.
• Оцените вероятность наступления риска.
• Рассчитайте подверженность риску в терминах расписания и бюджета.
• Определите заранее, какие меры придется принять, если и когда событие риска наступит.
• Определите, какие меры для ослабления риска следует принять до наступления риска, чтобы обеспечить осуществимость избранных мер реагирования.
• Включите действия по ослаблению риска в обший план проекта.
• Опишите все детали в специальной форме, шаблон которой приведен в Приложении Б.
4. Укажите возможные риски-катастрофы как исходные допущения проекта. Разработайте схему делегирования управления каждым из таких рисков вышестоящему руководству.
5. Сделайте первый подход к оценке расписания, исходя из предположения, что ни один из рисков не материализуется. Другими словами, ваш первый шаг по оценке состоит в определении «даты с вероятностью нанопроцента», то есть самой ранней из дат, к которой вы можете успеть завершить проект. Это отличается от принятой в отрасли практики тем, что мы предлагаем использовать нанопроцентную дату как входные данные процесса составления расписания, а не как его результат. Определите N, используя какой-нибудь из инструментов параметрической оценки, если у вас он есть, настроенный на самые оптимистичные сценарии.
6. Скачайте RISKOLOGY (см. http://www.pmo.ru/riskology). Введите параметры своего проекта в главную рабочую таблицу. Там же введите все индивидуальные настройки, какие сможете найти, опираясь на имеющиеся у вас записи о предшествующей деятельности вашей компании. Замените как можно больше общеотраслевых, заложенных в имитаторе, данных относительно главных рисков имеющейся у вас достоверной информацией. Добавьте индивидуально настроенные рабочие таблицы для всех второстепенных рисков, которые вы отслеживаете. Проведите моделирование для получения диаграммы риска для вашего проекта, добиваясь пересечения с вашей нанопроцентной датой.
7. Выразите, используя диаграмму риска, все обязательства по проекту, в явном виде показывая неопределенность, связанную с каждой планируемой датой и бюджетом. Вместо того чтобы объяснять концепцию диаграмм риска любому из не самых сообразительных заказчиков, отнеситесь к ней как к моделированию своего проекта, сделайте 500 прогонов, показывая все возможные результаты и сравнительную вероятность каждого.
8. Разработайте иерархическую структуру работ, показывающую все задачи, которые нужны для выполнения проекта. Оцените усилия для выполнения каждой задачи, используя любую схему, которую обычно применяете для этого. Мы собираемся использовать эти оценки несколько менее привычным способом: будут приниматься во внимание только относительные веса усилий для выполнения задач, а не их абсолютные значения. Эти относительные веса будут нужны как входные данные для вычисления показателей ООФ.
9. В начале проекта утвердите договоренности по определению входных и выходных потоков данных. Вам следует иметь полную определенность относительно всех потоков данных, вплоть до самого низкого уровня, в пределах первых 12-15% календарного времени. Рассматривайте это как важное контрольное событие проекта. Не переходите к следующим задачам, пока не пройдено это событие. Помните, что неудача с этим показателем, определяющим все потоки, может оказаться роковым предупреждением.
10. Полностью разработайте план разбиения процесса разработки на части до начала осуществления проекта. Используйте это как входные данные для процесса создания плана инкрементных поставок.
11. Когда план разбиения процесса разработки на части завершен, вернитесь к иерархической структуре работ, оцените заново веса задач и выразите задачи в процентах от работы, которую предстоит выполнить.
12. Оцените выгоды с той же точностью, что и затраты.
13. Разбейте требования, содержащиеся в спецификации, до элементарного уровня. Перечислите их в порядке приоритета. В качестве двух критериев установления приоритета выбирайте чистую выгоду для пользователя и технические риски.
14. Разработайте план инкрементных поставок, в котором весь продукт разбит на версии (множество версий, по крайней мере столько, чтобы запланировать появление новой версии примерно раз в неделю). Опишите все требования к элементам соответствующих версий, чтобы пункты с более высоким приоритетом шли раньше. Вычислите ООФ для каждой версии и запишите в план. Рассматривайте план инкрементных поставок как главный результат проекта.
15. Разработайте технологию общих приемных испытаний для данного продукта и разделите их на приемные испытания отдельных версий (ПИn), по одному на каждую версию.
16. Построите график ООФ в соответствии с ожидаемыми датами поставки каждой иерсии. По мере прохождения версиями приемочных испытаний (ПИ) проставьте на том же графике реальные результаты.
17. Отслеживайте на протяжении оставшейся части проекта все риски на предмет наступления или исчезновения и выполняйте планы реагирования всякий раз, когда риски наступают. Наблюдайте за ООФ и его исполнением в сравнении с ожидаемым. Рассматривайте отклонения как признак возможного наступления риска.
18. Поддерживайте в действии процесс идентификации рисков на всем протяжении проекта, чтобы справиться с поздно проявляющимися рисками.
Что понимают под управлением рисками (уточненное и переработанное)
Управление рисками по сути представляет собой осуществление следующих шагов, включаемых в проект (пункты 6-12 включают больше всего изменений по сравнению со списком в главе 10, но мы, конечно, рассмотрим заново весь процесс):1. Используйте процесс идентификации рисков (подробности в главе 14) для составления перечня рисков, которые грозят вашему проекту
2. Убедитесь, что все главные риски проектирования программного обеспечения (подробности в главе 13) представлены в вашем перечне.
3. Проведите всю указанную предварительную подготовку по каждому из рисков:
• Дайте наименование риску и присвойте ему уникальный номер.
• Проведите мозговой штурм для выявления показателей наступления события риска.
• Оцените влияние наступления риска на стоимость и расписание проекта.
• Оцените вероятность наступления риска.
• Рассчитайте подверженность риску в терминах расписания и бюджета.
• Определите заранее, какие меры придется принять, если и когда событие риска наступит.
• Определите, какие меры для ослабления риска следует принять до наступления риска, чтобы обеспечить осуществимость избранных мер реагирования.
• Включите действия по ослаблению риска в обший план проекта.
• Опишите все детали в специальной форме, шаблон которой приведен в Приложении Б.
4. Укажите возможные риски-катастрофы как исходные допущения проекта. Разработайте схему делегирования управления каждым из таких рисков вышестоящему руководству.
5. Сделайте первый подход к оценке расписания, исходя из предположения, что ни один из рисков не материализуется. Другими словами, ваш первый шаг по оценке состоит в определении «даты с вероятностью нанопроцента», то есть самой ранней из дат, к которой вы можете успеть завершить проект. Это отличается от принятой в отрасли практики тем, что мы предлагаем использовать нанопроцентную дату как входные данные процесса составления расписания, а не как его результат. Определите N, используя какой-нибудь из инструментов параметрической оценки, если у вас он есть, настроенный на самые оптимистичные сценарии.
6. Скачайте RISKOLOGY (см. http://www.pmo.ru/riskology). Введите параметры своего проекта в главную рабочую таблицу. Там же введите все индивидуальные настройки, какие сможете найти, опираясь на имеющиеся у вас записи о предшествующей деятельности вашей компании. Замените как можно больше общеотраслевых, заложенных в имитаторе, данных относительно главных рисков имеющейся у вас достоверной информацией. Добавьте индивидуально настроенные рабочие таблицы для всех второстепенных рисков, которые вы отслеживаете. Проведите моделирование для получения диаграммы риска для вашего проекта, добиваясь пересечения с вашей нанопроцентной датой.
7. Выразите, используя диаграмму риска, все обязательства по проекту, в явном виде показывая неопределенность, связанную с каждой планируемой датой и бюджетом. Вместо того чтобы объяснять концепцию диаграмм риска любому из не самых сообразительных заказчиков, отнеситесь к ней как к моделированию своего проекта, сделайте 500 прогонов, показывая все возможные результаты и сравнительную вероятность каждого.
8. Разработайте иерархическую структуру работ, показывающую все задачи, которые нужны для выполнения проекта. Оцените усилия для выполнения каждой задачи, используя любую схему, которую обычно применяете для этого. Мы собираемся использовать эти оценки несколько менее привычным способом: будут приниматься во внимание только относительные веса усилий для выполнения задач, а не их абсолютные значения. Эти относительные веса будут нужны как входные данные для вычисления показателей ООФ.
9. В начале проекта утвердите договоренности по определению входных и выходных потоков данных. Вам следует иметь полную определенность относительно всех потоков данных, вплоть до самого низкого уровня, в пределах первых 12-15% календарного времени. Рассматривайте это как важное контрольное событие проекта. Не переходите к следующим задачам, пока не пройдено это событие. Помните, что неудача с этим показателем, определяющим все потоки, может оказаться роковым предупреждением.
10. Полностью разработайте план разбиения процесса разработки на части до начала осуществления проекта. Используйте это как входные данные для процесса создания плана инкрементных поставок.
11. Когда план разбиения процесса разработки на части завершен, вернитесь к иерархической структуре работ, оцените заново веса задач и выразите задачи в процентах от работы, которую предстоит выполнить.
12. Оцените выгоды с той же точностью, что и затраты.
13. Разбейте требования, содержащиеся в спецификации, до элементарного уровня. Перечислите их в порядке приоритета. В качестве двух критериев установления приоритета выбирайте чистую выгоду для пользователя и технические риски.
14. Разработайте план инкрементных поставок, в котором весь продукт разбит на версии (множество версий, по крайней мере столько, чтобы запланировать появление новой версии примерно раз в неделю). Опишите все требования к элементам соответствующих версий, чтобы пункты с более высоким приоритетом шли раньше. Вычислите ООФ для каждой версии и запишите в план. Рассматривайте план инкрементных поставок как главный результат проекта.
15. Разработайте технологию общих приемных испытаний для данного продукта и разделите их на приемные испытания отдельных версий (ПИn), по одному на каждую версию.
16. Построите график ООФ в соответствии с ожидаемыми датами поставки каждой иерсии. По мере прохождения версиями приемочных испытаний (ПИ) проставьте на том же графике реальные результаты.
17. Отслеживайте на протяжении оставшейся части проекта все риски на предмет наступления или исчезновения и выполняйте планы реагирования всякий раз, когда риски наступают. Наблюдайте за ООФ и его исполнением в сравнении с ожидаемым. Рассматривайте отклонения как признак возможного наступления риска.
18. Поддерживайте в действии процесс идентификации рисков на всем протяжении проекта, чтобы справиться с поздно проявляющимися рисками.
Часть V
Так есть или нет?
Как узнать, осуществляется ли на практике управление риском или нет?
Глава 23
Тест на управление риском
Если вы отвечаете за управление риском или стоите на более высокой иерархической ступени, вам нужен объективный способ, чтобы понять, делается ли эта работа. Зачем это? Почему бы просто не предположить, что люди, отвечающие за управление проектами, естественным образом будут привлечены к управлению рисками в этих проектах? Причина в том, что существуют мощные ложно-положительные показатели работы в организации. Они направлены на то, чтобы необоснованно давать ход всему, что называет себя управлением.
Представьте, что вы — руководитель более высокого уровня, чем тот, на котором находится рассматриваемый проект, а управление риском должно происходить на уровне проекта (внутри проекта или на том же уровне). Ложно-положительный показатель действует на уровне таких рассуждений: «Угу, мои люди ведут рискованные проекты, поэтому, конечно, они управляют рисками. В чем же состоит управление, в конце концов, если не в предвидении и поисках путей обхода различных препятствий, которые могли бы погубить проект? Разумеется, мои менеджеры — профессионалы: они не позволят себе обращать фокусироваться на ерунде и игнорировать реальные опасности».
Звучит хорошо. Проблема только в том, что такой ход мыслей игнорирует все расхолаживающие факторы, встроенные или зарытые в корпоративной культуре. Это включает в себя мышление «будет сделано», нежелание разочаровывать, требование сохранять «радужность» радужных сценариев, страх перед выражением неопределенности, необходимость видимости контроля (даже когда на самом деле контроль иллюзорен), соблазн использовать политическое влияние для приукрашивания действительного положения дел и своего рода близорукое мышление, губящее все начинания.
Это — мощные силы. Они могут заставить несомненно думающих людей отказываться от разумного управления и принимать вместо него разумное на вид управление. Есть разница.
Набор объективных тестов для определения того, происходит ли на самом деле управление рисками, может быть полезен не только высшему руководству, но и самим менеджерам рисков.
1. Имеется перечень рисков. В этот перечень включены все главные риски проектов разработки программного обеспечения, а также риски, присущие исключительно данному проекту. Риски эти по природе своей причинные (то, что вызовет ужасные результаты, а не то, что само является ужасным результатом).
2. Имеется действующий процесс идентификации рисков. Идентификация рисков ведется открыто, причем приветствуется участие каждого в этом процессе. Конкретные шаги сделаны для того, чтобы можно было безопасно высказывать вслух неприятные вещи. Можно даже открыть анонимный канал для сообщения плохих новостей. Такая схема успешно работает в компаниях некоторых наших клиентов. (Ее не часто используют, но когда используют, это неоценимо).
3. Везде есть диаграммы неопределенности. Их используют для количественного измерения причинных рисков и для выражения совокупных рисков и ожиданий. Корпоративная культура начинает считать непрофессиональным взятие обязательств без упоминания в явном виде об их неопределенности.
4. Имеются цели и оценки проекта, и они никогда не совпадают. Цели могут быть на уровне «нанопроцентной даты» или рядом с ней, а оценки должны быть гораздо более консервативными. Если целью данного проекта является поставка продукта через 12 месяцев, то оценка должна планировать поставку хотя бы месяцев через восемнадцать. В любом случае, конкретный уровень доверия, который связан с любым обстоятельством, должен быть указан диаграммой неопределенности.
Представьте, что вы — руководитель более высокого уровня, чем тот, на котором находится рассматриваемый проект, а управление риском должно происходить на уровне проекта (внутри проекта или на том же уровне). Ложно-положительный показатель действует на уровне таких рассуждений: «Угу, мои люди ведут рискованные проекты, поэтому, конечно, они управляют рисками. В чем же состоит управление, в конце концов, если не в предвидении и поисках путей обхода различных препятствий, которые могли бы погубить проект? Разумеется, мои менеджеры — профессионалы: они не позволят себе обращать фокусироваться на ерунде и игнорировать реальные опасности».
Звучит хорошо. Проблема только в том, что такой ход мыслей игнорирует все расхолаживающие факторы, встроенные или зарытые в корпоративной культуре. Это включает в себя мышление «будет сделано», нежелание разочаровывать, требование сохранять «радужность» радужных сценариев, страх перед выражением неопределенности, необходимость видимости контроля (даже когда на самом деле контроль иллюзорен), соблазн использовать политическое влияние для приукрашивания действительного положения дел и своего рода близорукое мышление, губящее все начинания.
Это — мощные силы. Они могут заставить несомненно думающих людей отказываться от разумного управления и принимать вместо него разумное на вид управление. Есть разница.
Набор объективных тестов для определения того, происходит ли на самом деле управление рисками, может быть полезен не только высшему руководству, но и самим менеджерам рисков.
Тест «Действительно ли мы занимались управлением рисками?»
Когда управление рисками действительно ведется и укореняется в корпоративной культуре, проекты смогут пройти все или большинство следующих проверок:1. Имеется перечень рисков. В этот перечень включены все главные риски проектов разработки программного обеспечения, а также риски, присущие исключительно данному проекту. Риски эти по природе своей причинные (то, что вызовет ужасные результаты, а не то, что само является ужасным результатом).
2. Имеется действующий процесс идентификации рисков. Идентификация рисков ведется открыто, причем приветствуется участие каждого в этом процессе. Конкретные шаги сделаны для того, чтобы можно было безопасно высказывать вслух неприятные вещи. Можно даже открыть анонимный канал для сообщения плохих новостей. Такая схема успешно работает в компаниях некоторых наших клиентов. (Ее не часто используют, но когда используют, это неоценимо).
3. Везде есть диаграммы неопределенности. Их используют для количественного измерения причинных рисков и для выражения совокупных рисков и ожиданий. Корпоративная культура начинает считать непрофессиональным взятие обязательств без упоминания в явном виде об их неопределенности.
4. Имеются цели и оценки проекта, и они никогда не совпадают. Цели могут быть на уровне «нанопроцентной даты» или рядом с ней, а оценки должны быть гораздо более консервативными. Если целью данного проекта является поставка продукта через 12 месяцев, то оценка должна планировать поставку хотя бы месяцев через восемнадцать. В любом случае, конкретный уровень доверия, который связан с любым обстоятельством, должен быть указан диаграммой неопределенности.