Сначала расскажу о синхронизации продуктового видения на уровне всего банка. Направления бизнеса формируют структуру «Сбера»: в ней несколько больших бизнес-блоков, один из которых — «Розничный бизнес», в котором я работаю. Блоки поделены на трайбы, трайбы — на кластеры, а кластеры – на команды.
На меня непосредственно влияют цели лидера трайба, которые сначала декомпозируются на уровень кластера, а потом — на уровень команды. Цели команд декомпозируются на различные эпики (в терминах Jira), под эти эпики мы формируем гипотезы и заводим их в виде сторей (тоже термин из Jira), а дальше идет синхронизация по гипотезам и сторям. Но есть команды, которые не работают с гипотезами, — например, команды, которые занимаются различными интеграциями.
Цели каждого уровня (кластера, трайба) обсуждаются на встречах. Например, есть общие встречи для синхронизации между кластерами, которые помогают уточнить видение всех команд и сверить ориентиры по целям. После таких обсуждений кластер-лиды обсуждают результаты с каждой командой.
Еще есть стартовый синк — встреча-погружение, на которой лиды рассказывают о целях, объясняют, почему цели именно такие. А команды обсуждают, что необходимо сделать для достижения целей. Такие вводные встречи обычно проходят в конце года — в ноябре или декабре. Их достаточно много — ведь они помогают синхронизироваться на глобальном, стратегическом уровне и понять, что команды и кластеры не делают противоречащие друг другу вещи.
Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.
Например, если для достижения цели мне понадобилась биометрия в продукте, то человек, который на уровне «Сбера» отвечает за нее, должен сказать: «Хорошо, я тоже ставлю себе цель по биометрии и закрою твою потребность».
Инструменты, которые помогают синхронизировать процессы продуктовой разработки
Синхронизации
Синхронизация на уровне владельцев продуктов. Это регулярные встречи для синхронизации по всем задачам с теми людьми, с которыми у тебя есть пересечения по продукту. Например, у нас четыре команды, которые занимаются IVR (Interactive Voice Response, голосовой бот на номере 900), и мы синхронизируемся раз в неделю: обговариваем все изменения в продукте, результаты проверки гипотез. То есть все, о чем нам обязательно надо знать.
Формат синхронизации наших IVR-команд — это просмотр и корректировка роадмапа, некая агрегация всего, что у нас сейчас в работе по гипотезам и попытка уложить это в более-менее четкий таймлайн, чтобы, например, команда, которая делает какую-то интеграцию, знала, что мне эта интеграция уже не нужна прямо сейчас — она понадобится только спустя три месяца, потому что какая-то из гипотез не выстрелила.
Синхронизация с внешними командами из других продуктов, с которыми есть взаимозависимости и пересечения. У меня есть несколько таких регулярных встреч — одна из них проходит уже три года, на ней я общаюсь с владельцем продукта, от которого мы очень сильно зависим. По плану она длится час, но иногда хватает и десяти минут — если с предыдущего звонка мало что изменилось. Эта встреча похож на стендап — только между менеджерами разных продуктов и с большей протяженностью, потому что почти всегда возникают сложности, которые надо обсудить и решить. В каких-то случаях это может быть и обычным обсуждением: каждый из нас приходит со своим списком вопросов и мы проходимся по ним.
Фреймворки
Чтобы продуктовая разработка была еще более консистентной и вопросы решались не только на уровне менеджеров продуктов, мы стараемся все свои задачи стандартизировать с помощью фреймворков. Например, команды, которые у нас занимаются IVR, делают свой продукт по единым принципам: есть стандарты для текстов, формирования клиентского пути, необходимая последовательность шагов, чек-листы под разные сценарии. То есть мы берем любую задачу и оборачиваем ее в понятный и привычный всей команде фреймворк — стейкхолдеры и коллеги читают получившийся документ и быстро погружаются в тему. Есть и инструкции по фреймворкам — они служат ориентиром, по которому надо сверяться, правильно ли ты выполняешь ту или иную операцию. И конечно, их в обязательном порядке изучают новые сотрудники, чтобы быстрее погрузиться в продукт и процессы.
Фреймворк — это не какая-то высеченная «в камне» десять лет назад внутренняя нормативная документация. Это живой продукт, набор документов, в которых все описано. Он постоянно обновляется и дополняется. Подобные фреймворки у нас используют не только менеджеры продуктов, но и, например, аналитики. Это помогает сделать итоговое решение простым и консистентным, а результаты — сравнимыми, когда над разными взаимосвязанными задачами работает много аналитиков.
Гайды
Еще в каждом продукте есть гайды. Они находятся на разных этапах проработки и иногда бывают очень поверхностными, если продукт еще очень молодой. Наш гайд по IVR лично я оцениваю как Medium Rare, а вот гайд по мобильному приложению «Сбера» — одному из флагманских продуктов с огромными MAU и DAU — находится уже на уровне well-done. В нем все описано максимально просто и понятно, вплоть до мельчайших деталей: открываешь его и понимаешь: какими должны быть экраны, что можно делать в продукте, чего нельзя, как протекают процессы продуктовой разработки.
Как решаются сложные вопросы и несостыковки по срокам
Причины могут быть разными: у команды другие приоритеты, физически невозможно уложиться в сроки, ограничения legacy-систем — например, они так тесно переплетены, что проще сделать всё заново и не встраиваться в них. В рамках Discovery Sprint у команд, которые активно разрабатывают какие-то части продукта и пересекаются по задачам, такое часто случается. Обычно канва обсуждения проблем строится примерно так: нам надо получить от вас готовое решение через неделю, а вы готовы выдать его только через полгода. Что мешает сделать через неделю?
Когда мы определили, что нам мешает, мы начинаем обсуждать проблему. Если вы взаимодействуете с командами, которые готовы идти навстречу, — вы ищете решение вместе, если это команды, которые не очень готовы взаимодействовать и идти на уступки, то придется искать решение самостоятельно: с помощью своих знаний и понимания процесса или пытаясь надавить на через вышестоящее руководство.
Когда задача очень важная, ты просто приходишь к лиду кластера или трайба и говоришь: «У нас есть такая потребность, она обусловлена такой-то необходимостью с точки зрения целей компании, даст такую-то бизнес-ценность. Давайте вместе подумаем — способна ли та задача, которую сейчас делает команда, дать сопоставимую ценность? Какая задача важнее? И если ты экономишь банку сто рублей, а решение, которое делает команда, сэкономит сто миллионов, ты просто отступаешь и ждешь, когда они освободятся.
Хотя как правило вы можете сделать то, что вам нужно, самостоятельно. Конечно, это не всегда быстрее — ведь в разных задачах используются разные среды разработки, разные правила взаимодействия. И пока ты погрузишь в задачу и процессы свою команду, может освободиться та команда, которая должна была сделать это решение изначально.
Если же сразу разработать полноценное решение не удается, то для начала можно собрать какой-то временный вариант, используя legacy-систему. Пусть лучше решение запустится в продакшен и будет работать, а тем временем доработается идеальный запланированный вариант.
А еще всегда есть четвертая опция — просто поднять руки вверх, сдаться и взять в работу вторую лучшую гипотезу 🙂
