За крепкой спиной Enterprise: как мы перестали чувствовать себя проектом, нашли цель продукта и сделали ее инструментом принятия ежедневных решений (Наталья Епейкина)

Наталья Епейкина, Скрам мастер, Райффайзенбанк

Меня зовут Наташа Епейкина, я — скрам-мастер в команде Digital Onboarding в корпоративном секторе «Райффайзенбанка», и сегодня мы поговорим о том, как за крепкой стеной энтерпрайза мы и моя команда перестали чувствовать себя проектом и стали чувствовать себя продуктом, нашли его цель и стали использовать ее в принятии ежедневных решений.

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

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

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

Откровенно говоря, в этой ситуации есть свои плюсы. Какие плюсы? Это стабильно. Все понимают, что все хорошо, что ничего не рассыплется, что если что, нам докинут денег. Нас готовы поддерживать, если мы даже где-то ошибаемся, компания чаще всего закрывает на это глаза и помогает нам. У нас есть хороший ресурсный набор команды. Нам не нужно страдать в поисках тех самых людей, которые будут реализовывать наши идеи, просто потому что на это трудится в основном род рекрутеров. И еще один плюс — внутри компании обычно много компетенций, и даже если вдруг у вас в вашей команде эта компетенция не нужна на 100%, есть такая штука как аллокации, договориться друг с другом ртом, попросить, подсобить, поменяться и вот это всё.

Плюсы весомые, но в этой ситуации есть и свои минусы. Во-первых, многим вещам дается второй шанс. Например, команда выпускает какую-то фичу, по ней нет ожидаемого эффекта, но стейкхолдеры прикрывают глаза и говорят: «Возможно, выстрелит». Знаете, как с этими советскими лыжами на балконе, которые 20 лет стоят, вы каждый год говорите, что вы на них пойдете. С фичами часто бывает точно так же. При этом все это в рамках спешки, просто потому что обычно внутри большой компании бюджет защищается через тот или иной инвесткомитет. Вы готовите большую презентацию, много всяких цифр, пока вы защищаете ее, переделываете и так далее, все ваши сроки едут, и поэтому мы начинаем пятилетку за три года покорять — больше-больше, быстрее-быстрее, фичи-фичи-фичи.

В связи с этими закрываниями дырок и этой спешкой очень часто продукт начинает строить потемкинские деревни. Где-то привирать в метриках, где-то придумывать метрики тщеславия, которые вау какие классные, высокие, но абсолютно ничего не говорят про наш продукт. При всем при этом разматывается ответственность. Если вы где-то косячите, внутри домена ваш косяк не будет сильно замечен, если у вас есть более сильные собратья, которые зарабатывают много денюжек. И не факт, что выбраны те люди, потому что рота рекрутеров, которые ищут вам людей, очень часто имеет свои иногда кривенькие KPI. Им абсолютно наплевать, подходит ли человек под ваши особенно софтовые описания, им надо закрыть свои KPI. Поэтому вы можете получить свою очень веселую команду, с которой вам потом будет очень «продуктивно» жить.

И вам  гораздо сложнее приватнуться. Опять же, потому что это, так или иначе, инвесткомитет, от вас есть ожидания, и вам гораздо сложнее признать — мы накосячили, эта идея плохая, нам надо сейчас повернуться и сделать что-то еще.

Если рассказывать конкретно про мой опыт, я могу показать на примере, как это бывает. Мой продукт, точнее у нас канал, который заводит корпоративных клиентов от момента появления потребности в банковском продукте до подключения к крупному корпоративному клиенту продукта через диджитал. Идея и вдохновитель этого продукта — это наш управляющий директор домена. Он придумал это, ему эта идея понравилась, он собрал первую команду. Это была сборная солянка из команд в домене, люди никогда не работали вместе друг с другом, и им надо было в сжатые сроки сделать MVP. Product Owner стал человек, который реально, как свои пять пальцев знает весь процесс, который происходит на бумаге сейчас, просто потому что это операционный руководитель подразделения, которое наша команда начала интенсивно оцифровывать.

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

