PMI PMP: Руководство командой и управление ресурсами — Руководство по подготовке

By Laurynas Brazys · 22 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

Часть PMP — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов PMI, или пройдите тесты на время на ExamRoll.io.

Формирование команды, устав и ясность ролей

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

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

Ясность ролей замыкает этот треугольник формирования. Матрица RACI (или ее вариант RASCI), сопоставляющая результаты работы с ответственными (responsible), подотчетными (accountable), консультируемыми (consulted) и информируемыми (informed) сторонами, устраняет сбои в стиле «я думал, ты этим занимаешься». В новой команде, где менеджер проекта наследует группу, которая несколько недель дрейфовала без руководства, правильный первый шаг — это не агрессивное перепланирование и не немедленный пересмотр графика со спонсором. Правильный шаг — это собрать команду, выслушать, что, по их мнению, блокирует работу, и заново создать устав и карту ролей. Команда чувствует себя потерянной именно потому, что эти опоры отсутствуют.

Адаптация стиля руководства к зрелости команды

Ситуационное лидерство рассматривает стиль руководства как переменную, а не как черту личности. Классическая модель Херси-Бланшара соотносит стиль с готовностью сотрудников:

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

Ловушка попустительского руководства (laissez-faire) в команде, лишенной направления — это распространенная причина неудач. Отстраниться, «чтобы дать команде самоорганизоваться», когда у команды нет общего понимания работы, приводит к путанице, упущенным зависимостям и деморализации. Самоорганизация — это результат зрелости, а не стартовое условие. И наоборот, микроменеджмент старших инженеров, которые уже пять раз выполняли подобную работу, сигнализирует о недоверии, подавляет инициативу и ведет к оттоку кадров. Признак этого — когда менеджер проекта проверяет детали на уровне коммитов в работе эксперта в предметной области, игнорируя при этом обсуждение рисков на уровне портфеля проектов.

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

Коучинг, встречи один на один и управление производительностью

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

Проблемы с производительностью необходимо поднимать при первом же их обнаружении, а не копить их до формального цикла оценки. Откладывание трудных разговоров — один из самых разрушительных паттернов в управлении проектами: сотрудник с низкой производительностью ничего не узнает, пока не станет слишком поздно что-то исправить, высокопроизводительные сотрудники наблюдают за этим и теряют вовлеченность, а моральный дух незаметно падает. Обратная связь должна ссылаться на измеримые показатели — количество дефектов, попавших в прод (defect escape rate), время цикла пользовательской истории (story cycle time), скорость проведения код-ревью, посещаемость встреч, надежность выполнения обязательств — а не на субъективные впечатления («кажется, ты не вовлечен»). Измеримые показатели привязывают разговор к наблюдаемому поведению и дают сотруднику конкретную цель.

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

Разрешение конфликтов и построение команды

Межличностные конфликты, если их не решать, разрастаются. Когда в краткосрочном проекте коллеги изолируют одного из членов команды, менеджер проекта не должен ни выжидать (проект закончится раньше, чем ситуация разрешится), ни публично конфликтовать с группой (это унижает и ожесточает участников). Правильный подход сочетает три действия: провести личную беседу с пострадавшим сотрудником, чтобы понять его точку зрения; поговорить индивидуально с коллегами, демонстрирующими изоляционное поведение, чтобы обозначить наблюдаемую модель поведения и её последствия; и укрепить нормы инклюзивности через устав команды и фасилитируемое мероприятие по построению команды. Документирование вмешательства необходимо на случай, если потребуется эскалация в HR.

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

Распределение, выравнивание ресурсов и планирование мощностей

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

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

Передача знаний и перекрёстное обучение

Зависимость от одного специалиста (single-point dependency) — один из самых предсказуемых и часто игнорируемых рисков проекта. Когда один человек является единственным владельцем подсистемы и попадает в больницу на два месяца, провал заключается не в несчастном случае, а в отсутствии предварительных мер по его смягчению. Профилактические практики включают парное программирование или парное наставничество, ротацию дежурств, обязательное документирование «племенных знаний» в ранбуках, записанные сессии по передаче знаний и ротации для перекрёстного обучения, в ходе которых второй специалист сначала наблюдает, а затем выполняет задачи основного. Планы по адаптации новых сотрудников должны явно включать назначение «бадди» и карту компетенций на 30-60-90 дней.

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

Фасилитация совещаний и признание заслуг

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

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

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

Сценарий: Прия Капур только что была назначена руководителем проекта «Меридиан» по модернизации платежных систем в среднем региональном банке с бюджетом 4,2 млн долларов и сроком 14 месяцев. Команда из 11 человек работает в трех часовых поясах: пять разработчиков в Бангалоре, три бизнес-аналитика в Лондоне, а также QA-лид, архитектор и сама Прия в Торонто. Через две недели после начала проекта разработчики из Бангалора создали прототип, который бизнес-аналитики из Лондона отклонили как не соответствующий требованиям комплаенса, которые, как они «предполагали, все прочитали». Архитектор из Торонто утверждает, что с ним не консультировались при принятии решения о технологическом стеке.

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

Рекомендуемый подход:

1. Приостановить активную разработку на два дня для проведения виртуального воркшопа по формированию команды, запланировав его на пересекающиеся рабочие часы (7:00–10:00 в Торонто / 12:00–15:00 в Лондоне / 16:30–19:30 в Бангалоре), чтобы все 11 участников могли совместно создавать артефакты в реальном времени.
2. Организовать совместное создание устава команды, который будет охватывать общие пересекающиеся рабочие часы, права на принятие решений, определение понятий «консультируемый» (consulted) и «информируемый» (informed), правило 24-часового ответа для асинхронных решений и схему эскалации, заканчивающуюся на спонсоре проекта.
3. Построить матрицу RASCI для 18 основных результатов проекта из ИСР (WBS), прорабатывая каждую строку вместе с командой, чтобы в роли «Ответственного» (Accountable) всегда был один конкретный человек, а в роли «Консультируемого» (Consulted) был явно указан архитектор для любых решений по технологическому стеку.
4. Установить основные правила — включенные камеры на обзорах дизайна, фиксация решений в Confluence в течение одного рабочего дня, еженедельная 30-минутная межзональная синхронизация в рамках пересекающихся рабочих часов — и закрепить их в командном канале Slack.
5. Переработать скоуп прототипа совместно с бизнес-аналитиками и разработчиками, используя новую четкую матрицу RASCI для определения того, кто должен дать утверждение (sign-off) до начала написания кода.
6. Добавить постоянный 10-минутный «обзор устава» в первую ретроспективу каждой итерации для пересмотра норм по мере развития команды.

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

← Взаимодействие с заинтересованными сторонами и коммуникации · Все домены · Agile →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →