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

Петр Дикий

Автор простым языком объясняет, что такое управление проектом, как выстроить весь процесс «с нуля», взаимодействовать с командой, клиентами, как держать все под контролем и многое другое, полезное и интересное.Книга заставляет задуматься и начать действовать, отринув все сомнения и страхи, так как в ней предлагаются конкретные и проверенные на личном опыте методы, позволяющие руководителю и команде реализовать свои задачи с максимальной эффективностью.

Глава 1. Управление проектами

1.1. Что такое проект?

Согласно официальной терминологии:

— Первое определение утверждает, что проект — предприятие с определенными датами начала и завершения, предпринятое для создания продукта или услуги (сервиса) в соответствии с заданными ресурсами и требованиями (ISO/IEC/IEEE 15288:2008 Systems and software engineering — System life cycle processes).

— Еще одно определение данного понятия из свода знаний PMBOK утверждает, что проект (в управленческой деятельности) — временное предприятие, направленное на создание уникального продукта, услуги или результата.

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

Конечные цели проекта и операционной деятельности отличаются. Задачи проекта — достижение поставленных целей, после достижения которых проект завершается. Операционная деятельность обычно служит для обеспечения стабильной работы бизнеса, операции получают новые цели и продолжают выполняться.

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

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

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

— Проект имеет четкие функциональные рамки.

— Проект может потребовать использования рискованных решений.

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

— Для проекта может потребоваться уникальное расположение места реализации.

— Проект имеет ограниченные временные рамки. После завершения не продолжается.

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

1.2. Почему управление проектами?

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

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

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

Далее собрал в список основные причины распространения проектного управления:

1. Сокращение жизненного цикла товаров.

2. Усиление конкуренции.

3. Рост неопределенности внешней среды.

4. Стремительное развитие технологий.

5. Возросшие требования потребителей.

6. Сокращение расходов.

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

1.3. Проектная команда и ее варианты

Как мы помним, проект — это деятельность, значит управление проектом это управление теми, кто ведет эту деятельность, если упрощенно излагать суть.

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

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

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

Далее хочу привести наиболее интересные варианты команды (без учета специалистов внутри команд):

— Вариант 1. Проектная команда только из штатных (in-house) сотрудников;

— Вариант 2. Проектная команда из штатных сотрудников, включая распределенных по разным офисам и/или удаленный штат (работающие из дома);

— Вариант 3. Проектная команда из группы штатных + команда аутстаффер;

— Вариант 4. Проектная команда из группы штатных + команда/-ы на аутсорсе (им передают части, а приемку осуществляют внутренние специалисты).

Варианты 1 и 2 понятные и пояснять их не буду. А вот варианты 3 и 4 более интересные, потому что, когда есть потребности/проекты, подключаешь дополнительные ресурсы, а когда нет их, то просто не подключаешь и нет затрат на них.

Вариант 3 подразумевает, что выделенные ресурсы управляются так же, как и внутренние ресурсы, только при необходимости, точнее за отсутствием необходимости, распускаются. Вариант 4 не менее интересный — в нем вы говорите, что нужно сделать и получаете результат в срок, без дополнительных затрат.

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

Далее хочу рассказать вам немного о составе команд, которые я чаще всего встречал в работе и которые являются самыми популярными. Начнем с того, что роли в команде могут существенно различаться. Состав команд будет зависеть от многих факторов, например, размера компании, типа проекта, того, создаете что-то с нуля или дорабатываете.

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

1. Состав «Упрощенный»

— Руководитель проекта.

— Программисты (FronEnd/BackEnd или Fullstack/Mobile).

— Дизайнер.

— Аккаунт-менеджер.

2. Состав «Классический»

— Руководитель проекта.

— Технический лидер.

— Программисты (FronEnd/BackEnd/Fullstack/Mobile).

— Дизайнер.

— Аккаунт-менеджер.

— Аналитик.

3. Состав «Классический +»

— Руководитель проекта.

— Технический лидер (иногда добавляют системного архитектора или один совмещает две роли).