Такая картинка была у нас, и чтобы проанализировать тот список проблем, которые я выгрузила на одном из первых слайдов, я решила составить CLD модель и посмотреть, как это все взаимосвязано. Выяснила очень интересную вещь — если у нас в команде отсутствуют понятные цели, то у команды чаще всего нет умения ответить, для кого и зачем делается этот продукт. В итоге команда начинает просто работать со скоупом, и скрам служит как хлеборезка — он просто берет скоуп, разрезает на приблизительно равномерные кусочки, как хлебушек, и мы работаем. Чтобы не зарыться в этом скоупе, команде необходимо каким-то образом управлять потоком. Но так как она не может опираться на цели, которых она не знает, она начинает управлять им иначе и начинает требовать очень подробное ТЗ и усиливать definition ready. То есть тот входной параметр, по которому команда может сказать: «Мы не берем эту фичу в работу, потому что она еще незрелая».

Начинается оттягивание сроков разработки, начинаются неоптимальные или очень сложные решения. Потому что раз уж у нас будет сложная аналитика, так уж давайте ее зашибись какой хорошей сделаем. В итоге у нас едут сроки, у нас увеличивается Time to Market. Как только у нас увеличивается Time to Market, у нас как факт увеличивается цена фичи. И все это, естественно, не соответствует ожиданиям стейкхолдеров. Как только стейкхолдеры недовольны, недоволен бизнес. Когда недоволен бизнес, бизнес начинает давить на команду. Команда начинает воевать с бизнесом, и команде становится неинтересно. Когда на нее постоянно давят — быстрее, выше, сильнее, больше скоупа, почему не успели — команда опускает лапки, и говорит: как можем, нам надо так. И когда бизнес видит это, он начинает относиться к ним, как к винтикам и исполнителям. А зачем исполнителям доносить какие-то цели, если они есть у нас в голове. И у нас круг замкнулся.

Посмотрев на это все сумасшествие, мы поняли, что нам нужно влиять на этот пункт отсутствия понятных целей. Как мы с этим работали? Во-первых, можно продиагностировать. По своему опыту мы выбрали вариант поговорить с каждым участником команды и понять, действительно ли есть эта проблема непонятных целей или нет. Более триггерным вариантом можно сделать встречу всей команды, но это может повлечь некоторое брожение, которое потом вам как скрам-мастеру или просто как факт лиду команды придется успокаивать. Я выбрала безопасный вариант и провела серию one-to-one.

Что можно спросить на таком one-to-one, чтобы понять, что у вас происходит с целями в команде? Можно задать несколько вопросов, иногда даже один — что делает наша команда? Если у вас уже на первом вопросе ответы начинают расходиться на разных one-to-one, вы можете сказать, у вас есть эта проблема. Если ответы плюс-минус похожи, но нет дальше глубины — зачем она это делает, как она это делает, для кого она это делает, а им это зачем, а какие последние три фичи на это повлияли?

Если здесь вы не можете собрать внятные ответы, у вас точно есть эта проблема, и на нее можно влиять. Как на нее можно влиять, что делать дальше? Три простых пункта. Во-первых, узнать, чего на самом деле от нас хотят. Во-вторых, понять и осознать это вместе с командой. В-третьих, использовать это на всех этапах нашего планирования.

Как узнать? Если у нас есть автор идеи, у нас немножко упрощается жизнь. Мы идем к автору, мы уточняем у него идею, берем все наработки, исследования, узнаем хотелки, ожидания, выясняем почему. Это очень важно — главное выяснить, почему. Потом с этой всей красотой мы все равно идем к пользователям и узнаем их желания и выясняем причины, почему они это хотят. Если нам автор идеи недоступен — так бывает, кто-то придумал идею, кто-то нашел людей, которые будут эту идею пушить, а сам ушел в другое подразделение или компанию — то мы уже идем к стейкхолдерам, потому что именно они платят деньги, у них есть какие-то ожидания. Мы уточняем, какое у них видение нашего продукта, чего они хотят, и выясняем, почему.

