Рубрика: Практика лидерства · Блок: Лидерство и командная динамика

Управление проектной командой

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

Автор: Василий Пигин

Чем проектная команда отличается от постоянной

Проектная команда живет ограниченное время: у нее есть дата начала и дата окончания. Люди приходят из разных отделов, у каждого остается свой линейный руководитель, который отвечает за зарплату, отпуск и карьеру. Руководитель проекта не имеет формальной власти: он не может поставить оценку за год или повлиять на премию. Из-за этого управление строится на договоренностях, а не на приказах.

Признаки проектной команды:

• Срок. Команда расформировывается после сдачи результата. Нет задачи развивать отдел или поддерживать процессы.
• Кросс-функциональность. В команде разработчик, маркетолог, аналитик, специалист поддержки. Они не подчиняются друг другу в постоянной структуре.
• Двойное подчинение. Участник отвечает и перед линейным руководителем за текущую работу, и перед руководителем проекта за проектную задачу.
• Руководитель проекта без власти. Он не ставит KPI, не распределяет премии, не нанимает и не увольняет. Его влияние основано на экспертности, прозрачности и умении договариваться.

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

Как собрать команду

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

Роли в проектной команде:

• Заказчик. Тот, кому нужен результат. Принимает итог, выделяет бюджет и время.
• Руководитель проекта. Организует процесс, снимает блокеры, следит за сроками.
• Исполнители. Делают конкретные блоки работ: аналитик, дизайнер, разработчик, тестировщик.
• Эксперт. Консультирует по узким вопросам, но не делает задачи.
• Владелец ресурса. Обычно линейный руководитель, который выделяет сотрудника на часть времени.

Переговоры с линейными руководителями:

• Обсудите процент загрузки на проект: не «помогай по возможности», а «10 часов в неделю до 15 марта».
• Договоритесь, какие задачи можно отложить или передать коллеге.
• Договоритесь, что происходит при аврале: кто имеет приоритет, проект или операционная работа.
• Попросите назвать замену на время отпуска участника.

Кого брать в команду:

• У кого есть свободное время или возможность освободить его без ущерба для текущего процесса.
• Кому интересна тема проекта или кто видит в ней развитие.
• Кто уже работает с нужными инструментами или знаком с предметной областью.

Кого не брать:

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

Пример разговора с линейным руководителем: «Мне нужен дизайнер на 8 часов в неделю до конца квартала. Нам нужно закрыть макет к пятнице, чтобы не сдвинуть запуск. Какие варианты по загрузке дизайнера возможны?»

Старт проекта

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

Что зафиксировать на старте:

• Цель проекта. Одно предложение, понятное каждому: «Обновить страницу оформления заказа, чтобы снизить число брошенных корзин к 1 июня».
• Границы. Что входит, а что нет. Пример: «Меняем только интерфейс, не трогаем логику оплаты».
• Критерии готовности. Как поймем, что проект завершен: «Страница запущена на боевом домене, ошибок меньше 1 процента, время загрузки не выросло».

Распределение ответственности: кто делает, кто согласует, кто информируется.

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

Для каждой крупной задачи пропишите эти три роли. Не нужна сложная таблица, достаточно списка в файле.

Правила общения:

• Основной канал: общий чат или трекер. Все статусы пишем там, а не в личных сообщениях.
• Встречи: короткий созвон раз в неделю, длительность до 30 минут.
• Если вопрос срочный: пишем в чат с пометкой «срочно», руководитель проекта отвечает в течение рабочего дня.

Правила принятия решений:

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

Как управлять без формальной власти

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

1. Договоренности вместо приказов. Формулируйте просьбы как предложение с объяснением выгоды и последствий. Пример: «Если ты закроешь эту часть до четверга, мы успеем проверить макет на реальных данных. Если нет, тестирование уедет на следующую неделю».

2. Прозрачность. Ведите открытый список задач, сроков и блокеров. Каждый видит, кто что делает и где задержка. Это снижает ощущение, что руководитель проекта кого-то выделяет или прячет проблемы.

