Проектный менеджер: вопросы на собеседовании

При возникновении regulatory проблемы в середине проекта важно действовать системно и оперативно:

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

Вовлечение экспертов: Привлечь юридический отдел, compliance-специалистов или внешних консультантов для точного понимания требований.

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

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

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

Документирование: Зафиксировать все изменения и решения для последующего аудита и отчетности.

Мониторинг: Следить за выполнением новых требований и возможными дополнительными изменениями в регуляторной среде.

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

Cumulative Flow Diagram (CFD) — это визуальный инструмент для отслеживания прогресса работы в проекте, часто используемый в Agile и Kanban.

На диаграмме отображаются накопительные количества задач в разных состояниях (например, "To Do", "In Progress", "Done") по времени. Это позволяет видеть, как меняется количество задач на каждом этапе, выявлять узкие места и оценивать стабильность процесса.

Преимущества CFD:

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

Позволяет оценить скорость выполнения работы.

Визуализирует баланс между этапами процесса.

Пример: если область "In Progress" растет, это может означать, что задачи задерживаются на этом этапе и нужно оптимизировать процесс.

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

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

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

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

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

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

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

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

Анализ рисков: понять, как срыв повлияет на общий график и бюджет.

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

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

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

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

Milestone (веха) — это важная контрольная точка в проекте, которая отмечает достижение ключевого этапа или цели.

Зачем нужен milestone:

Помогает отслеживать прогресс проекта и своевременно выявлять отклонения.

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

Позволяет планировать ресурсы и время более эффективно.

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

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

Scope baseline — это зафиксированная и утверждённая версия описания объёма работ проекта, которая служит основой для контроля и управления изменениями.

Она обычно состоит из трёх основных компонентов:

Требования к продукту (Product Scope) — описание функций, характеристик и качества конечного продукта.

Требования к работам (Project Scope) — перечень всех работ, необходимых для создания продукта.

Рабочий пакет (Work Breakdown Structure, WBS) — иерархическая декомпозиция объёма работ на управляемые части.

Scope baseline помогает контролировать изменения в объёме проекта и служит эталоном для оценки прогресса и управления рисками.

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

Типы PMO:

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

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

Директивный PMO (Directive PMO) — непосредственно управляет проектами, назначает менеджеров проектов и несет ответственность за результаты.

Выбор типа PMO зависит от зрелости организации и её потребностей в управлении проектами.

Решение о переписывании системы вместо доработки требует тщательного анализа. Важно оценить следующие аспекты:

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

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

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

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

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

Рекомендуется провести:

Анализ затрат и выгод (Cost-Benefit Analysis)

Оценку технического долга и качества кода

Прототипирование или пилотный проект

Консультации с командой и заинтересованными сторонами

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

Переход со Scrum на Kanban требует оценки нескольких условий:

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

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

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

Визуализация и ограничение WIP (Work In Progress). Команда должна быть готова внедрить доску Kanban с ограничениями на количество одновременно выполняемых задач.

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

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

Жизненный цикл проекта обычно включает следующие основные фазы:

Инициация — определение целей, обоснование проекта, назначение руководителя.

Планирование — разработка плана работ, ресурсов, сроков и бюджета.

Исполнение — реализация запланированных задач и контроль выполнения.

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

Завершение — сдача результатов, оценка итогов и закрытие проекта.

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

WBS (Work Breakdown Structure) — это иерархическая декомпозиция всего объема работ проекта на более мелкие, управляемые части. Она нужна для того, чтобы структурировать и четко определить все задачи и подзадачи, необходимые для успешного завершения проекта. Это помогает лучше планировать, распределять ресурсы, оценивать сроки и контролировать выполнение работ.

IRR (Internal Rate of Return, внутренняя норма доходности) — это ставка дисконтирования, при которой чистая приведённая стоимость (NPV) проекта равна нулю. Проще говоря, IRR показывает ожидаемую доходность инвестиции в проект. Если IRR выше стоимости капитала, проект считается выгодным.

Payback period (срок окупаемости) — это время, необходимое для возврата первоначальных инвестиций за счёт чистых денежных потоков проекта. Этот показатель помогает оценить, за какой период проект «отобьёт» вложенные средства.

Пример:

Инвестиции: 100 000 руб.

Годовые доходы: 30 000 руб.

Срок окупаемости = 100 000 / 30 000 ≈ 3,33 года.

