Всем привет! Меня зовут Анна Мозер, я работаю тимлидом системных аналитиков в X5 Tech. Мне удалось поработать и в корпорации, и в стартапе, и в качестве фриланс Delivery Manager на этапе запуска стартап команды.
Системный аналитик находится в центре между бизнесом и командой разработки и часто видит весь процесс целиком: от выявления требований до доставки реализации пользователю. Именно поэтому я всегда интересовалась тем, как устроены процессы в командах и принимала активное участие в их изучении и выстраивании.
Периодически мои друзья, знакомые, коллеги в кулуарах делятся тем, что процессы в их командах напоминают хаос. Они говорят: "Мы только и занимаемся тем, что тушим пожары" или "Я не знаю, чем буду заниматься на следующей неделе". И моё самое любимое: "Мы начали делать задачу, а на полпути потребности поменялись, и теперь нужно совсем другое. Но это же Agile…".
Хотя многие менеджеры объясняют это стремлением к гибкости и следованием Agile-философии, чаще всего такие признаки указывают на неправильное понимание и применение гибких методологий. Цель моей статьи – подсветить типичные ошибки менеджмента команды и рассказать об индикаторах того самого "недопонятого" Agile (я насчитала таких 10 штук).
1. Изменение потребности или решения в момент реализации
Пример из жизни. Вы бы видели глаза моей коллеги, которая пришла с 1x1 встречи и рассказала, что руководитель продукта прибежал с изменёнными требованиями в момент, когда задача была уже почти доделана.
Я часто слышу о том, что в Agile требования меняются каждый день, и это норма.
Но на самом деле это не так.
Задача Agile – прислушиваться к потребностям клиента и вовремя на них реагировать. Например, грянул COVID, и теперь магазины обязаны перейти на доставку, чтобы не потерять клиента. У клиента появилась новая потребность – бизнес должен на неё оперативно отреагировать.
Изменение требований к функционалу на ходу – другое дело.Такая ситуация означает не изменение потребностей клиента, а неправильное понимание, непроработанность этих потребностей. Это значит, что мы неправильно услышали, неправильно поняли, недостаточно экспертизы собрали, чтобы понять, какую функциональность нужно реализовать.
2. Отсутствие менеджмента
"Зачем менеджер? А как же самоорганизация?!", – часто слышно в разговоре об управлении командой.
Роль менеджера в Agile, особенно в контексте самоорганизованной команды – предмет жарких споров. Концепция самоорганизованности команд настолько привлекает владельцев продуктов, что становится оправданием отсутствия менеджера в команде. А зачем, если команда должна самоорганизоваться?
Пример. Недавно я общалась с менеджером продукта, который был недоволен работой системного аналитика. Он говорит: «Я ему выставил приоритеты, а он всё равно чем-то другим занимается». Я уточнила у аналитика, в чём дело. Оказалось, что на регулярных встречах приоритизация выглядит примерно так: «Займись интеграциями». При этом задача даже не заведена. По мнению менеджера продукта, аналитик должен был сам организоваться, завести себе задачу, определить смысл этих интеграций, наладить контакты с соседними командами и т. д.
В чём же роль менеджера в гибких методологиях? В традиционной структуре менеджеры часто являются "руководителями": принимают решения, распределяют и назначают задачи, контролируют сроки. Занимаются микроменеджментом, короче. Но динамика Agile команды трансформирует эту роль. Получается, что задача менеджера в Agile – создать комфортную, благоприятную среду для работы, помочь команде функционировать наилучшим образом.
Благоприятная среда в команде поможет участникам достичь той самой организации:
принимать решения, учитывая риски;
иметь возможность высказать идеи и подсветить проблемы;
работать работу, а не "самоорганизовываться" весь рабочий день.
"Роль руководителя состоит в том, чтобы поддерживать работу в рамках подхода, устранять преграды на пути к росту производительности и создавать среду, в которой команды смогут свободно взаимодействовать и отлично выполнять работу."
Саймон Хейворд (“Agile-трансформация. Готовый план перехода к гибкой бизнес-модели организации”)
3. Agile гарантирует быструю доставку? Серьёзно?
А вы тоже считаете, что гибкие методологии созданы, чтобы быстрее создавать продукты и выкатывать функциональность? Это заблуждение.
Гибкие методологии помогают быстрее доносить ценность. Основной фокус Agile и того, что строится вокруг него – качественная, сфокусированная работа, акцент на главном. В первую очередь команда реализует самый ценный функционал, и таким образом клиент быстрее решает задачу.
Эффективность, а не скорость. Гибкие методологии фокусируются на оптимизации процесса производства, а не на увеличении его скорости. Качественная коммуникация, выстроенные процессы, оптимальная слаженная работа команды способствуют скорости работы. Но скорость – это следствие, а не цель. А работа второпях запускает целый каскад ошибок и связанных проблем.
4. Замыкание экспертизы и процессов на одном человеке
Неправильная адаптация Agile-процессов в командах зачастую приводит к замыканию экспертизы и процессов на одном человеке.
В быстром темпе работы всегда кажется, что быстрее сделать самому, чем учить нового сотрудника, распределять задачи на команду, передавать экспертизу, настраивать процесс приёмки и передачи задачи по флоу. Это приводит к тому, что появляется гений-эксперт, который замыкает на себе значительное количество знаний о системе.
Единая точка знаний также приводит к замыканию процессов на этом человеке, потому что без него задачи уже не будут двигаться.
Пример, знакомый участнику любой IT команды. У вас есть инициативный разработчик, который пишет код, знает систему, распределяет задачи, общается с другими системами по интеграции и заведует техническим долгом и особенностями архитектуры. А потом он увольняется, и команда тратит пол года (хорошо, если столько, а не больше) на реверс-инжиниринг и на налаживание коммуникаций, которые сотрудник “забрал” с собой.
5. Постоянные итерации, которые не приводят к результату
Во фреймворках Agile работа разбивается на итерации, каждая из которых доставляет ценность и приближает продукт к цели. Однако, иногда команды попадают в цикл итераций, которые не приносят значимого сколь угодно финального результата с точки зрения ценности. Часто это происходит из-за неправильной декомпозиции требований.
Пример декомпозиции
Команда создаёт каталог товаров с фильтрами и поиском.
Примерный список требований:
поиск должен учитывать всевозможные "умные" подборки, предложения по вводу, искать на нескольких языках с переводом;
фильтры в каталоге должны быть взаимозависимые: при переключении цены изменяется список брендов;
в карточке товара можно листать картинки, открывать предпросмотр и открывать полную страницу товара.
Как может выглядеть декомпозиция на итерации: выпускаем минимально-необходимый функционал в каждом разделе, собираем скелет системы.
Первая итерация может выглядеть так:
- базовый поиск будет работать по совпадению подстроки;
- фильтры в базовом варианте будут независимы, но уже закроют 80% потребностей пользователя;
- карточка товара будет открываться на новой странице.
Это стандартная декомпозиция, при которой пользователь быстро получит базовые необходимые функции.
Другие опции декомпозиции могут быть такие:
1. Инкременты: выпускаем функции по очереди (как бы "едим слона по кусочкам"), но на 100% каждую.
- 4 месяца делаем каталог с предпросмотром (первая итерация);
- 3 месяца делаем поиск;
- 2 месяца доделываем фильтры.
Такая декомпозиция имеет место быть, но нужно учитывать, что пользователь получит работающий продукт нескоро. Наверняка, идеально работающий каталог практически бесполезен без минимального поиска.
2. Архитектурная декомпозиция проекта: делаем один микросервис, потом второй, потом третий, потом подключаем фронт, потом интегрируем.
С такой декомпозицией я тоже встречалась, и чаще всего это ошибка (при работе с продуктом).
Микросервисы – это, конечно, круто, но пока пользовательский сценарий минимально не выполняется, они практически бесполезны.
Чаще всего неправильная декомпозиция приводит к тому, что потребность клиента будет закрыта, но поздно, либо не закрыта вовсе. А как известно, 20% усилий приносят 80% результата. Это именно про итеративный подход к разработке.
6. Нет документации
Отсутствие документации в Agile – одно из моих любимых заблуждений. К счастью, большинство компаний уже осознали, что это ошибка, и написали большое количество статей, провели много митапов на эту тему.
К месту будет напомнить, как звучит ценность Agile:
«Работающий продукт важнее исчерпывающей документации»
«То есть, не отрицая важности того, что справа, мы всё‑таки больше ценим то, что слева»
Манифест Agile
Легко проигнорировать нижнюю приписку и попрощаться с любыми формами базы знаний.
База знаний о том, как работает продукт, нужна. Но это не то статичное ТЗ, которое пишется в проектном подходе. Эта база знаний должна быть динамичной, живой, удобной для использования и покрывающей необходимое и достаточное количество знаний для участников команды.
Пример. Представьте себе тестировщика, который пытается разобраться, правильно работает функционал или нет. Представьте себе сотрудника поддержки, который не понимает: пользователь что-то неверно ввёл или это система неправильно отработала? Представьте себе разработчика, который разбирает код при рефакторинге и не понимает, зачем накрутили столько интеграций и обращений в сервисы? А там, оказывается, где то закопано маааленькое бизнес-правило.
«Если этого нет в документах – этого не существует. Пока информация хранится у кого-то в голове – она легко теряется»
Луис Фрайд, автор книг об управлении командами в IT
7. Отсутствуют роль аналитика и этап проектирования
Роль аналитика в Agile командах – как кот Шрёдингера. Даже если её нет, то она как бы есть.
В чём суть роли аналитика:
Придумать, какая функциональность закроет потребность пользователя.
Придумать, как эта функциональность будет работать и зафиксировать эти требования.
Предусмотреть, чтобы функциональность была спроектирована так, чтобы её можно было расширить, если потребность пользователя изменится.
Даже если команда состоит из владельца продукта и разработчиков, так или иначе кто-то закрывает роль аналитика:
либо владелец продукта, когда ставит задачу разработчику;
либо разработчик, когда пишет код и выясняет мелкие детали.
Такое взаимодействие имеет место быть, но часто приводит к тому, что не понятно, что в итоге сделали, не понятно так ли хотели, это приводит к переделкам после реализации и прочим неприятным моментам.
Для снижения этих рисков команды часто выделяют отдельного сотрудника под роль аналитика, который снимает неопределённость требований до того, как они попадут в код.
Опять же, это не означает, что аналитик пишет ТЗ на 300 страниц и через пол года выдаёт требования. Аналитик также работает небольшими функциональностями (например, UserStory) согласно итеративному подходу. И все счастливы.
8. Слишком много встреч, недостаточно действий
Самоорганизованность команд во многом строится на коммуникации. Именно поэтому фреймворки Agile включают в себя ряд ритуалов-встреч, в рамках которых команда договаривается, решает, планирует, обсуждает и т. д.
Зачастую команды забывают, что на встречи нужно не только приходить, но и готовиться к ним. В таком случае они проходят непродуктивно, не приводят к результатам: команда много разговаривает и мало делает.
Пример, он же спойлер: после ряда неэффективных встреч руководитель решит просто отменить планирование, ретроспективу, сделает дейлики раз в неделю. Нет встреч – нет проблем по их проведению.
Спойлер 2: спустя месяц тот же руководитель будет удивляться, почему команда занимается не понятно чем.
9. Отсутствие ретроспективы и анализа процессов в команде
Первым делом, когда я слышу от коллеги, что в команде процессы идут чёрти как, я спрашиваю: есть ли у вас ретро? Когда оно было в последний раз? Обсуждался ли там этот вопрос?
К сожалению, чаще всего ответы бывают такие: “У нас нет ретро”; “Последнее ретро было 3 месяца назад”; “Ретро было, но не получилось озвучить проблему”.
Отсутствие ретро в основном связано со следующим:
руководитель команды считает, что ретро не нужно, либо чаще всего не получает обратную связь (причинно-следственная связь работает в обе стороны);
несколько раз команда провела ретро, потратили время, ни к чему не пришли, демотивировались, и в итоге отменили;
ретроспектива проходит неправильно по формату, не приводит к результатам.
Пример. Есть ещё одна команда, с которой я тесно общаюсь, частенько интересуюсь, как у них дела. И часто слышу, что все работают чисто на энтузиазме, на человеческом факторе, без процессов, с задачами в Телеграме и т. д. Ну я им и говорю: “Ребята, проведите ретроспективу, обсудите между собой. Видно же, что вы все устали и надо что-то делать с этим”. Скрам-мастера у ребят нет, поэтому они собрались на десятерых, полтора часа поговорили и разошлись. И так два раза. В итоге оба этих раза вся команда обсуждала релизный цикл системы, даже не узнав, какие ещё есть сложности в процессах и взаимодействии.
Ошибка этого кейса в том, что команда принялась решать проблему вместо сбора и изучения всего, что наболело. Правильнее было бы зафиксировать проблему, назначить ответственных, которые отдельно собрали бы встречу с рабочей группой и обсудили бы возможные решения. Так команда может выстроить процессы работы, снизить человеческий фактор, создать общие договорённости, снизить риски при каждом принятии решения.
Кстати, после обсуждения такого мало-удачного ретро, один из аналитиков вызвался самостоятельно провести ретро по формату, и у команды наконец-то появился список проблем, назначены ответственные и сроки по первым шагам для решения проблем.
10. Слишком жёсткая привязка к инструментам и методологиям
С одной стороны, Agile фреймворки включают в себя обязательные ритуалы, способы визуализации, правила коммуникации. Но с другой, основной принцип – это гибкость и адаптация.
Я очень радуюсь, когда слышу, что команда использует нечто под названием “скрамбан”. Для меня это означает, что команда изучила фреймворки, выбрала подходящие практики и адаптировала под свою работу.
Пример. Я сама работала в команде, в которой мы начали со Scrum с двухнедельными спринтами. Потом мы осознали, что физически не успеваем поставить релиз в такой срок. Тогда мы сначала увеличивали длину спринтов, но всё равно было неудобно. Даже строили сложные конструкции в виде: спринт на разработку + спринт на стабилизацию релиза. Но оставался ряд проблем, про которые можно написать отдельную статью, например, маленькие фичи надолго застревали в спринтах.
В итоге мы перешли на Канбан с релизными итерациями. И я не уверена, что это наше финальное состояние, потому что процесс должен развиваться и адаптироваться под потребность.
Основная моя мысль здесь в том, что Scrum и Kanban – это просто инструменты. Это исходник, с которым можно работать, приземляя его на свою команду.
«Сейчас многие руководители проектов стали забывать, что заполняемые ими формы, схемы и таблицы созданы, чтобы помогать, а не наказывать»
Mantel, Meredith, Shaffer, and Sutton, авторы книги «Project Management in Practice»
Если резюмировать: я ни в коем случае не топлю за то, что Agile – это зло. Наоборот: это полезный и эффективный подход, но только при его правильном, уместном использовании. Например, Agile вам подойдёт, если вы хотите делать качественный продукт, а не делать его быстро. При этом важно соблюдать баланс между самоорганизованностью команд и построением процессов.
Мне очень интересно услышать ваши мысли на эту тему. Делитесь в комментариях своими наболевшими примерами и как выходили из ситуаций.
