# Вопросы к зачёту

### 1. Что такое проект? Операционная деятельность и проекты. Признаки успешного проекта.

**Проект** — временная деятельность для создания уникального результата.
Главное: есть **начало, конец, цель и уникальный результат**.

**Операционная деятельность** — постоянная, повторяющаяся работа для поддержания бизнеса.

**Проект** — временная, уникальная работа для достижения конкретной цели.

**Успешный проект** завершён:
* в срок;
* в рамках бюджета;
* с нужным содержанием;
* заказчик доволен.

### 2. Что такое "управление проектами"? Связь управления проекта с другими областями менеджмента. Ограничения проекта.

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

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

**Связь с другими областями менеджмента:**

Для управления проектами нужны знания:

* общего менеджмента: планирование, контроль, мотивация, организация;
* экспертной области проекта;
* стандартов и нормативов;
* коммуникаций и работы с людьми.

**Ограничения проекта:**

Главные ограничения:
* **содержание** — что нужно сделать;
* **сроки** — за какое время;
* **стоимость** — какой бюджет.

### 3. Основные участники проекта.

* **Руководитель проекта** — управляет проектом и отвечает за его выполнение.
* **Спонсор / куратор** — обеспечивает проект ресурсами и поддержкой.
* **Заказчик** — принимает результат и оплачивает работу.
* **Пользователь** — использует результат проекта.
* **Команда проекта** — выполняет работы по проекту.
* **Команда управления проектом** — помогает управлять проектом.
* **Исполняющая организация** — организация, чьи сотрудники выполняют проект.
* **Проектный офис** — координирует управление проектами.

### 4. Фазы проекта. Модели жизненного цикла проектов. Закономерности жизненного цикла проекта.

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

**Модели жизненного цикла проекта:**

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

**Закономерности жизненного цикла:**

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

### 5. Группы процессов управления проектами. Цикл Деминга (PDCA). Области знаний по управлению проектами.

**Группы процессов управления проектами:**

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

**Цикл Деминга (PDCA):**

* **Plan** — планируй.
* **Do** — выполняй.
* **Check** — проверяй результат.
* **Act** — улучшай и корректируй.

**Области знаний по управлению проектами:**

// TODO

### 6. Организационное окружение проекта (структуры организаций).

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

**Основные структуры организаций:**

* **Функциональная** — сотрудники работают по отделам. Руководитель проекта слабый или отсутствует.
* **Проектная** — команда создаётся под конкретный проект. Руководитель проекта имеет большие полномочия.
* **Матричная** — сочетание функциональной и проектной структуры.

**Виды матрицы:**

* **Слабая матрица** — больше власти у функционального руководителя.
* **Сбалансированная матрица** — полномочия проектного и функционального руководителя примерно равны.
* **Сильная матрица** — больше власти у руководителя проекта.

**Другие структуры:**

* простая / органичная;
* мультидивизионная;
* виртуальная;
* гибридная;
* офис управления проектами.

Главное: **структура организации определяет, насколько легко управлять проектом и получать ресурсы**.

### 7. Устав проекта (содержание). Формирование целей с использованием "фильтров целей".

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

**Содержание устава проекта:**

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

**Цели проекта** должны проходить через «фильтры целей».

**SMART:**

* **S** — конкретные;
* **M** — измеримые;
* **A** — достижимые;
* **R** — ориентированные на результат;
* **T** — ограниченные по времени.

**PURE:**

* позитивно сформулированные;
* понятные;
* релевантные ситуации;
* этичные.

**CLEAR:**

* содержат вызов;
* законные;
* не вредят окружению;
* уместные;
* записанные.

### 8. План управления проектом.

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

Он объединяет планы по разным областям проекта и базовые планы по:

* срокам;
* стоимости;
* содержанию.

**Что может включать план:**

* выбранные процессы управления проектом;
* методы и инструменты управления;
* жизненный цикл проекта;
* порядок выполнения работ;
* мониторинг и контроль изменений;
* управление коммуникациями;
* поддержание актуальности базовых планов.

**Важно:** план должен соответствовать масштабу проекта.
Для маленького проекта не нужен слишком подробный план.

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

### 9. Метод набегающей волны.

**Метод набегающей волны** — способ планирования, когда:

* ближайшие работы планируются **подробно**;
* дальние этапы планируются **укрупнённо**;
* по мере продвижения проекта план постепенно уточняется.

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

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

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

### 10. Руководство и управление работами проекта. За какие работы отвечает руководитель проекта?

**Руководство и управление работами проекта** — процесс, в котором выполняется план проекта и создаются результаты проекта.

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

**Руководитель проекта отвечает за:**

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

### 11. Мониторинг и контроль над работами проекта. Что включает в себя мониторинг и контроль?

**Мониторинг и контроль над работами проекта** — это постоянное наблюдение и анализ выполнения проекта, чтобы понять, идёт ли он по плану.

**Что включает мониторинг и контроль:**

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

Главное: **мониторинг помогает вовремя заметить проблемы и скорректировать проект**.

### 12. Общее управление изменениями. Утверждение изменений.

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

Проекты редко идут точно по плану, поэтому изменения нужно контролировать.

**Как происходит управление изменениями:**

* замечается отклонение или появляется новое требование;
* оценивается влияние изменения на проект;
* оформляется **запрос на изменение**;
* запрос рассматривается и утверждается или отклоняется;
* утверждённые изменения вносятся в документы и планы проекта.

**Что оценивают при изменениях:**

* содержание;
* качество;
* сроки;
* бюджет;
* ресурсы;
* риски.

**Утверждение изменений:**

Изменения могут утверждать:

* руководитель проекта;
* спонсор проекта;
* заказчик;
* управляющий комитет.

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

> Любое изменение должно быть согласовано и отражено в документах проекта


### 13. Управление знаниями проектов.

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

**Зачем нужно:**

* не повторять старые ошибки;
* использовать лучшие практики;
* быстрее решать похожие задачи;
* сохранять опыт команды для будущих проектов.

**Что включает:**

* документирование накопленных знаний;
* хранение проектной информации;
* обмен знаниями между участниками;
* распространение полезного опыта.

**Примеры инструментов:**

* база знаний проекта;
* карта знаний проекта;
* сообщества практиков;
* конференции и встречи;
* внутренние порталы, трекеры, сетевые диски;
* мессенджеры, почта, документация.

**Факторы, влияющие на управление знаниями:**

* культура доверия и обучения;
* географическое распределение команды;
* наличие экспертов по знаниям;
* требования конфиденциальности.

### 14. Что такое "Содержание проекта"? Перечислить процессы управления содержанием проекта.

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

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

**Процессы управления содержанием:**

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

# Управление проектами — вопросы 15–29 для подготовки к зачёту

## Тема 3. Управление содержанием проекта

### 15. Сбор требований. Что может являться источником требований?

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

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

**Инструменты сбора требований:** интервью, опросы, наблюдение, анализ документов, воркшопы, прототипирование, уточняющие вопросы.

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

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

---

### 16. Описание содержания проекта. Какие основные разделы должно содержать описание?

**Описание содержания проекта** — подробное описание проекта, его результатов и границ.

Обычно включает:

1. Описание продукта или результата.
2. Критерии приёмки.
3. Результаты поставки.
4. Исключения из проекта.
5. Ограничения.
6. Допущения.

Также может включать высокоуровневые требования, границы ответственности, ключевые этапы и связи с ИСР.

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

**Что сказать на зачёте:** особенно важны исключения: они защищают проект от лишних ожиданий.

---

### 17. Иерархическая структура работ. Создание ИСР, подходы к созданию. Привести пример

**ИСР / WBS** — иерархическая декомпозиция полного содержания работ проекта на более мелкие управляемые компоненты.

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

**Подходы к созданию ИСР:**

1. По фазам проекта.
2. По результатам или продуктам.
3. По функциональным областям.
4. Комбинированный подход.

**Правило 100%:** ИСР должна включать все работы проекта и не включать лишние работы.

**Пример для внедрения системы:**

1. Инициация.
2. Анализ требований.
3. Настройка системы.
4. Миграция данных.
5. Обучение пользователей.
6. Приёмка и запуск.

**Что сказать на зачёте:** ИСР описывает работы, а не оргструктуру команды.

---

### 18. Подтверждение содержания проекта. Контроль содержания проекта

**Подтверждение содержания** — формальная приёмка завершённых результатов проекта заказчиком или уполномоченной стороной.

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

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

Главная задача контроля — не допустить неконтролируемого расширения содержания, то есть **scope creep**.

**Что сказать на зачёте:** подтверждение = принимаем результат; контроль = управляем изменениями содержания.

---

## Тема 4. Управление расписанием проекта

### 19. Основные процессы управления сроками

**Цель управления сроками** — обеспечить выполнение проекта в заранее запланированное время.

