Лекция 6. Команда проекта и распределение ролей. Базовый курс.

Лекция 6. Команда проекта и распределение ролей. Базовый курс.

Давайте поговорим о том, ради чего проект и существует, — о людях. Вы можете обладать идеальным планом, точными оценками и красивой диаграммой Ганта, но если команда развалится — проект не выживет. И наоборот: отличная команда может вытянуть даже плохой план — было бы желание и настрой. Поэтому в этом блоке мы сняли «броню» из процессов и инструментов и посмотрим на проект глазами людей: кто в нём участвует, какие у кого роли, как строить команду, как мотивировать и что делать, когда всё не ладится.

Начнём с ролей. В проекте всегда есть несколько ключевых фигур. Спонсор — мы уже говорили о нём в блоке про инициацию: человек с деньгами и властью, который снимает барьеры и отвечает за бизнес-результат. Заказчик — тот, кто формулирует требования и принимает результат; он может быть внутренним или внешним. Пользователь — тот, кто будет работать с результатом каждый день; часто его голос никто не слушает, и зря — пользователи знают о боли больше всех. Руководитель проекта — менеджер, который держит план, бюджет, риски и коммуникации. Команда — исполнители: разработчики, строители, аналитики, дизайнеры, тестировщики. И ещё есть «спокойные» роли третьего плана — администратор проекта, который ведёт документацию и встречи, и ментор, который помогает команде расти. Запомните базовую вещь: роль — это не должность и не человек. Один человек может совмещать несколько ролей, а одна роль — делиться между людьми. Важно, чтобы все роли были заняты — иначе проект захромает.

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

Теперь про команду и её стадии. Наверное, все слышали про модель Такмана: forming — storming — norming — performing. По-русски: формирование — бурление — нормализация — работа. Это не абстракция, это реальные стадии, через которые проходит любая команда. Формирование: люди знакомятся, притираются, ведут себя вежливо и осторожно. Бурление: начинаются конфликты, выясняется, кто главный, идёт борьба за роли и влияние. Нормализация: устанавливаются правила, люди начинают сотрудничать, конфликты уходят в конструктивное русло. Работа: команда показывает результат, люди понимают друг друга с полуслова, работа идёт как часы. Роль менеджера — не паниковать на стадии бурления (это нормально!) и не давать команде застрять ни на одной из стадий. Понимать, где вы находитесь, — уже половина управления.

Типовой конфликт на стадии бурления: «вы с нами не считаетесь», «я тут самый опытный, а делаю работу новичка», «она сказала, а он не сделал». Опытные менеджеры знают: стадию бурления нельзя «задавить», её нужно прожить. Задача менеджера — превратить разрушительные конфликты в споры о работе. Перевести разговор с «кто виноват» на «что делать». Установить прозрачные правила: кто за что отвечает, как принимаются решения, как решаются споры. И не принимать сторону в личных дрязгах — а канализировать энергию в задачу. Команда, прошедшая бурление и не развалившаяся, становится в разы сильнее команды, которая его избегает.

Ещё одна базовая вещь — матрица ответственности, по-английски RACI. Это таблица: по строкам — работы из вашей WBS, по столбцам — люди или роли. В ячейках — буквы: R (responsible) — кто делает, A (accountable) — кто отвечает за результат, C (consulted) — кого консультируют перед решением, I (informed) — кого просто ставят в известность. В каждой строке должен быть ровно один A — один ответственный. Если в строке два A — ответственность размазана. Если ноль — работу никто не ведёт. RACI — это, пожалуй, лучший способ снять вечную проблему «я думал, это делает он». Сделали RACI — раздали обязанности — споров стало меньше.

Часто спрашивают: а чем отличается A от R? По-русски это сложно передать, но попробуем. R — тот, кто делает руками: пишет код, красит стену, пишет письмо. A — тот, кто отвечает головой: если работа не сделана или сделана плохо, спрашивают с него. Обычно R — исполнитель, A — его руководитель. Для каждой работы A ровно один, R может быть несколько, если работа делится. C — это эксперты, чьё мнение нужно учесть: их спрашивают, но не они определяют результат. I — это все остальные, кому не помешает знать. Звучит просто, но как же часто проекты тонут из-за того, что «все за всё отвечают» — то есть никто ни за что.

