Главная

Центр подготовки руководителей и команд цифровой трансформации

Меню

3.1.1 Команда
3.1.2 Полномочия
3.1.3 Функциональность
3.1.4 Самоорганизация
3.1.5 Размещение команды
3.1.6 Подбор и обучение
3.1.7 Оценка эффективности

3. АНАТОМИЯ AGILE

3.1 КОМАНДА AGILE

Авторы раздела:

Бутвина Н. Л.

Алферов П. А.

Ожаровский А. В.

Коротких С. С.

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

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

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

Время чтения: 20 мин.

Команда гибкого проекта имеет ряд особенностей. Она должна быть:

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

Время чтения: 20 мин.

Команда гибкого проекта имеет ряд особенностей. Она должна быть:

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

Руководитель департамента собрал команду проекта — 7 человек, обладающих опытом в разработке ИТ-продуктов, формировании баз данных, UX-дизайне и работающих в сфере спорта и здравоохранении. Несколько человек было привлечено из соседнего департамента.

3.1.1 РАЗМЕР КОМАНДЫ

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

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

Если для разработки одного продукта требуется большее количество ресурсов, то недопустимо увеличивать размеры команды сверх рекомендованного, нужно декомпозировать продукт на более мелкие «подпродукты» и/или использовать специальные инструменты масштабирования команд гибких проектов (например, LeSS, SAFe и подобные, в том числе описанные в разделе 1.3).

3.1.2 КОМПЕТЕНЦИИ И ПОЛНОМОЧИЯ

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

Строго не рекомендуется вводить уровни иерархии внутри команды (не путать с уровнями компетентности по тем или иным направлениям). Некоторые из Agile-фреймворков (в частности, Scrum) вообще требуют «плоской» команды, где у всех членов команды, за исключением владельца продукта и Scrumмастера, одна и та же роль — разработчик продукта (то есть не допускаются роли «аналитик», «тестировщик», «дизайнер», могут быть только разработчики, имеющие схожие компетенции) (рисунок 6).

Рисунок 6. Agile-команда

Команда, как совокупность участников:

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

Рекомендуется не включать в Agile-команду специалистов, если их компетенции и навыки требуются эпизодически (например, экспертов по стратегии, юристов, HR-специалистов). Нужно заранее предупредить таких специалистов, что потребуется их содействие, они должны быть доступны и отвечать на запросы в разумные сроки. Если в организации функционирует много Agile-команд, периодически востребованных специалистов можно включать в состав так называемых центров компетенций, построенных по сервисной модели. Для управления потоком запросов к таким центрам также можно использовать Agile-фреймворки, например Kanban.

3.1.3 КРОСС-ФУНКЦИОНАЛЬНОСТЬ

«T-shape» — англ., в форме буквы «Т».

В последнее время эксперты говорят уже об H-shape или даже W-shape специалистах, когда необходимо обладать экспертными, глубокими компетенциями в двух (или трех) разных областях (например, биолог-программист или дизайнер-юрист-архитектор)

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

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

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

3.1.4 САМООРГАНИЗАЦИЯ

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

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

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

Обычно команде не делегируются (остаются на уровне руководства и заказчиков):

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

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

При стандартном применении гибких подходов самоорганизация команды допускает отсутствие роли руководителя проекта (или существенное сокращение его функций и полномочий), но обязательно выделяется роль владельца продукта — члена команды, отвечающего за успешность продукта, а также роль Scrum-мастера (название роли взято из конкретного фреймворка Scrum, но de facto эта роль стала уже общепринятой в Agile в целом). Фактически роль классического руководителя проекта распадается на две — владельца продукта и Scrum-мастера. При этом роли обязательно принадлежат разным лицам, совмещать их не рекомендуется.

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

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

Подробнее о роли Scrum-мастера и том, как стать выдающимся Scrum-мастером и добиться отличных результатов в работе с командой, можно прочитать в пособии «Пути скрам-мастера». Данная книга хорошо написана и легка для восприятия — вы сможете прочитать ее за выходные, а пользоваться полученными знаниями будете в течение всей карьеры. Шохова З. Путь скрам-мастера. М.: Манн, Иванов и Фербер, 2018. URL: https://www.mann-ivanov-ferber.ru/books/put-skram-mastera/.

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

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

3.1.5 РАЗМЕЩЕНИЕ КОМАНДЫ

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

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

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

Команда проекта «Спортивная страна» разместилась в помещении департамента, где была начата разработка продукта. Сотрудники соседнего департамента присоединяются к работе основной части команды на 3−4 часа в течение дня или на полный день раз в неделю для регламентированных встреч, поскольку нет возможности обеспечить ежедневное очное взаимодействие. Команда активно работает с инструментами визуализации (флипчартами и досками), а также использует онлайн-решения для синхронизации работы (Trello, JIRA и др.).

3.1.6 ПОДБОР И ОБУЧЕНИЕ СОТРУДНИКОВ AGILE-КОМАНДЫ

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

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

При организации обучения обратите внимание на следующие рекомендации:

Для людей, не участвовавших ранее в Agile-проектах, необходим «курс молодого бойца» с объяснениями как теории и логики (Agile-manifesto, области применения), так и практики Agile (роли, регулярные встречи, инструменты).
Для кандидатов на роли владельца продукта и особенно Scrum-мастера следует подготовить более глубокую и системную программу обучения. Крайне желательно отправить их на стажировку в уже работающую зрелую Agile-команду на 1−2 дня.
Хорошей практикой является наличие в организации роли Agile-коуча (это может быть и специалист, привлеченный из другой организации), который в долгосрочной перспективе помогает командам развиваться и двигаться по пути повышения зрелости и осознанности.

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