**Основные процессы управления сроками:**

1. Планирование управления расписанием.
2. Определение состава операций.
3. Определение взаимосвязей операций.
4. Оценка ресурсов операций.
5. Оценка длительности операций.
6. Разработка расписания.
7. Контроль расписания.

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

Базовое расписание используется для сравнения плана и факта.

**Что сказать на зачёте:** расписание строится на основе ИСР и списка операций.

---

### 20. Виды взаимосвязей между операциями. Опережения и задержки. Привести примеры

**Финиш — Старт:** последующая работа не может начаться до завершения предыдущей.  
Пример: установка пользовательского ПО после установки операционной системы.

**Финиш — Финиш:** последующая работа не может закончиться раньше завершения предыдущей.  
Пример: тестирование завершается после исправления ошибок.

**Старт — Старт:** последующая работа начинается не раньше начала предыдущей.  
Пример: резервное копирование начинается с вводом данных.

**Старт — Финиш:** последующая работа не может закончиться, пока не началась предыдущая.  
Пример: опытная эксплуатация продолжается до начала промышленной эксплуатации.

**Опережение** — последующая работа стартует до полного окончания предыдущей.

**Задержка / лаг** — пауза между зависимыми работами, например ожидание 28 дней после заливки фундамента.

**Что сказать на зачёте:** самая частая связь — Финиш — Старт.

---

### 21. Методы оценки длительности операций. Оценка PERT

**Методы оценки длительности:**

1. Экспертная оценка.
2. Оценка по аналогам.
3. Количественная / параметрическая оценка.
4. PERT / трёхточечная оценка.

**Экспертная оценка** опирается на знания специалистов. Метод Дельфи — вариант экспертной оценки с итерациями и анонимными оценками.

**Оценка по аналогам** использует данные похожих прошлых работ или проектов.

**Количественная оценка** рассчитывает длительность через объём работ и производительность ресурсов.

**PERT** использует три оценки:

- `O` — оптимистическая;
- `M` — наиболее вероятная;
- `P` — пессимистическая.

**Формула PERT:**

```text
(O + 4M + P) / 6
```

**Что сказать на зачёте:** PERT ближе к наиболее вероятной оценке, но учитывает риски.

---

### 22. Что такое критический путь проекта?

**Критический путь** — самая длинная цепочка связанных задач проекта, определяющая минимальную длительность проекта.

Задачи на критическом пути не имеют общего резерва времени: их задержка сдвигает дату окончания проекта.

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

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

Менеджер проекта должен особенно внимательно контролировать задачи на критическом пути.

**Что сказать на зачёте:** критический путь — не обязательно самые важные задачи, а задачи без временного запаса.

---

### 23. Методы сокращения расписания работ проекта

**Сжатие расписания / Crashing** — привлечение дополнительных ресурсов к работам на критическом пути. Обычно увеличивает стоимость.

**Быстрый проход / Fast Tracking** — параллельное выполнение работ, которые изначально планировались последовательно. Обычно увеличивает риски и возможные переделки.

Дополнительно могут использоваться:

1. Пересмотр зависимостей.
2. Уменьшение содержания.
3. Замена технологии.
4. Повышение производительности.
5. Перераспределение ресурсов.

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

**Что сказать на зачёте:** Crashing = дороже; Fast Tracking = рискованнее.

---

## Тема 5. Управление стоимостью проекта

### 24. Методы и средства стоимостной оценки

**Стоимостная оценка** — определение примерной стоимости ресурсов, необходимых для выполнения операций проекта.

**Основные методы:**

1. **Оценка по аналогам / сверху вниз** — сравнение с похожими проектами; быстрее и дешевле, но менее точна.
2. **Оценка снизу вверх** — оценка отдельных работ и суммирование; точнее, но дороже и требует детальной ИСР.
3. **Параметрическая оценка** — использование статистической зависимости между параметрами и стоимостью. Например: стоимость переустановки ОС на 1 компьютер × число компьютеров.

Также применяются анализ предложений поставщиков, экспертные оценки, анализ резервов и программные средства управления проектами.

**Что сказать на зачёте:** точность оценок растёт по мере уточнения проекта.

---

### 25. Анализ освоенного объёма. Основные показатели метода освоенного объёма

**Метод освоенного объёма** объединяет анализ содержания, сроков и стоимости, чтобы понять фактический прогресс проекта.

**Основные показатели:**