IRR рассчитывается сложнее и требует анализа всех денежных потоков с учётом времени.

Если stakeholder требует фичу, которая ломает архитектуру, важно действовать так:

Понять требования и мотивацию — выяснить, зачем нужна эта фича и какие задачи она решает.

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

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

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

Принять совместное решение — обсудить с командой и стейкхолдерами компромисс или план рефакторинга.

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

При смене спонсора проекта важно сохранить первоначальное видение (vision) для обеспечения стабильности и успешного завершения проекта. Для этого можно:

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

Документировать vision в виде четкого и доступного артефакта (например, в проектной документации или roadmap).

Обеспечить вовлечение ключевых заинтересованных сторон для поддержки и подтверждения vision.

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

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

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

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

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

Feedback loops (циклы обратной связи) в Agile — это регулярные процессы получения и анализа отзывов от команды, заказчиков или пользователей для улучшения продукта и процессов разработки.

Основная цель таких циклов — быстро выявлять проблемы, адаптироваться к изменениям и повышать качество продукта. В Agile это реализуется через:

Ежедневные стендапы (Daily Scrum) — команда обсуждает прогресс и препятствия.

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

Ретроспективы (Sprint Retrospective) — анализ процесса и поиск улучшений.

Эти циклы позволяют гибко реагировать на изменения требований и повышать эффективность команды.

Project Manager (PM) и Scrum Master — разные роли с разными задачами, хотя обе связаны с управлением проектами.

Project Manager отвечает за общий успех проекта: планирование, управление ресурсами, бюджетом, сроками, рисками и коммуникацией с заказчиком. Его задача — обеспечить выполнение проекта в рамках требований и ограничений.

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

Проще говоря, PM управляет проектом сверху вниз, а Scrum Master — служит команде, помогая ей эффективно работать по Scrum.

Value Stream Mapping (VSM) — это метод визуализации и анализа всех шагов процесса создания продукта или услуги, от начала до конца, с целью выявления и устранения потерь и повышения эффективности.

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

Основные элементы VSM:

Карта текущего состояния процесса

Определение времени выполнения и ожидания на каждом шаге

Выявление неэффективных операций

Планирование улучшений и создание карты будущего состояния

Применение VSM способствует более прозрачному управлению и повышению качества продукта.

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

Например, если баг не выявлен на этапе юнит-тестирования или интеграционного тестирования, а обнаружен уже после релиза, это escaped defect. Метрика escaped defects помогает оценить эффективность процессов контроля качества и тестирования в проекте.

В PMBOK (Project Management Body of Knowledge) термины OPA и EEF относятся к факторам, влияющим на управление проектом:

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

EEF (Enterprise Environmental Factors) — это факторы внешней и внутренней среды предприятия, которые могут влиять на проект. К ним относятся культура организации, инфраструктура, рыночные условия, законодательство, политическая ситуация и другие внешние и внутренние условия.

Пример:

OPA: шаблоны отчетов, стандарты качества, уроки из прошлых проектов.

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

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

PMI (Project Management Institute) — это международная организация, которая занимается развитием стандартов и практик управления проектами. Она выпускает различные стандарты, включая PMBOK (Project Management Body of Knowledge), который описывает лучшие практики в управлении проектами.

Сертификация PMP (Project Management Professional) подтверждает, что специалист обладает знаниями и опытом в области управления проектами согласно стандартам PMI. Это повышает доверие работодателей и клиентов, улучшает карьерные перспективы и помогает применять проверенные методы для успешного завершения проектов.

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

Основные особенности:

Двойное подчинение сотрудников

Совместное использование ресурсов между проектами

Улучшенная коммуникация между отделами

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

Empathy (эмпатия) в работе Project Manager необходима для понимания чувств, потребностей и точек зрения команды, заказчиков и других заинтересованных сторон. Это помогает:

Улучшить коммуникацию и снизить конфликты.

Правильно оценивать мотивацию и состояние команды.

Принимать решения, учитывая интересы всех участников проекта.

Создавать доверительную атмосферу, что повышает продуктивность.

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

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

Принципы Lean включают:

Определение ценности с точки зрения клиента

Выявление и устранение потерь (муда)

Создание непрерывного потока работ

Внедрение системы вытягивания (pull system)

Постоянное совершенствование (кайдзен)

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

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

Выполнение сроков — насколько проект соответствует запланированному графику.

Бюджет — соблюдение финансовых ограничений.

