Проект — как поход. Кого брать в команду?

6 мая 2025
5 мин.

Зарплаты разработчиков, по разным данным, составляют от 50 до 60 процентов бюджета при разработке софта. Так, согласно информации блога Tech JDI, более половины расходов приходится на разработку, а остальная сумма распределяется между затратами на дизайн, тестирование и управление проектом. Портал {SD:UK} оценивает расходы на разработку в 60 процентов, при этом оборудование занимает долю всего до 10 процентов бюджета.

Это означает, что успех проекта в сфере IT очень сильно зависит от правильного подбора специалистов. Формирование команды является большим вызовом, особенно для начинающих проектных менеджментов. Также, как и с походом в горы, еще на “берегу” очень важно выбрать правильных участников — с достаточными навыками и компетенциями, чтобы мероприятие прошло успешно и безопасно.

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

Какие специалисты доступны проектному менеджеру

Какие вопросы задать самому себе

Как готовится к разговору со спонсором проекта

Что запомнить

Какие специалисты доступны проектному менеджеру

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

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

UX/UI-дизайнер делает продукт понятным и удобным, бизнес-аналитик превращает желания заказчика в требования, системный аналитик переводит их на язык разработчиков. Технический лидер выбирает архитектуру и инструменты, программисты воплощают идею в код, а QA-инженеры ищут баги до того, как это сделает пользователь. DevOps-специалист обеспечивает стабильную работу серверов и выкладку софта. Каждый участник закрывает часть жизненного цикла разработки, и задача PM — понимать, кто и на каком этапе нужен.

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

Какие вопросы задать самому себе

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

  • Этот человек вообще доступен? Свободен ли он на нужный период и в нужной загрузке?
  • Сколько он будет стоить?  Укладывается ли он в наш бюджет или потребует пересмотра сметы?
  • Он справится с задачами проекта? Есть ли у него технические или управленческие способности, которые требуются?
  • Есть ли у него релевантный опыт?  Работал ли он с похожими задачами, заказчиками или продуктами?
  • Он понимает контекст проекта? Знает ли он специфику отрасли, заказчика или нюансы нашей среды?
  • Он владеет нужными инструментами? Например, умеет ли он работать с нашей системой трекинга, фреймворками, BI-средой и т.п.?
  • Он умеет работать в команде? Сможет ли он влиться в существующую группу, не конфликтует ли?
  • Где он физически находится и как будет коммуницировать? Есть ли проблемы с часовыми поясами, языком, каналами связи?

Как готовится к разговору со спонсором проекта

Спонсор проекта — это человек, который отвечает за бизнес-результат проекта, одобряет его запуск и обеспечивает ресурсы. В IT-проектах эту роль часто выполняет продакт-менеджер, особенно если он инициатор проекта и заинтересован в его успехе.

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

Как проекту “встать с дивана”: составляем бизнес-кейс

Следующим этапом становится обращение к уставу проекта (Project Charter), в котором зафиксированы цели, ключевые вехи, допущения и ограничения. Этот документ — основа аргументации в разговоре о ресурсах: без него потребности будут звучать оторвано от стратегии и логики проекта.

Далее необходимо определить требуемые роли и обосновать их необходимость. Используются Scope Baseline и расписание проекта: они позволяют соотнести роли с конкретными задачами и сроками. Не «нужен дизайнер», а «нужен UX-специалист на этапе прототипирования, с загрузкой 40% в течение второго и третьего спринтов».

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

Как ставить цели по методу SMART

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

И, наконец, ключ к убедительному разговору со спонсором — наличие формальных инструментов: RACI-матриц, OBS и Resource Breakdown Structure. Эти инструменты не только демонстрируют подготовленность, но и упрощают процесс согласования ресурсов, снижая уровень неопределённости и риска в дальнейшем.

Что запомнить

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

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