Кто выделял какие разработчики нужны в проекте?

Кто и как определяет потребность в разработчиках в проекте?

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

Ключевые участники процесса и их роль:

• Менеджер проекта (Project Manager / Program Manager):

    *   **Основная ответственность:** Координация всего процесса, сбор оценок, консолидация требований к команде, планирование ресурсов и сроков, управление бюджетом на персонал.
    *   **Конкретные действия:** Организует workshops по оценке, анализирует исторические данные о velocity команды, ведет **resource allocation plan**, согласовывает финальный запрос с заказчиком или спонсором.

• Технический лидер / Архитектор (Tech Lead / Solution Architect):

    *   **Ключевая роль:** Определяет **технологический стек** и **архитектурные решения**. На основе этого формирует первичный запрос на роли (например, нужны ли специалисты по Kubernetes, React Native или машинному обучению).
    *   **Пример:** Если проект подразумевает микросервисную архитектуру с event-driven взаимодействием, архитектор укажет на необходимость разработчиков с опытом работы с Kafka и Docker, а не просто "бэкенд-разработчиков на Java".

• Тимлиды / Ведущие разработчики (Team Leads / Senior Developers):

    *   **Ключевая роль:** Детализируют оценку трудозатрат. Они разбивают высокоуровневые требования на задачи и оценивают, сколько человек и какого уровня квалификации потребуется для их реализации в заданные сроки.
    *   **Инструмент:** Часто используют **декомпозицию работ (Work Breakdown Structure - WBS)** и оценку в story points или человеко-днях.

• Продуктовый владелец / Бизнес-аналитик (Product Owner / Business Analyst):

    *   **Ключевая роль:** Определяет **объем работ (scope)** через пользовательские истории, функциональные и нефункциональные требования. Их приоритизация напрямую влияет на то, каких разработчиков и в какой последовательности нужно привлекать.
    *   **Пример:** Если в первую очередь требуется прототип мобильного приложения, то первыми понадобятся React Native/Flutter/iOS/Android разработчики, а специалисты по высоконагруженному бэкенду могут быть привлечены позже.

• Отдел управления персоналом / Ресурсный менеджер (HR / Resource Manager):

    *   **Ключевая роль:** Участвует на этапе валидации "рынка труда". Помогает понять доступность требуемых специалистов, уровень зарплатных ожиданий, что может привести к корректировке требований (например, рассмотрение альтернативных, более доступных технологий).

Процесс определения потребности: пошаговый взгляд PM

1. Инициирование и высокоуровневая оценка: На этапе пресейла или инициации проекта архитектор и проджект-менеджер на основе vision документа готовят первоначальную high-level оценку типов и количества разработчиков. Это нужно для примерного бюджета.

   # Пример высокоуровневой структуры команды (псевдокод для планирования)
   project_phase = "Пилот (3 месяца)"
   initial_team_estimate = {
       "backend_java": {"senior": 1, "middle": 1},
       "frontend_react": {"middle": 2},
       "qa_automation": {"middle": 1},
       "devops": {"middle": 1} # Part-time
   }
   

2. Детальное планирование после старта: После kick-off проводится детальный planning workshop с участием тимлидов, разработчиков и PO. Backlog разбивается на спринты/этапы, и оценивается потребность в ресурсах для каждого.

   | Этап (Спринт) | Основной фокус                    | Ключевые требуемые роли               |
   |----------------|------------------------------------|---------------------------------------|
   | 1-3            | MVP Core Backend + API             | Backend (Java), DevOps, DB Architect  |
   | 4-6            | Web Admin Panel + Basic UI         | Frontend (React), UX/UI Designer      |
   | 7-9            | Mobile App + Integrations          | Mobile (React Native), Middleware Dev |
   

3. Уточнение квалификации: Просто "2 бэкенд-разработчика" — недостаточно. Совместно с техлидом мы определяем уровень (Junior/Middle/Senior) и специфические компетенции (например, "Senior Backend с опытом оптимизации PostgreSQL и написания интеграционных тестов").

4. Валидация и согласование: PM консолидирует все входные данные в единый план по ресурсам (Resource Management Plan) и согласовывает его со спонсором проекта, учитывая бюджетные и временные ограничения.

5. Итеративная корректировка: В ходе проекта (на ретроспективах, при изменении scope) потребность в разработчиках пересматривается. Project Manager постоянно мониторит загрузку команды (capacity) и прогресс (velocity), инициируя запрос на дополнительных специалистов или перераспределение текущих.

Итог: Ответ на вопрос "Кто выделял?" — это команда проекта под руководством Project Manager'а. Архитектор и тимлиды определяют "каких именно" разработчиков с технической точки зрения, продуктовый владелец — "для каких целей и когда", а PM сводит это воедино с бюджетом, сроками и возможностями компании, превращая технические потребности в реалистичный кадровый план. Успех проекта часто зависит от качества именно этого collaborative процесса на ранних этапах.