кто такой чаптер лид

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ритуалы

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

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

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

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

Chapter

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

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

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

Tribe

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

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

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

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

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

Источник

Роль QA Lead в продуктовой компании: особенности и зоны ответственности

QA Lead в Miro отвечает за стратегию качества большой части продукта, реализацию крупных инженерных инициатив и развитие QA-инженеров.

Я как Head of QA расскажу о зонах ответственности QA лида, но прежде кратко расскажу о наших структуре разработки и процессе обеспечения качества, потому что это даёт понимание основных принципов работы.

Интро: структура разработки и процесс обеспечения качества в Miro

Вся продуктовая разработка поделена на направления — стримы. Все стримы кросс-функциональные и кроме разработчиков в стримы входят и другие функции: аналитика, маркетинг, продакт, дизайн. Каждый стрим развивает часть продукта, объединённую общей идеей. Например, Growth стрим — это команды, которые работают над ростом продукта. Или Platform стрим — команды, которые разрабатывают публичную платформу и SDK. Есть стрим Stability and Scalability, команды в котором создают инструменты для доставки, инфраструктуры и обеспечения качества. Здесь разрабатываются системы для автотестирования. Все QA лиды и инженеры пользуются результатами работы этого стрима.

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

Например, практически с каждой Scrum командой работает выделенный QA инженер, который руководствуется ценностями Agile-тестирования:

«Testing throughout over testing at the end». Тестирование — это не дополнительный этап, а часть каждого этапа разработки.

«Preventing bugs over finding bugs». Процесс обеспечения качества в первую очередь направлен на предотвращение ошибок, а не на их эффективный поиск. Но это не значит, что процесс поиска ошибок нужно исключить.

«Testing understanding over checking functionality». Мы в первую очередь обеспечиваем качество продукта, а не только производим проверку на соответствие требованиям.

«Building the best system over breaking the system». У нас нет цели найти все ошибки — мы фокусируемся на предотвращении и поиске важных. Ошибки, что встречаются крайне редко, можно пропустить, потому что их поиск будет очень дорогим.

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

Подробнее процесс обеспечения качества описан в статье.

Зоны ответственности QA лида

QA Lead в Miro отвечает за стратегию качества большой части продукта, реализацию крупных инженерных инициатив и развитие QA-инженеров.

QA lead как стратег

QA лид отвечает за стратегию качества в стриме. Для этого он напрямую работает с Head of Stream Engineering и Head of QA.

Работает с Head of Stream Engineering

Вместе с Head of Stream Engineering QA лид определяет видение процесса разработки в части качества в перспективе минимум на год — что нам нужно сделать, чтобы достичь цели бизнеса. Head of Stream Engineering отвечает за техническую сторону достижения целей бизнеса: масштабируемую архитектуру, предсказуемую разработку, масштабирование команды (найм) и, конечно, качество продукта.

В данном случае обеспечение качества — это не дополнительная работа, которая удлиняет t2m, это, наоборот, история про сокращение издержек. Мы хотим уделять время фичам, но тратим много времени на исправление ошибок — нужно сделать так, чтобы мы не порождали ошибки. Мы хотим, чтобы добавление кнопки заняло один день, а это занимает три недели из-за легаси в коде — нужно устранить сложный код, так как в него невозможно быстро и качественно вносить изменения. То есть при должных ограничениях качества, единственный способ ускорить t2m — это сразу делать качественнее. Этот вопрос и решает QA lead в связке с Head of Stream Engineering.

Работает с Head of QA

Однако есть не только бизнес цели стрима. Есть принципы качества, единые для всех стримов, потому что мы работаем над одним продуктом. Есть эффективные подходы и инструменты, которые можно использовать всеми стримами для экономии ресурсов. Это всё задает видение стратегии обеспечения качества на уровне компании. Head of QA помогает QA лидам совместно определять принципы и подходы.

QA lead как Project manager

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

Реальные примеры таких проектов:

Обеспечить 80% покрытия тестами на разных уровнях;

Уменьшить втрое стоимость ответа на тикеты для команды поддержки;

Провести исследование доверия метрикам;

Улучшить качество релизных веток на Х;

Внедрение JS test framework для non-Canvas команд.

QA lead как People manager

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

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

Чем ещё занимается QA lead

Он проверяет на прочность всё вокруг.

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

Архитектура. Архитектура может не позволять покрывать код тестами из-за сильной связности. Это не дает гарантий надёжности изменений.

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

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

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

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