3.1.7 ОЦЕНКА ЭФФЕКТИВНОСТИ РАБОТЫ КОМАНДЫ

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

Гарантированно достигается единство целей команды.
Команда становится еще более сплоченной и самоорганизованной (участники ощущают, что «они все в одной лодке»).
Если кто-то из членов команды «не тянет», это выявляется на уровне команды, не нужно задействовать дорогостоящие сложные инструменты HR-диагностики и т. д.

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

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

CSI — индекс удовлетворенности клиента от продукта/услуги/сервиса (Customer satisfaction index, CSI) определяется путем опроса или анкетирования пользователей.

Какие именно командные КПЭ стоит установить в данном конкретном случае, зависит от специфики проекта/задачи, предметной области, корпоративной культуры. Тем не менее можно сформулировать базовые КПЭ, которые применимы всегда или почти всегда (возможно, с определенной модификацией и доработкой). Рекомендуется рассмотреть следующие глобальные (продуктовые) КПЭ:

Удовлетворенность потребителей (тех, кто использует продукт) разрабатываемым продуктом — фактически главный КПЭ. Конкретные показатели такой удовлетворенности могут варьировать: например, широко используемые показатели NPS, CSI 61, рейтинги («звезды») в тех или иных независимых реферальных системах или маркет-плейсах (например, AppStore). Считается, что чем больше конечных пользователей имеют возможность объективно оценить продукт, тем надежнее показатель. Заметим, что если продукт недоступен конечным пользователям, то этот КПЭ — ноль. Отлично сделанный продукт, которым никто не пользуется, — это всегда провал.
Удовлетворенность заказчика (того, кто финансирует или организует создание продукта) — тоже весомый КПЭ. К сожалению, показатель почти всегда носит субъективный характер, для минимизации субъективности можно привлечь оценки со стороны не индивидуального, а коллективного заказчика (комитета, комиссии и т. д.).
Удовлетворенность самой команды также считается важным и вполне весомым КПЭ. Нельзя признать успехом ситуацию, когда продукт сделан, пользователи и заказчики довольны, но часть команды уволилась, часть испытывает депрессию и упадок сил, а остальные перессорились и переругались.
Финансовые КПЭ — это, например, объем продаж продукта, прибыль от продукта, стоимость создания новой версии продукта. Существуют разные походы, мнения, методики относительно подобных КПЭ, и окончательное решение должно принимать руководство организации. Однако можно отметить следующие закономерности: хорошие показатели удовлетворенности потребителей всегда положительно коррелируют с готовностью платить за продукт, а значит, положительно влияют на оборот/прибыль.

Проектный треугольник (тройственная ограниченность) описывает баланс между содержанием проекта, стоимостью, временем и качеством (Тройственная ограниченность // Википедия. URL: https://ru.wikipedia.org/wiki/Тройственная_ограниченность).

Рекомендуется использовать также следующие локальные (операционные) КПЭ:

Скорость вывода продукта на рынок (time-to-market, T2M) — главный операционный КПЭ. Обычно этот показатель определяется как календарный срок, который нужен, чтобы вывести новый продукт (или версию продукта) на рынок (сделать доступным для использования потребителями). По сути, все нижеперечисленные операционные КПЭ «работают» на T2M, их соблюдение помогает получать хорошую T2M.
Регулярное выполнение плана спринта (все элементы бэклога спринта выполнены). С этой точки зрения спринт не сильно отличается от короткого классического проекта, в котором нужно соблюсти ограничения проектного треугольника.
Перепланирование (перенос из спринта в спринт) в пределах установленного норматива. Этот норматив вряд ли будет равен нулю (полному отсутствию переноса между спринтами). Перепланирование должно иметь объективный характер (не просто «не успели», «не смогли», а с четкой формулировкой реальной объективной причины).
Регулярная демонстрация инкрементов. Команда регулярно демонстрирует инкременты пользователям (раз в спринт или не реже, чем раз в два спринта).
Производительность команды. Важно представлять, как много полезной работы команда может сделать за спринт. Предполагается, что производительность хорошей команды должна постоянно повышаться (исключения — моменты перехода на новые технологические стандарты, выполнение ранее не встречавшихся задач и т. д.).
«Гигиена» работы с бэклогом. Команда соблюдает «гигиену» работы с бэклогом: бэклог размещен в согласованном месте, всегда актуализирован (команда работает только над теми задачами, которые есть в бэклоге), отдельные элементы бэклога описаны понятно и полно и т. д.
Соблюдение процедур. Команда соблюдает существующие процедуры взаимодействия/синхронизации с другими командами/проектами (смежниками) на своем уровне или с командами, направлениями работ, программами на более высоком уровне.
Регулярная работа над ошибками и с техническим долгом. Команда регулярно работает над ошибками (то есть включает исправление ошибок в бэклог, не избегает их) и с техническим долгом.
Соблюдение всех «правил игры». Проводятся регламентированные совещания, применяются инструменты, об использовании которых договорилась команда или которые определила организация в целом (например, в рамках фреймворка Scrum в команде есть владелец продукта и Scrum-мастер, проводятся ежедневные встречи команды, регулярные ретроспективы и т. д.).

Из книги по управлению командами с помощью Agile вы узнаете, на чем должен сфокусировать свое внимание руководитель при построении гибкой самоорганизующейся команды: как заряжать людей энергией, доверять и расширять полномочия, как работать над развитием командной компетентности и взращивать структуру. Аппело Ю. Agile-менеджмент. Лидер и управление командами. М.: Альпина Паблишер, 2018. https://www.alpinabook.ru/catalog/general-managment/344 675/.

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

Куда дальше?

Предыдущая страница

2.3 Соотношение гибких, классических и гибридных подходов

Следующая страница

3.2 Продукты и его артефакты