Chapter lead кто это

Почему Chapterы не летают

Привет, мы — Agile коучи МегаФона и эта статья посвящена разбору тех трудностей, с которыми мы столкнулись, развивая самоорганизующиеся сообщества в нашей и не только компании. Надеемся, что наш опыт и выводы, которые мы сделали, будут полезны как тем, кто только вступает в ряды Scrum мастеров и коучей, так и более опытным коллегам.

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

“Вы будете быстрее, точнее, смелее, а клиент — счастливее. Чтобы всё получилось, нужно сформировать команды и стать более гибкими. При этом ответственность за результаты нужно передать этим самым командам, ведь мотивированные профессионалы намного лучше знают что и как сделать”.

Что такое Chapter и как его “взлететь”

Многие компании, которые используют в качестве организационной структуры модель Spotify, со временем сталкиваются с тем, что им необходимо организовать сообщества компетенций для передачи опыта и выработки совместных улучшений. В модели Spotify такие сообщества называются Chapter или Отдел (данный термин периодически используется в русскоязычной литературе). Также рекомендуется, чтобы Chapter состоял не более чем из 9 человек, что связано с тем, что большое количество людей неизбежно порождает большее количество коммуникаций.

Цели создания:

1. Обмен опытом внутри компетенции
2. Выработка совместных правил и принципов работы
3. Выработка профильных практик и трансляция экспертизы в команды
4. Проведение собеседований
5. Помощь с распределением ресурсов компетенции по командам
6. Подготовка технического бэклога

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

Бизнес-аналитиков в один чаптер, системных аналитиков в другой. Еще есть java разработчики и С++, из них тоже два разных чаптера выходит. Маркетологов, стратегических маркетологов и продуктовых, чьи компетенции похожи, в один объединим.

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

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

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

Часто задают вопрос “как же такого гуру найти?” — нет в компании человека, который бы все компетенции знал и всему мог научить”. В. Между тем, по канонам аджайла, у чаптер-лида нет задачи знать все и уметь всему научить. Он должен воспитывать самоорганизацию, а значит, ему достаточно гореть желанием делиться знаниями. То есть, даже если он не знает КАК, он знает ГДЕ отыскать недостающее ЧТО.

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

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

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

Предыдущий опыт

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

В Tribe часто встречаются узкие компетенции, которые представлены лишь 1-2 участниками, и создание из них Chapter является нецелесообразным.

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

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

Здесь как раз полезным будет разобрать кейсы, “которые не смогли”, чтобы не попасть под очарование системной ошибки выжившего.

Какие уроки мы вынесли для себя из этого?

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

Ящик Пандоры при внедрении чаптеров в МегаФоне

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

Вот с какими антипаттернами мы столкнулись и как их решали:

1. Борьба за ресурсы/статус КВО

Начиная аджайл трансформацию и приходя к практике чаптеров в большой организации 500+ человек, неизменно сталкиваешься с управленцами и руководителями, которые боятся, что после аджаилизации у них не останется работы, так как их статус напрямую связан с количеством людей в подчинении. Если организация идет в плоскую структуру, и люди организовываются вокруг продукта, то с высокой степенью вероятности у этих менеджеров начнут “отбирать” людей. Именно так менеджеры воспринимают любые организационные изменения в период аджиализации/трансформации.

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

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

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

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

2. Лидеры, которых нет

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

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

Как как мы лечили:

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

Не принимать решение единолично, а сделать так, чтобы лидер был выбран самим чаптером, чтобы ребята сами наделили лидера ответственностью.

Искоренить хайп вокруг роли, желательно вообще не выделять ее как роль и уж тем более не мотивировать за нее дополнительно. Лидер “родится сам”, и он уже будет самый заинтересованный и экспертный.

“Вдруг образовавшиеся чаптеры и вместе с ними позиции лидеров — «все так делают и нам нужно», так решают компании в период трансформации.”

3. Манипуляция с з/п и мотивацией

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

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

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

Проанализировать рынок зарплат и провести над ним работу.

Повысить счастье сотрудников неденежной мотивацией.

