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

Продуктовый разработчик не только пишет код, но и погружается в бизнес-требования к продукту, думает о том, какую ценность фича принесет конечному пользователю.
В каких-то компаниях к продукту так относится только product owner (PO). В QIWI — вся продуктовая команда. Конечно, PO проводит интервью, изучает конкурентов и знает, какие фичи нужны продукту. Но разработчики видят, какие из них можно дать клиенту максимально быстро. Если они вникают в продукт и сценарии заказчиков, команда дает клиентам больше ценности.


За счет глубокого понимания и изучения потребностей клиентов мы можем получить скорость разработки с сохранением необходимого уровня качества.
Например, нас перестало устраивать наше десктопное приложение. Рынок ушел вперед, и мы решили выпустить новую версию в вебе. Если бы мы просто скопировали всю функциональность, то эта задача заняла бы 12–18 месяцев. Мы же сконцентрировались на тех клиентских сценариях, которые жизненно важны клиентам, и спроектировали во многом новый продукт. Первую версию с сохранением основных клиентских сценариев выпустили через 4 месяца.
Продуктовые разработчики принимают всю ответственность за доведение результата спринта до пользователя. Она начинается, когда PO принес задачу для обсуждения, а заканчивается анализом пользы от выпущенной фичи: «Нет не твоей проблемы, когда это касается темы спринта».

...и почему он в форме Т
Продуктовая команда QIWI — это автономная единица, которая сама закрывает все свои задачи. Она формируется, исходя из компетенций, нужных для развития продукта. Ее основа — разработчики. Другие специалисты (дизайнер, скрам-мастер, тестировщики, аналитики) появляются, если задачи требуют их профильной экспертизы и есть загрузка на фултайм.
А если нет, разработчики закрывают смежные задачи за счет T-shape. Так называется модель развития как по основной специализации («вертикальная черта Т»), так и в смежных («горизонтальная черта»). Скажем, бэкенд-разработчик может прокачаться во фронтенде и UI до достаточного уровня, чтобы эффективно работать на стыке специализаций и быстро решать небольшие задачи в этих областях.

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

По опыту QIWI, если команда состоит из T-shaped специалистов, в ней лучше работается. Когда нет островков специализации, то нет и сложностей коммуникации между ними, и потерь информации на границах.

Когда разработка iOS и Android у нас была разделена, мы с трудом понимали друг друга. Но мы объединились в фича-команды, перешли на продуктовый подход, стали немного затягивать себе «чужие» компетенции. Так нам гораздо легче договариваться и быстро выпускать фичу сразу на все платформы.
Еще T-shape делает продуктовую команду стабильной. Разработчики перекрывают смежными компетенциями профили друг друга, и, если кто-то недоступен, команда все равно выполняет спринт. А если специалист хочет сменить направление, скажем, перейти из аналитиков в iOS-разработчики или из автотестирования в бэкенд-разработку, T-shape облегчает задачу.
T-shape формируется естественным образом, когда команде нужно нарастить компетенции для текущих или будущих задач.

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

О продуктовой разработке в QIWI
1. Code as a Service: автоматизировать все, что можно
«Классическая автоматизация релизов — TeamCity, где разработчик жмет кнопку „Выложить на прод“, а инфраструктурная команда выпускает релиз и мониторит процесс, — поясняет Алексей Казин. — Мы идем к тому, что каждый разработчик сможет делать все это сам через выстроенный пайплайн, и готовим для этого автоматическую систему. В целом автоматизируем все, что можно, чтобы у продуктовых команд оставалось больше времени на исследования проблем пользователя, проверку гипотез, релизы и сбор обратной связи».

У нас есть выделенные команды Dev2Dev, которые занимаются задачами по развитию разработки. Это обычно что-то большое, инфраструктурное: внедрение UI Kit для веба на всю компанию, разработка портала со всеми ресурсами для разработчиков или объединение бизнес-логики для iOS и Android, так что теперь в разработке почти нет расхождений. В их работе больше всего R&D и нетривиальных технических решений.
2. Общее владение кодом
Весь исходный код компании доступен каждому разработчику: можно ознакомиться и предложить улучшения, даже если это не твой продукт. Это помогает командам собирать обратную связь, ставить правильные вопросы и развивать продукт. «А еще, — смеется Александр Десятов, — когда несколько человек ориентируются в твоем коде, в отпуске тебя не дергают по каждой мелочи».

3. Плоская иерархия
Иерархии в QIWI нет: все общаются на «ты» и на равных, сотрудники сами определяют для себя способы достижения результата и могут отстоять свою точку зрения перед любым менеджером.
Решения очень часто принимаются децентрализовано. Скажем, если команде нужен внутренний сервис, она обращается к эксперту, который его предоставляет, а не ставит задачу сверху через менеджера. При этом команды сохраняют распределение ответственности по ролям. Разработчик может аргументировать свой способ решения бизнесовой задачи, обозначить риски, зависимости, обсудить с менеджером объем работы. А решение о приоритетности задачи принимает менеджер (PO, APO или техлид).
Каждый сотрудник и команда может напрямую предложить коллегам идею, обсудить вопрос, без формальностей обратиться за помощью и экспертизой или заглянуть в кодовую базу соседей и найти баг, если вдруг рушится интеграция.

