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

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

Как применяются Agile-методологии сейчас?

Исходя из опыта GlowByte, нередко можно наблюдать у наших заказчиков ситуацию, когда руководство компании в приказном порядке принуждает к использованию тех или иных Agile-подходов целые CRM-подразделения или отдельные команды. Это могут быть классические Scrum, Kanban, SAFe или же собственные подходы.

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

Так мы и получаем команды, следующие не адаптированным под их специфические для CRM задачи, а выполняющие бессмысленные ритуалы “гибкости”. Менеджмент строит нереалистичные или неактуальные планы на спринт, а сотрудники раздражаются от бесполезных встреч. Как итог – руководство недовольно результатами, несмотря на переход к популярным и вроде как полезным гибким методологиям.

Почему так происходит?

По нашим наблюдениям, основные причины, почему не работает Agile, следующие:

• неправильное применение самой методологий из-за некомпетентности менеджмента;

• насаждение руководством методологий, не отвечающих специфике работы того или иного подразделения, и запрет на изменения в рабочих процессах;

• попытка руководства унифицировать фреймворк управления командами в компании и получить ответ на все проблемы управления в одном месте;

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

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

Особенности управления CRM-командами 

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

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

• разная направленность работы в рамках одного подразделения (часть сотрудников занимается маркетинговыми кампаниями, часть – развитием CRM-системы, другие  – её поддержкой);

• нередко – большой объём legacy-функционала, от которого крайне зависимы смежные подразделения и от которого невозможно отказаться;

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

Без учёта этих и других особенностей внедрение Agile ведёт к следующим проблемам:

• члены команды тратят время на ненужные и неэффективные церемонии;

• руководство остаётся неудовлетворённым производительностью команд;

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

• никто не понимает, что делать, ведь вроде бы уже используют этот хвалёный Agile.

Варианты решения проблем

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

Конечно, можно прийти на проект в компанию, где требуется решить проблему управления CRM-командой, пройти по очередному мануалу Scrum-методологий, внедрить Agile, поднять какие-то показатели, закрыть свои KPI и оставить людей мучаться с такой трансформацией. Но это не лучшее решение и точно не подход GlowByte, который всегда учитывает особенности команд, адаптируя методики управления в каждом отдельном случае.

Пример из нашей практики

Для наглядного примера решил далеко не ходить, поделюсь личным опытом описанной ситуации на проекте у заказчика. Может быть, кто-то из читателей узнает в нём себя. Итак, в какой-то момент работы в GlowByte я наблюдал такую команду, которая занималась доработками CRM-системы: 6-8 человек задействованы на разработке и аналитике по необходимому бизнес-функционалу CRM. Их рабочий процесс из классического Waterfall-подхода с релизами один раз в квартал был трансформирован в Agile с присущими ему особенностями:

• ежедневными статусами,

• встречами по планированию,

• ведению Kanban-доски в Jira,

• быстро меняющимся приоритетам.

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

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

“Дисциплинированный” Agile

Вообще было бы круто заметить это первым, но пока я в своей профессиональной деятельности погружался в проблематику Agile в CRM-системах, мне повезло встретиться с коллегами из Project Management Institute (PMI), которые обратили мое внимание на подход Disciplined Agile. Его основная суть состоит именно в комбинации и адаптации различных подходов. Этот метод оказал на меня влияние и во многом отразил мои мысли и чувства относительно существующих проблем в управлении Agile-командами.

Что же такое этот Disciplined Agile (DA) и чем он отличается от того, что чаще всего применяется сейчас в большинстве компаний?

В 2014-2015 годах несколько опытных в управлении проектами энтузиастов начали строить подход к управлению командами, который бы мог решать больше проблем, чем классический Agile. По мере развития его взял “под крыло” всемирно известный своими классическими моделями подходов к управлению проектами PMI и вывел популярность DA на следующий уровень. Несмотря на это, в РФ данный подход остаётся неизвестным и соответствующими сертификатами от PMI обладает крайне небольшое количество людей. Мне посчастливилось пройти курс от PMI, получить сертификат Disciplined Agile Scrum Master (DASM) и хотелось бы поделиться с вами возможностями применения этого набора инструментов в CRM.

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

Путь от диктата к настоящей гибкости

Для меня DA отличается в лучшую сторону от других подходов тем, что представляет из себя не набор предписаний относительно рабочего процесса, а набор инструментов. Он позволяет адаптироваться под разные внешние и внутренние условия. Кстати, одним из самых часто встречающихся слов в процессе изучения DA можно назвать “tailoring”, которое напрямую переводится как “портняжное дело” или же “подгонка костюма”. И действительно, авторы предлагают нам не идти строго по определённым ими пунктам, а “подогнать костюм” Agile под собственные нужды и уникальность конкретной ситуации.

Основными идеями и принципами DA, на мой взгляд, являются следующие:

• Контекст важен, каждая ситуация уникальна и нет одного идеального ответа на все вопросы.

• Вы можете менять свой рабочий процесс, и это необходимо делать постоянно. Этот принцип сформулирован как “Guided Continuous Improvement“ – “руководимое постоянное улучшение”.

Официальным руководством по DA является книга “Choose your WoW”. По мере погружения в суть подхода авторы проводят нас через несколько этапов:

1. Описываются основные принципы, заложенные в подход.

2. Даётся подробное описание возможных ролей в команде, какая и на ком в идеале должна быть ответственность.

3. Определяется выбор целей по улучшению работы, для которых мы хотим найти ответ.

4. Описывается выбор жизненного цикла продукта (предлагается целых 6 вариантов, по каждому из них описаны ситуации, когда он лучшим образом применим).

Далее за всем этим следует описание более сотни (!) различных ситуаций, применимых в различных командах.

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

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

Таким образом, DA предлагает:

• методологию выбора жизненного цикла продукта и ролей членов команды в нём;

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

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

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

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

Что же случилось с командой из примера?

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

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

• отсутствие прогнозируемости,

• постоянная реприоритизация задач сверху,

• отсутствие синхронизации со смежными командами.

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

Сразу это не заработало: “Ко мне прибежал X и попросил сделать задачу Y”, “Вот в письме от Z есть запрос максимально срочно, immediately ASAP, сделать задачу, я стал её делать, планы выполнить не успел” и другие подобные истории. Из этого были сделаны выводы, что дисциплинировать нужно не только нашу команду, но и наших внутренних заказчиков. Поэтому я попросил любые такие запросы маршрутизировать на меня, а также ввёл регулярную встречу с бизнесом, где все могли озвучить свои приоритеты на две недели вперёд. С первого раза поезд не тронулся, но это помогло в письменном виде начать фиксировать договорённости.

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

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

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

Через 4-6 месяцев ситуация кардинально поменялась в лучшую сторону, руководство меня с трудом отпустило с проекта, а заказчикам и членам команды по личным отзывам стало комфортнее и приятнее работать вместе.

Ещё один пример применения DA в разработке CRM-продукта

В качестве лирического отступления и завершения статьи поделюсь ещё одним примером. Ни для кого не секрет, что с недавнего времени импортозамещение стало актуальным как никогда, компании перестраивают (или уже перестроили) бизнес и ключевые направления в сторону разработки российского ПО. Меня как менеджера привлекли в вендорскую компанию для выстраивания и управления процессами по принципам Discplined Agile.

Ориентируясь на книгу “Choose your WoW” и существующий контекст из быстро собранных команд атмосферы стартапа, я начал с того, что выстроил инструментарий планирования в виде внутренней Jira. Затем, делая выбор жизненного цикла, вместе с командой мы выбрали описанный в DA Agile life cycle, близкий к классическому agile.

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

Улучшая таким образом наш “way of working” (рабочий процесс), сейчас мы пришли к ровным и спланированным спринтам, инструкциям для каждой роли в команде и понятному релизному процессу. Уже сейчас, как и говорят нам авторы подхода, я чувствую всё меньшую и меньшую необходимость в своём участии в качестве менеджера и всё больше прихожу к роли советника и наблюдателя.

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

Выводы

Подводя итоги: на мой взгляд, настало время переходить от бездумного следования классическим фреймворкам к самостоятельному мышлению над процессами с учётом контекста. Подход Disciplined Agile помогает нам получить большой набор инструментов для этого, диктуя только принцип “постоянно постепенно управляемо улучшайся”, что и является  его основным преимуществом. Кажется, что в 2022 работать неэффективно просто неуместно, и время требует от нас постоянного развития. DA может выступить руководством по этому развитию!

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

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

Использованные материалы:

1. 15th Annual State Of Agile Report

2. Результаты исследования Agile в России 2021

3. Disciplined Agile. В чем смысл?

4. Choose your WoW: A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working