Из кого состоит команда проекта и как её построить

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

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

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

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

● Менеджер или владелец проекта (англ. project owner)
Его задачи — спланировать проект, распределить задачи и ресурсы, следить, чтобы все выполняли работу вовремя. Менеджер отвечает за коммуникацию между всеми членами команды и решает проблемы, которые возникают в ходе проекта.

● Спонсор или владелец продукта (англ. product owner), то есть заказчик
Решает, каким должен получиться результат проекта или его части и для чего всё это делается. Опираясь на эти данные, спонсор определяет цели и оценивает результат. Иногда владелец продукта совмещает роль менеджера проекта и сам ставит цели и задачи команде проекта.

● Члены команды или исполнители
Выполняют отдельные задачи в рамках проекта, например дизайн или веб-разработку. Каждый вносит вклад в конечный результат, соблюдая личные сроки и KPI.

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

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

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

Если исполнители решают похожие задачи, структуру команды проекта можно описать так:

● Менеджер проекта.

● Владелец продукта.

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

● Исполнители разного уровня: джуниоры, мидлы, сеньоры.

На курсе «Управление командой» практикующие руководители делятся рабочими кейсами и базой, которая пригодится опытным менеджерам и новичкам. Здесь можно узнать, как формируется команда реализации проекта, с какими задачами и проблемами придётся столкнуться и как их решать с пользой для всех. Все типичные ситуации помогут отработать на практике, а ещё подготовиться к собеседованию и получить первый оффер от работодателя.

Распределение ролей зависит ещё и от того, постоянный это состав команды или временный, то есть проектный.

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

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

Бывает, что изначально состав команды постоянный, но по ходу проекта он может меняться. Например, после старта проекта выяснилось, что параллельно запустили другой, с новой командой и заказчиком, но со схожим продуктом. Из-за этого не рассчитали ресурсы и людей потребовалось больше, в итоге из первой команды позвали на помощь трёх разработчиков и тимлида. Это сказалось на сроках первого проекта, которые пришлось корректировать. Зато в итоге оба проекта выполнили на 100%, хоть и с отклонениями от плана.

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

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

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

2. Подбор специалистов и определение ролей в команде.
Менеджер или заказчик подбирают членов команды и распределяют роли.

Есть два основных способа собрать команду на проект:

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

● Менеджеру поставили задачи, а специалистов он набирает самостоятельно. Это повышает шансы создать сплочённую команду, которая движется к общим целям, а не просто выполняет свои задачи с персональными KPI.

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

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

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

Чтобы члены команды быстрее «притёрлись» друг к другу, менеджер проводит общие встречи, например ретроспективы или статусы. Важно, чтобы они были регулярными и воспринимались как ритуал. Это поможет членам команды привыкнуть друг к другу и понимать, что любой вопрос или проблему можно озвучить на ближайшей встрече.

4. Нормализация.
Члены команды уже сработались, конфликты возникают редко, но форс-мажоры всё же возможны. Если проект длится больше месяца, а нагрузка большая, есть риск выгорания. Менеджер здесь фокусирует внимание на конструктивной критике от каждого участника и проводит личные встречи, чтобы отследить проблему и прийти на помощь. Иногда проще и дешевле отправить сотрудника в короткий отпуск и подвинуть сроки, чем позволить ему работать в условиях крайнего напряжения и стресса.

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

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

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

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

Если стиль управления в компании ближе к демократичному, применяют гибкие методики управления проектами Scrum или Kanban, то отношения в команде будут построены на равноправии. У каждого участника есть право голоса, а команда регулярно обсуждает промежуточные результаты и инсайты, корректируя сроки и задачи, если это необходимо. Такие команды часто встречаются в IT, дизайне и медиа.

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

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

● Фиксация всех проблем. Далеко не всё можно решить здесь и сейчас, поэтому менеджер фиксирует проблему, чтобы вернуться к ней позже. Это можно делать прямо на доске проекта, в Trello или Notion, или собирать в Google документах. Такой подход помогает найти взвешенное решение либо разобраться, что проблема системная, и нужно копать глубже для улучшения командной работы.

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

● Лидерство и мотивация. Менеджер должен вести команду за собой во всех смыслах. Он может не разбираться в программировании до мелочей, но всё равно обладать авторитетом и вдохновлять команду на отличные результаты.

● Делегирование. На каждой стадии формирования команды менеджер проекта находится в разной позиции по отношению к команде.

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

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

● Диаграмма Ганта — график работ по проекту в виде таблицы, где расписаны задачи, сроки и KPI для каждого участника. Диаграмму можно построить в Excel, Google-таблицах или специальных платных сервисах.

● Сервисы управления проектами, или таск-менеджеры для постановки задач, сроков и хранения всех материалов по проекту. Чаще всего используют Miro, Trello, Notion или корпоративную CRM. В них удобно работать совместно и комментировать задачи онлайн.
Сервис Miro в России сейчас работает только для подписок, оформленных до марта 2022 года. Можно пользоваться бесплатной версией, но создавать не больше трёх онлайн-досок.

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

● Хранилища для документов и контента, который используют в рамках проекта. Это могут быть отдельные сервисы — Яндекс Диск, OneDrive или Google Drive — или встроенные хранилища в CRM, например в «Битрикс24» или amoCRM.

● Мессенджеры для общения внутри команды и за её пределами. Самые популярные — Slack, Telegram или встроенные мессенджеры в корпоративных сервисах. Чаты лучше разделить по задачам — например Дизайн или Разработка. Для неформального общения и обмена мемами обычно выделяют отдельный чат, чтобы не засорять рабочие каналы, выпустить пар и поддержать друг друга в трудный момент.

● Сервисы для видеозвонков, например Zoom или Goggle Meet. Позволяют общаться вживую с удалёнными командами или отдельными участниками проекта.

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

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

● Формы обратной связи в Google Forms или любом другом сервисе, где члены команды могут поделиться своими проблемами и предложениями, а менеджер — обратить внимание на сильные и слабые стороны каждого участника.