- `PV` — плановая стоимость запланированных работ.
- `EV` — освоенный объём, то есть бюджетная стоимость фактически выполненных работ.
- `AC` — фактическая стоимость выполненных работ.
- `CV = EV − AC` — отклонение по стоимости.
- `SV = EV − PV` — отклонение по срокам.
- `CPI = EV / AC` — индекс выполнения стоимости.
- `SPI = EV / PV` — индекс выполнения сроков.
- `BAC` — бюджет по завершении.
- `EAC` — прогнозная стоимость по завершении.
- `ETC` — оценка оставшихся затрат.
- `VAC = BAC − EAC` — отклонение по завершении.

**Что сказать на зачёте:** EV показывает не сколько потратили, а сколько «заработали» выполненной работой по плановой стоимости.

---

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

### 26. Качество проекта. Качество и сорт. Качество продукта проекта и качество управления проекта

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

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

Низкий сорт не всегда проблема, низкое качество — проблема.

**Качество продукта** — соответствие результата требованиям пользователя и спецификациям.

**Качество управления проектом** — качество процессов управления: планирование, коммуникации, контроль, работа команды.

Плохое управление качеством продукта или процесса может привести к неудаче проекта.

**Что сказать на зачёте:** высокий сорт ≠ высокое качество; низкий сорт ≠ дефект.

---

### 27. Основные принципы управления качеством

**Основные принципы управления качеством:**

1. **Удовлетворение заказчика** — нужно понимать реальные потребности, а не только формальные спецификации.
2. **Предотвращение вместо устранения** — дешевле предупредить дефект, чем исправлять его после контроля.
3. **Ответственность руководства** — руководство должно выделять ресурсы для достижения качества.
4. **Непрерывное улучшение** — команда постоянно улучшает процессы и продукт.
5. **Взаимовыгодное партнёрство с поставщиками** — устойчивые отношения с поставщиками снижают риски качества и сроков.

**Что сказать на зачёте:** качество создаётся всей командой, а не только тестировщиком.

---

### 28. Процесс обеспечения качества проекта

**Обеспечение качества** — плановая и регулярная оценка исполнения проекта, чтобы подтвердить соответствие выбранным стандартам и процессам.

Оно фокусируется не только на результате, но и на процессах, с помощью которых результат создаётся.

**Инструменты обеспечения качества:**

1. Аудиты качества.
2. Анализ процессов.
3. Проверка соблюдения стандартов.
4. Рекомендации по улучшению.

**Отличие от контроля качества:** обеспечение качества проверяет процессы, контроль качества проверяет конкретные результаты и дефекты.

Цель — повысить уверенность, что проект способен стабильно дать нужное качество.

**Что сказать на зачёте:** QA — про процесс; QC — про результат.

---

## Тема 7. Управление человеческими ресурсами / ресурсами проекта

### 29. Основные процессы управления ресурсами проекта

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

**Команда проекта** — люди, которым назначены роли при исполнении проекта. **Команда управления проектом** — часть команды проекта, отвечающая за управленческие процессы: планирование, контроль, принятие решений, координацию.

**Основные процессы управления человеческими ресурсами по PMBOK:**

1. **Планирование человеческих ресурсов** — определение и документирование ролей, ответственности, подчинённости и требований к персоналу. Результаты: план управления персоналом, организационная структура проекта, распределённые роли и ответственность.
2. **Набор команды проекта** — привлечение людей, необходимых для выполнения проекта; назначение конкретных исполнителей на проектные роли.
3. **Развитие команды проекта** — повышение эффективности участников команды и укрепление взаимодействия между ними.
4. **Управление командой проекта** — контроль эффективности членов команды, обратная связь, решение проблем и координация изменений, связанных с персоналом.

**Что включает распределение ролей и ответственности:**

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

**Инструменты:** организационная структура проекта, матрица ответственности, план управления обеспечением проекта персоналом.

**Что сказать на зачёте:** управление ресурсами — это не только «назначить людей», а спланировать роли, привлечь команду, развить её и управлять её работой на протяжении проекта.

### 30. Что необходимо учитывать при наборе команды проекта? Методы набора команды проекта