Тестирование на проде. Важно, чтобы это был действительно полезный эшелон защиты, например, chaos monkey testing. Большая проблема — когда используется тестирование на проде, потому что раньше не получается.

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

Канареечные релизы и процесс анализа пропущенных до прода ошибок;

Релизы и действия на проде;

Мониторинг вышедших фичей и компонентов;

Вывод

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

Это человек, который проверяет на прочность всё вокруг: процесс планирования и его контроль, архитектуру, тестовые окружения, релизы и действия на проде, инциденты, тестирования на проде, health monitoring и многое другое.

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

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

Это People менеджер QA инженеров стрима, который помогает QA инженерам расти. Необходимо понимать тенденции в профессии, привносить идеи, пробовать новое.

Источник

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

Введение

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

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

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

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

Обмен опытом внутри компетенции

Выработка совместных правил и принципов работы

Выработка профильных практик и трансляция экспертизы в команды

Помощь с распределением ресурсов компетенции по командам

Подготовка технического бэклога

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Понять, есть ли реальная проблематика, требующая создания чаптера;

Учитывать возможные культурные и языковые барьеры;

Не выделять роль лидера чаптера;

Не добавлять дополнительную денежную мотивацию лидеру чаптера;

Запустили систему самоизбрания и поддержки кандидатуры чаптером;

Тщательно продумать “рекламную кампанию” чаптеров: что, зачем, как и для чего.

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

Источник

Agile: сокращаем разрыв между теорией и практикой

Что делать, если сотрудники не понимают (или не хотят понимать) «этот ваш Agile» на этапе внедрения.

Agile – одна из передовых тенденций последних лет. На эту тему уже написано много статей и учебников. Как правило, в них собраны теоретические выкладки относительно того, что такое Agile, как надо работать в условиях Agile и как это помогает сократить «time-to-market» и повысить конкурентоспособность компании.

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

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

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

Дебоссинг

Идея Agile. Спустить вниз (на уровень команд) полномочия по принятию решений и развитию продуктов, на верхнем уровне менеджмента оставить функции по стратегическому развитию и финансовому управлению компанией.

Руководители же со своей стороны должны развить в себе hard skills по созданию и развитию продуктов для лучшего понимания сотрудников и для общения с ними на одном языке.

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

Однако на практике в ходе внедрения Agile руководители, разумеется, никуда не деваются, и невыполненное «обещание» дебоссинга разочаровывает сотрудников.

Как исправить / не допустить: Во-первых, я советую вообще не использовать термин «дебоссинг» при внедрении Agile. Он действительно имеет под собой семантическую подоплеку «избавления от руководителей», а Agile в реальности не требует такого избавления. Agile говорит о том, что не от руководителей надо избавляться, а наоборот: сотрудники должны подняться ближе к руководителям и взять часть их функций на себя (в первую очередь, функций по оперативному управлению продуктами и принятию решений по развитию продукта), а руководители должны слегка спуститься на уровень сотрудников и развить в себе hard skills. Как к этому прийти? Стандартными способами: через обучение, через боль, через ошибки, при этом приходится без жалости увольнять тех, кто не готов брать на себя дополнительную ответственность, а также уделять особое внимание наличию данных компетенций при найме новых сотрудников. «Просто хорошие» программисты и «просто хорошие» аналитики в Agile не востребованы: нужны хорошие программисты и аналитики с развитыми soft skills, готовые работать над продуктом самостоятельно. Так же, как и просто хорошие руководители, не обладающие предметными знаниями, в Agile тоже не востребованы.

Гибкость

Идея Agile. Идея гибкости отражена на самом верхнем уровне в основополагающем документе Agile – манифесте.

В нем есть следующие пункты:

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

Отношение сотрудников. «Работающий продукт важнее исчерпывающей документации» – отлично! Нет и не может быть никаких ТЗ! А значит, не может быть никаких обязательств: что успели сделать за спринт / суперспринт, то и показываем, то и выводим в пром.

«Готовность к изменениям важнее следования первоначальному плану» – еще лучше! Берем в работу любой новый чих, старые требования и договоренности отодвигаем (мы же должны продемонстрировать готовность к изменениям) и говорим, что их не выполнили, т. к. вскрылись новые обстоятельства и поступили новые требования!

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

Как исправить / не допустить. К чему приводит такое отношение, вполне понятно:

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

