Мы в Промсвязьбанке активно переходим от вотерфол-канальных команд к эджайл-продуктовым. Где-то обошлось парой шишек, где-то уже можно менять грабли… но в результате мы накопили немало опыта, связанного c эджайл-трансформацией. В этом посте мы хотим поделиться опытом — вдруг вы откроете для себя что-нибудь новое.
Как рождается идея перехода к эджайлу
Обычно в компании появляется идеолог, который заражает всех эджайл-вирусом, рассказывая про ценности работы в команде. Всё будет просто и быстро, результат поразит воображение, деньги так и польются в наши карманы, а все сотрудники будут счастливы валяться на пуфиках с кружкой кофе в руке и нескончаемой миской с печеньками, обещает он.
Чтобы закрепить мысли об эджайле, приглашают экспертов, которые прогнозируют пару-тройку сотен дней работы над продуктом, и, как следствие, «протухание» продукта, его кончину. А следом, возможно, и кончину компании. В пример приводят HTC и Blackberry. Как не повторить их судьбу? Консультанты предлагают рецепт, которым воспользовались такие гиганты как Google, Amazon, Apple, — а именно гибкий эджайл.
Что обычно происходит при трансформации
И вот вы узнали все необходимые словечки и фразочки, чтобы иметь право носить гордое имя PMI Agile Certified Practitioner: «стендап, груминг, демо, команда, доска, стикеры, шли все лесом со своими согласованиями». Вы профессионалы своего дела, знаете, что и как работает, знаете все новые необходимые понятия, мероприятия и процессы. Осталось провести agile-трансформацию. Приведем список типичных ошибок.
- Были отделы разработки, а сделали эджайл-команды.
- Бесконечную очередь задач по запросам на изменение в Jira легким движением руки превратили в бэклог из RFC.
- Если раньше на задачу централизованно выделялись ресурсы, то сейчас сделали распределение задач на разработчиков.
- «Чем будет заниматься у нас этот разработчик? А давайте возьмем в бэклог вот эту задачу, он сможет ей заняться»
- Вы поставили цель уйти от оценки задач в один месяц работы. В ответ разработчик говорит: «Окей, начнем делать в этом спринте, а в следующем закончим».
- Задача не согласована со службой безопасности и юристами? Давайте введем нормативные каникулы и проигнорируем этот момент.
- Задачи распределяет начальник? Тогда сделаем эджайл, плоскую структуру, но «я все равно буду начальник».
Что получаем в итоге?
Структура не изменилась. Начальники ставят задачи подчиненным. У людей взрыв , много руководителей, эти руководители параллельно ставят разные задачи с прибитыми сроками. Задачи стали просто измерять спринтами, а не месяцами.
Что делать — непонятно, как делать — непонятно. Документации нет! Вся команда все время сидит на совещаниях, куда приходят старые прожженные технологи и программисты. Они смотрят на сотрудников в команде словно пришли в зоопарк понаблюдать за поведением гиббонов в стае.
Скрам-мастер рассказывает про Definition of Ready и Definition of Done. Все же понимают, что это важно и нужно, почему же разработчики сопротивляются?
В этот момент как назло прилетает важная задача с прибитыми сроками от руководства, и молодой, еще некрепко стоящий на ногах эджайл погибает под натиском врагов и зомби.
А как надо?
Нельзя слепо следовать шаблонам успешных компаний. Здесь проще пояснить через аналогию — например, через футбол. Представьте, что вы тренер, ваша команда проигрывает, пять минут до конца матча. Есть пример безупречного плана, которым пользуется известный тренер Эрнесто Вальверде. Согласно ему, нападающий Луис Альберто Суарес врывается в штрафную, его сносят, судья назначает пенальти. К мячу подходит Лионель Месси и пробивает точно в дальний от вратаря верхний угол. Безупречный план. Но вы не Вальверде, и у вас в команде нет Суареса и Месси. Все. Вы проиграли.
Кроме того, мы начинаем цепляться за процессы, забывая, зачем мы их внедряем в своей работе. Поэтому я бы советовал сформулировать цель и повесить ее на видном месте. Как ставить цели, вы все знаете. Цель должна быть конкретной, измеримой, достижимой, значимой и со сроками. Что все это значит на практике?
На практике это значит, что самый главный во всем этом процессе — Клиент. Поэтому обязательно потратьте время и разберитесь, кто ваш реальный клиент, кто приносит вам деньги. Опишите его персону. Не во всех компаниях ответ на этот вопрос очевиден.
Для клиента вы делаете Продукт, причем такой, чтобы после его использования клиент остался счастлив. Продукт должен быть:
- полезным, то есть решать существенную проблему клиента;
- качественным, то есть соответствовать ожиданиям клиента или превосходить их;
- сделан и предложен вовремя, а не через год.
Продукт в свою очередь создает Команда. На самом деле Продукт и Команда тесно связаны. Как говорила команда утопленников на затонувшем корабле в «Пиратах Карибского моря»: «Часть команды — часть корабля». Хороший продукт без хорошей команды существовать не может, равно как и наоборот. И это главная причина, по которой разваливаются большинство попыток эджайл-трансформации. Чтобы этой ситуации избежать, мы в Промсвязьбанке начинали запуск каждую команду с выбора продуктового направления и владельца продукта.
О том, каким должен быть владелец продукта, уже много сказано и написано. Все это правда, основная сложность — это найти нужного вам человека. Вот что делает владелец продукта:
- ставит цель;
- описывает верхнеуровневый бэклог;
- продумывает KPI, по которым можно было бы постоянно отслеживать приближение к цели; в том числе не забываем про счастливого клиента;
- рассчитывает, как задачи из бэклога влияют на KPI.
Владелец продукта — это не тот человек, который умеет эффективно транслировать приоритеты чужих хотелок, а тот человек, который сам хочет. Он хочет сделать лучший продукт для клиента, сделать таким, каким он его видит каждый будущий день.
Команда разработки — это ответственные люди, которые могут самостоятельно и независимо разрабатывать продукт. В команде должны быть все компетенции, которые необходимы для достижения результата. Внешними зависимостями нужно не управлять, от них нужно избавляться включением или обучением нужных людей в команде. Однозначно не нужно делать команду с избыточными ролями. Чтобы договориться, команда должна быть как можно меньше размером. Мысленно уберите роль из команды, станет ли без нее хуже?
Самый лучший вопрос команде на старте: «У вас всех хватает, чтобы достигнуть цели?» А самая эффективная практика формирования состава участников — это самодизайн, когда сами сотрудники определяют, кому и с кем работать. Мы попробовали так сделать уже на старте — когда предложили самим сделать ротацию, то получилось хорошо.
Теперь, когда команда есть, она должна стремиться к тому, чтобы в конце спринта был прирост «добра» продукта с понятным бизнес-профитом.
Хорошая аллегория командной работы в Скрам — это соревнование на драгонботах. Барабанщик задает темп для синхронизации коллективной гребли, а в начале лодки есть рулевой, который задает направление. У нас владелец-продукта управляет видением бизнес-направления, а скрам-мастер помогает команде держать нужный темп для синхронной работы по всем фронтам. Барабан – это скрам-доска, общее место встречи для событий команды.
Основная ошибка здесь — это попытка назначить скрам-мастера или даже совместить в одном человеке несколько ролей. Возможно, в зрелых командах это получится, но это точно не ваш случай. И даже в зрелых командах никогда владелец продукта не может быть одновременно и скрам-мастером. Вы должны найти скрам-мастера, а не назначить кого-то из попавшихся под руку людей. Такой человек поможет команде становиться более сплоченной и эффективной от спринта к спринту.
Для развития инженерных практик нужно создавать не отдел, который будет навязывать правильные вещи вроде unit-тестов, а сообщество из заинтересованных в этом разработчиков. Если подобные инициативы будут рождены снизу, то их поддержат на всех уровнях.
Работа команды должна быть прозрачна для всех заинтересованных лиц. Это и обязанность команды, и ее существенное преимущество. Процесс своей работы команда выстраивает самостоятельно, а все вопросы, которые могут возникнуть, будут решены также самостоятельно в процессе ее взросления.
И последний совет: используйте простые инструменты. Любые поля и процессы в Jira легко заменяет физическая доска с набором магнитов.
К чему мы пришли?
У нас регулярно появляются новые продуктовые команды. В них не обсуждают эджайл, а делают новую функциональность. Благодаря людям в командах создаются продукты, которые полезны и удобны клиентам, а банку — выгодны.
Автор: shumakov_pro
