Gestire i pagamenti in scala: quello che la PM school non insegna

I pagamenti non sono come il resto del lavoro di prodotto. I riflessi da PM che funzionano altrove qui non reggono.

"Muoviti velocemente e rompi le cose" va benissimo per le funzionalità. Cambia tutto quando rompere qualcosa significa che un cliente è stato addebitato due volte. O tre. O pagato per una transazione fallita. Le competenze che contano davvero nei pagamenti non le insegna nessuna PM school.

Il progetto pagamenti a QubicaAMF

Quando sono arrivato, il sistema era in crisi. Quarantaquattro segnalazioni aperte. I centri perdevano transazioni. Tecnicamente il sistema funzionava, ma operativamente era inutilizzabile. Il riflesso del team: aggiustare tutto subito.

Nei pagamenti questo riflesso ti inganna. Non puoi risolvere tutto insieme perché aggiustare una cosa rischia di romperne un'altra.

La prima competenza è semplice: leggi la documentazione API come un investigatore. La documentazione di Square è ricchissima, ma non ti dice come i metadati fluiscono attraverso la riconciliazione. Devi capire il modello di dati abbastanza a fondo da porti questa domanda: "Se cambiamo questo campo, cosa si rompe downstream?" Ho speso una settimana a rileggere i documenti finché non ho trovato il campo (external_payment_type) che ha sbloccato la riconciliazione senza toccarne nient'altro. Un PM, una settimana, un campo. Il centro è rimasto e è diventato un account di riferimento.

La seconda competenza: capisci come fluisce il denaro prima di toccare il codice. Ogni funzionalità tocca il denaro. Non metaforicamente. Denaro vero. "Aggiungiamo una funzionalità per dividere le entrate tra due account" sembra sensato finché non realizzi: cosa succede se la divisione fallisce a metà? E se un account raggiunge il limite? E se un chargeback arriva sessanta giorni dopo e solo uno dei due è stato stornato? Devi tracciare il percorso del denaro prima che il team di engineering cominci a scrivere una riga.

La conformità PCI come vincolo di design, non come casella da spuntare

PCI DSS è il baseline. Ma non è una casella che spunti e passi oltre. È un vincolo che modella ogni funzionalità.

A QubicaAMF ho proposto ai certificatori di ridurre lo scope ristrutturando l'architettura in tre canali: pagamenti, riconciliazione e settlement. Ognuno su una traccia di conformità diversa. Questo ha ridotto il rischio di penalità e reso il sistema più semplice. Non è stata una vittoria di compliance. È stata una decisione di design di prodotto che è andata a beneficio della compliance.

Il motivo funziona: se capisci la conformità da un angolo di prodotto, diventa un vincolo di design, non un ostacolo. I migliori prodotti non nascono senza vincoli. Nascono dentro vincoli buoni.

La maggior parte dei team tratta la conformità come un ripensamento. "Costruisci la funzionalità, poi assicurati che siamo conformi." Nei pagamenti la conformità deve stare a monte. Definisce cosa è persino possibile.

Il coraggio di fermare una funzionalità quando la stabilità è a rischio

Questa è la parte più difficile. E qui i riflessi da PM danneggiano.

La funzionalità di rimborso era pronta. Il codice era solido, i test passavano. Eravamo due settimane prima del picco delle vacanze: i quattordici giorni più movimentati dell'anno per volume di transazioni. Il team voleva rilasciarla per raccogliere dati precoci.

L'ho bloccata. Non perché il codice era cattivo. Perché se qualcosa va storto con i rimborsi durante il picco, il danno è enorme. Ogni rimborso emesso in quei giorni. Centinaia di centri. Rimborsi doppi, riconciliazione persa, chargebacks sessanta giorni dopo.

Il team ha insistito. Il codice era buono. I test approfonditi. Rilascialo.

La risposta è stata no. Non "forse dopo altri test." No.

Abbiamo fatto una giornata intera di test. Dati reali, scenari reali, edge case reali. Abbiamo trovato tre problemi. Rilasciato dopo il picco.

Più lento? Sì. La funzionalità è uscita quattordici giorni in ritardo? Sì. L'azienda sta meglio? Anche sì, perché la funzionalità non ha causato una crisi di riconciliazione durante il picco che sarebbe costata dieci volte quello che avremmo guadagnato dai dati precoci.

Leggere le API, capire la conformità, il coraggio di dire aspetta

Queste non sono competenze sexy da PM. Non le metti nel CV come "product vision" o "stakeholder management." Ma nei pagamenti contano più della strategia.

Un PM che non legge attentamente una spec API perde i flussi di dati. Un PM che non capisce il panorama di conformità costruisce funzionalità che dovrà strappare via. Un PM senza la spina dorsale per fermare funzionalità rischiose è quello che spiega al CEO perché un bug di doppio addebito è costato all'azienda 400mila euro.

I PM che vincono nei pagamenti non sono quelli con le idee migliori. Sono quelli che capiscono una cosa sola: il sistema deve funzionare prima. Le idee vengono dopo.