Качество продукта — количество багов, удовлетворённость пользователей.

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

Риски — количество и серьёзность выявленных проблем.

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

Для Agile-проекта важны следующие метрики, которые помогают отслеживать прогресс и качество:

Velocity (скорость команды) — количество выполненных задач или story points за спринт.

Burn-down chart — график оставшейся работы по спринту или релизу.

Cycle Time — время от начала работы над задачей до её завершения.

Lead Time — время от запроса задачи до её завершения.

Cumulative Flow Diagram — показывает количество задач на разных этапах процесса.

Defect Density — количество дефектов на единицу функционала.

Team Satisfaction — опросы или индикаторы удовлетворённости команды.

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

Еженедельно обычно готовлю отчёты по статусу проекта, включающие:

Выполненные задачи и достигнутые цели

Текущий прогресс относительно плана

Выявленные риски и проблемы

Потребности команды и ресурсы

Ежемесячно делаю более детальный отчёт с анализом:

Ключевых метрик эффективности (KPI)

Отклонений от графика и бюджета

Итогов по качеству и тестированию

Планов на следующий месяц и корректировок стратегии

Такие отчёты помогают контролировать ход проекта и информировать заинтересованных лиц.

Правила декомпозиции WBS (Work Breakdown Structure) включают:

Иерархичность: Разбивка работы должна быть структурирована в виде иерархии, где каждый уровень детализирует работу предыдущего.

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

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

Управляемость: Каждый элемент должен быть достаточно мелким, чтобы его можно было планировать, контролировать и оценивать.

Определенность результата: Каждый элемент должен иметь четко определенный результат или продукт.

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

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

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

Withdraw (Уход/Избегание) — уклонение от конфликта, отказ от обсуждения проблемы. Подходит, если вопрос незначителен или нужно время, чтобы остыть.

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

Compromise (Компромисс) — поиск решения, при котором обе стороны уступают в чем-то. Быстрый способ найти приемлемый вариант, но не всегда оптимальный.

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

Пример: если в команде спорят о выборе технологии, forcing — руководитель просто выбирает, withdraw — никто не решает, smoothing — все соглашаются на что-то, чтобы не ссориться, compromise — выбирают средний вариант, collaborate — обсуждают и находят лучшее решение для всех.

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

Scrumban — это гибридная методология управления проектами, сочетающая элементы Scrum и Kanban. Она была разработана для того, чтобы объединить структурированность Scrum с гибкостью Kanban.

Основные характеристики Scrumban:

Использует итерации и роли из Scrum, но с более гибким подходом к планированию.

Визуализация работы с помощью Kanban-досок и ограничений на количество задач в работе (WIP limits).

Позволяет командам адаптироваться к изменяющимся требованиям без жестких спринтов.

Поддерживает непрерывное улучшение и оптимизацию процессов.

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

Основные практики Kanban включают:

Визуализация работы — создание доски Kanban с колонками, отражающими стадии процесса (например, «To Do», «In Progress», «Done»).

Ограничение количества задач в работе (WIP - Work In Progress) — лимитирование количества задач, которые могут одновременно находиться в каждой колонке, чтобы избежать перегрузки и повысить фокус.

Управление потоком — постоянное отслеживание и оптимизация скорости прохождения задач через процесс.

Ясные политики процесса — определение правил и критериев для перехода задач между колонками.

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

Постоянное улучшение (Kaizen) — непрерывное совершенствование процесса на основе данных и обратной связи.

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

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

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

Внедрить мониторинг и быстрый отклик на инциденты после релиза.

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

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

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

Инициация: бизнес-кейс, устав проекта, предварительный план, анализ заинтересованных сторон.

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

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

Мониторинг и контроль: отчёты о статусе, метрики качества, управление изменениями.

Завершение: итоговый отчёт, документация по проекту, передача продукта заказчику, уроки проекта.

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

Cycle time analysis — это метод анализа времени, которое требуется для завершения одной единицы работы в процессе разработки или производства. В контексте Kanban cycle time — это время от начала работы над задачей до её завершения.

Анализ cycle time помогает выявить узкие места в процессе, улучшить прогнозирование сроков и повысить эффективность команды. Например, если средний cycle time для задачи составляет 5 дней, а одна задача занимает 10 дней, это сигнал к тому, что процесс нужно оптимизировать.

