Цитаты из книг автора «Сергей Дерцап»

связано с тем, что обычно при работе над задачей выясняются и уточняются новые данные, которые могут увеличить объем работ. Вдобавок могут сработать риски, что приведет к увеличению первоначально определенной трудоемкости. Распределение выглядит так (рис. 17). Наиболее вероятно (НВ), что мы выполним задачу за пять дней, но если повезет, то можем и за три. Если же что-то пойдет не так, то решение задачи может растянуться на девять дней. Таким образом, вероятность того, что задача будет выполнена ровно за пять дней, невелика. Именно поэтому при оценке нужно указывать интервал (рис. 18). Если мы говорим, что выполним задачу за пять дней минус 10% плюс 25%, то вероятность попасть в интервал существенно выше.

Характеристики методов оценок В разных ситуациях требуется разная точность оценки. Существует три категории точности: порядок величины (Rough Order of Magnitude, ROM), бюджетная (budget) и полная оценка (definitive). В таблице 3 отображена разница между ними. Точность оценки и предположения, на которых основывается оценка Каждая оценка должна содержать указание точности и предположения, на которых она основывается. Поэтому опытный руководитель проекта на вопрос, сколько времени у него сегодня займет обед, отвечает так: «50 минут, минус 5 плюс 10 минут, при условии, что кафе не закрыто на спецобслуживание». В таком ответе есть четкое указание на точность оценки и предположение, на котором она основана. Заметили ли вы, что точность оценки имеет разные значения в минус и в плюс? Все дело в распределении вероятности. Если выполнение задачи оценивается в пять дней, то вероятность выполнить задачу раньше ниже, чем вероятность задержки. На практике это

длительности каждого пакета в отдельности. Сумма оценок пакетов показывает общую стоимость и длительность проекта. Оценка начинается с самого нижнего уровня ИСР и идет вверх. Оценка по аналогам. Предполагает использование исторических данных по выполненным проектам. В этом методе за основу берется похожий проект, который компания уже выполняла в прошлом. Метод подходит, если у компании есть опыт работы над похожими проектами. Параметрическое моделирование. Оценка проекта производится при использовании модели с параметрами. Например, мы знаем, что помыть одно окно займет 1,5 часа. В офисе 14 окон. Следовательно, трудоемкость всего проекта по мытью окон в офисе считается так: 1,5 часа × 14 окон = 21 час. Экспертные оценки. Суть метода заключается в проведении интервью с одним или несколькими экспертами, обладающими опытом подобной работы. В итоге эксперт дает свою оценку, базируясь на собственном опыте и имеющейся на данный момент информации о проекте. Чем выше уровень эксперта, тем точнее обычно его прогноз. PERT (оценка по трем точкам). Похожа на предыдущий метод, но эксперт дает не одну, а три оценки: наиболее вероятную, пессимистичную и оптимистичную. Далее считают по формуле (рис. 16). Метод хорош тем, что корректирует наиболее вероятную оценку с учетом количества рисков, связанных с выполнением задачи. Если пессимистичная оценка не сильно отличается от наиболее вероятной, значит, исполнитель не видит больших рисков, связанных с задачей. Если наиболее вероятная оценка — неделя, а пессимистичная — шесть недель, то, скорее всего, у задачи есть серьезные риски. Анализ предложений поставщиков. Метод заключается в анализе предложений других поставщиков услуг. Для этого проводится тендер, участников которого просят оценить стоимость выполнения проекта. Допустим, пришло пять предложений: $80 000, $130 000, $140 000, $150 000 и $230 000. Далее отсекаются крайние значения, поскольку, скорее всего, они неадекватны ($80 000 и $230 000), а из оставшихся выводится среднее: (130 + 140 + 150) / 3 =140. Эта сумма и берется в качестве оценки стоимости проекта. Такой метод компании используют, когда нужно оценить проект в той сфере, где у них совсем нет или мало экспертизы.

Процесс оценки показан на рисунке 15. Допустим, менеджер узнал, с какой целью и точностью необходимо делать оценку, собрал детали проекта и создал соответствующую ИСР. Теперь нужно решить, каким методом оценки воспользоваться. Методы оценки При проведении оценки можно использовать один или несколько методов. Использование нескольких методов позволяет подтвердить правильность оценки. Оценка «сверху вниз». При этом методе разрабатывается первый уровень ИСР, и на базе прошлого опыта (реализованных ранее проектов) выполняется оценка крупных частей проекта. Затем полученные оценки складываются, и получается итоговая цифра. Оценка «снизу вверх». При этом подходе разрабатывается ИСР, детализированная до уровня пакетов работ. Далее проводится оценка стоимости и

