В книге “Мифический человекомесяц” Фредерика Брукса описан интересный подход: организация команды по принципу хирургической бригады.

В чём суть?

Суть в разделении труда, а точнее — обязанностей и специализации.

Вместо “у нас в команде пять программистов” команда делится чётко по специализациям, каждый выполняет только свою роль и сосредотачивается на ней полностью. В команде хирурга только сам хирург режет скальпелем, остальные ассистируют — тем самым облегчая самую важную задачу. Каждый выполняет свою часть задачи и тем самым вся команда работает быстро и слаженно.

А в разработке?

Какие могут быть роли в команде разработки?

Ну например:

• Архитектор — разработка требований и внешнего дизайна продукта
• Менеджер (администратор) — управление задачами, отслеживание сроков, отчётность, общение с заказчиками
• Разработчик реализации, имплементатор
• Разработчик тестов
• Разработчик вспомогательного инструментария
• Тестировщик

Погодите, ведь такие роли уже есть?

Да, сейчас во многих компаниях есть разделение на бэкенд, фронтенд, тестирование и управление командой (продакты, проджекты, тимлиды).

Это лучше чем ничего. Но набор ролей часто просто заимствуется с других компаний, и это менее эффективно чем создание ролей под нужды своей компании и продукта.

К тому же разделение в командах не всегда чёткое. Например, часто бывает что тимлид помимо управления командой ещё и пишет код. Это уступает в эффективности чёткому и строгому разделению ролей.

В чём плюсы?

Рассмотрим на примере вспомогательных утилит, которые нередко разрабатываются в крупных компаниях.

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

При разделении ролей, каждый член команды может сосредоточиться только на одной задаче, максимально углубиться в неё, найти способы работать быстрее и качественнее.

А ещё плюсы?

Имея выделенную роль главного архитектора системы, которому подчиняются остальные члены команды, мы в результате получим концептуальную целостность продукта.

Когда архитектура системы разрабатывается одним человеком, то она более согласована и логична.

Если архитектор занимается технической стороной, то у нас будет стройная система с которой легко работать разработчикам.

Если архитектор сосредоточен на пользовательском опыте, то пользователи оценят то как согласованы в ней все её составные части.

Если и то и другое лежит на архитекторе, то команда будет легко внедрять новую функциональность, улучшающую опыт пользователей.

Куда девать освободившееся время?

Понятно, что если разработчика посвятить только одной задаче, то многие из них выполнят всё что необходимо и часть времени будут “простаивать”.

Тогда придёт менеджер и спросит “почему у нас N сидит без дела?”

Здесь главное понять, что благодаря разделению должна повыситься эффективность всей команды, и это выражается в том что команда будет успевать делать больше полезной работы за один отрезок времени.

Если при этом часть команды вынужденно простаивает, то хоть это и неприятно начальству, но это хороший знак: у команды есть запас по ресурсам.