В Kanban для анализа cycle time часто строят диаграммы распределения времени выполнения задач, что помогает визуализировать вариативность и выявить аномалии.

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

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

Основные отличия:

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

Уникальность: проект создаёт уникальный результат, операционная деятельность повторяется.

Цель: проект направлен на достижение конкретной цели или изменения, операционная деятельность — на поддержание текущих процессов.

Planned Value (PV) — это один из ключевых показателей в методологии управления проектами Earned Value Management (EVM). PV отражает запланированную стоимость работ, которые должны были быть выполнены к определённому моменту времени согласно плану проекта.

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

Например, если к середине проекта по плану должно быть выполнено 50% работ, а общий бюджет проекта — 100 000 рублей, то PV на этот момент будет 50 000 рублей.

PV используется для сравнения с фактическими показателями (Earned Value и Actual Cost) для оценки прогресса и эффективности выполнения проекта.

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

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

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

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

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

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

Главное — не игнорировать проблему и принимать решения на основе объективного анализа.

Техника Pomodoro — это метод управления временем, направленный на повышение концентрации и продуктивности.

Суть метода:

Работа разбивается на интервалы по 25 минут, называемые "помодоро".

После каждого помодоро следует короткий перерыв (обычно 5 минут).

После четырёх таких циклов делают более длинный перерыв (15-30 минут).

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

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

SV (Schedule Variance) и SPI (Schedule Performance Index) — ключевые показатели в методологии управления проектами по методу оценки выполнения работ (Earned Value Management, EVM).

Schedule Variance (SV) показывает отклонение по графику и рассчитывается как разница между выполненной стоимостью работ (Earned Value, EV) и запланированной стоимостью работ (Planned Value, PV):

SV = EV - PV

Если SV > 0 — проект опережает график, если SV < 0 — отстает.

Schedule Performance Index (SPI) — индекс производительности по графику, показывает эффективность использования времени:

SPI = EV / PV

Если SPI > 1 — проект идет быстрее запланированного, если SPI < 1 — медленнее.

Пример:

Если на текущий момент запланировано выполнить работ на сумму 100 тыс. руб. (PV), а фактически выполнено работ на 90 тыс. руб. (EV), то:

Actual Cost (AC) — это фактические затраты, понесённые на выполнение работы или проекта на определённый момент времени. В методологии управления проектами, основанной на оценке стоимости выполнения (Earned Value Management, EVM), AC отражает реальные денежные расходы, которые уже были сделаны.

Например, если на выполнение задачи было запланировано потратить 1000 долларов, а на текущий момент фактически потрачено 800 долларов, то AC равен 800. Это значение используется вместе с Planned Value (PV) и Earned Value (EV) для оценки эффективности и прогресса проекта.

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

Основные характеристики:

Итеративные циклы с регулярными релизами.

Активное вовлечение заказчика и заинтересованных сторон.

Гибкость в планировании и изменении требований.

Быстрая реакция на изменения внешних условий.

Примером adaptive lifecycle является Agile-методология, где команда постоянно адаптирует план и продукт под новые данные и обратную связь.

Такой подход особенно полезен в условиях высокой неопределенности и быстро меняющихся требований.

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

M (Must have) — обязательные требования, без которых продукт не может быть выпущен.

S (Should have) — важные требования, которые желательно реализовать, но продукт может работать и без них.

C (Could have) — желательные, но не критичные функции, которые можно добавить, если есть время и ресурсы.

