Собирал ли команду с нуля

Мой опыт сборки команд с нуля

Да, собирал команды с нуля многократно в разных контекстах. Это один из ключевых и наиболее сложных навыков IT Project Manager. Процесс никогда не бывает шаблонным, но я выработал четкую методологию, которую адаптирую под конкретный проект.

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

Мой подход состоит из нескольких взаимосвязанных фаз:

1. Анализ и планирование (Pre-Kickoff)

• Глубокий анализ требований проекта: Технический стек, архитектура, сроки, бюджет. Это основа для профилей компетенций.
• Создание RACI-матрицы и карты ролей: Определяю, какие роли критичны на старте (часто Tech Lead, Architect, ключевой Backend), а какие подключатся позже (напр., QA Automation, DevOps).
• Разработка онбординг-плана: Как мы будем интегрировать нового человека: доступы, документация, первый таск.

2. Подбор и оценка (Recruitment & Assessment) Здесь я тесно сотрудничаю с HR и техническими лидерами. Моя роль — не проводить собеседования за них, а быть «заказчиком» команды.

• Формулирую четкие запросы: Не просто «нужен Java-разработчик», а: «Нужен мидл+ с опытом в Spring Boot и Kafka для разработки модуля обработки платежей, важно умение работать в распределенной команде».
• Участвую в финальных интервью на «культурное соответствие»: Оцениваю soft skills, мотивацию, способность работать в нашей методологии. Задаю кейсы из будущего проекта.
• Организую практические сессии (workshop style interview): Например, небольшой групповой разбор архитектурной задачи для кандидатов на lead-роли.

3. Интеграция и запуск (Forming & Storming) Самая важная фаза. Команда собрана — теперь нужно превратить ее в работоспособный организм.

• Провожу командный kick-off: Общая картина проекта, ценности, правила игры. Не только «что делать», но и «как мы будем работать».
• Инициирую создание «рабочих соглашений» (Working Agreements): Команда сама устанавливает правила: время стендапов, ревью кода, коммуникации. Это повышает ответственность.
• Запускаю первый короткий спринт или итерацию с простыми, но значимыми задачами: Цель — быстро получить первое чувство победы, наладить цикл «задача-код-тест-деплой».
• Внедряю инструменты с первых дней: Настраиваю Jira/Confluence, Slack-каналы, CI/CD пайплайн (пусть и минимальный). Пример того, как мы документируем соглашение по код-ревью в README.md репозитория:

## Процесс Code Review
1. **Мердж-реквест (MR)** создается на каждую задачу.
2. **Минимум 1 апрув** от коллеги, не являющегося автором.
3. **Критерии апрува:**
   - Код соответствует стандарту (проверяем линтером).
   - Покрытие unit-тестами не снизилось.
   - Нет утечек безопасности (запускаем SAST-сканирование).
4. **Стиль общения в ревью:** "Можно улучшить вот здесь..." вместо "Ты сделал ошибку".

4. Формирование и развитие (Norming & Performing)

• Регулярные ретроспективы: Особенно частые на старте (раз в неделю), чтобы оперативно снимать блокеры.
• Менторинг и ротация пар: Связываю опытных и новых разработчиков для передачи знаний.
• Фокус на развитии T-shaped компетенций: Поощряю изучение смежных областей (бэкенд-разработчик понимает основы инфраструктуры).

Ключевые вызовы и их решения

• Вызов: «Звездный» разработчик с низкими soft skills демотивирует команду.
• Решение: Четко договариваюсь о правилах взаимодействия с первого дня. Подключаю Tech Lead как формального ментора для такого специалиста, направляя его экспертизу в конструктивное русло (проведение внутренних воркшопов, код-ревью).
• Вызов: Команда из специалистов разного уровня (джуны и сеньоры).
• Решение: Использую парное программирование и четкое распределение задач по принципу «вертикальных срезов» (фича затрагивает и бэк, и фронт, и тесты), а не «бэкенд-джун делает только простые CRUD».
• Вызов: Удаленный/гибридный формат.
• Решение: Внедряю «перекрывающиеся часы» для всех членов команды, обязательные ежедневные видео-стендапы с включенными камерами, и выделяю время на неформальное общение (virtual coffee breaks).

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