Хорошим (но сложным) подходом, который может обезопасить команду от неправильного толкования Agile-гибкости, может быть подход, когда оценка и премирование команды напрямую зависит от показателей удовлетворенности клиентов (NPS, CSI или аналогов) и/или от бизнес-показателей, отражающих вклад команды в прибыль компании (прибыль от продукта, доля рынка компании по данному продукту и пр.). В этом случае происходит перелом в мышлении сотрудников, и они начинают отказываться от бездумного подхода по учету всех подряд требований: остаются только требования, влияющие на приписанные к команде показатели.

Работающие вместе команды из бизнеса и ИТ

Идея Agile. Данная идея тоже отражена в манифесте Agile:

Отношение сотрудников. Данные пункты манифеста Agile расслабляют многих сотрудников (либо особо ленивые и хитрые сотрудники начинают использовать их в своих целях). Вместо того, чтобы включать голову и думать самим над функционалом продукта и способом его реализации (в т. ч. с учетом всевозможных архитектурных и других ограничений), все активно начинают «взаимодействовать» и «сотрудничать» друг с другом. В условиях open-space это может превратиться в сущий ад: в течение рабочего дня все друг друга дергают, спрашивают, ставят в копии писем и пр. В течение дня через человека может проходить до сотни, а то и больше, электронных писем (т. е. в среднем человек может получать новое письмо каждые 5 минут), человек может чуть ли ни весь день принимать участие в различных (не всегда эффективных) встречах и совещаниях и пр. В результате каждый занят не своей работой, а реагированием на входящие коммуникации. И получается, что самое эффективное для работы время – это нерабочее время, когда коммуникационные страсти утихают и можно сесть и спокойно, сосредоточенно поработать.

Как исправить / не допустить. Я не говорю о том, что коммуникации надо полностью исключить и ни в коем случае никому ни с кем не взаимодействовать. Нет, конечно же, без взаимодействия и общения никакой командной работы не будет. Но эти взаимодействия должны быть осознанными и качественными. Один из способов повышения качества взаимодействий является внедрение инструментов Time-management. И мне представляется, что при переходе на Agile руководство должно особое внимание уделить внедрению и популяризации Time-management. Количество коммуникаций при переходе на Agile возрастает в десятки или даже сотни раз и без соответствующего инструментария Time-management в новых условиях просто не выжить. А учитывая, что во время коммуникаций, встреч и совещаний (количество которых при переходе на Agile тоже увеличивается) время тратится кратно количеству участников (1 час неэффективного совещания 8 человек – это потерянные 8 человеко-часов, или 1 человеко-день), критичность необходимости внимания к данному вопросу просто зашкаливает.

Agile-офис (пуфики, пространства для общения и пр.)

Идея Agile. Особые требования к Agile-офису ни в каких описаниях Agile, как правило, не встречаются. Иными словами, как такового критерия «Agile-офис» для перехода на Agile-методологию нет. Однако складывается практика и традиция, что для Agile нужен какой-то свой особый офис, и старые классические офисные пространства для Agile не то, чтобы не подходят, но, как минимум, снижают эффективность использования новой методологии. Обычно новые Agile-офисы ассоциируются с творческой атмосферой, большими зонами open-space, пуфиками, кофе-пойнтами, зонами для проведения Agile-церемоний (демо, ретро, стенд-ап) и большим количеством переговорных комнат и зон для проведения «быстрых» встреч.

Отношение сотрудников. Нельзя сказать что это относится ко всем сотрудникам, но ко многим – наверняка: оказавшись в атмосфере такого нового модного офиса, сотрудники расслабляются, живут в атмосфере вольности, не чувствуют никаких корпоративных рамок, на официальных Agile-церемониях (и даже встречах) просто «разваливаются» в пуфиках, ходят в какой попало одежде (прикрывая это модной шуткой, что «люди в дорогих костюмах и галстуках выглядят успешными, пока не выясняется, что они работают на людей в джинсах и футболках»), думают «как же это круто, что у нас офис как Google / Apple / Yandex / Facebook», а не о том, как выполнять свою работу, и пр.

Ожидания некоторых руководителей. Но не менее страшным и опасным является неправильное отношение руководителей и их завышенные ожидания от новых офисов. Некоторые руководители, также ассоциируя новый офис «с офисом как в Google» / «как в Apple» / «как в Yandex» / «как в Facebook» и пр., начинают считать, что похожий офис – это достаточное условие, чтобы компания стала такой же (ну или почти такой же), как и ведущие ИТ-гиганты. Но офис – это только оболочка. Поэтому не стоит думать, что успех Google, Apple, Yandex, Facebook и пр. компаний кроется только в офисе. Наверняка там есть что-то еще, что позволило им добиться таких высот (например, система управления, выстроенные процессы, корпоративная культура и пр.).