— Программисты (FronEnd/BackEnd/Fullstack/Mobile).

— Дизайнер.

— Специалист по продажам.

— Аналитик.

— Специалист внедрения и сопровождения.

— Поддержка.

4. Состав «Расширенный»

— Руководитель отдела разработки или Технический директор.

— Руководитель проекта (часто в таком составе РП находится в подчинении руководителя отдела или CTO).

— Системный архитектор.

— Тимлид/-ы.

— Программисты (FronEnd/BackEnd/Fullstack/Mobile).

— Дизайнер/-ы и/или Дизайнеры UI/UX.

— Специалист/-ы по продажам.

— Аналитик/-и.

— DevOps-инженер/-ы (не всегда).

— Контент-менеджер/-ы.

— Специалист/-ы внедрения и сопровождения.

— Поддержка.

Замечу:

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

1.4. Руководитель проекта. Кто такой? Какие у него обязанности?

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

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

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

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

1. Снижение стоимости и сокращение сроков создания новых продуктов (включая и внутренние цели, например, внедрение новой IT-системы).

2. Повышение качества новых продуктов (результатов) и эффективности.

3. Повышение прозрачности процесса создания новых продуктов.

4. Минимизация отклонения по срокам.

5. Повышение удовлетворенности владельцев, инвесторов, повышение мотивации персонала.

6. Усиление конкурентной позиции компании.

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

1.5. Четыре этапа управления проектом

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

Вообще, в жизненном цикле проекта выделяют пять этапов управления проектом:

— инициация;

— планирование;

— исполнение (выполнение);

— мониторинг;

— закрытие (завершение).

Вы явно зададите вопросы — «Как пять?!», «Разве в названии не четыре указано?!». И будете правы, но ошибки тут нет, я рассматриваю исполнение и мониторинг, как неразрывно связанные процессы одного этапа — «Исполнение». Данное взаимодействие я изобразил на рисунке 1. Приведу пример, поясняющий суть мысли. Невозможно приготовить сложное блюдо, всего лишь один раз взглянув на рецепт. Вы постоянно будете заглядывать в него и сверяться, в какой последовательности и какие ингредиенты добавлять, сколько готовить, какая температура должна быть и так далее.

Вы будете очень внимательны во время приготовления, чтобы получилось указанное в рецепте блюдо. Получается это будет проектом, блюдо — это продукт, а контроль времени приготовления, объема ингредиентов, последовательности добавления будут составляющими этапа «Мониторинг», который невозможно отделить от приготовления — «Исполнения». Работа над любым другим проектом идет примерно также. Конечно, это упрощенный пример, в проектной деятельности руководителю проектов придется контролировать как минимум:

— Соблюдение сроков.

— Чтобы команда делала только то, что положено, не хватаясь за лишние работы.

— Чтобы расходы оставались в рамках бюджета.

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

Уточню:

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

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

Сложив все эти преимущества, вы получите главное — команда сможет быстрее выполнить успешный проект и не выйти за рамки бюджета.

Рисунок 1 — Этапы управления проектом

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

1.5.1 Этап «Инициация»

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

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

По-хорошему, основным результатом этого этапа является более подробный документ — устав проекта, который содержит:

— Требования, удовлетворяющие потребности, пожелания и ожидания заказчика, спонсора и других заинтересованных сторон проекта.

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

— Цели (по сути, это обоснование проекта).

— Сведения о руководителе проекта, проектной команде (включая роли и обязанности).

— Данные по клиенту, представители клиента и контактные данные.

— Основные этапы проекта.

— Риски и возможные проблемы.

— Список заинтересованных сторон и их участие в проекте.

— Функциональные подразделения организации и их участие в проекте (если есть деление).

— Ограничения, накладываемые организацией, окружением и внешней средой.

— Обоснование проекта, включая бизнес обоснование и данные о ROI (Return on Investment).

— Суммарный бюджет проекта.

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