Набор членов команды проекта осуществляется из всех доступных источников, как внутренних, так и внешних. В процессе подбора персонала участвует команда управления проектом, в первую очередь, руководитель проекта. 
При подборе персонала следует учитывать: 
- Доступность: будут ли данное лицо или группа доступны в те периоды времени, когда потребуется их участие в проекте. Например, будет ли человек в отпуске или не успеет освободиться от работы над другим проектом 
- Способности: какая у этих людей квалификация. Например, разработчик программного обеспечения должен владеть Java, Spring, Maven. 
- Опыт работы: имеют ли эти люди опыт такой или подобной работы и каковы их прошлые успехи. Например, не менее 3 лет в качестве Java-разработчика.
- Заинтересованность: интересно ли людям работать над данным проектом. Прежде чем пригласить сотрудника на проект, с ним проводят собеседование, на котором рассказывают особенности проекта. Прежде чем взять человека на проект, всегда интересуются, будет ли ему интересно работать над этим проектом. Если сотрудник не заинтересован в проекте, то он будет работать над этим проектом неэффективно 
- Стоимость: сколько надо будет платить каждому члену команды и каким образом это отразится на бюджете проекта. Например, мы готовы тратить на разработчика не более 1700 рублей в час.

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

### 31. Мотивация команды проекта: иерархия Маслоу и теория Герцберга

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

Одна из самых распространённых теорий мотивации — **теория Маслоу**.

Теория Маслоу предполагает, что существует пять уровней потребностей. При этом человека начинают интересовать потребности более высокого уровня только после полного удовлетворения потребностей предыдущих уровней.

