Все статьи
Эволюция Потребности или в прошлом квартале было по-другому
Дата: 02.04.2021
История Ак Барс Банка про эволюцию процесса управления бэклогом портфеля на протяжении года.
Доклад с конференции Enterprise Agile Russia 2020.
Андрей Гирин: Всем привет! Сегодня мы с вами поговорим про эволюцию потребности. О том, что я под этим подразумеваю, зачем нам нужно эволюционировать и какие преимущества мы можем получить в результате этой эволюции.
Начнем как всегда со знакомства. Меня зовут Андрей. Я Release Train Engineer в Ак Барс Цифровые Технологии. Это IT-лаборатория Ак Барс Банка. Помимо этого, я также являюсь одним из организаторов серии митапов Three Amigos Talk.
Содержание статьи
Об Ак Барс Банке
Для того чтобы вы поняли, насколько все то, что я буду сегодня рассказывать, будет для вас релевантным, расскажу про наш банк. Ак Барс Банк – это федеральный банк со штаб-квартирой в Казани. Банк универсальный, мы оказываем большое количество услуг как для клиентов физических лиц, так и для клиентов юридических лиц. Банк регулярно входит в различные топы рейтингов, как по банковским, так и по цифровым продуктам. Но очевидно, так было не всегда. Большую часть наших достижений мы смогли достичь в последние 4 года, когда начали пересматривать свои подходы к созданию продуктов. Именно про эти подходы я сегодня и буду рассказывать.
Пирамида Гирина
Определимся, что же такое потребность. Когда я только начинал готовить этот доклад, я сразу использовал это слово. Но спасибо организаторам, мне намекнули, что разные люди могут понимать это слово по-разному. Я сел думать, как же объяснить, что такое потребность, коротко и понятно. И тут мне помог 2020 год, за что говорить ему спасибо точно не стоит. Потребность – это то, что вы хотите получить здесь и сейчас. Если в начале 2020 года я хотел самореализоваться, то уже к лету я хотел просто увидеть свою семью и обнять друзей.
Несмотря на то, что сегодня мы будем говорить не про мои потребности, а про потребности больших компаний в создании продуктов, тем не менее, совсем забывать об опыте предыдущих поколений не хочется. Поэтому давайте рассмотрим такую штуку как пирамида Маслоу, очень часто критикуемую и достаточно старую концепцию. Но тем не менее, она дает представление о том, каким образом развивается потребность человека, от физиологии в основании до самореализации на вершине. Пять простых уровней, каждый из которых базируется на предыдущем.
Эту концепцию мы можем с вами отразить на потребности бизнеса в создании продуктов. Встречайте пирамиду Гирина. В основании просто результат, наверху стратегический: результат.
Как структурирован доклад:
- Сначала рассмотрим уровень пирамиды потребностей и поймем, что это вообще означает в контексте продуктовой разработки.
- Потом я предложу способ формализации потребностей. Только один из возможных, тот который мы использовали в Ак Барс Банке.
- Рассмотрим полученные нами результаты.
- Подумаем, почему нам нужно эволюционировать дальше.
Так мы пройдем всю пирамиду целиком, по каждому из пяти уровней.
Прежде чем мы начнем, небольшой дисклеймер. Я не большой сторонник ЦРУ-шных методов, когда мы фотографируем реальный документ, а потом все замазываем в нём так, что его невозможно читать. Поэтому я аккуратно перерисовал артефакты, заменил чувствительные данные выдуманными, и чтобы вы не путались, пометил их красным курсивом. Давайте начинать.
Уровень 1. Результат
В этом случае все, что нужно компании от продуктовой разработки – это получить некоторый результат, который соответствует поставленным вначале требованиям. Соответственно, формализовать нашу потребность мы можем с помощью такой штуки, как бизнес-требование.
Мне пришлось немного покопаться в архивах, чтобы найти, как же они выглядели в Ак Барс Банке. Это были документы word, бумажных кип на подоконниках я, слава богу, не встречал. Он содержит некоторое количество полезных данных, например, лист согласования, и какая-то непонятная ерунда типа функциональных требований.
Что важно понимать про подобные документы. Они создаются людьми, которые сидят в одном функциональном колодце для людей, которые сидят в другом функциональном колодце. Давайте посмотрим на примере.
Мы начинаем реализацию какой-то инициативы. Странно, мы вроде только начали, какое-то время уже прошло. Я никогда не понимал, почему так происходит, но тем не менее. И вот мы работаем, мы молодцы, и хотим передать нашу работу в другой функциональный колодец.
Тут возникает небольшой гэп. В первую очередь потому что люди в соседнем отделе вряд ли сидят и бездельничают, ожидая, когда вы что-то им принесете. Во-вторых, надо немного договориться со всеми и так далее. Так или иначе, это происходит некоторое количество раз. Аналитики передают работу разработчикам, разработчики в тестирование, и так далее. Потом все немного затягивается, нам приходится переделать часть работы. Что-то, что мы не предусмотрели в начале, всплывает. Потом все выходит из-под контроля. А потом инициатива умирает и только иногда кто-то пытается пинать мертвую лошадь.
Это негативный сценарий. Как мы знаем, плохие вещи случаются только с плохими людьми. Тем не менее, рассмотрим позитивный сценарий. Мы все хорошо поработали. Получили тот результат, который хотели, в какие-то адекватные сроки. Все молодцы. Казалось бы, зачем нам куда-то эволюционировать. Ведь все и так хорошо. С этими гэпами, в принципе, можно жить.
Тут у нас наступает минутка ностальгии. В 1986 году, я тогда еще не родился, в Harvard Business Review вышла статья «The new new product development game«. Ребята проводили исследование о том, каким образом разные компании создают новые продукты. Участники этого исследования отметили, что сейчас требуется нечто большее, чем общепринятые принципы высокого качества, низкой цены и хорошей отстройки от конкурента. Сейчас, чтобы победить в конкурентной борьбе, нужна еще скорость и гибкость. Такую скорость и гибкость дает то, что ребята назвали подходом регби, когда все участники проекта работают вместе, на протяжении проекта, а не передают друг другу эту эстафетную палочку.
Поиграю в Дмитрия Анатольевича и скажу, что никто не может вернуться в 1986 год. Сейчас экономика стала глобальной. Конкуренция только выросла. Клиенты стали более требовательными к нашим продуктам. И то, что раньше отмечали только некоторые участники исследования, сейчас становится аксиомой. Нам нужно быстрее создавать наши новые продукты. И тут мы переходим к следующему уровню нашей пирамиды.
Уровень 2. Быстрый результат
На этом уровне компании, которые научились эффективно создавать продукты в функциональных колодцах, понимают, что им для обеспечения своей безопасности, для своего успеха на конкурентном рынке, нужно делать все то же самое, но гораздо быстрее.
В качестве потребности мы на этом этапе можем рассматривать такую штуку как пользовательская история. Что это такое? Давайте разбираться. Это описание того, что наш продукт должен делать для пользователя. У нее очень простая формула: роль + действие + цель. Например: «я как участник конференции хочу слышать спикера и видеть презентацию удаленно, чтобы получать инсайты даже в условиях пандемии». Важная особенность пользовательской истории в том, что она сама по себе прошивает все наши функциональные колодцы. Для того чтобы вы сейчас меня слышали, потрудилось большое количество людей: организаторы, программисты, звукорежиссеры и монтажеры. Что такое пользовательская история мы, вроде бы, разобрались. Но это же у нас не самоцель, это всего лишь инструмент, с помощью которого мы формализуем эту потребность. Но эту потребность кто-то должен реализовать.
С момента создания Ак Барс Цифровые Технологии, мы сразу начали использовать такой подход как Scrum. Основная единица Scrum – это небольшая команда людей или Скрам-команда. Она состоит из Скрам-мастера, Владельца продукта и Разработчиков. У нее есть важная особенность, она кросс-функциональна сама по себе. То есть компетенции Скрам-команды достаточно для того, чтобы каждый спринт создавать инкремент к нашему продукту.
В теории мы избавляемся от необходимости передавать эстафетную палочку от одного отдела к другому и можем создавать продукты быстро. Опять же только в теории. В 2017 году мы внедрили подход DevOps. DevOps – это набор практик, которые за счет взаимодействия development (разработки) и operations (обслуживания), за счет их более тесного взаимодействия позволяет нам быстрее поставлять продукт на рынок, повысить его качество, уменьшить количество отказов. А в случае если отказ все-таки произошел, сократить время на восстановление системы. Все это позволяет создать для команд такое окружение, когда они могут экспериментировать и быстро, независимо друг от друга поставлять ценность в течение коротких промежутков времени. Давайте посмотрим на результаты.
Что мы видим на этом графике? Cycle time – это время, в течение которого мы разрабатываем пользовательскую историю с момента как мы взялись за её реализацию, и до того момента, как мы поставили ее нашим клиентам. Это значит, что 95% всех наших пользовательских историй мы делаем в то время, которое обозначено на графике. Или за 4 периода мы сократили cycle time в три раза.
Что такое попугаи? Это реальное количество времени, которое команды тратили на реализацию пользовательских историй, умноженное на некий коэффициент, чтобы в первый период получилось 100. На этот коэффициент были умножены все реальные значения, в результате чего, в четвертом периоде получилось 32 попугаев
Казалось бы, мы большие молодцы. Мы можем поставлять ценность каждый спринт. Быстро и круто. Зачем нам эволюционировать дальше? Когда мы умеем раз в спринт получать результат, мы, разумеется, хотим видеть на панели с метриками, на которую смотрят топ-менеджеры, результат работы команд. Так как банк достаточно большой, а инфраструктура достаточно сложная, регулярно делать это раз в спринт бывает проблематично. Каждая пользовательская история хорошо влияет на опережающие метрики, но с отстающими не все так просто. И тут мы понимаем, что хотим сделать какой-то большой кусок функциональности, поставить большую ценность, с чем и переходим на следующий уровень.
Уровень 3. Большой результат
Давайте тут в качестве потребности возьмем такую штуку как фича. И сейчас будем разбираться, что же это такое. Вот так сейчас фича выглядит в Банке:
Она включает в себя само название, ценностную гипотезу, за счет чего мы поставляем ценность и некоторые критерии приемки, как мы поймем, что мы эту фичу действительно реализовали и нашу ценность способны доставить. Такая фича уже не может быть выполнена за один спринт одной командой. Возникает необходимость привлечь некоторое количество команд для ее реализации. Когда у нас работает большое количество команд, возникает потребность каким-то образом организовать их работу.
Мы рассмотрели различные варианты, как же нам масштабировать нашу разработку и остановились на SAFe. Если очень коротко, то SAFe предлагает следующее. Взять наши команды, посадить их в вагончики, сцепить вагоны между собой и по рельсам отправить до следующей станции, реализуя одну или несколько фичей. В результате, команды бегут в одном направлении. Это позволяет командам дать некоторый горизонт планирования того, как будет развиваться наш продукт. А бизнес может планировать достижение тех или иных бизнес-показателей. Такая команда команд называется поездом. Перегон поезда с одной станции на другую, в нашем случае, длится один квартал.
Что у нас получилось в результате:
Важно понимать, что фичи не один в один вытекают в цели. Но тем не менее, мы можем это опустить и рассмотреть такую важную метрику как предсказуемость. Это то, насколько мы можем возвращать взятые на себя обязательства. В результате нашей работы мы достигли показателя 80% — 85%. Минимум 80% всех целей по компании мы каждый квартал достигаем. Вроде бы, ниже не падали. Хорошо это или плохо? А это 80% самых важных штук или нет? Что будет если какая-то фича дает максимальный эффект только в синергии с другой фичей? Чтобы ответить на этот вопрос, мы переходим на следующий уровень.
Уровень 4. Рыночный результат.
Для того чтобы достигнуть рыночного результата, реализации какой-то одной фичи бывает недостаточно. Давайте здесь возьмем более верхнеуровневый элемент SAFe как Возможность и посмотрим, как нам с этим жить.
Итак, есть шаблон возможностей, которые мы используем сейчас. Здесь из важных штук, на которые стоит обратить внимание, это финансовый эффект в год, оценка трудоемкости от команд, сама ценностная гипотеза, плюс опережающие метрики и каким образом и когда мы будем отслеживать достигаемый эффект.
Несмотря на то, что такая возможность, которая предоставляется для бизнеса, в конечном итоге также разбивается на фичи, которые реализует тот или иной поезд, мы как Банк уже перестаем оперировать фичами как потребностью.
Нам уже недостаточно, как в этом примере, реализовать карту, которая начисляет какой-то кэшбэк. Нам точно так же важно, чтобы соседний поезд этот кэшбэк превратил в золото и положил клиенту на счет. И только тогда наш продукт будет классным и сможет претендовать на высокие результаты на рынке.
В ситуации когда нам нужно синхронизировать работу некоторого количества поездов, очень важной становится такая штука как приоритизация. Сейчас в рамках розничного бизнеса у нас действуют сквозные приоритеты для реализации всех наших потребностей. Приоритет состоит из двух основных частей. Это финансовый эффект, который определяется продуктовым менеджментом и оценка трудоемкости, которая предоставляется командами.
Тут важно отметить, что приоритет – это не математически рассчитываемая штука, а на основании вот этих двух параметров продуктовый менеджмент уже оценивает уровень приоритетности той или иной возможности. Плюс у нас есть право вето у профильного заместителя председателя правления банка, который может каким-то образом изменить приоритеты, получившиеся в результате вот такой работы. Иногда он этой возможностью пользуется. Для того, чтобы наши оценки не были пол, палец, потолок, а были более точными, мы разработали процесс управления потребностью. Давайте рассмотрим его на примере трех кварталов.
В самом начале мы готовим возможности для реализации в будущих кварталах. Что такое подготовка? Это формирование гипотез, расчет эффектов, выбор способа реализации и оценка трудоемкости этого способа реализации. Параллельно мы реализуем какие-то возможности в этом квартале. Откуда там подготовка возможностей для третьего квартала, мы сейчас посмотрим. Потом наступает второй квартал, четвертый месяц и мы начинаем реализацию ранее выбранных возможностей плюс проверяем гипотезы от ранее реализованных возможностей.
Проходит два месяца и скоуп, который у нас определен на текущий момент, мы фиксируем. Мы говорим о том, что именно эти возможности пойдут в PI планирование. Все это сделано для того, чтобы на планировании мы занимались именно составлением плана, а не разбором того, что за ерунду мы тут вообще хотим сделать и зачем мы это делаем. Иногда нам 2020 год опять же подкидывает сюрпризы, новые возможности и так далее, но это, скорее, исключение. Начиная с этого момента мы уже готовим возможности для следующих кварталов, а на текущий момент продолжаем реализацию и проверку гипотез. И так далее это повторяется раз за разом.
Что касается результатов проверки наших гипотез, то к сожалению, сказать вам этого я не могу. Но…
если мы нарисуем виртуальную шкалу от Ванги, которая иногда угадывает, и до градусника, который всегда показывает нужную температуру, мы ближе ко второму. Остался один вопрос. Мы делаем клевые вещи. По идее, мы должны быть в шоколаде. Но у каждой компании есть стратегия, которая вытекает в стратегию продуктов. Как обеспечить связь стратегии с операционной деятельностью. И тут мы переходим на следующий уровень.
Уровень 5. Стратегический результат
В 2019 году корпоративный проектный офис предложил такую концепцию, как трансформация для формализации потребностей на нашем последнем уровне. Что же это такое?
Есть некоторая ситуация как сейчас, где мы находимся на рынке. Есть позиция, куда мы хотим прийти. Между этими двумя точками существует определенный разрыв. И этот гэп мы назвали вызовом. Штука, которая позволяет нам преодолеть этот вызов, и названа трансформацией.
Как она выглядит у нас сейчас?
На основе Portfolio Canvas была разработана канва трансформации. Большая и сложная штука. Но нас с вами сейчас интересуют две вещи: эффект и годовые метрики. Эффект – это некоторый кратный рост нашего бизнеса в том или ином направлении, и годовые метрики, которые определяются на какой-то год, по отслеживанию того, как мы этого эффекта в конечном итоге и достигаем.
По итогам 9 месяцев 2020 года мы можем говорить о 70% достижении годовых метрик по канвасам, которые мы разработали.
Завершение
Итак, мы с вами рассмотрели пирамиду от результата до стратегического результата. Неочевидно, что эта пирамида является законченной. Тем не менее, на мой взгляд, она является интересным концептом для того, чтобы рассматривать эволюцию потребностей бизнеса.
Есть одна важный пойнт, про который нельзя забывать, о котором хочется сказать в первую очередь. Это то, что каждый следующий уровень пирамиды базируется на предыдущем. Когда вы пытаетесь перепрыгнуть через какой-то уровень, вы с высокой вероятностью либо откатитесь назад, либо формально, внешне будете делать все то, что там придумано, разрабатывать стратегии, смотреть на неё, радоваться. Но если вы не научились работать в функциональных колодцах, например, ваши разработчики не умеют разрабатывать, а тестировщики тестировать, вы не сможете собрать из них хорошую команду. Если вы не умеете работать с командами, вы не сможете масштабировать эту разработку. Без масштабированной разработки вы никогда не достигнете тех стратегических целей, которые себе ставите.
Вопрос-ответ
Ольга Захарова (модератор конференции): Андрей, большое тебе спасибо за доклад. Можно вопрос? Какие сложности сейчас встречаются на пути? Вроде бы, стройная пирамида, красивая, стройный рассказ. Но мы все как практики понимаем, что без сложностей не обходится. Что бы ты отметил?
Андрей Гирин: Хороший вопрос, спасибо. Если вы обратили внимание, то в презентации на каждом из уровней пирамиды были указаны даты. Это те года, когда мы эти уровни проходили в нашей компании. На последних двух уровнях пирамиды есть дата начала, но нет даты окончания. Это те уровни, которые мы проживаем сейчас. Каждый раз мы что-то немного подкручиваем именно потому, что сталкиваемся с какими-то новыми вызовами. Например, процесс управления возможностью мы разработали относительно недавно просто потому, что в какой-то момент мы пришли на PI-планирование и команды удивились, увидев вместо понятного бэклога неизвестные для них слова. Это было большой проблемой для команд, а на выходе из квартала это стало большой проблемой для стейкхолдеров. Тогда мы немного изменили процесс и сейчас, вроде бы, выплываем.
Опять же привет, 2020 год. Очень большим вызовом для нас является удалёнка именно с точки зрения запуска новых команд. То есть если старые, вроде бы, сменили локацию, но сохранили саму модель взаимодействия.
Ольга Захарова (модератор конференции): Уже налаженную.
Андрей Гирин: Да, уже налаженную. То с новыми командами все гораздо сложнее. Этот процесс нужно выстраивать заново. Запускать команды, когда люди никогда друг друга не видели вживую, когда участник команды для них – это строчка в мессенджере и дай бог, если видео, то все гораздо сложнее.
Ольга Захарова (модератор конференции): Хотела чуть-чуть сюда углубиться. Про онбординг новых членов команд. Так как есть некоторый свой словарь в компании, есть свое понимание, что в этом направлении делается, как их погрузить быстро в то, что происходит? Основы, вроде бы, одни: SAFe, понятное PI планирование, цели и так далее. Но явно слышится свое. И это классно. Как их туда погружаете?
Андрей Гирин: Как всегда, есть план онбординга нового сотрудника, есть отдельный план, связанный с онбордингом в компанию. Это все, что связано с корпоративной культурой, гайдами, которые мы используем. Например, гайд по Scrum, гайд по DevOps, гайд по разработке. Плюс есть онбординг, связанный с работой команды. Это погружение непосредственно в продукт, который команда разрабатывает, знакомство с самой командой, особенностями тех практик, которые они используют. В общем-то, всё.
Ольга Захарова (модератор конференции): Какие планы? Куда вверх пирамиды прыгать?
Андрей Гирин: Если посмотреть на какие-то сходные концепты, например, kanban maturity model (KMM), то мы можем говорить о том, что там наверху, в случае с KMM внизу, регулярное достижение клевых показателей. Это то, что сейчас в пирамиде отсутствует. Неочевидно, что это туда надо добавлять. То есть пирамида все-таки про потребности, а KMM про зрелость всей компании. Может быть, каким-то образом она еще будет эволюционировать, но сейчас это будет, скорее, теоретическое измышление, с моей стороны. Возможно, когда-нибудь она разовьется.
Ольга Захарова (модератор конференции): Хотела еще спросить тебя про те сообщества, которые ты упомянул в начале. Как они помогают тебе, используешь ли ты их в работе, в компании? Зачем они?
Андрей Гирин: Конечно, помогают. Большое количество людей сталкивается с большим количеством кейсов. Скорее всего, та ситуация, которую проживаете вы в своей компании сейчас, не является новой и уникальной. Скорее всего, большое количество людей уже эту ситуацию прожили и могут вам помочь, подсказать. А вы, в свою очередь, можете поделиться в сообществе чем-то своим. Я вас уверяю, ваш опыт очень полезен для огромного количества людей. Многие стесняются, говорят: «Чем мне делиться? Я делаю обычную работу. Ничего особенного». Но на самом деле многие будут вам благодарны, если вы принесете в любое сообщество свой опыт, поделитесь им.
Видео и слайды
