Сколько было человек в командах?

# Размеры команд, с которыми я работал

За мою карьеру я работал с командами разных размеров — от 3 человек до 100+. Каждый размер имеет свой характер и вызовы.

Микрокоманды (3-5 человек)

Контекст

• Обычно стартапы на ранней стадии
• Часто: 1-2 разработчика, 1 дизайнер, иногда менеджер продукта
• Никакой иерархии, все в одной комнате

Мой опыт

Работал с 2-3 такими командами. В этом размере PM роль размывается — ты одновременно и PM, и скрам-мастер, и сом помощник.

Специфика:

• Не нужны сложные процессы, люди и так общаются
• Вызов: prioritization (что делать сначала с ограниченными ресурсами)
• Вызов: не срывать deadline'ы одного человека из-за другого
• Преимущество: быстрые решения, прямая обратная связь от пользователей

Инструменты: Простые — Trello, weekly sync'и, ничего сложного.

Результат: Обычно такие команды либо растут (и переходят в следующий размер), либо стабилизируются на этом уровне.

Малые команды (6-10 человек)

Контекст

• Обычно early stage startups, которые получили funding
• Backend, Frontend, часто DevOps/QA, Product/Design
• Обычно 1-2 слоя управления (Squad Lead, PM)
• Всё ещё fit в одном zoom call

Мой опыт

Это мой любимый размер команды для управления. Работал с 5-6 такими командами. Здесь есть достаточно разнообразия, чтобы быть интересно, но достаточно маленькое, чтобы управлять лично.

Специфика:

• Нужна структура, но не слишком жёсткая
• Можно знать каждого человека персонально, его мотивации, его вызовы
• Вызовы: с растом лучше планировать, иначе быстро становится хаотично
• Преимущество: быстро видишь impact твоего управления

Процессы: Двухнедельные спринты, еженедельные планирования, ретро.

Результат: Здоровые и продуктивные команды в этом размере могут выпускать 3-4 новые фичи в спринт, поддерживая качество.

Средние команды (11-20 человек)

Контекст

• Компании в стадии growth, которые начинают структурироваться
• Часто несколько подкоманд (backend, frontend, mobile)
• Несколько уровней: PM, Tech Lead, Senior Dev
• Нужна больше координации

Мой опыт

Работал с несколькими такими командами. На этом уровне появляются первые сложности управления.

Специфика:

• Не все могут быть на одном synch'е (разные часовые пояса, разные focus)
• Появляются зависимости между подкомандами (backend нужно ждать decision от frontend)
• Вызовы: синхронизация, коммуникация, культура
• Возможность: иметь специализацию (один PM на backend, один на frontend)

Процессы: Scrum на уровне team, плюс координация между teams. Я начинал использовать Nexus или SAFe lite.

Инструменты: JIRA начинает быть важным, потому что нужна видимость cross-team dependencies.

Результат: Обычно на этом уровне начинают появляться первые боли scale'инга — больше бюрократии, медленнее решения.

Большие команды (21-50 человек)

Контекст

• Компании, которые есть уже 5+ лет или привлекли Series A
• Несколько product lines или отделов
• Иерархия: PM → Team Lead → Senior Dev → Mid Dev → Junior Dev
• Часто распределённые географически

Мой опыт

Работал с одной большой интегрированной командой (50 человек) и с несколькими отделами в компании из 100+.

Специфика:

• Нужна серьёзная структура (иначе chaos)
• Не можешь знать каждого лично (ты знаешь 30-40 человек, остальные знают только свой team)
• Вызовы: культура, синхронизация, микро-манеджмент vs empowerment
• Преимущество: можно достичь больших результатов, scale вверх

Процессы: Полный SAFe или Scrum of Scrums. Каждый team имеет свой спринт, но есть program level координация.

Культура: На этом уровне очень важно, чтобы PM были aligned (иначе teams будут pull в разные стороны). Я проводил еженедельные PM synch'и.

Инструменты: Advanced JIRA с custom workflows, Confluence для documentation, Slack для async communication.

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

Очень большие команды (51-100+)

Контекст

• Корпоративные компании, которые трансформируют на Agile
• Несколько отделов, несколько product lines
• Многие уровни иерархии
• Часто legacy code и processes

Мой опыт

Работал в одной компании с 100+ разработчиками в Engineering. Моя роль была по трансформации на Agile.

Специфика:

• Не можешь управлять напрямую — нужно управлять через других PMs и Tech Leads
• Изменения идут медленнее (много stakeholders, много согласований)
• Вызовы: организационная политика, культура resistance
• Преимущество: если ты успешен, impact огромен

Процессы: SAFe (Scaled Agile Framework) был необходимостью. Program Increments, Team level, Release level.

Роль PM: На этом уровне PM больше про стратегию и vision, чем про day-to-day управление. Я был EPM (Engagement PM) — координировал между отделами.

Культура: Очень важна коммуникация vision. Я проводил много meetings, presentations, работал с resistance.

Результат: За 2 года трансформации мы привели 10 teams от Waterfall к Agile с 60% improvement в velocity.

---

Как размер влияет на мой подход

Мой идеальный размер

Если быть честным, мой идеальный размер команды — это 15-25 человек. Вот почему:

1. Достаточно большая для интересных проблем: Есть backends, frontends, дизайнеры, QA. Есть реальные вызовы.
2. Достаточно маленькая для прямого влияния: Я всё ещё знаю каждого по имени, вижу, как мои решения влияют на их жизнь.
3. Структурированная, но не жёсткая: Можно ввести процессы, но люди не чувствуют себя задавленными бюрократией.
4. Достаточно сложная для growth: Есть где расти в управлении и в технологии.

Но я готов работать с командами большего размера, если есть интересные организационные вызовы (трансформация, масштабирование, культурные изменения).