[![Иерархия потребностей Маслоу](https://notes.fedmog1lnkv.su/uploads/images/gallery/2026-05/scaled-1680-/image-1779807598045.jpg)](https://notes.fedmog1lnkv.su/uploads/images/gallery/2026-05/image-1779807598045.jpg)

---

**Теория Герцберга** — ещё одна популярная теория мотивации.

Герцберг разделяет все факторы, влияющие на людей, на две группы:

- **Базовые факторы** (*hygiene factors*)
- **Мотивирующие факторы**

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

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

#### Базовые факторы

- рабочие условия;
- зарплата;
- личная жизнь;
- отношения на работе;
- безопасность;
- статус.

#### Мотивирующие факторы

- ответственность;
- полномочия;
- самореализация;
- профессиональный рост;
- признание.

---

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

В то же время, если снизить зарплату до **95 000 руб.**, человек, скорее всего, будет работать хуже.

### 32. Стадии развития команды проекта (модель Такмана)

Процесс развития команды проекта включает **6 стадий**:

- **Формирование** (*forming*)  
  Команда ещё не сложилась и является рабочей группой индивидуумов, стремящихся достичь собственных целей.

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

- **Возмущение** (*storming*)  
  На этой стадии возникают конфликты. Причинами конфликтов могут быть разногласия по вопросам распределения ролей, нагрузки, ответственности, планирования работ, приоритетов и т. д.

- **Стабилизация** (*norming*)  
  На этой стадии группа начинает работать как единая команда. Группа принимает единые **«правила игры»** и соглашается с распределением ролей и разделением ответственности, принципами принятия решений и процедурами.

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

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

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

Уровень эффективности команды соответствует стадии её развития.

### 33. Конфликты и способы их разрешения. Методы предотвращения

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

Конфликты часто помогают найти оптимальное для проекта решение.

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

- **Решение проблемы** — «Давайте выясним причину и постараемся её устранить» (**лучший способ**)
- **Нахождение компромиссов** — «Давайте найдём золотую середину»
- **Откладывание решения** — «Давайте решим это через неделю»
- **Сглаживание** — «Остыньте и делайте каждый свою работу»
- **Принуждение** — «Делай, как я сказал!» (**худший способ**)

Причины конфликтов:

- сроки проекта;
- приоритеты проекта;
- ресурсы;
- технические решения;
- административные процедуры;
- стоимость;
- личные мотивы.

Вероятность возникновения конфликтов в команде можно снизить, если:

- информировать команду проекта о:
  - тенденциях в развитии проекта;
  - первоочередных задачах проекта;
  - принятых ключевых решениях;
  - произошедших изменениях;
- чётко назначать ответственных за каждую задачу;
- давать интересные и стимулирующие задачи.

### 34. Распространение информации. Коммуникативные сети

**Распространение информации** — это своевременное предоставление необходимой информации участникам проекта.

Для распространения информации используются разные формы коммуникации:

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

Для сбора и передачи данных используются:

- бумажные документы;
- телефоны;
- электронная почта;
- видеоконференции;
- специализированное программное обеспечение.

Коммуникативные сети можно рассматривать как направление распространения информации.

- **Цепь**  
  Данный способ организации коммуникаций характеризуется большими искажениями информации и задержками в скорости её передачи.

  Для передачи информации, особенно большому количеству людей, гораздо лучше подходит сеть типа **«звезда»**.

- **Кольцо**  
  В этой сети информация, поступившая от одного участника к другому, передаётся также третьему участнику для осуществления контроля.

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

- **Звезда**  
  В этой сети информация доносится до большинства участников в одинаковом формате и виде.

  В этой модели искажения информации минимальны.

- **Паутина**  
  Паутина — это пример неконтролируемых коммуникаций.

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

Критерии оценки коммуникативных сетей:

- надёжность;
- скорость передачи информации;
- коэффициент искажения или потерь информации;
- неравенство;
- характер связи элементов.

### 35. Основные процессы управления рисками

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

Стандарт **PMBOK®** выделяет **6 основных процессов управления рисками**:

- **Планирование управления рисками**  
  На этом этапе вырабатывается и фиксируется единый для всей команды подход к управлению рисками.

  Определяются:

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

- **Идентификация рисков**  
  Цель процесса — выявить риски, которые могут повлиять на проект, и задокументировать их характеристики.

  В результате появляется **реестр рисков**, в который включаются:

  - риски;
  - их величина;
  - владельцы рисков;
  - меры реагирования.

  Идентификация рисков производится периодически в течение проекта.

- **Качественный анализ рисков**  
  На этом этапе выполняется расстановка приоритетов рисков.

  Реестр рисков дополняется данными анализа для будущего количественного анализа.

  Основные параметры анализа:

  - вероятность риска;
  - воздействие риска.

  Качественный анализ выполняется на этапе планирования проекта и повторяется с некоторой периодичностью.

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

  В ходе количественного анализа:

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

- **Планирование реагирования на риски**  
  На этом этапе определяются меры, которые нужно предпринять для:

  - увеличения вероятности и воздействия на проект положительных рисков;
  - снижения вероятности и воздействия на проект отрицательных рисков.

  Реестр рисков дополняется информацией о том, как именно реагировать на риски. Для каждого риска назначается ответственное лицо.

- **Мониторинг и контроль над рисками**  
  Этот процесс включает:

  - наблюдение за существующими рисками;
  - выявление новых рисков;
  - контроль выполнения плана реагирования на риски.

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

### 36. Методы идентификации рисков

Идентификация рисков выполняется всей командой проекта, желательно с привлечением экспертов.

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

- **Метод мозгового штурма**  
  Быстрое и свободное высказывание идей без их немедленного обсуждения.

- **Метод номинальной группы**  
  Каждый участник выражает свои идеи в письменном виде, после чего они выносятся на обсуждение.

- **SWOT-анализ**  
  Анализ сильных и слабых сторон, возможностей и угроз.

  Этот метод позволяет получить более полное представление о рисках проекта.

- **Опросы**  
  Проведение опросов среди опытных сотрудников.

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


### 37. Стратегии реагирования на риски

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

- стратегии для негативных рисков, то есть угроз проекту;
- стратегии для позитивных рисков и потенциальных возможностей.

**Стратегии для негативных рисков:**

- **Уклонение от риска** (*avoidance*)  
  Изменение плана управления проектом для того, чтобы исключить риск или устранить его влияние на цели и результаты проекта.

  Пример: можно сократить содержание проекта.

- **Передача риска** (*transference*)  
  Перенос последствий риска на третью сторону.

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

  Пример: страхование основных средств, покупка опционов.

- **Снижение риска** (*mitigation*)  
  Принятие предупредительных мер по снижению вероятности наступления риска или его последствий до приемлемого уровня.

  Пример: выбор зарекомендовавшего себя поставщика.

- **Принятие риска** (*acceptance*)  
  Стратегия, которая применяется, когда исключить риски из проекта маловероятно.

  Эта стратегия может быть:

  - **пассивной** — не предполагает каких-либо действий;
  - **активной** — предполагает создание резерва на непредвиденные обстоятельства.

**Стратегии для позитивных рисков и потенциальных возможностей:**

- **Использование риска** (*exploit*)  
  Устранение неизвестности, связанной с риском, для того чтобы данная благоприятная возможность гарантированно проявилась.

  Пример: привлечение лучших ресурсов для сокращения длительности проекта.

- **Разделение риска** (*share*)  
  Частичная или полная передача риска третьей стороне, способной использовать его к наибольшей выгоде проекта.

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

- **Увеличение риска** (*enhance*)  
  Изменение «размера» благоприятной возможности путём увеличения вероятности её возникновения и позитивного воздействия.