Quello che abbiamo costruito per usarlo prima noi.

Automatizzare i processi degli altri è un lavoro fatto di scelte. In quasi ogni progetto arriva il momento in cui un passaggio del flusso dipende da uno strumento già pronto, e decidere quale usare tocca a noi. Per molto tempo abbiamo preso questa decisione da fuori: leggendo la documentazione, provando per una settimana, fidandoci della pagina dei prezzi. Il resto lo scopriva il cliente: il limite che salta fuori solo con i volumi di fine mese, l'assistenza che risponde dopo tre giorni, il rincaro che scatta al rinnovo annuale del contratto.

Costruire i nostri è stato il modo per portare una parte di quella decisione all'interno. Nessuno degli strumenti qui sopra è nato da una riunione sul portafoglio prodotti: vengono tutti da un collo di bottiglia che si è fatto sentire prima nel nostro lavoro o in quello di un cliente, e che non siamo riusciti a risolvere comprando qualcosa. Quando lo stesso problema si presenta per la terza volta in tre aziende diverse, non è più un'eccezione, e comincia a valere il costo di costruire.

Il criterio per partire è prudente di proposito, e vale la pena dichiararlo: diventa prodotto solo quello che usiamo nel nostro lavoro di tutti i giorni. È un filtro scomodo, perché scarta buone idee che nessuno qui dentro userebbe. Ma è l'unico che impedisce a chi lavora su commessa di trasformarsi in una fabbrica di software che nessuno gestisce.

La parte più utile è la più noiosa da spiegare: ci siamo fatti un'opinione precisa sul costo di manutenzione. Quando un'automazione si può risolvere in tre modi, la scelta raramente è tecnica. Riguarda chi la manterrà fra diciotto mesi, quanto spesso il fornitore cambia le regole del gioco e cosa succede il giorno in cui la persona che conosceva la materia lascia l'azienda. Chi consegna e se ne va non deve rispondere a queste domande.

È cambiato anche quello che accettiamo di costruire da zero. Aver scritto software nostro rende evidente quanto è grande l'impegno che c'è dietro ogni strumento nuovo: documentazione, aggiornamenti, migrazioni, il giorno in cui si rompe. Per questo buona parte delle raccomandazioni che escono da un nostro progetto è di non costruire: usare quello che esiste già, o semplicemente smettere di fare il passaggio di cui nessuno sa spiegare il motivo.

E c'è un effetto diretto: a volte il pezzo che mancava nel flusso era già stato costruito. Quando succede, diciamo da dove viene e quanto costa, e la decisione resta al cliente. Quello che non succede è che un nostro prodotto entri nel perimetro per comodità: il metro di giudizio è lo stesso che applichiamo agli strumenti di terzi.