В гостях у Комьюнити побывал бизнес-эксперт, старший менеджер продуктов Райффайзен Банка Антон Ширшаков. Антон занимается развитием мобильного приложения Райффайзен Банка, в частности направлением клиентского участия в монетизации.
Мы поговорили с ним о мотивации сотрудников, подходах к вовлечению разработчиков в стратегическое планирование и преимуществах горизонтальной иерархии в управлении продуктами.
— Антон, как в Райффайзен Банке выстроена командная работа над продуктом?
— Райффайзен Банк верит в гибкие практики методологии разработки продукта и построения производственного процесса. У нас максимально линейная и плоская структура, поэтому напрямую мне никто не репортит.
В моей команде два фронтэндера на iOS и Android, один бэкендер, два QA-специалиста и один системный аналитик. Но фактически у меня в подчинении ноль разработчиков, ноль менеджеров и других специалистов.
Задача развития подразумевает бэклог и систему OKR. Мы получаем совместную систему OKR и целей для всех продуктов, которые отвечают стратегии нашего банка. Исходя из поставленных целей, командой формируется бэклог. Можно сказать, мы занимаемся классическим продуктовым развитием, а не проектной деятельностью.
— Надо полагать, что вам знакома проектная иерархическая модель и есть с чем сравнить подходы.
— До прихода в Райффайзен Банк я работал в сфере телекоммуникаций, а это всегда грандиозные инфраструктурные и технологические проекты, в том числе за рубежом. Это и большие команды – в среднем 100-150 человек. А еще это всегда какое-то адское деливери.
Понимаете, у меня всегда было тесное сотрудничество с коллегами, но сам метод построения процессов и отношений был каскадным. Я могу сравнить подходы – жесткого иерархичного деливери с вертикальной структурой и того, как сейчас я работаю с текущей командой, где ключевыми аспектами успеха являются сотрудничество, прозрачность и совместная работа. Такой подход мне очень импонирует.
— Вы считаете, что добиться максимальной продуктивности от разработчиков можно только в горизонтальной модели?
— На предыдущей работе мы определяли план с техническим менеджментом, а потом просто выкатывали его разработчикам и просили их выполнить те или иные задачи. Делайте, и делайте это как можно быстрее. Я не могу сказать, что это не давало результатов, но проблема в том, что, если работа с разработчиками построена таким образом, есть некоторая демаркационная линия между бизнесом и сотрудниками. Как следствие – организации приходится искать дополнительные триггеры мотивации сотрудников. У кого-то это могут быть иностранные командировки, у других – финансовая мотивация.
Команда может быть эффективной даже при каскадных подходах, но только если речь идет о заказной разработке – когда у вас контракт на фикс-прайс, требования согласованы и всем известно, что должно быть на выходе.
Часто же при развитии продукта нет ясности в том, что прямо сейчас нужно сделать. В этом случае тесная интеграция бизнеса и разработки имеет гораздо больше плюсов, чем минусов.
— Как вы вовлекаете разработчиков в стратегический процесс?
— Для этого мы проводим совместные брейнштормы, еще на стадии формирования бэклога. Все участники команды решают проблему, делятся ценными идеями. Если разработчик готов что-то предложить, он говорит: «Ребята, нам надо сделать это, потому что...». Если идея классная, то она будет принята во внимание и реализована при должном уровне обоснования.
Читайте также
— Некоторые продуктологи заготавливают план, а потом просто приводят коллег к тем мыслям, что набросали. Коллеги думают, что предлагают классные идеи, хотя за них все уже решили. У вас такое не практикуется?
— Никогда, но есть исключения из ситуации. Деятельность банка связана с регуляторными действиями, например, может появиться новое требование Центробанка, которое нужно выполнить к определенному сроку. Или у бизнеса банка может появиться новая цель, которая повлияет на наш бэклог. Все это механическая работа, но что касается развития – без совместной работы не обойтись, и все идеи одинаково важны.
— А как у вас осуществляется декомпозиция целей? Глобальную задачу вроде увеличения числа переводов бывает сложно разложить на элементы в рамках одного брейншторма.
— Это не так сложно, так как мы хорошо ориентируемся в том, что делаем. Чтобы увеличить количество переводов по карте, мы можем воспользоваться аналитическими данными, посмотреть воронку, проверить, что сейчас хромает в переводах, и обнаружить, что на каком-то шаге конверсия сильно падает. Исходя из этого, делаем обоснованное предположение, что конверсию можно поднять. Дополнительно мы можем изучить исторические данные и увидеть, что огромное количество переводов идет в один банк, а в другой не идет, хотя рыночные бенчмарки показывают другую картину. На основании этого мы можем предложить проведение маркетинговой кампании, и такая идея может исходить даже от имени разработчика. Плюс мы можем пообщаться с пользователями и узнать, что их не устраивает, какие проблемы они испытывают при выполнении переводов. У нас есть все стандартные средства дискавери.
Кроме того, разработчики могут подсказать неожиданное решение проблемы – сервис работает нестабильно, интеграцию надо переделать. Вот и синергетический эффект в декомпозиции возникает.
— Разработчик – часто исполнитель, и не только в каскадных моделях. Как изменить его метод мышления и превратить из простого «кодера» в важный механизм достижения бизнес-целей?
— Слаженная команда обладает достаточной эмпатией, чтобы проникнуться проблемой и решить ее. Можно начать с того, что мы сделаем и зачем. Нужно построить карту влияния, импакт мап, расписать проблемы и понять, что мы решаем путем их устранения. Банальные инструменты визуализации неплохо вовлекают людей в процесс и объединяют.
И здесь лежат две простые идеи. Первая – это идея T-shape. Если завтра вы не сможете работать, ребята вас поддержат, вы не остановите бизнес-процессы. Вторая – вы создаете дополнительный источник мотивации для команды. Если они прониклись идеей, то вы тем самым сокращаете аттришн, ведь никому не секрет, что рынок IT сейчас на хайпе. Мобильному разработчику уровня мидл не составит труда найти новую работу уже завтра, и, возможно, его даже ждет one-day offer.
— В каскадной системе мотиваций речь чаще всего речь идет о финансовой выгоде. Какова сильнейшая мотивация в вашей компании?
— Влияние на результат. Райффайзен Банк специально делал структуру команды плоской, чтобы сближать иерархические уровни. У меня один шаг до правления банка. Так как я в плоской структуре с разработчиками, у них это плюс-минус два шага. Таким образом, люди получают шанс реализовать свои идеи и внести свой вклад в процесс, создав импакт.
Это сильнейшая мотивация, дополняет ее только правильная структура внутри компании. Она позволяет получать нетоксичную обратную связь, разговаривать на равных, говорить и быть услышанным.
— Какие советы вы могли бы дать начинающим продакт-менеджерам, а также тем, кто хочет оптимизировать рабочие процессы и повысить их эффективность?
— Самая большая проблема, которую испытывает начинающий продуктолог – эффект самозванца. Этот эффект вызывает ощущение энтропии, хаоса. Поймите, что вам не нужно все знать. Человек часто думает, что он должен все тащить на себе, раздавать команды... Это вызывает нервозность и неуверенность в своих силах. Вы должны доверять команде, а если чего-то не можете, то спокойно скажите об этом. Учитесь думать вместе с коллегами, и от этого все выиграют.
Также вам желательно культивировать волонтерство и T-shape в своей команде. Я могу отсутствовать во время спринта, но быть уверенным в том, что ребята справятся без меня. Возьмут задачу, декомпозируют и все сделают сами. Если вы воспитываете волонтеров и культивируете T-shape, это будет способствовать росту эффективности команды. Вы сможете полностью положиться на людей, с которыми работаете.
— Разумно, если и они смогут положиться на вас в случае необходимости.
— Безусловно. В рамках T-shape вы не только должны требовать от людей, чтобы они вовлекались в бизнес, учились декомпозиции и скраму, вам нужно быть готовым в любой момент помочь команде, если того требует ситуация. Если у вас заболел тестировщик, скачайте симулятор для мобильного приложения и помогите остальным пройти регресс. Не бойтесь помогать, берите часть задач на себя.
— Как выстроить плодотворные и доверительные отношения с коллегами?
— Заведите уан-ту-уаны, слушайте людей. Да, это не семья, ведь вы в формальных отношениях, но полезно узнать, чем люди заняты помимо работы, чем увлекаются, что их беспокоит. Вы должны хорошо узнать людей и позволить им узнать себя.
На уан-ту-уанах для меня хорошо работает один фреймворк, который позволяет понять, что люди хотят от организации. Есть работа, на которую организация нанимает нас, а есть работа, на которую нанимаем организацию мы – например, ради финансовой мотивации для выплаты ипотеки или повышения квалификации.
Поговорите с разработчиком и узнайте его профессиональные цели, личную мотивацию. Помогите прокачать его личные цели – это позволит подготовить аттришн, если он захочет уволиться, или предложить нечто особенное, если вы не захотите его терять. Все это окупится, так как нанять и обучить нового разработчика будет дороже, чем сохранить старого.
Ну и главное – старайтесь через эмпатию выстраивать отношения с командой, не нервничайте на пустом месте и не пытайтесь играть в автократию.
Комментарии