Ожидания против реальности
Отряды
Небольшая кросс-функциональная, самоорганизующаяся команда, они полностью владеют тем, что они создают, от сбора требований, проектирования, сборки, тестирования до выпуска и обслуживания. Обычно в их число входят руководитель проекта, инженер-менеджер, дизайнеры, бэкенд, инженеры по работе с клиентами, а иногда и специалист по контролю качества и инженер по данным.
Отряды обычно ориентированы либо на бизнес, либо на инфраструктуру. Каждая бизнес-группа сосредоточена на ключевой области бизнеса, такой как взаимодействие с пользователями, адаптация пользователей, каталоги продуктов или премиальные подписки. Другие группы больше озабочены инфраструктурой, то есть тем, как и где развертываются сервисы, инструментами для ведения журналов, установлением правил безопасности, предоставлением хранилищ данных, настройкой сети и круглосуточным мониторингом работоспособности системы.
Бизнес-команды определяются требованиями пользователей и бизнес-целями. Они работают с высокой автономностью и скоростью, чтобы не отставать от требуемых бизнес-функций и быстро превращать спецификацию в рабочую демонстрацию, которая может быть преобразована в сервис производственного уровня. Они запускают код в производство почти каждый день и полностью контролируют инструменты и ресурсы, которые они используют, такие как базы данных, кэши и задания cron.
Они больше заинтересованы в скорейшем выходе на рынок, чем в оптимизации задержки или стабильности. Решения принимаются «локально» внутри команды. Практически отсутствует координация и зависимость от других команд. Они проводят множество экспериментов, чтобы протестировать определенные функции и понять поведение пользователей. Их планы обычно меняются в зависимости от результатов экспериментов и новых возможностей для бизнеса.
На другом спектре есть команда по инфраструктуре, их основное внимание уделяется, ну, инфраструктуре всей компании! Итак, такие вещи, как кластеры Kubernetes, конфигурации терраформирования, разработка инструментов CI/CD, настройка панелей мониторинга работоспособности системы и SLO, оповещения о работе пейджера, и этот список можно продолжить. Они всегда горят. В отличие от бизнес-групп, здесь одна ошибка может повлиять на все другие команды.
Их работа поддерживает и позволяет бизнес-группам легко разрабатывать услуги. С помощью простых команд инженеры могут подготовить базы данных и развернуть свой код в различных средах. Кроме того, они осуществляют планы по переходу от устаревшего кода и источников данных, внедрению нового инструмента и внедрению инженерных методов. У них есть долгосрочные цели, и они смотрят в будущее.
Ожидания
В бизнес-команде руководитель проекта является отправной точкой. Они пишут документ, который определяет, какую функцию необходимо реализовать, почему мы это делаем, целевую аудиторию, ожидаемый результат и сроки. Решение о том, как, остается решать инженерам.
Затем бэкэнд-инженеры берут этот документ в качестве входных данных и переводят бизнес-спецификацию в документ технического проекта. Технический документ объясняет, как бизнес-функции или варианты использования будут реализованы на серверной части, и перечисляет все технические предположения и ограничения, API, запросы к базе данных и другие проблемы, такие как масштабируемость, тестирование и развертывание.
Инженеры-клиенты принимают этот технический документ в качестве входных данных, но их больше интересуют API (полезные нагрузки запросов и ответов); это их контракт с бэкэнд-людьми.
Очевидно, что в этом есть обратная сторона. Это никогда не бывает прямолинейным процессом. Меняются требования, меняются API, предположения оказываются ложными, а инженеры увольняются! Но как только они что-то собирают, они (надеюсь) тестируют это на сцене, запускают в производство и следят — а может и нет?
С другой стороны, команды по инфраструктуре имеют в списке меньше вещей, охватывающих более длительные периоды, и более четкое представление о том, что они будут строить в течение года. Их работа обычно начинается с выявления болевых точек инженеров: упрощение взаимодействия инженеров с их инфраструктурой, снижение барьеров для развертывания кода в рабочей среде и максимальное ускорение локальной разработки и тестирования.
Другие критические проблемы, которые могут быть неочевидны для других групп, но наносят ущерб стабильности, эффективности, безопасности и производительности инфраструктуры, например миграция из локальной среды в облако, принудительное применение разрешений и ролей доступа и замена нестабильных устаревших инструментов.
реальность
Накопленный технический долг, безусловно, является самой высокой стоимостью дополнительных доработок, вызванных тем, что бизнес-команды выбирают простые, хакерские и одноразовые решения для конкретных целей вместо того, чтобы использовать лучший подход, который занял бы больше времени. Инженеры всегда хотят двигаться быстро, их девиз — «автономность» — во имя Trust vs Control, и они не просчитывают долгосрочные последствия.
Это усиливается, когда разные отряды пытаются делать одно и то же снова и снова, так что много повторяющегося кода можно было бы унифицировать. У каждого отряда свои инженерные приемы и инструменты, поэтому смена отряда похожа на смену роты. Никаких унифицированных внутренних библиотек или SDK, некоторые используют AWS, некоторые используют GCP, некоторые предпочитают Golang, другие, такие как магия Ruby, … и этот список можно продолжить. Наивное представление о том, что свобода выбора сделает инженеров более эффективными в решении проблем, будет преследовать вас!
И в результате высокой независимости и почти полного отсутствия координации с другими командами — потому что кто хочет увязнуть в других командах, это создает разрозненность среди бэкенд-инженеров и клиентских инженеров во всех отрядах, разрозненность между бизнес-отрядами и отрядами инфраструктуры. Даже попытки соединить инженеров между отрядами обычно неорганизованны, неэффективны и, в конечном итоге, теряют приоритет. И это очень характерно для компаний, которые хотят получать доход в долларах или не могут проиграть свою конкуренцию на рынке, поэтому предотвращение технологического долга отходит на второй план.
Силосы не являются плохими по наследству. Они там по причине. Ключевой вопрос: послужит ли бункер нам?
Команда по инфраструктуре не рассматривается как еще одна команда по продукту/бизнесу с клиентами и спецификациями, которые необходимо выполнить. Разрыв между подразделениями бизнеса и инфраструктуры не редкость. Отряды Infrastrcutre редко зацикливаются на процессе технического планирования, потому что это требует дополнительной координации, и они обнаруживают несоответствия в системе только во время инцидентов. И они не будут пытаться опередить свои бизнес-команды и вмешаться как можно раньше, потому что ресурсы ограничены, они заняты другими делами!
Инфраструктурные отряды, как правило, увлекаются ажиотажем вокруг новых технологий, не принимая во внимание потребности других команд и последствия этих решений для других отрядов. И в результате новые инструменты воспринимаются как блокиратор, а не облегчение, вызывая еще большее разочарование, напрасные инженерные усилия и увеличивая технический долг.
И, в конце концов, то, что раньше занимало один день, теперь занимает неделю, если не больше.
Платформенные и продуктовые команды
На высоком уровне команды по платформе и продукту могут показаться похожими на команды по бизнесу и инфраструктуре. И да, есть некоторое совпадение, но поток коммуникаций, командное планирование и приоритеты, необходимые бизнес-знания и инженерные навыки… не одно и то же.
Команды платформы обычно состоят из двух уровней: один уровень заботится обо всех элементах инфраструктуры, таких как Kubernetes, хранилища данных, сети, а другой уровень поверх него создает инструменты разработки, библиотеки, фреймворки, централизованные системы отслеживания событий и планирования. , флаги функций, A/B-тестирование и эксперименты, а также любые распространенные проблемы, с которыми сталкиваются инженеры, мешающие им изобретать велосипед. Они также обмениваются знаниями и опытом, а также определяют передовой опыт и рекомендации по архитектуре.
Платформенные команды — это, по сути, продуктовые команды. У них есть пользователи (инженеры в компании), долгосрочные планы и сроки, с меньшим количеством проектов и более четкими миссией и целями (например, сокращение среднего времени развертывания на 30%), где успех означает предоставление реальной ценности другим командам инженеров и защиту. их от меняющихся сложностей базовой инфраструктуры.
Платформенные команды должны понимать не только собственную архитектуру и потоки, но также широкий спектр потоков продуктов и бизнес-целей. Они заглядывают в будущее, чтобы увидеть, как их материал будет использоваться, как он может развиваться и как можно управлять будущим переходом.
Продуктовые команды очень похожи на командные бизнес-команды: они работают с внешними пользователями, переводят бизнес-требования и выясняют, что им нужно создать. Они часто сосредотачиваются на создании прототипов и проведении экспериментов, они хотят двигаться быстро, чтобы конкурировать с другими конкурентами, поэтому они склонны жертвовать надежностью и стабильностью ради скорости, дохода и конкурентного преимущества.
Ожидания
Там, где командные группы предпочитали автономию, независимость и небольшую координацию, команды платформы и продукта координируют планирование на раннем этапе. В каждой продуктовой команде есть контактный инженер из команды платформы во время процесса планирования, в ходе которого они обсуждают, над чем будет работать команда продукта, их цели и сроки, а также необходимые инструменты. Это работает и в другую сторону! Команда платформы сообщает им, когда приближается миграция, чтобы они могли учесть это в своих планах, или устаревший инструмент, который они больше не могут использовать, или технология, которая не соответствует стандартам безопасности.
Команды платформы не участвуют в планировании, поэтому они создают одноразовые настраиваемые инструменты для команд разработчиков! Они участвуют, чтобы понять, понять и устранить общие болевые точки. Например, упрощение процесса развертывания и тестирования, создание внутренних платежных API, библиотек для доступа к источникам данных, среды тестирования, системы публикации и подписки, системы отслеживания событий и т. д. Они также служат руководством, помогающим инженерам принимать устойчивые проектные решения и убедитесь, что команды придерживаются стандартов качества кода и тестируемости. Таким образом, координация во время планирования работает лучше от платформы к продукту, чем наоборот.
Платформенные команды должны опережать требования, исходящие от продуктовых команд, потому что в противном случае, если платформа не сможет реагировать на их потребности достаточно быстро, продуктовые команды могут в конечном итоге взломать ее вместе, чтобы их разблокировали. Они должны найти баланс между тем, чтобы быть помощниками и защитниками, защищая продуктовые команды от причинения вреда себе и другим.
Руководители проектов, инженеры, технические руководители и старшие разработчики должны все участвовать в этом процессе планирования. Существуют четкие каналы поддержки, чтобы знать,где, когда и как они могут получить поддержку от команды платформы, четкий процесс для команды платформы для работы с командой продукта над запросами функций и четкие границы между платформы и неплатформенные команды о том, что они делают и чем владеют.
Здесь тратится больше усилий на координацию и коммуникацию. Инженерам приходится работать с людьми, не входящими в нашу команду, что сопряжено с некоторыми накладными расходами. И поэтому готовность помогать другим, терпеливое отношение к техническим заказчикам, понимание и прислушивание к точкам зрения являются важными навыками, которыми должны обладать инженеры. Долгосрочная выгода перевешивает накладные расходы на связь+, которые заключаются в повышении уровня безопасности, надежности и сокращении инженерных усилий разработчиков по выпуску функций.
реальность
Это сложнее.
Продуктовые команды могут рассматривать команду платформы как узкое место и избегать их участия, поскольку это требует дополнительных усилий по координации. Поэтому они делают то, что считают правильным. К тому времени, когда об этом узнает команда платформы, она уже находится в производстве, и это, очевидно, приводит к разочарованию. Инженеры по продукту просто старались действовать быстро, и они не думают, что сделали что-то неправильно! В то же время команда платформы должна взять на себя инструмент или исправить технический долг, к созданию которого они не приложили руку, и, возможно, сделать его полезным для другой команды и поддерживать ее продвижение вперед.
Ни команда продукта не сообщает о необходимости этой функции, ни платформа не говорит о препятствиях, с которыми они сталкиваются. И когда команда платформы зацикливается, они постоянно работают над выполнением разовых запросов, что снижает производительность. Важно выяснить, что пытаются сделать команды разработчиков продукта, и заранее спланировать, как обеспечить необходимую поддержку.
Иногда команда платформы слишком сильно лишает себя автономии, устанавливая очень строгие ограничения и стандарты для своего развития. Команда разработчиков рада испытать передовые технологии, но команда платформы отказывается от них без уважительной причины. И когда происходит миграция, у продуктовых команд возникает дополнительная работа по переходу на новый инструмент, что не является тривиальным процессом. Они расстраиваются из-за повышенных требований к обновлению и миграции. Хуже того, процесс миграции плохо задокументирован, поэтому у них есть миллион причин его игнорировать. Никто не доволен переходом с локальной среды на AWS, когда он неожиданно появляется в дорожной карте продуктовой команды.
Общение и сотрудничество не считаются работой и/или не учитываются при планировании. Инженерам важно отслеживать в своих календарях время, потраченное на паузы и встречи.
Отсутствие правильных инженеров обычно игнорируется. Вы идете к врачу, когда вы больны, но не для того, чтобы преподать вам урок истории! Инженерное мышление здесь другое. Коммуникация является приоритетом, сопереживание клиентам является критическим навыком, требуются двойные усилия по координации, приоритеты сместились и больше не связаны только с бизнесом, все замедляется, и менеджеры действительно должны быть в курсе всего или иначе они разобьются, как картошка.
Состав → Платформенные и продуктовые команды
Обычно компании начинают с команд Squad, затем они попадают в ловушку технического долга и понимают, что у них уходит много времени на поставку в производство или текущий стек не способен справиться с возросшим спросом.
Поэтому они говорят: «О, нет!»
Каждое новое предлагаемое изменение может решить некоторые из первоначальных проблем, но, как и все в мире программного обеспечения, оно также создает новый набор проблем, о которых мы должны знать и готовы платить за это.
Переход от подхода «Отряд» → «Платформа и продукт» требует изменений не только в структуре, но и в мышлении. И самое трудное для изменения в любом человеке — это его поведение. Это относится и к инженерам, и к менеджерам. Чтобы извлечь выгоду, требуется время и гораздо больше усилий. Например, бэкэнд-разработчики «платформы», которые раньше работали изолированно и писали bash-скрипты, теперь столкнутся с дилеммой координации работы и прислушивания к потребностям групп «продукта». И у нас не может быть менеджеров как единственного канала связи, особенно при согласовании технических деталей.
В командах Squad, если инженер хотел оптимизировать свой сервис или создать инструмент, ему не нужно было обращаться к какой-то другой команде. Это все в рамках одного отряда. Между другими инженерами за пределами отряда меньше общения, поэтому меньше накладных расходов. С новым подходом общение становится болью. Например, разработчики платформ должны опережать требования своих продуктовых команд. В противном случае они будут восприниматься как «блокировщики», что может привести к разочарованию. Практически невозможно предотвратить это. Продуктовые команды хотят двигаться быстро, возможно, с краткосрочными целями, в то время как разработчики платформы работают над долгосрочными инициативами, предпринимая небольшие обдуманные действия.
Замедление прогресса и удвоение инженерных усилий. При новом подходе разработчикам платформ необходимо понимать не только инфраструктуру, но и потребности бизнеса. В конце концов, они помогают продуктовым командам создавать функции, поэтому им нужно знать «почему». Это требует двойных инженерных усилий. Например, проверка кода будет включать кого-то из команды платформы, а также команды продукта. Количество встреч удвоится. Количество вовлеченных менеджеров увеличивается, а также время, необходимое для получения согласия.
В заключение можно сказать, что выгоды любого из них могут перевесить трудности и проблемы, но обычно компании не задумываются об этом!
В эпоху влиятельных лиц неудивительно, что компании слепо следуют некоторым статьям только потому, что они были написаны какой-то библейской компанией, когда эта компания не следует им, но творит чудеса для их маркетинга и найма! удачи!
Спасибо за чтение!
Хотел бы подключиться на LinkedIn. Пожалуйста, не стесняйтесь сказать: Привет!
