Управление проектами. Правильный путь для начинающих

скачать книгу бесплатно


– Внешние. Зависят от глобальных факторов, внешних для проекта (политика, право, экономика, технический прогресс и прочего) и независящих от проекта.

Замечу:

Внутренние и внешние изменения могут изменяться в очень большом диапазоне и все изменения в проекте в итоге влияют на «магический треугольник управления проектом». А значит в любом случае будут возникать дополнительные затраты, изменения сроков и качества работ.

Стратегия состоит из прогнозирования, планирования, осуществления, контроля и регулирования изменений.

Управление изменениями связано со всеми процессами и функциями в проекте, рассмотренными ранее. При реализации проект может подвергаться различным изменениям: область применения, время, стоимость, качество, риски, контракты и поставки, человеческие ресурсы, коммуникации, а также процессы управления проектом на всех фазах его жизненного цикла.

Давайте рассмотрим правильную процедуру управления изменениям в проекте.

Рисунок 2 – Правильная процедура управления изменениями

Опишу шаги на схеме:

– Запрос на изменение. Инициатор (не обязательно только заказчик) высказывает требование, выходящее за рамки проекта, и является изменением текущего функционала или добавлением нового. Не забывайте, что это только запрос, а не призыв к действию, который нужно сразу исполнять.

– Запись в реестре изменений. Все запросы на изменение нужно занести в специальный документ «Реестр заявок на изменение» (или просто «Реестр изменений»). В нем нужно зафиксировать запрос, дату поступления, состояние заявки, статус, сроки реализации, комментарий и поле для подписи клиента (при наличии физического контакта с запросившим изменение).

– Анализ изменения. На этом этапе нужно понять, как предлагаемое изменение может повлиять на проект. Также на этом этапе проводится оценка последствий, что будет, если принять изменение или отказаться, как повлияет на стоимость и время разработки.

– Обсуждение с заказчиком. Часто одна из сторон настаивает на внесении изменения в проект, а другая противится этому по разным причинам. Поэтому нужно провести обсуждение, в результате которого прийти к обоюдному решению о реализации или отклонению изменения. Не забудьте получить подтверждение в устной форме и письменно с указанием того, что согласовываете. Напомню, это стоит делать как в самом начале (перед началом работ), так и в процессе работы, при получении изменений.

Приведу пример из жизни:

На проектах, которые я делал, заказчики часто присылали в процессе работы какие-то замечания, «хотелки», мелкие доработки и переделки. Это может быть как изменение цвета элемента или изменение положения, так и дополнительный макет страницы, которая из простой становится адаптивной. Я начинал считать и показывать заказчикам, что это требует дополнительного времени (да, по Agile я мог добавить это), а значит будут дополнительные расходы. Они, в свою очередь, начинали долгие разговоры/переписки и не всегда в спокойном тоне, что их не так поняли, что мы сделали не то, договаривались о другом, что были устные договоренности и так далее. Были случаи, когда выходили на моих руководителей (владельцев бизнеса) и жаловались им. Зная, что такое может быть, в начале работы в компании и перед запуском проектов я общаюсь с руководством и доношу свою позицию – все договоренности должны быть зафиксированы и согласованы заказчиком хотя бы в письме. Это давало возможность устранить конфликты внутри компании (часто верят больше заказчикам), иметь четкую позицию в переговорах с аргументами в виде согласованных материалов, а значит прийти к согласию с заказчиками на выгодных условиях. Если этого не учитывать и не делать, то для исполнителей, то есть для меня и команды, это станет большой проблемой и финансовыми потерями для компании.

– Решение. По результатам обсуждения предлагаемого изменения должно быть принято одно из пяти решений:

1. Одобрить. Принять в работу и произвести предлагаемое изменение.

2. Отклонить. Признать нецелесообразным отдавать в работу.

3. Отложить. Запрос на изменение имеет смысл, однако временно будет отложен и рассмотрен позднее.

4. Доработать. Запрос на изменение имеет смысл, но нужно или что-то продумать лучше, произвести дополнительную оценку и анализ последствий.

5. Эскалировать. Запрос на изменение имеет смысл, но оценивать и принимать решение могут только вышестоящие специалисты.

