Какой состав команды хочешь на новом проекте?

Идеальный состав команды для проекта

Это очень хороший вопрос, потому что успех проекта зависит не только от меня, но на 70% от команды. За 10+ лет я видел высокофункциональные и дисфункциональные команды. Вот что мне нужно.

Core roles

1. Product Owner / Product Manager

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

Почему критично:

• Я не могу быть аналитиком И product manager одновременно
• Нужен быстрый канал к решениям (не "я спрошу и перезвоню")
• Нужно кто-то, кто говорит на одном языке с executive layer

Идеальный profile:

• Минимум 5 лет в роли
• Понимает эту индустрию (не обязательно, но плюс)
• Может сказать "нет" и обосновать почему
• Готов к итерации (не зафиксированный план на 6 месяцев)
• Красный флаг: человек, который говорит "я покупаю требования" и не может их объяснить

2. Архитектор / Lead Developer

Кто: Senior технолог, который может говорить о стратегии архитектуры.

Почему:

• Я должен знать технические constraints с самого начала
• Не хочу спроектировать идеальный процесс, а потом слышать "это невозможно"
• Архитектор помогает выбирать между вариантами решений

Идеальный profile:

• 7+ лет опыта
• Может говорить на уровне trade-offs, не деталей
• Понимает business impact технических решений
• Готов объяснять, не отмахиваясь
• Красный флаг: технолог, который в первый раз слышит о BPMN

3. QA Lead / Test Manager

Кто: Опытный QA, который может помочь спроектировать test scenarios.

Почему:

• Требования → тесты это одно целое
• QA видит edge cases, которые я могу упустить
• На ранней стадии QA input экономит недели на тестирование

Идеальный profile:

• 5+ лет в QA
• Может писать test cases, не только кликать
• Понимает автоматизацию
• Может дискутировать о требованиях (не "я буду тестировать, что дали")
• Красный флаг: QA, который говорит "я тестирую, вы пишите требования"

4. Junior/Mid Developer (2-3 человека)

Кто: Разработчики, которые будут реализовывать.

Почему:

• Они увидят проблемы в требованиях быстро
• На стендапе слышу сложности в реализации
• Для меня это feedback loop

Идеальный profile:

• 2-5 лет опыта (не junior, не senior)
• Хотят учиться, а не просто писать код
• Готовы задавать вопросы на review требований
• Красный флаг: девелопер, который говорит "просто дай requirements, я напишу код"

---

Support roles

5. UX/UI Designer (если есть user-facing interface)

Кто: Дизайнер с опытом в design thinking.

Почему:

• Мой анализ может быть идеален, но если UI плохой — пользователи не будут это использовать
• Дизайнер помогает выявить непрактичность требований
• Нужны пользовательские сценарии, не технические

Идеальный profile:

• 4+ лет опыта
• Может провести юзер-тестирование
• Понимает accessibility
• Готов спорить о юзабилити

6. DevOps / Infrastructure Engineer (если сложная система)

Кто: Инженер, который понимает deployment и масштабирование.

Почему:

• Требования могут быть неправильными, потому что я не знаю production constraints
• Нагрузочное тестирование — не трюизм, a требование
• Нужны мониторинг и алерты для production issues

Идеальный profile:

• 5+ лет DevOps
• Понимает disaster recovery и high availability
• Может говорить о cost trade-offs

7. Data Analyst (если data-heavy проект)

Кто: Аналитик, который умеет SQL и A/B тестирование.

Почему:

• Я аналитик требований, не data analyst
• Нужна статистика для принятия решений
• Метрики успеха → где их брать?

---

Управления и процессы

8. Scrum Master / Agile Coach (в зависимости от размера)

Кто: Человек, который управляет процессом и блокерами.

Почему:

• Я не должен быть project manager
• Нужен кто-то, кто следит за сроками и рисками
• Может помочь разрешить конфликты

Идеальный profile:

• 3+ лет Scrum Master
• Сертификация (не обязательно, но плюс)
• Не микроменеджер, а фасилитатор
• Красный флаг: SM, который ведёт daily standup 30 минут

---

Размер команды в зависимости от проекта

Малый проект (1-3 месяца)

Минимум:

• 1 Product Owner
• 1 Architect
• 2-3 Developers
• 1 QA Lead
• Я как BA
• Total: 7 человек

Средний проект (3-6 месяцев)

Добавить:

• UX Designer
• Scrum Master
• 1-2 дополнительных Developer
• Total: 10-11 человек

Большой проект (6+ месяцев)

Добавить:

• DevOps engineer
• Data analyst (если нужна аналитика)
• 2-3 дополнительных Developer
• 1 Tech Writer (для документации)
• Total: 14-15 человек

---

Мой идеальный сценарий

Структура команды:

Product Owner ← → Я (BA)
       ↓            ↓
   Architect   QA Lead
       ↓            ↓
Developers (2-3) — Test Engineers
       ↓
   DevOps (если нужен)

Динамика:

• Daily standup 15 минут (я, architect, lead dev, QA lead)
• Weekly planning с PO (на 2 недели вперёд)
• Bi-weekly refinement с целой командой
• Sprint review с PO и stakeholders
• Retro с командой

Коммуникация:

• Slack для быстрых вопросов
• Confluence для документации
• Jira для tracking
• Weekly 1:1 с PO (15 минут)
• Bi-weekly 1:1 с Architect (30 минут)
• Monthly all-hands (план и results)

---

Характеристики идеальной команды

1. Психологическая безопасность

• Люди готовы задавать вопросы
• Не бояться сказать "это не сработает"
• Признают ошибки
• Нет микроменеджмента

2. Стремление к качеству

• Хотят делать хорошо
• Не довольствуются "достаточно хорошо"
• Делают code review
• Пишут тесты

3. Ориентация на результат

• Понимают, почему делают проект
• Могут сказать "нет" бесполезным фичам
• Измеряют успех метриками
• Готовы к итерации

4. Гетерогенность опыта

• Senior и junior микс
• Разные background (не все ex-Google)
• Разные типы мышления
• Внутренние и нанятые извне люди

---

Мои красные флаги при комплектовании команды

🚩 Избегаю таких людей:

• Senior девелопер, который не хочет слушать требования
• Product manager, который не может объяснить зачем проект
• QA, который только ловит баги, не предотвращает
• Architect, который за complexity ради complexity
• Team lead, который микроменеджерит
• Человек, который говорит "это не моя работа"

---

Что я МОГУ делать один (при нехватке бюджета):

• Собирать требования
• Создавать диаграммы
• Планировать спринты
• Вести документацию
• Проводить retrospectives

Что я НЕ МОГУ делать один:

• Быть Product Owner (конфликт интересов)
• Архитектурные решения (не мой уровень)
• Тестирование (нужен other perspective)
• Кодирование (нужна свежая пара глаз)
• Управление людьми (не я должен делать это)

---

Вывод

Идеальная команда это не 15 senior инженеров, а 10 хороших людей с разным уровнем опыта, которые:

• Уважают друг друга
• Понимают, зачем они вместе
• Готовы говорить правду
• Хотят делать хорошо
• Не боятся итерировать

Когда я выбираю проект, я выбираю людей, не только задачу.