трайб это что такое простыми словами
существительное ↓
Мои примеры
Словосочетания
Примеры
He was a great sachem of his tribe. 
Он был великим вождём своего племени.
Legend has it that the tribe came from across the Pacific Ocean.
Легенда гласит, что это племя пришло из-за Тихого океана.
Few outsiders have ever visited this tribe.
За всё время только несколько человек из внешнего мира побывало в этом племени.
Their tribe is a small but cohesive group.
Их племя представляет собой небольшую, но сплочённую группу людей.
Some members of the tribe were scalped by the attacking warriors.
С некоторых членов племени нападавшие сняли скальпы.
The river derives its name from a Native American tribe.
Эта река берет своё название от индейского племени.
The neighboring tribe staged an invasion.
Соседнее племя устроило набег.
The tribe lived in communal huts.
Племя жило в общих хижинах.
The tribe’s patriarch ruled for 20 years before his death.
Глава этого племени правил двадцать лет — до своей смерти.
The tribe’s matriarch ruled for 20 years before her death.
Матриарх возглавляла племя в течение 20 лет до своей смерти. / Матриарх племени правила 20 лет до самой своей смерти.
The tribe is governed by a 10-member council.
Племенем управляет совет из десяти членов.
He absorbed the knowledge or beliefs of his tribe.
Он впитывал в себя познания или верования своего племени.
The wedding joined the two tribes together.
Свадьба объединила два этих клана.
The tribe fought to maintain its predominance.
Племя сражалось за сохранение своего превосходства.
The ultimate fate of the tribe was even sadder.
Дальнейшая судьба этого племени была ещё печальнее.
A common religion ensures the coherence of the tribe.
Общая религия обеспечивает сплочённость племени.
The tribe practised a religion that mixed native beliefs and Christianity.
Племя исповедовало религию, в которой местные верования смешивались с христианством.
This tribe transmigrated many times over the centuries.
На протяжении веков это племя переселялось множество раз.
Примеры, ожидающие перевода
The tribe has different ceremonial masks for each ceremony.
The tribe is divided into clans.
At the age of thirteen the boys in the tribe are initiated into manhood.
Несколько трансформаций одновременно: не по книжкам, а ровно наоборот
Общепринятые мировые практики против проведения нескольких трансформаций в компании одновременно. И все же они возможны, при соответствующей подготовке, привлечении необходимых ресурсов и правильном мониторинге результатов. Плюсами и минусами одновременных трансформаций на конференции DevOps Live 2020 поделился лидер трайба IT4IT в ОТП Банке Максим Ефимов.
В этой статье вы найдете материалы, которые были полезны при внедрении нескольких трансформаций, детальное описание процесса, а также уроки, которые вынесли для себя в банке: как позитивные, так и негативные.
Как происходит любая трансформация в крупной организации?
Как правило, берутся лучшие мировые практики, опыт и книги, в которых можно почерпнуть для себя полезную информацию. Максим предлагает остановиться на трех произведениях:
«Впереди перемен» Джона Коттера — мировой бестселлер, который может стать настольной книгой любого лидера трансформации.
«Accelerate» — это произведение о том, как инженерные практики и DevOps культура меняются сами, меняют организации и бизнес, увеличивают performance и profitability любой организации.
«Team topologies» рассказывает о практиках организации взаимодействия между командами.
Основная мысль, которую можно вынести из книги «Впереди перемен», это:
«Никогда нельзя делать несколько крупных глобальных изменений одновременно».
Это анти-паттерн того, как выполняются трансформации, потому что такие действия влекут за собой:
Гораздо большие риски;
Взаимное негативное влияние трансформаций.
Не нужно забывать о том, что изменения нередко вызывают негатив у многих людей. А когда речь идет о большом количестве изменений, негатива становится больше.
Кроме того, трансформации могут иметь негативное влияние друг на друга. И занимаясь, вроде бы, хорошими делами, вы в конце концов приходите к отрицательному результату.
Трансформация в ОТП
Предпосылки для начала трансформации в ОТП были серьезными: процессы критично устарели и усложнились, а TTM был очень низким (4 релиза в год).
В компании было понимание, что конкурентоспособность падает, и для того, чтобы выжить на рынке, необходимы изменения.
И в ОТП решили сделать все и сразу:
Изменить оргструктуру, перейти к Spotify-модели и внедрить продуктовые трайбы;
Создать институты чаптеров и гильдий;
Сфокусироваться на продуктовой разработке и поменять процессы IT;
Провести редизайн IT ландшафта и модернизацию IT;
Внедрить DevOps и автоматизацию;
Кардинально привязать работу к облакам и микросервисной архитектуре.
Обсудим подробнее, что произошло по каждому из этих пунктов.
Трайбы и оргструктура
В ОТП запустили трайбы, отказались от линейной подчиненности и ввели матричное подчинение.
У каждого трайба есть трайб-лидер и трайб-техлидер. Первый отвечает за бизнес-направление и доходность, второй — за IT-составляющую в каждом трайбе.
Трайб состоит из нескольких команд. У каждой из них есть product owner и бизнес-эксперты.
В ОТП есть своя особенность: в их командах нет выделенных DevOps’ов и QA, это роли, которые выполняют разработчики.
Но для того, чтобы это было возможно, разработчики должны улучшать свои навыки и развиваться. Увы, нельзя сразу набрать исключительно крутых профессионалов, как это делают в Google. Не ко всем же выстраивается очередь из экспертов. В ОТП решили организовать институт чаптеров для того, чтобы сеньоры могли развивать чуть менее экспертных разработчиков в их профессиональной области.
Например, есть Java senior бэкенд разработчик Вася. Он бы хотел развиваться в качестве менеджера, а еще не прочь поделиться экспертизой. Вася становится лидером чаптера бэкенд разработки в трайбе №1. Он помогает наращивать экспертизу и повышать профессиональные хардскиллы людям из его трайба, которые занимаются Java бэкенд разработкой.
Важный нюанс: в компании хотели, чтобы люди переопылялись не только внутри трайба, но и кросс-трайбово. Для этого был запущен институт гильдий. Разница между подходами в том, что участие в трайбе условно обязательно. Если вы бэкенд-разработчик, то попадете к сеньору Васе в чаптер бэкенд-разработки, трайба №1. Гильдия — это сообщество, можно сказать, «кружок по интересам».
Например, в ОТП есть гильдия Kubernetes. В ней состоят сотрудники, которым интересна эта технология. В гильдии постоянно идет диалог на профильные темы, сообщество реализовывает автоматизации и лучшие мировые практики, то есть все, что связано с Kubernetes внутри организации.
Членство исключительно добровольное. При этом, эта гильдия является своеобразной площадкой, где вы можете получить экспертное мнение или поделиться им с остальными участниками.
Продуктовая разработка и изменение IТ процессов
Одним из основных фокусов трансформации являлось создание самодостаточных продуктовых команд, которые были бы сфокусированы на развитии определенных продуктов и быстро бы реагировали и доставляли ожидаемую ценность клиенту. Но бОльшая часть бизнес процессов так или иначе оставалась завязана на CORE системы, развитие и доработка которых требует узкой экспертизы. Поэтому помимо продуктовых команд, в ОТП есть команды платформенной разработки CORE систем.
Было важно организовать взаимодействие между всеми этими командами так, чтобы:
Продуктовые команды могли вносить изменения в функционал CORE систем;
Эти изменения не влияли негативно на стабильность в CORE системах;
Сохранялся необходимый темп доработок.
В ОТП распределили функциональность некоторых систем и дали возможность продуктовым командам контрибьютить в них. Конечно, при определенных условиях и наличии договоренностей между платформенными и продуктовыми командами. Эти условия описывают правила совместной работы над кодом, автоматизированные пайплайны сборки, требования к тестированию и т.д.
IT модернизация и редизайн IT ландшафта
Для того, чтобы все вышеописанное стало возможно, в ОТП решили создать слой API вокруг CORE систем.
Например, есть платформенная команда, развивающая сервис В. Она, посредством API, взаимодействует с сервисом А, который развивает продуктовая команда. В ОТП выработали стандарт, проясняющий, каким образом можно делать интеграции, как они должны работать и как организовано синхронное/асинхронное взаимодействие.
DevOps и автоматизация — IT4IT (enabling team)
Если вспомнить про Team Foundation, IT4IT — та самая enabling team.
Когда-то одной из ключевых задач в ОТП было создание стека централизованных инструментов. Это базис, с которого нужно было начать. Его выбрали совместно с community, внедрили и начали использовать. Естественно, для того, чтобы все это было возможно, пришлось серьезно вложиться в процессы и составляющую DevOps культуры. И сейчас в компании этим серьезно занимаются.
В ОТП не стали выбирать путь создания пайплайнов за команды. Вы ведь помните, что DevOps’ов в командах нет?:) Эксперты из IT4IT приходят в команду, которой требуется определенная помощь (например, с пайплайном). В этом случае члены команды разбираются в проблематике с девелопером и вместе пишут пайплайн.
Почему был выбран именно этот путь? Есть ведь распространенная альтернатива — создание пайплайна вместо команды. Давайте посмотрим, как бы это выглядело на практике: эксперт из Enabling team делал бы пайплайн, отдавал его в эксплуатацию и уходил из команды.
Вроде бы, бинго! Продукт активно развивается, меняются конфигурация приложений и инфраструктура, окружение, появляются новые интеграции. Но все это требует доработки и внесения изменений в пайплайн. А экспертиза внутри команды, в случае написания пайплайна, не была бы проведена. И никто в команде не понимал бы, как провести доработку.
Поэтому был выбран путь накопления и наращивания экспертизы внутри команды, достижения нужного уровня DevOps-культуры и технической зрелости, использования лучших инженерных практик. Когда совместная работа продуктовой команды и IT4IT над пайплайном заканчивается, экспертиза остается в продуктовой команде.
Облака и микросервисы
С точки зрения инфраструктуры, запустить огромное количество новых команд, которых раньше не было, достаточно сложно.
В ОТП выбрали подход использования облачной инфраструктуры, заключили договор с провайдером и начали осваивать public clouds. Важный нюанс: речь идет о банке, где очень беспокоятся о безопасности. В публичные облака договорились выносить только то, что не содержит чувствительных клиентских данных.
Сейчас в ОТП идет работа над внедрением Private cloud, которое позволит размещать любые сервисы и даст командам возможность еще более гибко управлять своей инфраструктурой. В дальнейшем public и private будут связаны. Командам не придется ждать, пока будет создана необходимая классическая инфраструктура. Это положительно отличает ОТП от других банков.
Все эти изменения произошли буквально за полгода.
На данный момент в ОТП уже есть:
8 трайбов, 60+ команд и продуктовая разработка;
Часть трайбов сфокусирована на определенных бизнес-направлениях, а еще есть три IT трайба, которые поддерживают CORE-платформы, общебанковские сервисы и сервисы для IT.
Матричная структура и функционально/административная подчиненность;
Чаптеры и гильдии по всем трайбам;
Слой в 60+ API вокруг CORE-систем;
Большая часть (90%) команд находятся на централизованном стеке CI/CD;
Изначально у всех были и GitLab, и Jenkins, и инстансы Nexus. Однако централизация — важный аспект для банка. Она позволяет ускорить наращивание экспертизы, упрощает обмен опытом и знаниями.
Уроки, вынесенные во время трансформации
Lesson №1. Негативный эмоциональный фон
Многие люди любые изменения воспринимают в штыки, потому что не все готовы быстро меняться. Так как в ОТП запустили несколько трансформаций, негативный эмоциональный фон был особенно ярким.
Настолько, что несколько человек решили уйти без какой-то конкретной причины, а просто из-за ощущения неопределенности. Казалось, что ситуация тяжелая, но обратившись к сухим фактам, в ОТП поняли, что даже в самый пиковый по уходам месяц среднегодовой показатель текучки персонала не превысил 13%, при рыночном бенчмарке в 10-15%. То есть происходящее ощущалось страшнее, чем было на самом деле.
Кроме того, оказалось, что всех уходящих объединяло одно желание: они хотели «просто писать код». То есть you build it, you run it, DevOps, автоматизация и прочие штуки были им не интересны. Таким узко-специализированным профессионалам стало сложно продолжать получать удовольствие, когда вокруг наступили всеобщие эджайл и гонка за тайм ту маркетом. Сложившаяся ситуация была взаимовыгодной: уходящие, будучи крутыми профи в своей сфере, нашли себе команду по душе, а в ОТП продолжают развитие культуры, не тратя силы и время на перевоспитание тех, кому это не интересно.
Lesson №2: Внезапный COVID
Следующий важный момент, с которым все столкнулись в 2020 году — это пандемия, которую никто не мог предусмотреть. Любая трансформация — достаточно хрупкая вещь, неустойчивая к внешним изменениям. С учетом количества изменений в ОТП, эта хрупкость была гораздо более заметной.
Но в какой-то момент в организации поняли, что COVID больше помог, чем навредил. Так как все должны были быстро уйти на удаленку, пришлось отказаться от части бюрократизированных процессов и закрыть глаза на наличие не самых важных приказов, тоже связанных с бюрократией. В итоге пандемия скорее помогла трансформации, чем навредила.
Lesson №3: Измерения — важная часть DevOps культуры
В ОТП хотели понять, насколько происходящие внутри организации трансформации, успешны, чтобы понимать, правильно ли заданное направление.
Для этого нужно было измерить определенные показатели. Но какая-то автоматизированная система измерений и метрик не может появиться мгновенно. Это система или платформа, в которую нужно долго вкладываться, она дорогая, и быстро создать ее не получится.
Поэтому было принято решение запустить ручной assessment и условно измерить, насколько в командах все хорошо с точки зрения:
Когда assessment был запущен, его показали топ-менеджменту, и все сказали: «Вау! Круто! Давайте это запускать везде, где только сможем». И в этот момент было принято важное решение о том, что полученные оценки не должны стать KPI. Ведь assessment базируется на честности и открытости. И ОТП доверяют своим сотрудникам — какая же DevOps культура без доверия?
В какой-то момент heatmap выглядел так (это только часть, просто чтобы дать некоторое общее видение):
Есть определенный трайб, в нем команда 1,2,3, а у них — несколько приложений. Базируясь на их ответах, можно понять, что происходит, и построить heatmap вместе с Agile коучами и архитекторами. Здесь можно увидеть интересующие практики, подчеркнуть сильные стороны трайба и команды, наметить основные зоны роста.
В дальнейшем планируется, что, как минимум, техническая часть этого assessment будет автоматизирована.
Кроме того, принято решение о том, что в ОТП станут опираться на четыре основные метрики DORA, о которых много говорится в «Accelerate». Например, есть идея, чтобы Lead time распадался в дальнейшем на все составляющие SDLC процесса, которые происходят условно от события git push до выкатки в продакшен. Таким образом, его можно будет измерить. А каждая из составляющих второго уровня метрик распадется, в свою очередь, на еще большее количество технических метрик (наличие и использование код-ревью, сколько времени согласовывается pull request и пр.).
И, конечно, этот assessment будущего по-прежнему не будет являться основой для KPI.
Lesson №4 Любая трансформация — это в первую очередь люди
Большой ошибкой, которую допустили в ОТП, была недостаточно эффективная работа с ожиданиями сотрудников, отчего некоторые из них какое-то время негативно влияли на трансформацию.
Важно управлять ожиданиями со старта трансформации. Сейчас даже на этапе интервью в компании уделяют большое внимание проверке вовлеченности: насколько человек в принципе готов к продуктовой разработке, как относится к T-shape или готов ли он надеть на себя шапочку QA, когда и если это потребуется?
Проверка на хард и софт скиллы, безусловно, остается важным этапом любого интервью, но стоит проверять и готовность к вовлеченности в запущенные в организации процессы. Причем, строится она на уровне ощущений. Нельзя дать правильный или неправильный ответ на определенные вопросы, нужно прочувствовать настрой собеседника. И это очень важный аспект.
Подытожим
Что в ОТП вынесли для себя:
Запуск нескольких трансформаций значительно увеличивает риски неуспешности каждой из них.
Эти риски нужно либо каким-то образом митигировать, держа во внимании тот факт, что любое изменение — есть эксперимент, который может закончиться не успешно, и это нормально.
Важна плотнейшая работа с людьми, в том числе:
— Информационные события и постоянный подогрев информационного поля;
Трансформация в ОТП протекала исключительно в правильно сформированном информационном поле. Чтобы у людей всегда было понимание, что происходит в каждый момент времени, пришлось серьезно вложиться во внутренние митапы, конференции, информационно-популяризационные мероприятия;
— Персональное общение и индивидуальный подход.
Звучит банально, но находить индивидуальный подход придется ко всем разработчикам. С каждым нужно пообщаться, что-то донести, ответить на вопросы, снять опасения, или просто выслушать. В это вовлекаются самые разные люди, вплоть до топ-менеджмента.
Существенные единовременные затраты.
Наверное, не нужно объяснять, почему трансформация — это дорогое мероприятие, ценность от которого проявляется в долгосрочной перспективе. То есть если вы ожидаете, что компания через год станет приносить намного более серьезную прибыль, чем сейчас, скорее всего вы ошибаетесь.
Во время трансформации рекрутменту придется несладко.
Люди будут уходить — это неизбежно и относиться к этому нужно как к неизбежной данности. При запуске нескольких трансформаций такой отток может быть больше обычного, что логично и не страшно.
С учетом всех сложностей, рисков и серьезной неопределенности, запуск нескольких трансформационных активностей в одно время может быть хорошим решением, если принимать его осознанно, и не бояться экспериментировать. Дорогу осилит идущий.
Профессиональная конференция по интеграции процессов разработки, тестирования и эксплуатации DevOpsConf 2021 пройдет 31 мая и 1 июня 2021. Билеты на нее вы можете приобрести уже сейчас, успев сделать это до повышения цены.
С 1 апреля стоимость билетов на наши ближайшие конференции: TeamLead Conf 2021, DevOpsConf 2021 и HighLoad++ Весна 2021 возрастет.
Хотите получать полезные материалы по DevOps? Подписывайтесь на рассылку.
Продуктовая команда
Сегодня постараюсь рассказать, что такое продуктовая команда. Ее состав и роли, на примере большой организации.
ПРОДУКТ — Предмет, являющийся результатом человеческого труда (книжн.).
В IT — продукт это программное обеспечение решающее какие-то задачи или потребности.
Отличие продуктовой команды от сервисной
Сервисная разработка заканчивается после запуска проекта.
В продуктовой разработке после запуска происходит анализ обратной связи, генерация новых идей. За тем цикл повторяется вновь, и длится это бесконечно.
Состав команды
В зависимости от специфики продукта состав команды может меняться. Чаще всего в команду входят Владелиц продукта, Аналитик, Разработчики, Дизайнер, Тестировщик.
Давайте рассмотрим каждого из них и поймем чем они занимаются.
Задача Владельца продукта вести разработку в нужном направлении. Формулировать потребности пользователя, изучать обратную связь и формулировать задачи для команды, расставлять приоритеты и помогать команде выполнять свою работу в максимально комфортных условиях.
Составляет Бэклог Продукта.
В некоторых случаях владелиц проводит командные ритуалы, такие как дейли, ретроспективу и планирование.
Продуктовый аналитик — должен уметь работать с данными. Чем больше данных, тем выше вероятность принять правильное решение. Для этого необходимо изучать метрики, строить воронки, следить, к каким результатам приводят малейшие изменения.
У дизайнера в команде бывает несколько задач. Проектирование взаимодействия пользователя с системой и отрисовка ui компонентов. На этапе проектирование, он плотно взаимодействует с аналитиком, создает UX карты, вайрфремы сценариев. За тем они превращается в полноценные макеты и связываются в прототипы. После тестирования и доработки, макеты передаются разработчикам
Разработчики это те люди которые превращают идеи и картинки в рабочее приложение с которым в последствии взаимодействует пользователь. Обычно разработка разделяется на серверную и фронтальную часть.
Серверные разработчики пишут программно-аппаратную часть сервиса. Работа с базой данных, API.
Frontend разработчик отвечает за визуальную часть сервиса, с которым взаимодействует пользователь.
В продуктах для мобильных платформ это часто бывает один и тот же человек.
Тестировщики люди которые отвечают за то, чтобы новый код работал корректно и решение соответствовало поставленной задаче, чтобы не было пропущено ни одного запланированного сценария и чтобы после внедрения новых частей кода, старые оставались в рабочем состоянии.
Ритуалы
В зависимости от принятых в компании метод управления проектами в продуктовых командах проводят свои ритуалы. В нашем случае это дейли, ретроспектива и планирование.
Дейли — проводится каждый день, на нем каждый член команды рассказывает что было сделано вчера и что планируется к исполнению сегодня. Цель мероприятия не контроль исполнителя, а своевременное выявление осложнений и выработка решений.
Ретроспектива — встреча команды в конце каждого спринта для улучшения совместной работы. На ней участники обсуждают, хорошо ли они взаимодействовали между собой. К концу встречи участники составляют план улучшения работы для внедрения в следующем спринте.
Планирование — это встреча для определения цели и объёма работы в будущем спринте. На ней обсуждают, в каком направлении развивать продукт и сколько задач взять в спринт, чтобы к этому прийти. Благодаря встрече они чётко представляют, что и как улучшить в продукте.
Chapter
Когда в компании несколько продуктовых команд, одинаковые роли из разных команд образуют чаптер.
Из этих сотрудников выбирается чаптер лидер, который несет ответственность за консистентность и за то, как именно будут решаться те или иные задачи в командах. Так же чаптер лидер устанавливает иерархию и ответственен за развитие членов чаптера.
Вся нагрузка ложится на него в дополнение к той которую несет на себе каждый участник чаптера.
Tribe
Когда в компании много команд и подразделений коммуникация между ними может стать проблемой. Здесь и возникают Трайбы.
Трайб — это совокупность команд объединенных одной миссией.
Трайбы координируются Лидером трайба, который выступает гарантом того, что знания и понимание является общим, управляет приоритетами и распределяет бюджет. Лидер так же обеспечивает взаимодействие с другими трайбами компании.
Сервисные команды
Иногда для эффективного выполнения работы команде не нужна на постоянной основе какая-то роль. Например один дизайнер, в состоянии обслуживает 4–5 команд, но в этом случае не может полноценно участвовать в жизни команды. Такие роли исключают из продуктовой команды и образуют из них сервисную структуру, которая берет заказы от продуктовых команд. Часто бывает что такими командами являются аутсорсовые ресурсы.