– Отложено. Если задачу отложили (на этапе «Решение»), она попадает в блок/статус «Отложено» это временное состояние, из него задача попадает на обсуждение с заказчиком. Почему именно на обсуждение, все просто, все данные по задаче есть, нужно только понять, будем делать и когда, если нет и задача нужна, повторно отклоняем. Вечно отклонять не стоит, это будет говорит, что она не нужна, введите число отклонений, среднее число три раза (статистика из практики), после чего задача закрывается с пометкой – «Не будет реализовано».

– Корректировка плана. На этом этапе нужно внести корректировки в план работ, так как задача принята и на ее реализацию нужно время. Если задача небольшая и запаса времени достаточно, чтобы реализовать без перерасчета сроков, то добавляем в план, или если задача большая и нет возможности реализовать без изменений графика, то планируем работы на ближайший этап. Если нужна реализация в ближайшей сборке, то нужно определить вместо какой задачи поставить обсуждаемую.

– Реализация. Изменение внесено в план и является частью проекта. Работать нужно с ним, как с обычной задачей в плане проекта. Дальше идет реализация.

– Проверка результатов. После реализации задачу проверяет руководитель проекта, соответствует ли реализованное поставленной задаче и нет ли проблем в работе. Если есть проблемы, то проектная команда исправляет, а руководитель проекта повторно проверяет.

– Сдача заказчику. Осталось сдать задачу заказчику и получить подтверждение, что она реализована и принята. Не забудьте получить от заказчика подтверждение в виде подписи в документе «Сопроводительное письмо» или, если проект маленький, то хотя бы в виде письма, что задача принята.

Если задачи приняты, то работы по реализации изменений считаются завершенными, а задачи закрываются.

Давайте посмотрим схему работы с изменениями, по которой работает большое количество компаний.

Рисунок 3 – Некорректная процедура управления изменениями

Из схемы видно, что изменение приняли без проверки его влияния на текущий функционал, цену и время работы. Это однозначно ухудшит и/или разрушит проект со стороны архитектуры и кода, приводя к увеличению его стоимости или вообще к закрытию.

Замечу:

– Встречаются компании, где нет даже третьего шага.

– Со временем запросов на изменение может стать большинство от общего объема задач, если не будет надлежащей организации и управления изменениями. Внедрение управления изменениями может помочь проектной команде увидеть все запросы на изменения и измерить целесообразность каждого из них.

Руководитель проекта после получения одобрения изменений должен обновить проектную документацию, проинформировать всех заинтересованных участников проекта, а также продумать способы реализации изменений.

Эта стратегия управления также дает возможность непрерывно контролировать и отслеживать состояния системы с учетом сделанных изменений. На практике это будет похоже на сравнение фактических изменений с плановыми. Особое внимание руководитель проектов должен уделять влиянию внесенных изменений на сроки проекта, использование ресурсов и стоимости проекта.

Не забывайте, что без надлежащего контроля вносимых изменений со стороны руководителя проектов объем проекта может легко отклониться от утвержденного, что негативно скажется на проекте и в результате на продукте.

1.5.3.8. Управление рисками

Риски влияют на все основные ограничения проекта. Следовательно, управление рисками – это процесс управления всеми значимыми параметрами проекта для повышения качества его исполнения и достижения конечных целей. Этот процесс включает в себя подпроцессы сбора, контроля и урегулирования всех рисков, связанных с проектом. Процессом управляет руководитель проекта. А вот чтобы определить и собрать риски, нужно понимать, какие есть признаки риска.

Анализ различных определений риска позволил выявить следующие признаки:

1. Вероятная опасность – опасность, с которой возможно столкнуться в будущем. Сильнее всего может влиять на сложные продукты так, что это приведет к ухудшению или невозможности их функционирования и/или развития.

2. Субъективность – риск всегда субъективен, поскольку без субъекта, который знает, что такое несчастье, что можно считать злом, что таковым не является, откуда исходит вред, представления о риске невозможны. Таким образом, риск – понятие, присущее человеку. Оно исходит из его ценностей, способностей и возможностей.

3. Действие – любое действие может привести к возникновению риска, поэтому он всегда связан с действием. Если нет действий, то нет и рисков.