Данный этап является важнейшим, так как на нем собираются все данные по будущему проекту. Молодые специалисты часто не уделяют ему достаточно внимания и не прорабатывают. Бывает, что и люди с большим опытом часто не делают качественную проработку устава.

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

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

Основная цель формы обзора проекта — получить одобрение заказчика, чтобы перейти к следующему этапу.

1.5.2. Этап «Планирование»

Основная цель этого этапа — составить детальный план действий.

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

К данному плану стоит относится, как к дорожной карте. Он определит масштаб проекта и в нем должны быть перечислены все этапы, чтобы можно было отслеживать любые движения и изменения. План также должен включать информацию о каждой фазе проекта и задачах (без технической или углубленной детализации), над которыми команда будет работать на протяжении всего жизненного цикла проекта. План должен показывать, какие члены команды отвечают за какие задачи, и установить предварительные (максимальные, с учетом возможных проблем, проверок и корректировок) сроки выполнения каждой задачи при первой итерации работы с документом. Далее, в плане должен появиться подробный график проекта от начала до конца. То есть, план может начинаться с нескольких функциональных блоков в начале этапа планирования, но к концу этого этапа он должен превратиться в подробный план, поскольку информация начинает поступать с появлением вопросов при уточнении и детализации плана. Задачей руководителя проекта является ежедневная работа с планом и сравнение его с фактическим статусом задач проектной команды. Для этого удобно использовать одну из систем отслеживания задач, например Jira, Redmine и подобные.

Основной план будет включать в себя несколько подпланов, отражающих конкретные аспекты проекта:

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

— праздники,

— отпуски,

— возможные отгулы,

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

— риски (например, задержки у клиента в предоставлении обратной связи),

— занятость на проектах (задействованы на других проектах и на сколько).

Конечно, этот список можно продолжать еще, но я выбрал самое основное и важное. У вас может появится вопрос — зачем так много сложностей? Нет, это не сложности, так только кажется из-за того, что нужно собирать много данных и прорабатывать их. Но это один из важнейших пунктов, данные на выходе которого будут помогать на протяжении всего проекта. Попытаюсь перечислить, что зависит от этого плана:

— прибыль компании от проекта,

— успех проекта (люди работают над проектом),

— своевременный найм сотрудников (а это работа HR),

— подготовка рабочего места (а это работа поддержки),

— эффективность работы компании.

— Финансовый план. Этот план основывается на ресурсном плане и служит для детализации суммы денежных средств, которая потребуется для реализации проекта. Основная цель финансового плана — обеспечить основу для сравнения общего бюджета проекта и его фактической стоимости (сколько потратили на реализацию). Давайте рассмотрим основные пункты финансового плана:

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

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

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

— Транспортные расходы. В этом пункте учтите стоимость доставки материалов к вам, выезды ваших специалистов к клиенту (а это может быть дорого и не один раз, если клиент в другом городе). Определите с какими службами доставки вы будете работать, включите ли вы стоимость доставки в стоимость проекта или же заказчик будет оплачивать ее отдельно. В моей практике были случаи доставки курьерскими службами документов, образцов техники (терминалов), образцов продукции (от пищевой до бытовых средств), поверьте, это было дорого.

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

Не забудьте обсудить с заказчиком его ожидания. Объясните ему, что создание дизайна самого продукта не является фирменным стилем, что его создание является отдельным проектом и на его основе можно будет сделать дизайн ИТ или другого продукта. Уточните, хочет ли клиент индивидуальный дизайн или достаточно использовать что-то готовое, шаблонное (часто клиент не задумывается или имеет свои мысли на этот счет). Это тот минимум, который необходим на старте каждого проекта. Многие руководители проектов не учитывают эти траты при планировании, а зря, они могут составить значительную сумму и время. Подобные расходы возможно просчитать на старте и на ближайший период достаточно точно, далее скорректировать и предупредить об этом клиента. Обязательно нужно заложить 5—10% от общих затрат на непредвиденные расходы. Далеко не всегда все идет по плану, и лучше, если вы будете к этому подготовлены не только морально, но и финансово. Исходя из своего опыта скажу, что дизайн проектов, фирменный стиль, отбор фотографий согласовывается не сразу, то есть это длительный процесс отбора и обсуждений у 80% заказчиков. Не забудьте, что существует такой тип работ, как «Фотосъемки», который стоит прорабатывать и обсуждать отдельно от общей сметы.

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

