Участники проекта: как собрать состав, который доведет дело до конца
Рассказываем о том, кто важен в проектах на разных этапах и как собрать команду под любую инициативу
Участники проекта — это не только те, кто делает задачи. Это еще и те, кто принимает решения, согласует изменения и задает ограничения. Если роли между ними распределены плохо, проект тормозит даже с сильной командой.
В статье разберем, какие роли нужны в проекте и как собрать состав под конкретную задачу.
Участники и команда проекта: почему это не одно и то же
Участников и команду проекта нередко воспринимают как синонимы, однако эти понятия только пересекаются, а не заменяют друг друга.
Команда проекта — это люди, которые регулярно работают над проектом: выполняют задачи, двигают проект вперед и отвечают за конкретные результаты. Обычно это проектный менеджер и различные специалисты — те, кто «внутри процесса» каждый день. Например, разработчики и дизайнеры.
Участники проекта — это более широкое понятие. Это все, кто вовлечен в проект напрямую или влияет на его ход: решения, сроки, бюджет и итоговый результат.
Участники включают в себя не только команду исполнителей, но и заказчиков, согласующих лиц, стейкхолдеров, внешних экспертов, подрядчиков, руководителей и т. д. Они могут не выполнять работу ежедневно, но зачастую имеют критическое влияние на проект.
Распространенная ошибка — сосредоточиться только на команде и не определить остальных участников. В итоге решения могут долго согласовываться, задачи зависать из-за отсутствия ответственных, а также появляться неожиданные ограничения и правки.
Какие роли бывают в проекте
В любом проекте есть набор основных ролей:
- Внешний или внутренний заказчик. Формулирует цель и принимает результат. Наличие этой роли особенно критично на старте и при финальной приемке.
- Руководитель проекта. Организует процесс, координирует участников, отвечает за сроки и результат.
- Команда исполнителей. Выполняет регулярные задачи и создает ценность.
- Функциональные эксперты. Точечно подключаются, когда нужны знания в узкой сфере, например, юридической, финансовой, технической и др.
- Куратор, спонсор или руководитель направления. Обеспечивает ресурсы и решает вопросы на уровне руководства.
- Внешние подрядчики или партнеры. Закрывают часть задач извне.
- Стейкхолдеры. Лица, заинтересованные в результате. Их ожидания влияют на ход проекта.
Важно: роли в проекте не равны должностям в компании. Один и тот же человек может быть разработчиком по оргструктуре, но в проекте отвечать за интеграцию, аналитику или внедрение. Поэтому роли нельзя просто скопировать из штатного расписания — их нужно определять под намеченную задачу.
Функции участников проекта и риски их отсутствия
У каждой роли есть свои функции и зона ответственности, а также риски, если такого участника в проекте нет.
| Роль | Ключевая функция | Примеры задач | Риски при отсутствии или неверном выборе |
|---|---|---|---|
| Заказчик | Определяет, что считать успехом | Утверждает ТЗ, согласует бюджет, принимает финальный результат | Проект уходит не в ту сторону и не двигается к нужной цели |
| Руководитель / координатор проекта | Двигает проект вперед | Составляет план проекта, распределяет задачи между участниками, проводит встречи для обмена информацией о работе | Хаос, срывы сроков |
| Команда исполнителей | Выполняет регулярную работу для получения результата | Пишут код, подготавливают дизайн, настраивают интеграции, проводят тестирование | Низкое качество или отсутствие результата |
| Эксперты | Помогают принимать решения | Проверяют договор с юридической стороны, оценивают налоговые риски, консультируют по архитектурным вопросам | Ошибки, большое количество исправлений |
| Куратор / спонсор | Снимает ограничения | Утверждают решения по бюджету проекта, расставляют приоритеты, снимают блокировку с ресурсами | Проект замедляется в согласованиях или из-за нехватки ресурсов |
| Подрядчики | Закрывают внешний контур задач | Реализовывают отдельный блок работ (например, разработку модуля), проводят маркетинговые исследования, выполняют настройку или внедрение | Перегрузка штатной команды, срывы сроков |
| Стейкхолдеры | Влияют на решения и результат | Дают обратную связь по промежуточному результату, обозначают ограничения или риски со своей стороны | Конфликты, неожиданные правки |
Кто участвует в проекте постоянно, а кто эпизодично
Минимальный состав, который обеспечивает управляемость проектом и движение к результату: заказчик, руководитель и команда исполнителей.В проекте мешает не только нехватка ролей, но и избыток лишних участников.
Минимальный состав, который обеспечивает управляемость проектом и движение к результату: заказчик, руководитель и команда исполнителей.
В проекте мешает не только нехватка ролей, но и избыток лишних участников. Каких людей не стоит держать в проекте на постоянной основе:
- Смежные руководители. Руководитель соседнего отдела, которого проект касается не напрямую. Например, HR при запуске продукта. Достаточно раз в 2 недели присылать короткий статус — что сделано, что планируется, где необходима помощь.
- Эксперты. Юрист, финансист, архитектор и другие узкопрофильные специалисты подключаются в конкретный момент, когда необходимы их компетенции: проверить договор, оценить бюджет, согласовать техническое решение. После консультации не принимают активного участия в проекте до следующего вопроса.
- Согласующие лица. Руководитель или владелец результата, который утверждает бюджет и финальный результат. Включается на 2-3 точках за весь проект — на старте, при ключевых развилках и на приемке конечного итога работы. В операционной работе не участвует.
- Стейкхолдеры из соседних подразделений. Отделы, которых результат затронет после запуска — например, поддержка при выпуске нового продукта. Их зовут на демо и на этап внедрения, но не на планирование задач.
Как понять, нужен ли человек в ежедневной работе: он либо выполняет задачу, либо принимает решение. Если ни то, ни другое — его достаточно держать в курсе через статусы или демо.
Как понять, что состав участников собран неправильно
Есть несколько явных сигналов, что структура проекта собрана неудачно.
| Признак | Как это проявляется в работе |
|---|---|
| Задачи зависают при передаче между сотрудниками или отделами | Непонятно, кто должен делать следующий шаг. Сотрудники передают задачи от одного участника к другому без явного владельца, и в итоге не выполняют их |
| Решения постоянно ждут согласования из-за перегруженного контура участников | Любое изменение приходится согласовывать с несколькими людьми, которые не погружены в детали проекта. В результате решение даже простых вопросов затягивается |
| Нет владельца результата | Команда выполняет задачи, но никто не принимает и не оценивает результат. В итоге проект движется, но не ясно — туда ли и с нужным ли качеством |
| Много обсуждений — мало действий | Встречи проходят регулярно, в них участвует много людей, но после завершения непонятно, кто что делает и к какому сроку |
| Границы ответственности размыты, задачи четко не распределены по ролям в проекте | Одни и те же задачи могут делать несколько человек или, наоборот, не делает никто. Это признак того, что роли в проектной команде и их функции не определены |
Если совпадает несколько пунктов, начать стоит не с новой встречи, а с простого упражнения: выписать всех участников проекта и напротив каждого указать, какую задачу он решает и какое решение принимает. Пустые строки — кандидаты на выход из проекта.
Как собрать рабочую команду проекта
Команду проекта начинают не с подбора людей, а с разбора самой задачи. Разберем пошагово, как это можно делать в Кайтене.
Шаг 1. Разложите проект по результату
Сначала ответьте на базовые вопросы:
- Что должно получиться в итоге? Конкретный результат, который можно принять.
- Какие функции затрагиваются и необходимы для достижения результата? IT, маркетинг, продукт, финансы, операционные процессы и т. д.
- Где есть зависимости? Какие этапы требуют участия других команд или согласований, какие этапы обязательно нужно завершить перед другими.
- Кто принимает ключевые решения? Кто утверждает результат, бюджет, изменения, новых участников.
На этом шаге становится понятно, какие роли действительно нужны, без привязки к конкретным людям.
Шаг 2. Определите состав по уровням вовлеченности
Для этого разнесите участников по 4 группам:
- Кто работает постоянно. Руководитель проекта и исполнители — ядро, которое ведет работу ежедневно.
- Кто подключается по этапам. Эксперты и подрядчики — там, где нужна конкретная компетенция.
- Кто принимает решения. Заказчик, спонсор, руководители — участвуют в ключевых точках или вехах проекта.
- Кто остается в контуре информирования. Стейкхолдеры — получают информацию, но не участвуют в операционной работе.
Шаг 3. Зафиксируйте роли и ответственность
Запишите распределение ролей в документе, который будет доступен всем участникам. Там можно зафиксировать:
- Состав рабочей команды проекта. Так сотрудники будут знать, кто и за какие задачи отвечает.
- Состав всех участников проекта. Исполнителям не менее важно понимать, кто ожидает, согласовывает и влияет на конечный результат.
- Этапы проекта и тех, кого необходимо подключить на каждом из них. Это поможет избежать дефицита и избытка людей в разные моменты работы, а также вовремя получать информацию для решений.
Такой алгоритм позволит команде избегать конфликтов по поводу ответственности и точно понимать свое назначение в проекте.
Помочь распределить роли в проекте также может матрица RACI. Название матрицы расшифровывается так:
- R (Responsible) — выполняет задачу.
- A (Accountable) — отвечает за результат.
- C (Consulted) — консультирует.
- I (Informed) — информируется.
Она помогает четко разделить ответственность, сократить лишние согласования и ускорить работу и особенно полезна в проектах с большим количеством участников.
Управление командой проекта: что важно кроме ролей
Сам факт, что вы собрали команду и назначили роли, еще ничего не гарантирует. Даже выверенный и надежный состав начинает ошибаться, если не выстроены сами рабочие процессы.
Определили,что еще нужно продумать для работы над проектом.
| Что еще важно | Почему это важно |
|---|---|
| На основе чего принимать решения | Решения не должны приниматься интуитивно. Например, опора на метрики, результаты маркетинговых исследований, дедлайны и приоритеты помогает быстрее выбирать варианты действий и снижает риски. |
| Где фиксировать договоренности | Если решения остаются в чатах или устно, они теряются. Например, фиксация в системе управления проектом позволяет всем участникам двигаться в одном направлении, не терять контекст и избегать конфликтов. |
| Какие инструменты использовать для достижения результата | Набор инструментов влияет на скорость и прозрачность работы. Например, канбан-доски помогают видеть поток задач, а правила автоматизации — сокращать ручную работу и ошибки. |
| Где смотреть актуальный статус задач и проекта | Если статус нужно долго выяснять, проект уже теряет эффективность. Например, таск-трекер с актуальными задачами и этапами позволяет быстро понять, где есть задержки и что происходит с проектом. |
| Кто и к каким данным имеет доступ | Прозрачность и разграничение доступа важны одновременно. Команда должна видеть нужную информацию, а чувствительные данные должны быть надежно защищены. Это снижает риски и упрощает работу. Например, в ряде проектных систем можно настроить роли участников проекта и уровни доступа к данным разного типа. |
Все эти задачи требуют не просто дисциплины, а удобной среды, где это можно делать системно. Иначе проект быстро распадается на чаты, таблицы и устные договоренности.
Как упростить управление командой и участниками проекта: несколько инструментов
Собрали несколько типовых проблем в проектах и то, как их можно решить. Инструменты рассматривали на примере Кайтена.
Проблема: решения принимаются интуитивно. Когда нет общей картины происходящего в проекте, решения зависят от мнений, а не точных данных.
Решение: использовать аналитику и метрики (график Cycle time, отчет о загрузке команды, Накопительная диаграмма потока), чтобы опираться на реальные данные.
Проблема: договоренности теряются. Решили на встрече или в чате — через неделю никто не помнит, о чем договорились.
Решение: собирать все в одном рабочем пространстве и фиксировать все прямо в карточках задач: комментарии, файлы, инструкции, чек-листы.
Проблема: не видно реального статуса проекта. Чтобы понять, что происходит, нужно писать и спрашивать коллег.
Решение: использовать канбан-доски — статус каждой задачи и этап проекта видны сразу.
Проблема: лишние участники перегружают процесс. Кто-то должен видеть все, но не участвовать в работе.
Решение: настраивать пользовательские роли: кто работает, кто принимает решения, кто просто наблюдает.
В результате все участники проекта получают инструмент, где можно следить за ходом работы, видеть зоны ответственности и хранить всю важную информацию по проекту.
Кто такие участники проекта: коротко о главном
- Понятие участников проекта шире, чем команда: это все, кто влияет на решения, сроки и результат, а не только исполнители.
- Не всех нужно включать в ядро проекта: часть людей работает постоянно, часть — подключается точечно, часть — нужно только информировать.
- Эффективность состава не зависит от количества: понятные роли, зоны ответственности и порядок взаимодействия важнее, чем большой список участников.
- Проблемы проекта зачастую связаны не с людьми, а со структурой: размытые роли и лишние согласования тормозят даже компетентную команду.
- Результат дает система работы: когда задачи, роли и договоренности прозрачны и зафиксированы, управлять проектом и идти к результату становится значительно проще.
