Большинство компаний из ИТ, банковской, страховой и телекоммуникационной сфер в России и в мире уже активно применяют либо находятся в стадии внедрения различных гибких, или, другими словами, 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”. По мере погружения в суть подхода авторы проводят нас через несколько этапов:
Описываются основные принципы, заложенные в подход.
Даётся подробное описание возможных ролей в команде, какая и на ком в идеале должна быть ответственность.
Определяется выбор целей по улучшению работы, для которых мы хотим найти ответ.
Описывается выбор жизненного цикла продукта (предлагается целых 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 может выступить руководством по этому развитию!
Попробовать его применить очень просто: возьмите за основу из доступных источников книгу, откройте на нужном разделе и изучите предлагаемые инструменты. Далее – применяйте по принципу управляемого последовательного улучшения.
Если у вас остались вопросы или же интересно детальнее узнать про кейсы и подход, я буду рад пообщаться в комментариях или личных сообщениях!