Продукты QIWI
Все знают флагманский продукт QIWI — Кошелек. Но вообще продукты QIWI пронизывают всю финансовую систему России и обеспечивают 156 млрд транзакций в месяц. Когда вы платите через крупнейшие банки, делаете покупки на маркетплейсах или заказываете такси, вполне возможно, что «под капотом» продукт QIWI. Вот некоторые из них.
QIWI Кошелек

Кошелек прошел путь от терминалов до онлайна, мобайла, разных вариантов чекаута¹ и собственного эквайринга². Сейчас мы помогаем людям легко решать задачи по оплате и переводу денег. Наша особенность — простота и большой выбор провайдеров, которых мы быстро подключаем.
QIWI Выплаты поставщикам металлолома

Допустим, человек выгреб с дачи металлолом и принес его в пункт приема. Раньше ему заплатили бы налом, но в 2023 году наконец-то приняли закон о переводе огромного рынка (более миллиарда рублей) на безналичные платежи. К ним предъявляются особые требования. Например, всегда должен быть акт: кто сдал, что именно, на чем привез и т.д. Мы оформляем транзакцию по правилам регулятора и проводим выплату в удобной сборщику форме.
QIWI Выплаты таксопаркам

Большинство таксопарков работают через посредников, но для клиента это все не прозрачно. Клиенту хорошо: заказал такси — списались деньги. По факту это множество транзакций: от клиента — Яндексу, от него — таксопарку, а затем — таксисту на карту или счет. Последняя часть — как раз наша.
Самые творческие задачи у нас связаны с интеграцией продукта в систему QIWI. В платеже задействовано много компонентов (проведение платежей, сверка балансов, отчеты и т.д.). Поэтому нам нужно немного понимать бухучет, схему движения денег (платежи, комиссии и возвраты) и с учетом этого настраивать и автоматизировать работу продукта.

Так работают в QIWI: современный стек, гибкость, самореализация
«У нас классический современный энтерпрайзный стек без динозавров и экзотики», — в один голос говорят Александр, Алексей и Евгений. Основные языки — Java и Kotlin. В мобильной разработке используются нативные iOS- и Android-решения. В вебе — «старый» React и «новый» MobX. Базы данных — в основном на PostgreSQL, а для мониторинга применяются Prometheus, Grafana и Zabbix. Поверх всего — системы автоматизации с пайплайнами, TeamCity.

А бэкенд у нас — на микросервисах Spring Boot, по инфраструктуре — Kubernetes, Argo CD и вот это все. Кстати, инфраструктура и облако у нас свои. Микросервисы развернуты в трех собственных дата-центрах, для устойчивости поднято несколько инстансов. Так что в построении распределенной инфраструктуры у нас тоже большая экспертиза.
Работа продуктовых команд гибко строится по скрам. Скрам-мастера помогают адаптировать методологию, чтобы конкретная команда легко и удобно решала свои задачи. А команда адаптирует процессы под себя так, чтобы это было эффективно и удобно, без лишней бюрократии. Например, команда Александра Десятова применяет фреймворк LeSS³.
Благодаря автономии команд и плоской иерархии разработчики QIWI больше влияют на процессы. Скажем, PO может предложить фичу. Но, как ее делать и в каком спринте, решается на внутреннем обсуждении команды. В работе — тоже свобода решений.

Никакой условный «архитектор всея QIWI» не принесет готовое ТЗ, а тимлид не микроменеджит, контролируя каждую строчку. Ты сам понимаешь, как и для кого делаешь фичу и почему именно так. Техническая реализация идеи — это всегда творческая работа продуктовой команды. Для нас с ребятами — это драйв, ответственность и самореализация!

Трудно ли стать продуктовым разработчиком?
Не трудно, если есть желание. Процессы QIWI помогают постепенно погрузиться в разработку. Сначала — курс по продуктовому подходу, скрам ритуалам, потом — обучение в деле. Когда вся команда фокусируется на том, как конкретная фича поможет клиенту, новый сотрудник тоже впитывает культуру продуктового мышления.
Подход QIWI подойдет тем, кто готов взять ответственность за свое развитие: погружаться в тему, спрашивать коллег, разбираться в документации. Если есть любознательность, самостоятельность и инициативность, то hard skills подтянутся — тем более что в QIWI отличные возможности обучения и коллеги-профессионалы.

__________
¹ Чекаут — процесс оформления заказа в интернет-магазине, страница оплаты, которая предоставляет покупателю возможность выбора наиболее удобного способа платежа.
² Эквайринг — возможность для торгового предприятия принимать безналичную оплату товаров и услуг банковскими картами.
³ Large-Scale Scrum, сокращенно LeSS. Создатели этого фреймворка позиционируют его как «Скрам, применяемый ко множеству команд, работающих совместно над одним продуктом».