— План рисков. Данный план содержит все риски, связанные с проектом. Разбейте их по категориям, а затем по приоритетам, так будет удобнее. Это поможет команде в определении того, какие риски наиболее вероятны и важны, позволив более эффективно распределить время или принять решение об устранении проблемы. В этом плане стоит изложить влияние каждого риска на проект, если не свести к минимуму или не устранить. Группа управления проектом или сам руководитель проекта использует план рисков для разработки и реализации превентивных мер, составления планов действий в чрезвычайных ситуациях и отслеживания каждого риска на протяжении всего срока реализации проекта. План рисков является важным шагом в процессе планирования, так как он может значительно снизить вероятность неудач.

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

Правильно будет к данному плану завести документ «Сопроводительное письмо». Используйте его, когда формируете промежуточные сборки для показа клиенту. В файле указывайте списком, что вы планируете показывать и, что может проверять клиент. Напротив каждой задачи стоит оставить поле для комментариев — принята/не принята, замечания для устранения. И не забывайте получить подпись заказчика. Мы все люди, что-то забывается, а согласованный документ напомнит и подтвердит согласованное. Да, это может показаться избыточным — заводить файл, в нем список сдаваемого функционала, подпись клиента и так далее, но вам все равно нужно взаимодействовать с клиентом, а если отправлять через почту, то письмо может потеряться по разным причинам. Если проект мелкий и показов немного, то можно, конечно, коммуницировать через почту. Сопроводительное письмо можно так же использовать на момент сдачи проекта, в нем указать состояние проекта, требуются ли дополнительные работы или нет.

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

— План закупок определяет, каким образом группа будет получать ресурсы от внешних поставщиков. Идеальный план закупок должен содержать список всех необходимые ресурсов для закупки. В нем также следует указать, когда и каким образом будут выделены средства для получения этих ресурсов. Группы могут использовать план закупок для изучения необходимых задач и способов эффективного приобретения ресурсов. Этот план не менее важно согласовать с клиентом, чтобы не возникало спорных ситуаций наподобие «Мы думали вы это купите и уже включили в стоимость проекта».

Уточнение:

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

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

— ТЗ определяет и уточняет тип работ, тип поставщика, ресурсы (необходимые команде), график сроков и копию условий оплаты.

— Далее идет документ запроса информации (RFI). Этот документ помогает команде определить потребности.

— После запроса информации запрашивают документ с предложениями (RFP), он поможет команде выбрать лучшего поставщика, опираясь на конкретные предложения.

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

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

Заключительным блоком работ этапа планирования является еще один обзор проекта. В данном блоке работ в форме обзора проекта следует указать:

— планируется ли завершить проект в срок;

— соответствует ли он бюджету на сегодняшний день;

— устранены или нет какие-либо существующие препятствия и риски.

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

Более детально планирование будет рассмотрено во второй главе данной книги.

1.5.3. Этап «Исполнение»

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

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

1.5.3.1. Тайм-менеджмент

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

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

1.5.3.2. Управление затратами

Это процесс управления всеми расходами, связанными с проектом. Еще управление затратами это:

— Знание, когда, где и в каких объемах расходуются средства компании/проекта.

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

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

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

— обязательства,

— бюджетные затраты,

— фактические затраты.

1.5.3.3. Обязательства

Это плановые, будущие затраты, которые возникают при заключении договоров, контрактов, заказе каких-либо товаров или услуг. Обычно это происходит заранее согласно плану проекта.

1.5.3.4. Бюджетные затраты

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

1.5.3.5. Фактические затраты

