Микросервисы и организационная структура. Какие типы команд обеспечат успех?

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

    Традиционный подход


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

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

    Примечание: Менталитет обособленности (a Silo Mentality) — это нежелание делиться
    информацией с сотрудниками других подразделений той же организации. Такое
    поведение часто приводит к снижению эффективности организации и, в худшем
    случае, приводит к разрушению корпоративной культуры.


    Более того, в строго функциональных подразделениях, процесс принятия решений неизбежно замедляется. Затраты на согласование рабочих графиков команд увеличиваются. Квалификация и опыт тех же тестировщиков, к примеру, нуждается в постоянном балансировании с учетом специфики, которая требуется командам разработки. Да и высокий порог входа и необходимость передачи знаний замедляют процесс: привлекаемым извне специалистам требуется постоянное переключение контекста задач для обслуживания запросов, поступающих от различных команд.
    Таким образом, когда компании с традиционной организационной структурой столкнулись с необходимостью практически мгновенной реакции на вызовы, непрерывно поступающие от бизнеса, их IT подразделения оказались неспособными обеспечить эффективность решений. Стремительное эволюционирование технологий только усугубили это отставание и усложнили задачи поддержания требуемого уровня мотивации и профессионализма в выделенных, обслуживающих разработку, командах. А поскольку основной задачей IT было и есть эффективное обеспечение полного жизненного цикла автономных продуктов (в том числе, микросервисов), то стало очевидна необходимость реорганизации команд из горизонтально-ориентированных функциональных — в вертикально-ориентированные, самодостаточные и автономные команды.

    Кросс-функциональные команды


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


    Рисунок 1. Функциональные и кросс-функциональные команды.

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

    Шамим Мохаммад, ІТ-директор CarMax, говорит: «В стремительно эволюционирующем мире важно создать гибкие, кросс-функциональные продуктовые команды, которые могут быстро перебирать варианты решения задачи. Они наделены всеми необходимыми полномочиями и руководство никогда не говорит им, как решить проблему, а только в чем она заключается и каковы ключевые показатели эффективности, с которыми нужно работать. Такой подход позволяет улучшить обратную связь, значительно ускорить процесс разработки, использовать метод проб и ошибок, чтобы в конечном счете найти наилучшее для клиентов и партнеров решение. Мы также обнаружили, что команды более разумно рискуют и проявляют творческий подход в достижении поставленных целей. Если у вас нет таких полностью интегрированных команд — присмотритесь и подумайте, готовы ли вы к успешной цифровой трансформации?».

    Согласно опросам «Massachusetts Institute of Technology» и «Deloitte Global Human Capital Trend» компании с высоким уровнем цифровизации процессов в развитии своих инноваций чрезвычайно зависят от наличия кросс-функциональных команд. 83% зрелых компаний признают, они используют кросс-функциональные команды. Несмотря на возросшую операционную сложность (дополнительные расходы составляют до 16%), компании получили значительное улучшение операционных показателей (до 53%), усовершенствованный доступ к ресурсам и активам (до 37%), большую гибкость (до 12%) и снижение уровня избыточной бюрократии благодаря сокращению иерархии организационной структуры (до 11%).


    Рисунок 2. Преимущества адаптации кросс-функциональных команд. Статистика.

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


    Рисунок 3. Переход к кросс-функциональной команде.

    Возникновение платформенных команд


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

    • Синхронизация (согласованность) данных;
    • Устаревание данных;
    • Безопасность;
    • Межсервисная коммуникация;
    • Обнаружение сервисов;
    • Распределенное логирование и мониторинг;
    • Циклические зависимости между сервисами и отладка;
    • Тестирование;
    • Надежность и отказоустойчивость;
    • Производительность.

    Большинство из них не являются локальными задачами какого-либо конкретного микросервиса. Это – задачи уровня системы в целом и больше относятся к инфраструктуре микросервисной системы. Многие организации называют эту инфраструктуру «платформой», фундаменту, на основе которого создаются и развиваются микросервисы.

    Фактически, при разрастании организации, повышается уровень ее зависимости от используемых технологий. Все чаще возникают множественные области рассогласования, что приводит к потере организацией способности к быстрому продвижению на рынке, оценке появляющихся возможностей и инновациям. Возможным выходом из данной ситуации является переход к использованию «цифровой платформы», состоящей из «блоков возможностей» в важнейших областях деятельности организации (таких как инфраструктура доставки решений или взаимодействие с клиентом). Цифровые платформы позволяют минимизировать брешь между концепциями и инвестициями; повысить стабильность системы и, что еще важнее, — улучшить микроклимат внутри организации.

    Многие IT организации задаются вопросом: какое количество персонала необходимо выделить для работы непосредственно над «продуктом», а какое – для работы над «платформой»? Одним из важнейших аргументов пользу подобного разделения персонала является следующий: цифровая платформа нуждается во владельцах, посвятивших себя обеспечению соблюдения принципов, декларируемых платформой, имеющих большой опыт и высокий уровень экспертизы в разработке, внедрении и сопровождении платформ.

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

    Как бы ни был прост канал, он все же требует владельца. И если есть множество команд, каждая из которых «владеет своим микросервисом», тогда кто отвечает за их взаимодействие? За обнаружение сервисов, за безопасность, мониторинг на уровне целой системы (или даже на уровне организации, если речь идет о межсистемном уровне)? Кто будет ответственен за всестороннее тестирование? Если мы начнем возлагать эти обязанности на те или иные команды разработки микросервисов, то какова будет наша стратегия и критерии выбора? И, наконец, останутся ли такие команды (разработки, напомню) по-прежнему гибкими и автономными в своих продуктах? Похоже, настал момент, когда на сцене должна появиться команда разработки платформы!

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

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

    • Инфраструктура доставки;
    • Архитектура и исправление API;
    • Данные самообслуживания;
    • Экспериментальная инфраструктура и телеметрия;
    • Взаимодействие с клиентом.


    Рисунок 4: Стратегия цифровой платформы

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

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

    К преимуществам можно отнести:

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

    К недостаткам можно отнести:

    • временные затраты для адаптации стратегии в организации;
    • необходимость в дополнительных ресурсах — платформенной команде требуется изучить специфику работы различных микросервисных команд, а также сформировать требования для создания унифицированной платформы;
    • если платформа будет неправильно реализована, она станет «узким местом» в процессах организации.

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

    Синергия взаимодействия


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

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


    Рисунок 5: Взаимодействие с командой разработки платформы: слева — платформа как продукт, справа — проникновение в команды.

    Заключение


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

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

    Комментарии 8

      0
      Вы уж извините, но 10 из 10 в булшит бинго. Платформенная команда это такое сборище дармоедов с огромным ЧСВ, которые как-бы формируют стратегию и вообще самые главные. А на деле сборище архитектурных астронавтов, от которых кроме цветных прямоугольничков и слова таксономия никакой пользы. Причем их «очень важные архитектурные решения» зачастую просто кривы (привет хранилищу всего, где данные, которые вообще-то матрица, хранятся по одному числу в записи и записи разных типов в одной таблице), завязаны на их любимые технологии (а у меня, например, другие и выбор их обоснован ровно так-же — мне нравится) или вообще не доходят до тех, кто реально что-то делает (была-же email рассылка в прошлом месяце! почему вы не по стандарту работаете?).
        +1
        просто в платформенной команде должны быть не одни манагеры, а желательно разработчики, которые будут исследовать текущий опыт в ИТ и брать технологии/библиотеки не «потому что у Васи такая же» или «я с ней 10 лет назад работал», а потому что она лучше подходит для наших задач — вот смотрите бенчмарки.
        В общем, рисунок где платфрменные члены команды протикают в продуктовые… команды — плохой вариант. Лучше когда наоборот :)
          0
          По поводу рисунка. Я хотел просто проиллюстрировать связь между продуктовыми и платформенными командами через определенных представителей, входящих в состав продуктовых комманд. А кто будут эти представители — обсуждаемо и зависит от конкретного контекста :)
          Принципиальна сама разница между этим вариантом и вариантом «Платформа как продукт», где непосредственная коммуникация между продуктовыми и платформенной коммандами не предусмотрена, хотя, конечно, может (и должна) существовать опосредованно. Да и тема не исчерпывается только этими двумя вариантами, они приведены для примера.
          Спасибо за Ваш комментарий!
          +1
          Риск «появления дармоедов» присущ любому коллективу. Тут, скорее, вопрос культуры в организации и командах. Но необходимость наличия платформенных команд мне кажется очевидной по мере роста сложности тех «меж-командных» concerns, которые проиллюстрированы выше. Особенно, если организация предоставляет свою платформу как продукт на рынок (в том или ином виде). И чем выше прогнозируемая сложность, тем ранее должен быть решен вопрос владения платформой.
          Спасибо за Ваш комментарий!
          0
          — Проникновение в микросервисные команды, когда в микросервисной команде присутствует представитель платформенной команды (или же один из членов микросервисной команды выделен для коммуникации с платформенной командой). При использовании данного подхода микросервисные команды имеют возможность более быстрой обратной связи с платформенной командой и могут инициировать процесс внедрения в платформу тех или иных изменений.

          Первое (наличие представителя платформенной команды в команде микросервиса) — не работает. Второе — работает. Проверено на опыте.


          Еще одним интересным следствием описанной парадигмы является возможность полностью аутсорсить разработку микросервиса на сторону. А в головной компании оставить только стратегию. Выгодны понятны — профессионалы в отдельных компаниях, занимающихся профильной деятельностью, уже обучены и готовы работать качественно. Остается вопрос контроля.
          И даже платформенное решение может быть построено из сторонних SaaS компонентов (напр., aws, managed DB, Gitlab)

            +1
            Только не нужно забывать, что платформа — это не только компоненты хостинга, транспорта, данных и т.д., но в большей степени предметно-ориентированная эко-система бизнеса. И тут, как раз, знание «чистых» компонент помогает мало.
            Что касается «стратегии в головной», быстро наступает оторванность от реалий. И если с непрофессионалами еще можно казаться молодцом, то как раз профессионалам с вами будет скучно и они предпочтут большую вовлеченность в другой компании или форкнут свой вариант продукта с более прогрессивными характеристиками.
              +1
              Полностью согласен с первой частью комментария.
              Что касается «оторванности от реалий» — она неизбежна в любом случае если мы перестанем валидировать окружающий нас контекст (организационный в данном случае — интеграцию с другими командами/организациями).
              Связанность команд/организаций контрактами никуда не девается. Сторонние микросервисные команды связаны и сверху (потребителями микросервиса) и снизу (платформой). Платформенная же команда зависит и как от consumers (обратная связь от микросервисных команд) так и от своих стратегических целей.
            0
            Довольно распрастраненная проблема, что в платформенную команду попадают люди с недостаточным опытом и квалификацией, т.к. у менеджера «людей нет». Максимум один понимающий, а остальные: админ, который «DevOoops» и «пишет на коленке», джуны, которые, на самом, деле интерны-геймеры… И на выходе проваленая поставка, т.к. «они поменяли API, т.к. им этого было достаточно» и «ждут, когда вы напишите сервисы, чтоб потестить API». Эх…

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

            Самое читаемое