Потоковые команды

В современном мире скорость поставки новой функциональности является определяющим критерием успеха ИТ-команд. Как правило, основными негативными факторами здесь являются дефицит ресурсов (времени, людей) и избыточная коммуникация для координации. Сегодня я хочу рассказать о прогрессивном подходе к организации команд, призванном ускорить поставку новой функциональности.

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

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

Искусственное разграничение на команды по специализации также лишает других разработчиков возможности приобрести востребованные навыки. К примеру, у вас есть отдельная команда для работы с базами данных (назовем ее для краткости "команда БД"), в ответственности которой находится внесение любых изменений в базы данных. На бумаге все выглядит отлично - ответственность распределена. Но со временем вы начинаете замечать, что разработчики начинают хуже понимать, как работают базы данных, и создавать программное обеспечение, неэффективно с ними работающее. Команда БД, в свою очередь, чтобы снять с себя ответственность за ошибки разработчиков, а также оградиться от неточно сформулированных запросов, создает все больше регламентов и административных барьеров, усложняющих кросс-командное взаимодействие.

Обратная ситуация, когда вы устраняете разграничение по специализации, не повлияет на способность специалистов выполнять свою работу. Наоборот, это увеличит пропускную способность, которую специалисты смогут использовать для решения сложных проблем, действительно требующих их внимания. В рамках приведенного выше примера, большая часть рутинной работы с базами данных, требующейся для реализации обозначенной функциональности, будет передана команде разработки. Команда БД будет разгружена от ежедневной рутины. В свою очередь, команда разработки не будет простаивать в ожидании решения блокирующих задач на стороне баз данных, а также научится лучше понимать устройство баз данных и начнет писать более эффективное программное обеспечение. Помимо всего прочего, вы избавитесь от извечного перекладывания ответственности и необходимости постоянно синхронизировать работу разных команд.

Преимущества потоковых команд, объединенных вокруг сквозной функциональности, выглядят убедительно. Как эффективно организовать работу потоковых команд и какие проблемы возникнут в процессе? В идеале, специалистов нужных компетенций необходимо объединить в отдельную команду. Однако, иногда может оказаться недостаточно работы для того, чтобы оправдать их постоянное присутствие в конкретной команде. В таком случае, специалисты вполне могут разделить свое рабочее время между несколькими командами.

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

Ответом на рассогласованность может являться создание команд поддержки. Команды поддержки - это специализированные (как правило, по технологическим стекам) команды, задачей которых является помощь потоковым командам в их работе с целью повышения их самодостаточности. Также, команда поддержки должна обеспечивать согласованность работы потоковых друг с другом. Помимо общения с целью обучения, команда поддержки может заниматься созданием общих ресурсов, стандартизирующих работу потоковых команд в рамках различных стеков технологий.

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

Общими характеристиками автономных, слабо связанных команд, по мнению авторов книги "Ускоряйся!", являются возможности:

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

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

Существует множество изменений, которые следует рассмотреть на пути к построению потоковых команд. Я выделю следующие моменты:

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

Закон Конвея показывает нам, что слабо связанная организационная структура приводит к слабо связанной архитектуре (и наборот). Это укрепляет идею о том, что проблематично получить преимущества слабо связанной микросервисной архитектуры без учета организационной структуры компании.

Небольшие команды работают быстрее, чем большие. Данное утверждение привело к появлению термина команд на две пиццы. Суть его заключается в том, что максимальный размер команды должен быть таким, чтобы ее можно было накормить двумя пиццами. Это не очень полезная единица измерения, однако смысл в том, что оптимальный максимальный размер команды - 8 человек. Эта команда должна быть ориентирована на клиента и владеть всем жизненным циклом своих сервисов. Было проведено научное исследование (Rodriguez D., Sicilia M. A., Garcia E., Harrison R. Empirical Findings on Team Size and Productivity in Software Development), результаты которого показали, что производительность труда имеет наихудшие показатели для команд, чья численность 9 и более человек. В книге "Думай как Amazon" есть замечательная цитата Джона Россмана про команды на две пиццы:

Выделяют две основные модели владения кодом - сильное и коллективное владение.

При сильном владении команда сама принимает решения о стандартах и применяемых технологиях. Данная модель владения повышает автономность команд. Чем более сильную модель владения может принять команда, тем меньше требуется координации, и следовательно, тем более продуктивным может быть коллектив.

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

Дополнительно к общей концепции команд поддержки, потоковым командам потребуется набор инструментов самообслуживания, позволяющим им выполнять свою работу - это платформа.

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

Платформе также требуется команда, которая будет управлять ее жизненным циклом. Команда платформы должна выяснять, с какими трудностями сталкиваются ее пользователи (программисты потоковых команд), и находить решения.

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