Когда дело касается командной работы, размер команды часто становится предметом ожесточённых споров. Казалось бы, больше сотрудников — выше производительность. Но в реальной жизни всё намного сложнее. Именно это подробно разбирает Алекс Эверлёф в своём блоге, делясь личным опытом управления командой из 14 инженеров. Эта история особенно ценна тем, что она не предлагает «волшебную пилюлю», но чётко показывает: важно экспериментировать, пока не найдёшь подход, подходящий именно твоей команде.
🧩 Проблемы больших команд на практике
Команда Алекса столкнулась с типичными для больших команд проблемами коммуникации и производительности. 14 человек – это не просто число, это:
- 🥱 Скучные стендапы: Стендапы быстро стали бессмысленными: сотрудники зевали и не слушали друг друга, потому что обсуждались вопросы, касавшиеся только отдельных специалистов.
- 👻 Фантомные задачи: Внезапно обнаруживались задачи, которые никогда не появлялись в общем списке задач или на стендапах, но каким-то образом выполнялись.
- 📞 Асинхронность не спасла: Попытки перейти на асинхронные стендапы через Slack не решили главной проблемы — отсутствия реального диалога и интереса друг к другу.
🛠️ Попытки разделить команду по специализации
Один из первых подходов — разделение команды на две специализированные группы:
- 🎨 Фронтенд-команда занималась интерфейсом и дизайном.
- ⚙️ Бэкенд-команда отвечала за API, CI/CD и облачную инфраструктуру.
Эта идея звучала логично ровно до первого стендапа. Оказалось, что возникли новые проблемы:
- 🔄 Зависимости: Группы начали постоянно зависеть друг от друга, и коммуникация только усложнилась.
- 🕰️ Увеличение времени на стендапы: Многие сотрудники теперь посещали два стендапа, теряя ещё больше времени.
🎭 Введение гибких, временных команд (feature teams)
Попытка создать временные команды по конкретным задачам, таким как внедрение GDPR, выглядела многообещающе, но не решила всех проблем:
- 📌 Закреплённые ресурсы: Сотрудники постоянно были «заблокированы» в одной задаче и не могли легко переключаться на другие.
- 🚩 Проблемы поддержки: После завершения задачи было непонятно, кто отвечает за её поддержку.
🎩 Решение: от специалистов к генералистам
После множества экспериментов команда пришла к выводу: убрать строгие роли и перейти на модель генералистов — сотрудников, которые способны выполнять разные задачи (фронтенд, бэкенд, QA, DevOps).
Это привело к впечатляющим результатам:
- 🚀 Высокая скорость доставки: Сократились задержки из-за отсутствия узких специалистов.
- 🧑💻 Полная ответственность (You build it, you own it): Сотрудники получили доступ к инструментам и ответственность за свои решения, что повысило качество работы.
- 🌟 Повышение мотивации: Сотрудники начали чувствовать большую автономию и смысл в своей работе, что совпадает с идеями Дэниела Пинка («автономия, мастерство, цель»).
⚠️ Негативные последствия генерализма
Однако решение имело и «обратную сторону медали»:
- 💼 Потеря специалистов: Некоторые сотрудники покинули команду, не желая менять привычную специализацию.
- 🔥 Высокий риск выгорания: Из-за повышенной нагрузки некоторые генералисты были на грани истощения.
- 🧊 Отсутствие глубины: Сложнее стало погружаться глубоко в технологии, когда тебе приходится охватывать широкий спектр задач.
🧑🔬 Моё личное мнение и опыт
Из собственного опыта работы в разных командах могу подтвердить, что строгая специализация и большие команды часто создают больше проблем, чем решают. Модель генералистов требует особой культуры и зрелости команды, но окупается сторицей: повышением мотивации, скоростью разработки и гибкостью.
Однако важно понимать, что универсального решения не существует. Как справедливо подчёркивает Алекс, не стоит слепо копировать подходы других компаний, вроде знаменитой «Spotify модели». Вместо этого каждая команда должна найти своё собственное «лучшее решение» методом проб и ошибок.
Лично для меня самое важное из этой истории — не сама модель, а культура открытости к экспериментам и постоянного улучшения. Именно это, на мой взгляд, является ключом к эффективной работе в современных условиях.
📌 Выводы для руководителей и команд
- 🎯 Экспериментируйте: не бойтесь пробовать разные подходы и отказываться от тех, которые не работают.
- ⚖️ Ищите баланс между специализацией и генерализмом, исходя из особенностей вашего продукта и команды.
- 💬 Слушайте сотрудников и дайте им больше свободы и ответственности. Именно это мотивирует людей больше всего.
И помните слова Сундара Пичаи: «Scarcity breeds clarity» («Дефицит рождает ясность»). Иногда ограничения ресурсов помогают нам находить самые эффективные решения.
🔗 Полезные ссылки и источник: