PhotoCRM — il sistema che non perde niente

Il punto di partenza

Un'azienda di fotografia immobiliare riceve richieste di servizio da decine di agenzie. Ogni richiesta arrivava da un modulo Google, finiva in un foglio di calcolo, e da lì qualcuno la leggeva, decideva quando farla, la scriveva sul calendario e assegnava un fotografo.

Funzionava. Fino a un certo volume.

Il problema di un foglio di calcolo non è che sia primitivo: è che non ha opinioni. Se una riga arriva con l'indirizzo scritto male, il foglio la accetta. Se due agenzie si chiamano quasi uguale, il foglio non se ne accorge. Se una riga viene sovrascritta, il foglio non lo dice a nessuno. Il lavoro di capire cosa fosse andato storto ricadeva sulle persone, ogni giorno, a mano.

La regola: zero perdite silenziose

Quando ho progettato il sistema che ha sostituito quel flusso, ho messo una sola regola sopra tutte le altre.

Un dato può essere sbagliato, incompleto o incomprensibile. Non può sparire senza che qualcuno lo sappia.

Sembra ovvia. Non lo è: la maggior parte dei sistemi di importazione fa esattamente il contrario. Trovano una riga che non rispetta il formato e la scartano, magari scrivendo una riga di log che nessuno leggerà mai. Il risultato è un sistema che sembra pulito e in realtà sta perdendo lavoro.

Le conseguenze pratiche di quella regola:

• Un ordine senza indirizzo non viene rifiutato: entra marcato come [Da completare], con la nota di cosa manca, e finisce in cima alla lista di chi deve sistemarlo.
• Un'agenzia il cui nome non corrisponde a nessuna anagrafica non fa scartare la riga: la riga entra e l'agenzia finisce in una coda di assegnazione rapida, dove una persona decide in due secondi.
• Ogni tentativo di importazione lascia una traccia con un esito esplicito. Non esiste lo stato "non è successo niente".

Il costo di questa scelta è che il sistema mostra il disordine invece di nasconderlo. Il primo mese è scomodo. Poi diventa l'unica ragione per cui ti puoi fidare dei numeri.

Il passaggio più delicato

La migrazione dal vecchio flusso al nuovo è stata la parte che poteva fare più danni. Anni di richieste storiche andavano recuperate e riconciliate con gli ordini già esistenti, senza creare doppioni e senza perdere nulla.

Il recupero storico ha esaminato 6.421 risposte, trovando le corrispondenze con gli ordini già a sistema e collegandole. La verifica vera è arrivata subito dopo: la prima sincronizzazione in tempo reale dopo il recupero ha importato zero righe nuove. Nessun duplicato. Il che significa che il recupero aveva già preso tutto quello che c'era da prendere.

Nella stessa operazione sono emersi problemi che il foglio nascondeva da anni — gruppi di ordini duplicati per indirizzo, righe con filiali non riconoscibili. Non li ha creati la migrazione: li ha resi visibili.

Cosa ho imparato

Togliere è una funzionalità. A un certo punto ho rimosso un intero modulo di post-produzione e nascosto sei pagine poco usate. Il codice è rimasto nel repository, la navigazione è diventata più corta. Un gestionale che fa cinque cose che servono batte un gestionale che ne fa quindici di cui tre servono.

Le automazioni devono girare dove è noioso. Le sincronizzazioni programmate non girano sulla piattaforma che ospita l'applicazione, ma su un servizio di automazione separato: costa zero, è più prevedibile e se si rompe non porta giù il sito.

Un sistema interno è un prodotto. Ha utenti, ha un ciclo di rilascio, ha regressioni e ha persone che si arrabbiano se lo cambi male. Trattarlo come uno script è il modo più veloce per farlo morire.