Что советую на этом цикле? Делайте это сразу все вместе с командой. С одной стороны, ваша команда взвоет, потому что это — потратить их N часов времени. С другое стороны, можно наглядно посмотреть, что время это экономит. Потому что как выглядит стандартный цикл? Owner узнает желания, передает их в команду, у команды обязательно возникают хоть какие-то вопросы. Она задает вопросы, Owner идет их выяснять. Уже этот мелкий цикл можно повторить 100-500 миллиардов раз. Когда, наконец, выяснено все, команда решает, как это делать. И уже этот цикл повторяется так же каждый раз, когда у вас появляется какая-то новая фича.

Как мы можем сократить этот цикл? Мы приводим команду, сажаем ее рядом с людьми, у которых мы хотим что-то узнать. Команда узнает все желания, команда задает все вопросы, команда принимает решение, как делать. Мы выкидываем лишние звенья, которые в перспективе очень сильно экономят нам время, а, главное, помогают команде понимать, кто она такая, и куда она едет.

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

Но если ваша команда мыслит задачами и говорит — вы нам задачу поставьте, мы задачу классненько сделаем — можно проделать упражнение, которое сделали когда-то мы. Принести команде проблемы клиентов и задать ей три вопроса. Вопросы простые и очень последовательные. Первый вопрос — что мы делаем глобально? Пусть они выгрузят все, что они видят, исходя из этих проблем клиента. Попросите их потом еще проголосовать — какие из формулировок им очень сильно откликнулись. Потом вы можете задать — через какие направления мы видим, что мы этого можем достичь? Здесь уже у вас уже могут появиться какие-то кластеры направлений, через которые можно влиять на то, чего мы достигаем глобально. Третий вопрос, и его не лишне проводить — что именно нам для этого нужно сделать? Здесь будет просто мозговой штурм, где команды могут выгрузить первые идеи фич, которые могут лечь в основу в перспективе вашей дорожной карты.

Тот вопрос — что мы делаем глобально — я рекомендую прогонять с ребятами через очень простой чек-лист трех «зачем». По факту у них есть идея, что они делают глобально какую-то штуку, например, бесшовный процесс для клиента. Вы задаете им вопрос — зачем? Чтобы клиенту можно было не приезжать в офис и не подавать там документы. Вы спрашиваете — зачем ему не приезжать в офис? Это экономит его время. Зачем? Затем, чтобы клиент мог позволить себе зарабатывать деньги, не отвлекаясь на лишние вещи. И здесь у вас появляется, честно говоря, миссия вашей команды. Так разрабатывается миссия это зачем, чтобы к ней можно было стремиться очень-очень долго.

Дальше это все можно использовать в последовательности шагов. Во-первых, те самые глобальные вещи после трех «зачем», это миссия команды. Те направления, которые будут помогать достигнуть этого «зачем», могут лечь в основу стратегии. Я знаю, что у нас будет много докладов по стратегии, не буду заостряться на этом. Цели лучше всего в итоге ставить не больше чем на квартал, и, поверьте, даже внутри квартала они будут у вас меняться. Не надо от этого психовать, это нормально. Хуже придерживаться той цели, которая уже перестала быть актуальной.

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

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

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

Если подытожить, что я хотела донести в этом докладе — во-первых, очень важно, чтобы команда понимала тот продукт, который она делает. Иначе вы столкнетесь с этим жутким длинным паттерным мышлением, которое загоняет вас в том, что у вас будет немотивированная команда и продолбанные сроки. Во-вторых, работа с целями помогает команде фокусироваться. Она всегда может легально задать вопрос — а мы будем это делать, как это соотносится с нашими целями? И если оно с ними не соотносится, у них здесь есть легальное право выкинуть фичу по согласованию с Owner, вместо того, чтобы выкидывать ее из-за того, что у нее нет километрового ТЗ.

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

И самый, наверное, важный вывод — ребят, осознанная команда очень сильно упрощает жизнь Owner. Просто потому что она снимает с него огромное количество головняка, который он тащит на себе. Поэтому растите свои команды, чтобы они тоже понимали, зачем им делать продукт. И вам будет гораздо проще жить.