«Нужна культура, в которой команды действуют как датчики»: интервью о разработке платформ

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

Мы поговорили с Паисом о том, как использовать командные топологии и как они взаимодействуют с platform engineering.

The New Stack: Как появились командные топологии?

Мануэль Паис: У меня 20-летний опыт работы на разных должностях: начиная с разработки, тестирования, тимлида и заканчивая консультированием, особенно в отношении DevOps и непрерывной доставки. Я познакомился с Мэтью, и мы начали совместную работу в этих консультационных проектах с клиентами по всему миру, в основном начиная с «мы хотим внедрить DevOps».

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

Работая с клиентами, мы обнаружили разные закономерности, хорошие и не очень. И мы поняли, что это шире, чем DevOps. И вот здесь на помощь приходят «командные топологии».

Книга применяет инженерные принципы к тому, как мы организуем и настраиваем наши команды и взаимодействия.

Что такое «командная топология»?

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

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

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

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

Для меня Team Topologies — это не фреймворк. Это не модель. Для меня это просто набор способов думать об организации. И уже потом полезные шаблоны с точки зрения типов команд и способов взаимодействия.

Начинается ли это как нисходящее действие или это может быть сделано индивидуально для каждой команды?

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

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

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

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

А в прошлом мы бы больше думали о технологической стороне: что мы должны построить? Нам нужно построить то же самое, что у других, или использовать ту же новую технологию!

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

Как часто организация должна пересматривать свои командные топологии?

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

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

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

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

В идеале вам нужна культура, в которой сами команды действуют как датчики: «Нам нужно что-то изменить, это не работает. Может быть, у нас слишком много зависимостей, которые нам мешают, или у нас нет необходимых навыков».

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

Расскажите нам о различных типах команд согласно Team Topologies.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это хороший пример того, как делать не надо. При таком подходе все сосредоточено на человеке и не поддерживает идею о том, что важно команде.

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

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

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

Но вам нужно смотреть на общую картину: если платформа сделана правильно, в таком подходе «платформа как продукт», то вы увидите преимущества в командах, которые разрабатывают ориентированные на клиента продукты, которые намного превышают то, что вы собираетесь получить, сократив некоторые из сервисов платформы или команд.

А как командные топологии определяют команды?

Мы определяем «команду» как группу, обычно состоящую из 5-9 человек, которые работали вместе и выяснили, как им нравится работать. Они понимают друг друга, имеют общую миссию, которая соответствует целям заказчика и организации.

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

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

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

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

Может ли это застопорить инновации? Дэвид Дейм, директор по обеспечению доступности Microsoft, сказал, что команда, которая работает вместе 18 месяцев и более, приняла настолько единый образ мышления, что это уменьшает разнообразие и инновации.

Команде требуется от 6 до 12 месяцев, чтобы фактически стабилизироваться, дойти до того момента, когда мы можем назвать их командой, которая улучшается и работает. И спустя 18 месяцев рановато разбивать команду.

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

Есть разные способы привнести инновации и новые знания в команду. И это не просто привлечение новых людей. Именно об этом мы говорим в разделе «Топологии команд»: как эффективно встроить новые возможности в команды? Должны быть механизмы для обмена знаниями внутри организации.

Что касается идеи «команда прежде всего» и идеи о том, что наименьшая единица ценности — это команда, значит ли это касаемо DevOps, что они полностью автономны? И как это согласуется с разработкой платформ?

Цель платформы — помочь ориентированным на поток командам выполнять свою работу более эффективно. Некоторые люди говорят о создании «золотых путей» — это означает, что они владеют своим сервисом или продуктом, и они несут ответственность за мониторинг, развертывание и т.д.

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

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

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

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

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

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

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