4. Прогностический характер – возможность осуществить прогнозирование последствий от деятельности, связанной с рисками.

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

6. Возможности – деятельность по достижению цели направлена на использование существующих возможностей.

Теперь мы знаем признаки рисков, собрали их, двигаемся далее. Процесс управления рисками помогает руководителю проекта различать наиболее важные риски и менее важные, что позволяет легко расставлять приоритеты. Каждый риск детально анализируется и оценивается по важности от наиболее до наименее критического. Этот процесс облегчает определение того, какие риски требуют наибольшего внимания в первую очередь.

Вообще, в любом проекте могут появляться риски, причем они бывают как позитивные (возможности), так и негативные (угрозы). Далее затрону тему планирования реагирования на позитивные (возможности) и негативные (угрозы) риски. Под «Планированием реагирования на риски и возможности» понимается процесс разработки путей и действий по увеличению возможностей и снижению угроз на пути достижения целей проекта. Данный процесс начинается после выявления рисков, проведения качественного и количественного их анализа, а реагирование на них происходит согласно установленным приоритетам. При выявлении потребности в дополнительных ресурсах и действиях для устранения рисков их добавляют в планы управления стоимостью, расписанием и проектом.

Замечу:

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

Ранее я говорил про реагирование на риски, но не уточнял, какие бывают способы/стратегии. Так как руководителю проектов в работе придется определять, как нужно реагировать на риски, как выбрать наиболее подходящий вариант для вас, компании и проекта, то, думаю, стоит рассказать о них детальнее с разбивкой на две группы – «Стратегии реагирования на риски и угрозы» и «Стратегии реагирования на позитивные риски».

Стратегии реагирования на риски и угрозы:

– Уклонение. Уклонение от рисков предполагает изменение плана управления проектом или технического задания таким образом, чтобы исключить угрозы, вызванные негативными рисками, оградить цели проекта от последствий рисков или ослабить цели, находящиеся под угрозой (например, расширить рамки расписания или уменьшить объем проекта за счет урезания функционала или упрощения).

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

– Снижение. Предполагает понижение вероятности наступления и/или минимизации последствий негативных событий до приемлемых пределов. Предупредительные меры по снижению вероятности наступления рисков и их последствий часто оказываются намного эффективнее, чем применение усилий по устранению негативных последствий, после наступления событий. В качестве примеров мероприятий по снижению рисков можно привести внедрение менее сложных процессов, увеличение числа испытаний, выбор более надежных поставщиков, проработка более подробных технических заданий (с обязательным согласованием и подписанием со стороны заказчика). Сильно уменьшить риски поможет разработка прототипов, на основе которых заказчик сможет принять решение о правильности пути создания продукта, правильности течения проекта и необходимости корректировки документации.

Если невозможно снизить вероятность наступления рисков, то усилия должны быть направлены на устранение последствий рисков.

Замечу:

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

Стратегии реагирования на позитивные риски:

– Использование. Подходит для реагирования на риски с позитивным воздействием. К числу мер реагирования на данную возможность относятся, например, привлечение к участию в проекте более опытных и талантливых специалистов с тем, чтобы уменьшить время, необходимое для его завершения и повышения качества конечного продукта.

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

1. Партнерство с совместной ответственностью за риски.

2. Образование (привлечение) специализированных компаний или совместных предприятий, созданных, в том числе и для управления благоприятными возможностями.

– Усиление. Суть этой стратегии в повышении вероятности возникновения положительного воздействия (за счет выявления и максимизации основных источников). Для повышения данной вероятности нужно работать с причинами (укреплять, облегчать течение), вызывающими благоприятную возможность, и целенаправленно усиливать условия ее появления (возможно также повлиять и на сами источники воздействия).

Исходя из написанного можно сделать вывод – если руководитель проекта не работает с позитивными рисками, то он упускает возможности и, как результат, теряет время и деньги.

Отдельно идут еще две стратегии:

– Общая стратегия принятия рисков. Стратегия, при которой риски принимаются. Руководитель проекта и проектная команда не пытаются повлиять на риски. Часто применяется для ситуаций, где возможности воздействия ограничены и влияние рисков несущественно.