Трудоемкость (Effort) — количество единиц труда, необходимое для выполнения задания. Обычно измеряется в человеко-часах. Длительность (Duration) — количество рабочих периодов, за исключением праздников, выходных и других нерабочих дней, необходимое для завершения одного пакета работ проекта (операции). Длительность обычно выражается в рабочих днях или неделях. Операции проекта могут быть двух типов: основанные на трудоемкости и основанные на длительности. Например, мы знаем, что помывка окон в доме занимает 16 часов — это операция, основанная на трудоемкости. Если один человек моет окна за 16 часов, то два работника одинаковой квалификации вымоют их за восемь. При добавлении ресурсов на операцию, основанную на трудоемкости, ее длительность уменьшается. Существуют операции, основанные на длительности. Например, тестирование программного обеспечения после внесения изменений в ядро системы занимает два дня. И это не зависит от того, три или четыре человека будут проводить тестирование.

Реестр обновляется после каждого промежуточного этапа проекта. В него вносится следующая информация: выявленные риски и их описание, включая причины их возникновения, триггеры и возможное влияние на цели проекта; результаты качественного и количественного анализа; согласованные стратегии реагирования для каждого риска и действия, необходимые для активации стратегий реагирования; кто «владеет» теми или иными рисками и несет за них ответственность. Вот пример реестра рисков для проекта по внедрению единого решения автоматизации бизнес-процессов в сети гостиниц (рис. 14). Контроль рисков У каждого риска должен быть человек, который за него отвечает. Это может быть любой член команды. Задача ответственного лица — наблюдать за триггерами, то есть событиями, которые могут спровоцировать наступление риска, отслеживать их приближение и убеждаться, что мероприятия по реагированию на риск выполняются. Задача руководителя — следить, чтобы процессы управления рисками работали. Выводы Управление рисками хорошо начинать во время создания иерархической структуры или сразу после того, как она готова. Когда у вас перед глазами есть список дел по проекту, вам гораздо легче идентифицировать риски, связанные с работами проекта. Работа с рисками помогает уточнить содержание проекта. Это как следующий уровень проработки дел проекта. От каких-то очень рискованных дел можно отказаться. Для надежного выполнения других работ что-то понадобится добавить. В случае, если мы принимаем стратегию снижения для рисков, направленная на доведение риска до приемлемого уровня работа должна быть включена в иерархическую структуру работ проекта, оценена и внесена в расписание проекта. Управление рисками — это не разовый, а повторяющийся процесс. Как часто вы будете его повторять, зависит от текущего состояния проекта, его новизны для команды и уровня лояльности к рискам в компании.

Важно отметить, что в случае использования стратегии снижения вы сами определяете, какие работы необходимы для снижения риска. Как и другие работы, они должны быть включены в ИСР проекта. Принятие риска (Accept). Принятие риска может быть активным и пассивным. При пассивном мы просто констатируем: «Да, риск есть, но делать мы с этим ничего не будем». Даже если избрана такая тактика, то менеджер все равно обязан предупредить о риске все заинтересованные стороны. Активное принятие подразумевает закладывание в бюджет резерва на случай возникновения риска. Например, если сломалось какое-то оборудование, то должны быть деньги на покупку или аренду нового. Рекомендуется закладывать резерв в размере рейтинга риска в деньгах. Например, риск того, что ноутбук разработчика выйдет из строя, составляет 20%, стоимость 2000 единиц, количество ноутбуков 5. Значит, в резерве на этот риск, согласно формуле 0,2 × 2000, должно быть заложено 400 единиц на сотрудника. На всех сотрудников понадобится резерв в 2000 единиц. Риски — это «известное неизвестное», так как мы их выявили и подготовились к ним. Существует еще такое понятие, как «неизвестное неизвестное» — непредвиденные обстоятельства. Как правило, менеджер и команда даже представить себе их не могут, не говоря уже о том, чтобы оценить вероятность возникновения. Как правило, на такие события в каждом проекте предусмотрен управленческий резерв. Его величина обычно достигает 10% от бюджета проекта.