Это отчет, содержащий информацию о фактических расходах проекта. При этом они могут произойти:

— Во время выполнения работ проекта.

— В момент выплаты денежных средств.

— В момент списания денежных средств со счета.

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

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

Вы можете спросить: «А как тогда это все оценить и учесть в стоимости проекта?». Давайте поймем, что нужно для прогнозирования и учета:

— Собрать реальную информацию о стоимости технических и/или программных средств, которые вы планируете использовать в проекте и которые нужно приобрести.

— Собрать объективные данные по стоимости разработки (включая продолжительность), ФОТ, налоги и прочие внутренние расходы компании на разработку проекта.

— Зафиксировать способ финансовых расчетов с заказчиком, поставщиками и субподрядчиками.

— Согласовать и подписать ТЗ с заказчиком.

— Установить, нужны ли выезды к клиенту, какая продолжительность и частота (включая выезды на внедрение и показы). К моменту запуска проекта вам будет приблизительно понятен портрет клиента и его сложность, вы сможете спрогнозировать стоимость данного пункта.

— Установить, нужно ли разовое привлечение сторонних специалистов и их стоимость.

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

1.5.3.6. Управление качеством

Качество проекта (Project Quality) — это совокупность характеристик продукта, относящихся к его способности удовлетворять установленные или предполагаемые потребности.

Управление качеством проекта (Project Quality Management) — одна из основных функций проектной команды и руководителя проектов. Представляет собой процесс управления и улучшения качества продукта для удовлетворения потребностей и требований, ради которых проект был запущен. Процесс управления качеством может помочь команде в определении целей в области качества, определить потенциальные риски и препятствия, которые могут привести к плохому качеству, если их не решить.

Замечу:

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

2. Оценка должна строиться на данных, которые будут собираться во время аудита. Аудит (audit) — системное исследование, проводимое для определения, насколько эта деятельность эффективна и приведет ли она к запланированным целям, то есть — к результату.

Процесс управления качеством следует разделить на три этапа:

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

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

1. Основание проведения аудита (цель) и объем проверки (границы).

2. Мероприятия по улучшению.

3. Список замечаний, несоответствий (включая их источники) и претензий.

4. Способы разрешения спорных вопросов и конфликтов.

5. Выводы и рекомендации (анализ опыта и извлеченные уроки), включая сводную оценку качества результатов проекта.

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

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

В любом случае каждую запись о проблеме нужно оформить правильно. Такую запись обычно называют «Баг-репорт» (Bug Report), в каждой компании свои стандарты оформления репортов, но в любом случае они должны позволить вам:

1. Зафиксировать и описать путь воспроизведения проблемы, описать саму ошибку/проблему, приложить изображения проблемы (если нужно и возможно).

2. Воспроизвести проблему (это не всегда возможно, но необходимо стремиться).

3. Установить ее важность (определить приоритет проблемы).

4. Понять в чем проблема и устранить.

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

1.5.3.7. Управление изменениями

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

Изменения — изменение утвержденного ранее содержания, сроков, ресурсов, а также установленных процедур из-за воздействия разных объективных или субъективных факторов при разработке и реализации проекта. Изменения могут вноситься в различные части и на любом этапе жизненного цикла проекта. Инициатором изменений может выступать любой участник проекта, чаще всего это:

— заказчик (может влиять на конечные характеристики проекта);

— аналитик/архитектор/руководитель проекта в зависимости от структуры компании исполнителя (может влиять на первоначальную документацию);

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

Основные причины возможных изменений в проекте:

— случайности в проектных решениях;

— непродуманные решения;

— совершенствование средств, методов, материалов;

— отставание от графика;

— изменение цен (работы, материалы).

А виды изменений обычно разделяют на:

— Внутренние. Зависят от параметров самого проекта (сроков, поставок, графиков, финансирования и прочего).

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

Замечу:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Замечу:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Замечу:

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

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

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

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

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

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

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

Замечу:

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

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

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

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

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

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

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

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

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

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

Конец ознакомительного фрагмента.