«Tips» вместо послесловия

Если резюмировать, вот на что следует обратить более пристальное внимание:

1. Понять, есть ли реальная проблематика, требующая создания чаптера;
2. Учитывать возможные культурные и языковые барьеры;
3. Не выделять роль лидера чаптера;
4. Не добавлять дополнительную денежную мотивацию лидеру чаптера;
5. Запустили систему самоизбрания и поддержки кандидатуры чаптером;
6. Тщательно продумать “рекламную кампанию” чаптеров: что, зачем, как и для чего.

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

Кстати, а какой у вас есть опыт запуска чаптеров? Что получилось, что нет и как лечили? С какими антипаттернами сталкивались вы? Поделитесь своими “волшебными таблетками” в комментариях, нам и читателям будет очень полезно.

• Блог компании МегаФон
• Agile

Чаптеры, метрики, мотивация: что мы изменили в отделе тестирования REG.RU и как он устроен сегодня

Рассказ об изменениях в отделе тестирования, призванных убрать рассинхрон в процессах между командами, а также внести общий вектор развития.

Ксения Бычкова
руководитель отдела тестирования хостинг-провайдера и регистратора доменов REG.RU

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

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

Почему перемены были необходимы и что изменилось?

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

Чтобы избежать подобного рассинхрона в отделах, и чтобы новые инструменты внедрялись оперативнее — в REG.RU появились чаптер-лиды. Мы в отделе тестирования дифференцировали технический чаптер и чаптер обучения. Перед каждым из них стоят свои задачи, у каждого свой workflow работы.

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

Цели и работа чаптеров и чаптер-лидов

Что такое чаптер?

Чаптер — это группа специалистов (обычно 7-9 человек) одного направления работы со сходными узкопрофессиональными навыками в одной сфере технических компетенций (hard skills). Например, чаптер бэкенд-разработчиков или UX-дизайнеров.

На данный момент этот блок не поддерживается, но мы не забыли о нём! Наша команда уже занята его разработкой, он будет доступен в ближайшее время.

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

Кто такие чаптер-лиды?

Чаптер-лид — это лидер чаптера, помогающий его участникам достигать целей чаптера. Он должен быть практикующим экспертом в своём направлении.

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

Зоны ответственности чаптер-лидов:

• постановка целей развития отдела в компании (регламенты, идеи, экспертная оценка);
• обучение (организация процесса, фокусировка на целях обучения в чаптерах);
• поиск точек роста и развития сотрудников, мониторинг динамики роста и развития сотрудников (индивидуальный план развития);
• мониторинг и контроль психологического комфорта сотрудников (performance review, оценка 360, обратная связь, one-to-one встречи);
• вопросы по профессиональному росту и зарплате;
• взаимодействие с PO (Product Owner), SDM (Service Delivery Manager), SRM (Service Request Manager) при сложностях в команде.

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

Чаптер обучения

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

Работа в чаптере обучения

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

Примеры задач в чаптере:

• рассмотреть редакторы баз данных;
• изучить продвинутый Xpath оси и операторы;
• изучить методы CodeceptJs;
• изучить, как генерируется и из чего состоит Allure отчёт.

Технический чаптер

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

Работа в техническом чаптере

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

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

Примеры задач в чаптере:

• автоматизация тестирования REG.API;
• подтянуть свежие образы браузеров;
• поправить хрупкость тестов deploy;
• оптимизировать архитектуру тестов.

Совместная работа отдела

Каждый отдельный чаптер, как уже отмечалось, работает по своему workflow: чаптер обучения — скрам, технический чаптер — канбан (изначально был скрам).

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

Раз в три недели проводят планирование, груминг и ретроспективу.

Общая ретроспектива со всеми тестировщиками проводится раз в квартал для фокусировки на roadmap отдела.

Как изменилась мотивация сотрудников?

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

Отгул «‎за молодец»

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

• поделиться знаниями вне общих задач;
• проверить задания в чаптерах;
• за заслуги перед отделом (сделать проще и лучше жизнь отдела, усовершенствовать какие-либо процессы);
• переработки (вынужденные и подтверждённые менеджером или руководителем);
• замещение сотрудника:выполнение тикетов во время отсутствия;проверка отчётов во время отсутствия;помощь более четырёх часов на другом проекте.

Обучение в компании

В дополнение к новым методам мотивации остались те, что давно работают в REG.RU. Например, программа внешнего обучения, где каждый может пройти курсы и съездить на конференцию за счёт компании. Также есть обширная онлайн-библиотека, корпоративный университет с тренингами, разработанными под потребности сотрудников. Доступна программа компенсации оборудования для удалёнщиков: можно прокачать не только скиллы, но и рабочее место.

Карьерный путь тестировщика: от студента до руководителя отдела

Ещё в REG.RU есть программа офлайн-встреч (временно приостановлена на период пандемии коронавируса), чтобы распределённые команды могли синхронизироваться по рабочим вопросам и познакомиться поближе.

Какие общие метрики появились в отделе?

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

Количество потраченного времени на задачи или другие активности

Для бизнеса необходимо измерять, сколько потрачено времени и на что, то есть сколько тратится из бюджета компании на тестирование, автоматизацию, работу чаптеров и прочие активности в командах.

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

В нашей системе баг-трекинга на задачи автоматически можно ставить счётчики выполнения задач (таймер).

Доля отфильтрованных дефектов

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

Формула: количество багов, обнаруженных после выкатки, разделённое на общее количество багов, обнаруженных до и после выкатки.

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

Количество багов, пойманных автотестами на предпроде

Метрика необходима, чтобы понять пользу e2e-тестов.

Считается количество багов из отчёта Allure, которые автотесты не пропускают на прод.

Тестовое покрытие требований

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

В Google-таблице на основании нашей карты функционала и тестов в TestLink. Считается вручную в %.

Покрытие автотестами требований

Отразить покрытие автотестами требований (тесты описываем в TestLink).

Общее количество тест-кейсов, покрытых автотестами. Считается вручную в %.

Скорость прохождения сквозных (e2e) тестов

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

Считается из отчетов по автотестам (Allure) каждый месяц.

Процент хрупкости e2e-тестов по командам

Проанализировать, как часто у нас падают тесты и в каком количестве (в %), чтобы уменьшить количество падающих тестов путем их стабилизации или вообще отказаться от этих тестов.

Собирается из отчетов по автотестам (Allure) каждый месяц.

После изменений работа в отделе тестирования стала прозрачной для всей компании: выстроились общие процессы, появился вектор развития, который отражается в roadmap. Удалось также внедрить множество новых идей. Среди них, например, общее ведение тестовой документации, оптимизация архитектуры кода, автоматизация REG.API, замер скорости динамических страниц.

Тестировщики прокачали soft skills и hard skills, а ещё — сплотились как команда. Для эффективной и слаженной работы важна комфортная обстановка и доверие к коллегам, поэтому появились неформальные встречи, игры, общение не только по работе. Благодаря всему этому мы стали продуктивнее и сплочённее.

На данный момент этот блок не поддерживается, но мы не забыли о нём! Наша команда уже занята его разработкой, он будет доступен в ближайшее время.

Модель Spotify как пример масштабируемого Agile

Если вы работаете в организации, которая внедряет Agile, либо уже внедрила этот гибкий подход, то вы возможно сталкивались с такими терминами, как Сквад (Squad), Трайб (Tribe), Чаптер (Chapter) и т. д.

Эти названия не упоминаются в Scrum Guide, и не совсем понятно, откуда они взялись.

На самом деле – это термины из Agile модели Spotify.

Spotify (рус. Спотифай) — стриминговый сервис, основанный в 2006 году, позволяющий легально прослушивать музыкальные композиции, аудиокниги и подкасты, не скачивая их на устройство.

Spotify — это на 100% Agile-компания, которая начинала с фреймворка Scrum, но по мере роста их команд они заметили, что некоторые элементы в фреймворке Scrum у них не работают. Поэтому, они решили изменить некоторые роли, артефакты и события Scrum.

