Почему платформенные команды негативно влияют на систему

Одно из частых управленческих решений в ИТ — выделение отдельных «платформенных» команд. Обычно такие команды занимаются или инфраструктурой, или системой доставки кода, или общими библиотеками, или даже «ядром продукта». Иногда таких команд делают несколько, иногда одна команда занимается всеми четырьмя частями.

Мотивация у такого решения — скрыть сложность от продуктовых команд, которые доставляют потоковую ценность, тем самым повысив их эффективность и продуктивность.

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

Быстро — не всегда хорошо

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

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

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

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

Расслоение разработчиков

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

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

И что делать?

Я не хочу сказать, что платформенные команды совсем не нужны. Платформенные команды создаются для того, чтобы скрывать сложность, чтобы не делать из раза в раз одно и тоже. Это полезно. Но нужно держать границы платформенной команды под контролем. Платформенная команда должна быть Thinnest Viable Platform — должна абстрагировать сложность и являться сервисом для продуктовых команд, а не быть надзорным органом.

Заметили слова «сервис» и «платформа» в одном предложении? В современном мире уже существуют множество Platform as a Service, которыми можно пользоваться и многие так и делают. Так что, возможно, вам не нужна собственная команда платформы.

Источники