3. Эскалация. Если договориться не удается, подключайте линейного руководителя или заказчика. Делайте это не как жалобу, а как совместный поиск решения. Формулировка: «У нас конфликт приоритетов: дизайнер назначен на срочную рекламную кампанию и не может закрыть макет до пятницы. Можем сдвинуть срок проекта или освободить его от рекламы на два дня. Что выберем?»

4. Конфликты приоритетов с основной работой. Это самая частая причина срыва проектных сроков. Заранее договоритесь с линейным руководителем о приоритетах и повторите это в момент конфликта. Пример: «Мы договаривались, что до 15 марта у тебя приоритет проект, а не поддержка клиентов. Сейчас три клиента требуют ответа, но если ты переключишься, мы потеряем день. Мы можем вместе обратиться к твоему руководителю, чтобы перераспределить нагрузку. Тебе так будет комфортнее?»

Что помогает во влиянии:

• Показывайте, что вы решаете проблемы участников: договариваетесь о ресурсах, снимаете технические блокеры.
• Признавайте вклад каждого публично, особенно когда участник сделал больше, чем обещал.
• Не используйте манипуляции в духе «если ты не сделаешь, подведешь команду». Это разрушает доверие.

Ритм работы

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

Встречи:

• Еженедельный статус: 30 минут, каждый участник отвечает на три вопроса: что сделал, что будет делать, какие блокеры.
• Раз в месяц: обзор хода проекта с заказчиком, на нем принимают решения о сроках и бюджете.
• По необходимости: короткие рабочие встречи по конкретной проблеме, не более 20 минут.

Статусы:

• Письменные статусы обязательны даже между встречами. Обновляйте список задач в трекере или общем документе.
• Формат статуса: задача, ответственный, срок, текущий статус, флаг риска (зеленый, желтый, красный).

Риски:

• На каждой встрече выделяйте 5 минут на вопрос: «Что может помешать нам закончить в срок?»
• Записывайте риск, ответственного за реагирование и дату проверки.
• Пример риска: «У аналитика отпуск с 3 по 10 апреля, задачи на этот период некому передать». Реакция: перенести часть задач или подключить второго аналитика.

Мотивация в середине проекта:

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

Удаленные участники:

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

Завершение проекта

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

Разбор итогов:

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

Признание вклада:

• Поблагодарите каждого лично, называя конкретный вклад: «Ты спас запуск, когда переписал интеграцию за ночь».
• Перед письменной благодарностью с ФИО и деталями вклада убедитесь, что сотрудник согласен на упоминание его данных, либо используйте общую формулировку без конкретики.
• Попросите заказчика отметить команду перед руководством.

Возврат людей в отделы:

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

Обратная связь их руководителям:

• Перед передачей обратной связи с ФИО убедитесь в согласии сотрудника, либо обезличьте пример: «один из участников трижды сдавал задачи раньше срока, самостоятельно решил проблему с API».
• Если были сложности, опишите ситуацию и ее влияние: «Иван дважды не предупредил о задержке, из-за этого сдвинулась дата тестирования».
• Не сравнивайте участников между собой.

Типичные ошибки завершения:

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

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

Люди из разных отделов приходят в проект с разным стилем поведения DISC: кто-то быстрее принимает решения и идет вперед, кто-то сначала проверяет детали и риски. Это видно в скорости решений и в отношении к плану, и это повод договориться о правилах, а не вешать ярлыки. 12 движущих сил подсказывают, что держит участника в проекте, который не его основная работа: одному важна новая задача, другому польза для людей, третьему порядок в результате. Стили мышления ACI показывают, на что каждый смотрит в первую очередь, и помогают распределить роли так, чтобы они дополняли друг друга. Эмоциональный интеллект руководителя проекта помогает договариваться о приоритетах с участниками и их линейными руководителями.

Если проектная команда собирается из разных отделов. Оценку участников мы собираем под задачу клиента. Зачем: заранее увидеть, как люди будут работать вместе, и распределить роли. Мы смотрим на стиль поведения DISC, 12 движущих сил и стили мышления ACI и обсуждаем результаты с руководителем проекта. Подробнее на страницах об управлении командой и о командных ролях.