Инженеры Spotify поняли, что Agile важнее, чем Scrum, а принципы важнее любых конкретных практик. В итоге, в Spotify переименовали Scrum Master-а в Agile Coach-а, потому что они хотели «служащего лидера» больше, чем «мастеров процессов». Они также переименовали Scrum команды в Сквады (Squads) и т. д.

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

Сквад (Squad) — это небольшая кросс-функциональная самоорганизующаяся команда, обычно состоящая менее чем из восьми человек. У членов команды есть сквозные обязанности, и они работают вместе для достижения своей долгосрочной миссии. В Сквадах ключевым фактором является автономность. У команды нет отдельного лидера команды (Team Lead), но есть выделенный Владелец Продукта (Product Owner).

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

Как работает Сквад в Spotify?

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

Теперь немного поподробней о структуре Spotify.

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

Рекомендуемое число людей в Трайбе, в соответствии с числом Данбара — около 100. Число Данбара — это гипотетический предел количества стабильных социальных отношений, зависящий от объема неокортекса. Согласно расчетам Данбара оно считалось равным 150.

В Трайбе есть Лидер Трайба (Tribe Lead), который отвечает за создание продуктивной и инновационной среды для Сквадов. Лидер Трайба также может быть частью какого-либо Сквада.

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

Чаптер (Chapter) — объединяет специалистов определенных дисциплин/технологических областей внутри Трайба. Например, QA инженеры, специалисты по базам данных, front-end и back-end разработчики, специалисты по UX/UI. Люди, выполняющие эти функции в нескольких Сквадах одного Трайба, объединяются в Чаптер.

Каждый Чаптер регулярно встречается для обсуждения своих достижений и проблем в соответствующих областях знаний, например, QA Чаптер, UX Чаптер, DB Чаптер.

В Чаптере есть свой лидер (Chapter Lead), который может подсказать различным членам Чаптера, «как» лучше всего реализовать задачу. Чаптер Лид также может быть непосредственным руководителем членов своего Чаптера, выполняя традиционные управленческие обязанности, такие как развитие людей, карьерный рост и т. д. Чаптер Лид также является членом одного из Сквадов в Трайбе, что позволяет ему понимать проблемы изнутри.

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

Гильдия (Guild) похожа на «сообщество по интересам», охватывающее Трайбы по всей Организации, в котором люди собираются и делятся знаниями в определенной области.

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

Хенрик Книберг (Henrik Kniberg), один из соучастников разработки организации работы внутри компании Spotify, в ответ на распространяющуюся известность модели Spotify и ее копирование в других компаниях утверждал, что модель Spotify не является фреймворком масштабирования команды, а также, что модель Spotify, строго говоря, не является «моделью» как таковой, но отображает пример организации работы в конкретной компании.

Chapter lead кто это

No items found.

У нас есть особые объединения сотрудников, которые мы называем чаптерами (от англ. Chapter — отдел). О них мы подробно и поговорим.

Кто они такие?

‍Чаптеры — это группы, которые объединяют специалистов, выполняющих одну и ту же роль в разных scrum-командах. Это сотрудники, которые работают по одному направлению и обладают схожими навыками и техническими компетенциями. Например, у нас есть чаптеры Data Engineering, Data Science, Business Intelligence.

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

В теории, чаптеры должны состоять не более, чем из 9 человек (идею с чаптерами впервые предложила компания Spotify), но это правило очень условное. К примеру, самый крупный в билайне чаптер состоит из нас, дата-инженеров, — в нём сейчас 117 сотрудников.

‍Для чего нужны чаптеры?

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

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

Команда инженеров данных

Как специалисты по Big Data мы помогаем руководству отвечать на вопросы о компании, основываясь на данных. Например, обобщаем все клиентские взаимодействия с компанией в одну историю, под одним универсальным идентификатором. Прогнозируем и корректируем общую выручку от клиента на всем периоде жизни с компанией. Боремся с фродом. Предсказываем отток и next-best-action для клиентов