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