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

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. Описание содержания проекта. Какие основные разделы должно содержать описание?

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

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

Описание продукта или результата.

Критерии приёмки.

Результаты поставки.

Исключения из проекта.

Ограничения.

Допущения.

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

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

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

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

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

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

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

По фазам проекта.

По результатам или продуктам.

По функциональным областям.

Комбинированный подход.

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

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

Инициация.

Анализ требований.

Настройка системы.

Миграция данных.

Обучение пользователей.

Приёмка и запуск.

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

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

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

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

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

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

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

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

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

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

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

Планирование управления расписанием.

Определение состава операций.

Определение взаимосвязей операций.

Оценка ресурсов операций.

Оценка длительности операций.

Разработка расписания.

Контроль расписания.

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

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

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

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

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

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

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

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

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

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

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

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

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

Экспертная оценка.

Оценка по аналогам.

Количественная / параметрическая оценка.

PERT / трёхточечная оценка.

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

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

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

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

O — оптимистическая;

M — наиболее вероятная;

P — пессимистическая.

Формула PERT:

(O + 4M + P) / 6

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

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

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

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

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

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

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

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

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

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

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

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

Пересмотр зависимостей.

Уменьшение содержания.

Замена технологии.

Повышение производительности.

Перераспределение ресурсов.

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

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

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

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

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

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

Оценка по аналогам / сверху вниз — сравнение с похожими проектами; быстрее и дешевле, но менее точна.

Оценка снизу вверх — оценка отдельных работ и суммирование; точнее, но дороже и требует детальной ИСР.

Параметрическая оценка — использование статистической зависимости между параметрами и стоимостью. Например: стоимость переустановки ОС на 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. Основные принципы управления качеством

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

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

Предотвращение вместо устранения — дешевле предупредить дефект, чем исправлять его после контроля.

Ответственность руководства — руководство должно выделять ресурсы для достижения качества.

Непрерывное улучшение — команда постоянно улучшает процессы и продукт.

Взаимовыгодное партнёрство с поставщиками — устойчивые отношения с поставщиками снижают риски качества и сроков.

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

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

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

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

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

Аудиты качества.

Анализ процессов.

Проверка соблюдения стандартов.

Рекомендации по улучшению.

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

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

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

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

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

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

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

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

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

Набор команды проекта — привлечение людей, необходимых для выполнения проекта; назначение конкретных исполнителей на проектные роли.

Развитие команды проекта — повышение эффективности участников команды и укрепление взаимодействия между ними.

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

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

роль — какую работу выполняет участник;

ответственность — за какую часть проекта он отвечает;

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

квалификация — какие навыки нужны для выполнения роли.

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

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

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

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

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

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

Опыт работы: имеют ли эти люди опыт такой или подобной работы и каковы их прошлые успехи. Например, не менее 3 лет в качестве Java-разработчика.

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

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

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

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

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

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

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

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

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

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

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

Базовые факторы (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)
Изменение «размера» благоприятной возможности путём увеличения вероятности её возникновения и позитивного воздействия.