Отдельно про мотивацию — вечный вопрос. Забудьте про «кнут и пряник» — в двадцать первом веке это работает плохо. Пряник в виде премии — работает, но туповато: команда делает ровно то, за что платят, и не более. А для проекта нужно «более». Хорошая новость: есть проверенные мотиваторы. Чувство значимости: люди хотят понимать, зачем их работа нужна и кому она помогает. Автономия: люди хотят сами решать, как делать свою работу, в рамках результата. Мастерство: люди хотят расти, учиться, становиться лучше. И принадлежность: люди хотят быть частью хорошей команды, где их уважают. Деньги — гигиенический фактор: мало денег — демотивация, но много денег само по себе не мотивирует. Проект, который даёт людям смысл, автономию и рост, — выигрывает у проекта, который даёт только премии.

Практичный совет по мотивации: мотивировать надо индивидуально, а не «в среднем по больнице». Одному важна карьера — дайте ему сложную задачу и видимость. Другому — признание — хвалите публично. Третьему — стабильность — не дёргайте его завтрашним планом. Четвёртому — интерес — дайте ему новую технологию. Пятому — свобода — не контролируйте каждую секунду. Один и тот же приём мотивации «совещание» одному покажется наградой («меня пригласили к руководству!»), другому — наказанием («опять оторвали от работы»). Поэтому хороший менеджер знает свою команду не как «ресурсы», а как людей: у кого дети, кто вчера ночь не спал, кто мечтает о повышении. Это не сплетни — это управление людьми.

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

Обязательно поговорим про виртуальные команды — реальность современного мира. Люди в разных городах, странах, часовых поясах. Плюсы: шире рынок талантов, ниже стоимость, гибкость. Минусы: сложнее коммуникация, медленнее обратная связь, легко теряется контекст, легко возникают недопонимания. Что помогает? Письменные договорённости — в чате, в вики, в задаче; все решения — в тексте, а не «мы же договаривались». Регулярные встречи — даже по видео — они строят доверие, которого в переписке нет. Общий канал коммуникации — один мессенджер, одна вики, один трекер задач, чтобы не было «а где эта информация?». И — очень важно — соблюдение границ времени: уважать чужой час дня и чужой выходной, иначе команда выгорает. Виртуальная команда требует от менеджера вдвое больше внимания к коммуникации, чем живая — это факт.

Теперь про обучение и развитие команды. Команда проекта — это не статичный «ресурс», а живой организм. Люди приходят и уходят, кто-то растёт, кто-то выгорает. Задача менеджера — следить за «состоянием здоровья» команды: есть ли у людей перегрузка, есть ли у них куда расти, не устали ли они делать одно и то же. Инструменты: регулярные one-on-one (личные разговоры с каждым), периодическая ротация задач, планы развития, курсы и конференции, открытое признание заслуг. Звучит как кадровая работа HR, но и проектный менеджер без этого не выживет: выгоревшая команда — это сорванные сроки, брак и уход людей в разгар проекта.

Не забывайте и про управление самим менеджером — управление вверх, по-английски managing up. Это умение работать со своим спонсором и руководством: регулярно информировать, вовремя поднимать проблемы, просить поддержки, управлять ожиданиями. Многие менеджеры пренебрегают этим — и платят: спонсор узнаёт о проблемах последним, в самый неподходящий момент, и проект теряет поддержку. Правило: плохие новости сообщайте сразу и с планом решения; хорошие новости — публично и регулярно; решения, требующие денег или власти, — готовьте заранее, с цифрами и вариантами. Управление вверх — это не подхалимаж, а ещё одна роль менеджера, без которой проект не получит ресурсов вовремя.

В конце блока — про практический ритуал, который сильно помогает команде: регулярное совещание по проекту. Раз в неделю, 15-30 минут, все ключевые люди. Формат простой: что сделали, что будем делать, какие проблемы, что нужно от кого. Не превращайте совещание в «разбор полётов» и не тащите туда всех подряд — только тех, чьё участие нужно. Совещание — это не самоцель, а инструмент синхронизации. Хорошее совещание заканчивается списком решений и ответственных. Плохое — разговором «по душам» без ясности. Умение проводить короткие, результативные встречи — это, между прочим, отдельный навык, который ценится в любой профессии.

Домашнее задание: составьте матрицу ответственности RACI для своего проекта. Возьмите пять-семь ключевых работ из вашей WBS и распишите по ролям: кто делает, кто отвечает, кого консультируют, кого информируют. Проверьте: в каждой строке ровно один A? Потом проведите честную самооценку команды по стадиям Такмана: где вы сейчас — формирование, бурление, нормализация или работа? Что нужно сделать, чтобы пройти дальше? И, наконец, ответьте себе: что мотивирует каждого ключевого члена команды? Если вы не знаете ответа — пора узнать.

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