Как исправить / не допустить. Все банально – не надо давать вольности в дресс-коде, в поведении, в корпоративной этике и культуре при переходе на Agile. Не важно, Agile у вас в компании или нет, элементарные правила поведения (в т. ч. и офисные) никто не отменял.

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

Матричная оргструктура: владелец продукта и чаптер-лидер

Идея Agile. Владелец продукта занимается развитием продукта, ведением бэк-лога и постановкой задач команде. Чаптер-лидер – поставщик ресурсов и компетенций в команде: занимается подбором людей и развитием команды.

Отношение чаптер-лидеров. Многие чаптер-лидеры (как правило, это бывшие начальники отделов в ИТ) продолжают «по привычке» ставить задачи «своим» людям, контролируют их, управляют приоритетами, закрытием дефектов разработанного программного кода и пр. А сотрудники, в свою очередь, тоже по привычке идут не к владельцу продукта, а к чаптер-лидеру, чтобы что-то проэскалировать, приоритезировать и пр. В результате получается, что чаптер-лидер не выполняет свои прямые обязанности (или выполняет их по остаточному принципу), вместо этого частично выполняет обязанности владельца продукта и в итоге не понятно кто отвечает за принятые по тем или иным вопросам решения.

Как исправить / не допустить. Необходимо как можно раньше (т. е. с самого начала перехода на Agile) аккуратно расписать, формализовать и привязать KPI и цели к системе стимулирования так, чтобы чаптер-лидеры отвечали только за HR-показатели по своему чаптеру:

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

Наполнение и ведение бэк-лога

Идея Agile. В этой части Agile мало чем не отличается от обычного классического подхода – есть стратегия компании (стратегические цели) на несколько лет, они декомпозируются в четкие цели и задачи на год, год распадается на кварталы и т. д. В итоге с помощью декомпозиции необходимо дойти до бэк-лога с конкретными user-stories. Для удобства user stories можно группировать в эпики/фичи, которые должны быть привязаны к квартальным / годовым целям. Вроде бы все просто и понятно.

Реальность. В реальности удобного единого инструмента, показывающего связь стратегических целей и бэк-лога, просто нет (как его часто не и в классическом подходе – есть только кипа документации). Как правило, стратегические и годовые цели ведутся в одном месте, бэк-лог в виде user-stories в другом месте. И самое страшное в этом даже не то, что необходима ручная синхронизация содержаний в различных источниках. Ключевая проблема в том, что, выполняя user-stories в бэк-логе, команда не видит, как это влияет на «длинные» цели. Команда даже может и не подозревать / забывать, что их user-stories влияют на стратегические цели: ведь стратегические цели – это зона ответственности руководства компании. И сотрудник, приходя на работу и делая привычные ему ежедневные действия, и не думает, что он работает на высокоуровневые «длинные» цели, и по большому счету это означает, что он попросту не понимает, зачем он выполняет свою работу.

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

Приоритезация бэк-логов, PI-planning

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

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

Как быть? Опять возвращаемся к манифесту Agile, который говорит, что «Люди и взаимодействие важнее процессов и инструментов» и «Сотрудничество с заказчиком важнее согласования условий контракта». Если говорить кратко и прямо – надо договариваться и обсуждать с заказчиком.

Реальность. Бывает, что в реальности происходит следующее: проводится огромная или не очень огромная встреча по вопросам синхронизации (например, Portfolio market place / Project Increment Planning / Product Owner Sync или какая-то еще), на встрече выявляются зависимости, но никаких решений не принимается – все расходятся с «домашним заданием» обсудить друг с другом и с руководством, что и в какие сроки кто кому может сделать. После этой встречи все погружаются в свои текущие дела. От инициаторов встречи начинают приходить напоминания, что «ждем от всех итоги домашнего задания». Под натиском этих напоминаний многие начинают встречаться, но безрезультатно – у всех свои приоритеты и свои задачи. Количество встреч и коммуникаций еще больше зашкаливает, они в итоге ни к чему не приводят и все решается путем обычных эскалаций с привлечением руководства.

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

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

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

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

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

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

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

Источник