Трайб что это такое простыми словами

Продуктовая команда

Сегодня постараюсь рассказать, что такое продуктовая команда. Ее состав и роли, на примере большой организации.

ПРОДУКТ — Предмет, являющийся результатом человеческого труда (книжн.).

В IT — продукт это программное обеспечение решающее какие-то задачи или потребности.

Отличие продуктовой команды от сервисной

Сервисная разработка заканчивается после запуска проекта.

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

Состав команды

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

Давайте рассмотрим каждого из них и поймем чем они занимаются.

Владелец продукта.

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

Составляет Бэклог Продукта.

Договаривается с Командой о сроках и объёмах.
Регулярно общается с пользователями.
Анализирует обратную связь и меняет направление разработки при необходимости.
Думает, как доставить клиентам больше ценности и сократить издержки.
Распоряжается бюджетом по своему усмотрению.

В некоторых случаях владелиц проводит командные ритуалы, такие как дейли, ретроспективу и планирование.

Аналитик

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

Помощь в стратегическом планировании
Операционная поддержка команды
Оценка результатов разработки

Дизайнер

У дизайнера в команде бывает несколько задач. Проектирование взаимодействия пользователя с системой и отрисовка ui компонентов. На этапе проектирование, он плотно взаимодействует с аналитиком, создает UX карты, вайрфремы сценариев. За тем они превращается в полноценные макеты и связываются в прототипы. После тестирования и доработки, макеты передаются разработчикам

Проектирование
Создание макетов
Прототипирование
Создание гайдлайнов
Авторский надзор

Разработчики

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

Серверные разработчики пишут программно-аппаратную часть сервиса. Работа с базой данных, API.

Frontend разработчик отвечает за визуальную часть сервиса, с которым взаимодействует пользователь.

В продуктах для мобильных платформ это часто бывает один и тот же человек.

Создание кода, серверной и клиентской логики приложения

Тестировщик

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

Проверка пользовательских сценариев.
Написание автотестов.
Проверка на соотвествие техзаданию.

Ритуалы

В зависимости от принятых в компании метод управления проектами в продуктовых командах проводят свои ритуалы. В нашем случае это дейли, ретроспектива и планирование.

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

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

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

Chapter

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

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

Вся нагрузка ложится на него в дополнение к той которую несет на себе каждый участник чаптера.

Tribe

Когда в компании много команд и подразделений коммуникация между ними может стать проблемой. Здесь и возникают Трайбы.

Трайб — это совокупность команд объединенных одной миссией.

Трайбы координируются Лидером трайба, который выступает гарантом того, что знания и понимание является общим, управляет приоритетами и распределяет бюджет. Лидер так же обеспечивает взаимодействие с другими трайбами компании.

Сервисные команды

Иногда для эффективного выполнения работы команде не нужна на постоянной основе какая-то роль. Например один дизайнер, в состоянии обслуживает 4–5 команд, но в этом случае не может полноценно участвовать в жизни команды. Такие роли исключают из продуктовой команды и образуют из них сервисную структуру, которая берет заказы от продуктовых команд. Часто бывает что такими командами являются аутсорсовые ресурсы.

Ускориться в 7 раз: как трансформировался Сбер

Agile (гибкая методика разработки) позволила Сберу в короткие сроки выйти на новый уровень производительности и эффективности в управлении проектами. О работе, проделанной Сбером с 2016 года в сфере управления проектами, рассказывает Антон Савельев, исполнительный директор центра «Agile как сервис».

Изначально Agile возник как методология разработки программного обеспечения. Чем она отличается от классического проектного менеджмента?

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

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

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

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

Если компания сильно зарегулирована, она нередко вынуждена двигаться по первоначальному плану, даже понимая, что он уже не ведёт её к цели.

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

Главное в Agile-подходе — системная возможность корректировать план в процессе его выполнения.

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

Как принималось решение о внедрении Agile в Сбере?

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

Для поиска оптимального решения были организованы специальные выезды топ-менеджмента по всему миру. Руководители Сбера знакомились с опытом крупнейших организаций Китая, США и Европы.

Топ-менеджеры обратили внимание на опыт «ING Bank Голландия», который на тот момент применял Agile уже годами.

Как удалось запустить процесс трансформации без риска для стабильности операционной деятельности банка?

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

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

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

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

В чём разница между трайбом и департаментом?

Разработка продукта в рамках классического проектного управления предполагает взаимодействие между IT-департаментом и внутренними заказчиками — бизнес-департаментами. В 2016 году согласование запуска проекта в Сбере могло составлять более полугода. Система взаимодействия в трайбе позволяет ускорить многие процессы.

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

Как поменялась система мотивации сотрудников и их KPI с внедрением системы трайбов?

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

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

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

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

Много ли было скепсиса и недоверия со стороны коллег и экспертов на старте трансформации?

По опыту, комплексная Agile-трансформация коллектива в 100 человек занимает год-полтора. И если всё делать последовательно, то при масштабе 35 000 человек (сегодняшняя суммарная численность сотрудников Agile-периметра Сбера) трансформация могла бы длиться веками.

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

Благодаря чему это всё же удалось сделать?

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

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

Как известно, все модели неверны, но некоторые из них полезны. Так же и с управленческими подходами: многие из них подробно описаны, но внедрение их без изменений в отдельной организации обречено на провал. Их можно брать за основу, после чего видоизменять регулярными итерациями. В 2017—2020 годах у Сбера было четыре крупных этапа изменений Sbergile как методологии.

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

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

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

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

Каковы результаты Agile-трансформации в Сбере? Можно ли сказать, что её цель достигнута?

В 2016 году были поставлены следующие цели:

делать лучшие продукты на рынке;

добиться кардинального сокращения времени выпуска продуктов на рынок;

чтобы у нас работали лучшие сотрудники в отрасли.

Главный результат, которого удалось достичь в результате Agile-трансформации — время от фиксации идеи до внедрения готового изменения в продукт сократилось в 7 раз.

В 2021 году Сбер занял первое место в рейтинге работодателей по версии HeadHunter. Кроме того, существуют внутриотраслевые рейтинги, условно говоря, «топ-100 лучших дата-сайентистов России». HR-служба Сбера регулярно отслеживает долю лучших представителей ключевых специальностей, работающих в Сбере, и эта доля постоянно растёт.

сократилось время от фиксации идеи до внедрения готового изменения в продукт

Изменился важный параметр инновационного процесса, который называется частота релизов (англ. — deployment frequency). Под релизом подразумевается изменение, которое оказывает влияние на пользовательский опыт клиента. Это может быть возможность заказывать дизайн карточки или появление новой метрики в алгоритме расчёта уровня кредитоспособности клиента.

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

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