Итак, представим, что у нас уже есть список рисков и мы знаем, как они могут сказаться на проекте. Теперь нужно определиться с тем, как на них реагировать. Существует пять стратегий реагирования. Эскалация (Escalation). Руководитель проекта эскалирует риск на следующий уровень менеджмента — руководителя программы или портфеля проектов. Эскалировать риск нужно в том случае, если команда или спонсор проекта понимает, что работать с риском на уровне проекта нет возможности. Вы не просто должны сообщить о риске вышестоящему руководителю, но и убедиться, что он принял на себя владение этим риском. После эскалации команда проекта не ведет мониторинг риска, хотя эта угроза может быть внесена в реестр рисков для информации. Уклонение (Avoid). В этом случае за рамки проекта выводятся те работы, которые содержат этот риск, — их не делают вообще. Таким образом, риски просто исчезают. Рассмотрим эту стратегию на примере. При обсуждении устава проекта с заказчиком менеджер понимает, что один из компонентов поставки нереально сделать к сроку, на котором настаивает заказчик. У него два варианта действий: взять на себя этот риск и попытаться с ним работать; предложить вынести этот компонент поставки за рамки данного проекта. Важно понимать, что при исключении рисков из проекта исключаются и возможности, с которыми риски ходят рука об руку. Передача (Transfer). Риск можно передать, например, субподрядчику. Допустим, у менеджера есть сомнения в том, что его команда справится с частью работы, но он знает, что есть компания, которая обладает для этого достаточным уровнем квалификации. В этом случае можно передать сложную работу ей. Важно помнить, что при этом менеджер все равно несет ответственность за результат работы перед заказчиком. На субподрядчика она не перекладывается. Снижение (Mitigate). Вероятность наступления риска можно попытаться снизить. Например, менеджер видит, что ключевой сотрудник (пусть это будет архитектор) уже несколько раз приходил на работу в костюме, а в течение дня куда-то отпрашивался. Скорее всего, он ищет новую работу и посещает интервью. Оценим вероятность этого риска в 40%. Если он все же уйдет, то на поиск и адаптацию нового специалиста уйдет время, а это могут быть потери, например, в 35 000 единиц. Можно попытаться снизить вероятность этого риска — например, пообещав архитектору премию за успешное завершение проекта. И вот уже вероятность его ухода падает с 40% до 10%, так как теперь он мотивирован довести проект до конца. Если такой вариант не подходит, то можно нанять человека, который будет учиться у архитектора и станет его бэкапом — сможет подменять его на время отсутствия или отпуска. Это будет немного дороже, но если архитектор уйдет, то менеджер серьезно сократит время на поиск и адаптацию нового сотрудника, так как в его распоряжении уже будет человек, который в курсе всех дел.

Оцифровываем вероятность. Для получения исходных данных можно воспользоваться информацией, которую собирает любая бухгалтерия — табель учета рабочего времени. Так можно получить данные о том, кто, когда и как долго болел. Собрав информацию о болезнях в команде за последние три года, мы можем определить, в какие периоды люди болеют чаще, соотнести это с периодом работы над проектом и взять среднее значение за основу. В примере выше это был период с декабря по март, и вероятность составила 50%. 2. Оцифровываем влияние. В качестве влияния берем недельную нетрудоспособность сотрудника, которая может привести или к смещению даты сдачи проекта, или к сверхурочным работам для оставшихся членов команды с трудоемкостью 40 человеко-часов. Предположим, что ставка за час сверхурочной работы составляет 10 единиц. Таким образом, оцифрованное влияние будет вычисляться так: 40 человеко-часов × 10 единиц = 400 единиц. 3. Вычисляем рейтинг риска в деньгах. Для этого берем вероятность наступления риска, которая в нашем случае равна 50%, или 0,5, и умножаем на влияние, которое для данного случая равняется 400 единицам. Получаем денежный эквивалент рейтинга риска в 200 единиц. Количественный анализ требует предварительной подготовки данных, что может быть крайне трудоемко. Поэтому рекомендуется проводить его только для самых значимых рисков.

На этом этапе оцифровывается вероятность наступления рисков и их влияние на проект. Вероятность оценивается в процентах, а влияние — в деньгах. Рассмотрим все шаги оцифровки на примере отсутствующего из-за болезни сотрудника.