Uncategorized

Разработка вашей организации с помощью сервисов, платформ и сообществ

Организации должны иметь возможность стабильно приносить пользу своим клиентам и бизнесу; Вот почему они существуют, – сказал Рэнди Шуп на QCon Plus в мае 2021 года. Для этого им необходимо эффективно и рационально использовать имеющиеся в их распоряжении «ресурсы» – своих людей, команды и технологии.

Шуп обсудил три механизма, которые организации используют для разделения работы: сервисы, платформы и сообщества:

Услуги отражают различные части бизнеса, или то, что Domain Driven Design назвал бы «доменами».

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

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

Эти механизмы не исключают друг друга; По словам Шупа, большинство крупных организаций используют их все.

Чтобы способствовать психологической безопасности и инклюзивности, лидеры могут сделать одну небольшую, но важную вещь – убедиться, что все точки зрения будут услышаны в обсуждениях и встречах, как объяснил Шуп:

Если говорят только белые люди (это не редкость), обязательно поощряйте участие других членов команды: «Как ты думаешь, Х?» Моделирование такого поведения в качестве лидера необходимо, но далеко не достаточно! — шаг.

InfoQ взяла интервью у Рэнди Шупа, вице-президента по проектированию и главного архитектора eBay, о технических организациях.

InfoQ: Как eBay организует свои услуги в зависимости от сферы своей деятельности?

Рэнди Шуп: На самом высоком уровне у нас есть домен для продажи, домен для покупки, домен для поиска, домен для платежей и т. Д. («Домен» – это фактический термин, который мы используем для этих подразделений). Каждый из этих очень больших доменов состоит из меньших доменов, обычно спускающихся вниз на несколько уровней. В идеале на «листовом» уровне этого организационного дерева каждая отдельная команда разработчиков отвечает за один и только один субдомен, а также создает и поддерживает небольшой набор (микро) сервисов.

Мы организовываем это по многим причинам:

  • Мы можем поддерживать команды-долгожители в каждой конкретной области, и эти команды могут развить глубокие знания в своей области.
  • Мы можем создать конкретную возможность в одном и только одном месте (обычно!)
  • Мы можем использовать друг друга с помощью четко определенных API.

Любой, кто знаком с законом Конвея, увидит, что организация и архитектура услуг дублируют друг друга – каждая отражает и усиливает друг друга. Архитектура микросервисов поддерживается и отражается организацией автономных команд.

Как вы понимаете, со временем такая экосистема команд и сервисов развивается. Мы добавляем службы, отказываемся от них и т. Д. Может показаться, что все постоянно меняется. Например, в Google есть хорошо известная шутка о том, что «все службы либо устарели, либо еще не готовы». Конечно, может так казаться!

Когда конкретной команде необходимо провести рефакторинг своей службы (служб) – обычно для исключения новой, но иногда для объединения двух из них – им нужно взаимодействовать только с командами, которые непосредственно затронуты, и часто эти команды «близки» by “в организации. Это сокращает накладные расходы на изменения и упрощает развитие.

InfoQ: Какие возможности платформы могут предложить командам разработчиков?

Shoup: Я не думаю, что когда-либо работал в компании, в которой не было бы какой-то команды разработчиков платформы. Что обычно является частью платформы? Подумайте об инфраструктуре (например, публичное или частное облако), общих возможностях (аутентификация, управление секретами, наблюдаемость и т. Д.) И опыте разработчика (конвейеры компакт-дисков, контроль версий и т. Д.).

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

Возможность здесь состоит в том, чтобы предоставить простой в использовании «асфальтированный путь», который снижает когнитивную нагрузку на команды разработчиков и делает использование общей платформы путем наименьшего сопротивления. Если я использую общую платформу, многие вещи предоставляются бесплатно, и мне не о чем беспокоиться. Итак, чтобы я мог выбрать что-то еще, это должно быть * намного * лучше для моего конкретного случая использования.

InfoQ: Почему мы должны взимать с внутренних клиентов плату за использование платформ?

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

Я усвоил этот урок в Google App Engine, когда одна из наших клиентских команд внутри страны потребляла около 25% очень дорогих и очень дефицитных ресурсов в глобальном масштабе. Несмотря на то, что мы взимали плату с внешних клиентов, а сами взимали плату внутри компании, в то время внутреннее использование App Engine было бесплатным. Не получалось ни спрашивать команду, ни попрошайничество, ни угрозы; Для них просто не было главной задачей облегчить жизнь моей команде. Но как только я отправил им счет за то, что мы должны были бы выставить извне – а в этом счете было много нулей! – они почти сразу смогли сделать оптимизацию своего использования приоритетной задачей. Они сократили время использования в 10 раз и, как прямую выгоду, получили лучшую задержку от App Engine. Экономические стимулы работают.

InfoQ: Как мы можем организовать сообщества практиков?

Shoup: Будь то каналы Slack, внутренние группы, регулярные встречи или комбинация всего вышеперечисленного, есть огромная ценность в поощрении разработчиков, которые, например, используют одну и ту же языковую структуру, выполняют ту же роль или практикуют те же методы, чтобы сотрудничать.

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

Сила внушения тоже работает. На eBay несколько команд независимо друг от друга использовали GraphQL для своих внутренних сервисов в течение нескольких лет, но эти команды работали независимо. С небольшим толчком со стороны руководства участвующие команды сформировали рабочую группу (с каналом Slack ;-)), чтобы помочь поделиться идеями и продвинуть GraphQL более широко внутри eBay.

InfoQ: Как лидеры могут способствовать психологической безопасности и инклюзивности?

Shoup: Как показывает исследование Project Aristotle в Google, психологическая безопасность (недавно перефразированная ее первоначальным сторонником Эми Эдмондсон как «ощутимое разрешение на откровенность») является самым важным фактором, определяющим успех команды. Эта командная динамика важнее любых индивидуальных характеристик членов команды. Понимание здесь состоит в том, что если мы не слышим точку зрения всех, мы принимаем более плохие решения, чем в противном случае, и фактически «оставляем деньги на столе».

Как говорил руководитель Xerox PARC Боб Тейлор: «Никто из нас не так умен, как все мы».

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button