W (Won't have this time) — требования, которые не будут реализованы в текущем цикле или релизе.

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

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

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

Такой подход помогает сохранить доверие и мотивацию сотрудников даже в сложные времена.

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

В PMBOK выделяют 10 областей знаний, которые охватывают ключевые аспекты управления проектами:

Управление интеграцией проекта (Project Integration Management)

Управление содержанием проекта (Project Scope Management)

Управление сроками проекта (Project Schedule Management)

Управление стоимостью проекта (Project Cost Management)

Управление качеством проекта (Project Quality Management)

Управление ресурсами проекта (Project Resource Management)

Управление коммуникациями проекта (Project Communications Management)

Управление рисками проекта (Project Risk Management)

Управление закупками проекта (Project Procurement Management)

Управление заинтересованными сторонами (Project Stakeholder Management)

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

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

Визуализация работы — использование доски Kanban с колонками, отражающими стадии процесса (например, "To Do", "In Progress", "Done"). Это помогает видеть статус задач и выявлять узкие места.

Ограничение незавершённой работы (WIP - Work In Progress) — лимит на количество задач, которые могут одновременно находиться в определённой стадии. Это снижает многозадачность и повышает фокус.

Управление потоком — постоянный мониторинг и оптимизация скорости прохождения задач через процесс.

Ясные правила процесса — определение критериев перехода задач между стадиями.

Использование обратной связи — регулярные встречи и анализ для улучшения процесса.

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

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

Процент выполнения задачи или проекта можно определить несколькими методами, часто применяемыми в управлении проектами и оценке Earned Value Management (EVM):

Метод «0/100» — задача считается либо не начатой (0%), либо полностью выполненной (100%). Промежуточные состояния не учитываются. Применяется для простых, коротких задач.

Метод «50/50» — при начале задачи сразу ставится 50%, а по завершении — 100%. Это упрощает оценку, учитывая, что половина работы уже сделана при старте.

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

Метод оценки по этапам или вехам — выполнение оценивается по завершению ключевых этапов проекта.

Использование метрик Earned Value (EV) — сравнение запланированной стоимости работы и фактически выполненной с учётом времени и бюджета.

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

В Lean выделяют 7 видов потерь (муда), которые снижают эффективность процессов:

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

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

Излишняя транспортировка — ненужные перемещения материалов или информации.

Избыточная обработка — выполнение лишних действий или операций.

Излишние запасы — накопление материалов или готовой продукции сверх потребности.

Лишние движения — ненужные движения работников, например, поиск инструментов.

Дефекты — производство брака и необходимость переделок.

Устранение этих потерь помогает повысить производительность и качество.

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

Для менеджера проектов эмоциональный интеллект важен, так как помогает:

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

Понимать мотивацию и настроения команды.

Эффективно разрешать конфликты.

Создавать позитивную рабочую атмосферу.

Развитие эмоционального интеллекта способствует улучшению коммуникации и повышению продуктивности команды.

Stage-gate process — это метод управления проектами и разработкой продуктов, который разбивает процесс на последовательные этапы (stages), разделённые контрольными точками (gates).

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

продолжать проект,

корректировать план,

или остановить работу.

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

Пример этапов:

Идея и концепция

Анализ и планирование

Разработка

Тестирование

Запуск

Каждый gate — это проверка готовности к переходу на следующий этап.

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

Облачное хранилище (например, Google Drive, OneDrive, корпоративные облака) с четкой структурой папок и правами доступа.

Системы управления документами (DMS), которые позволяют хранить, индексировать и быстро находить архивы.

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

Важно обеспечить:

Четкую маркировку и документацию архива.

Регулярное резервное копирование.

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

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

Trust building (построение доверия) в команде — это процесс создания атмосферы взаимного уважения, открытости и надежности между участниками. Это фундамент для эффективного сотрудничества и высокой производительности.

Основные аспекты trust building:

Честность и прозрачность: открытое общение о проблемах и успехах.

Выполнение обещаний: соблюдение договоренностей укрепляет доверие.

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

Обратная связь: конструктивная критика и признание достижений.

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

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

Ключевые моменты радикальной откровенности:

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

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

Баланс между поддержкой и вызовом — одновременно поддерживать и стимулировать развитие.

Пример: вместо того чтобы сказать "Ты всегда делаешь ошибки", можно сказать "Я заметил, что в последнем отчёте были ошибки, давай вместе посмотрим, как их избежать в будущем".

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

Основные шаги:

Фиксация изменений — зафиксировать новые требования письменно, желательно в виде Change Request.

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

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

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

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

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

Scope creep — это постепенное и неконтролируемое расширение объёма проекта за счёт добавления новых требований или задач без соответствующего изменения ресурсов и сроков.

Как с ним бороться:

Чётко определить и зафиксировать требования в начале проекта.

Использовать формальный процесс управления изменениями (change control), чтобы любые изменения проходили согласование.

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

Обучать команду и заказчика важности соблюдения согласованного объёма.

При необходимости пересматривать сроки и бюджет при добавлении новых задач.

Такой подход помогает избежать перерасхода ресурсов и срывов сроков.

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

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

OTOBOS — это аббревиатура, обозначающая ключевые параметры успешного управления проектом:

On Time — выполнение проекта в запланированные сроки.

On Budget — соблюдение бюджета, выделенного на проект.

On Scope — выполнение всех требований и задач, определённых в объёме проекта.

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