Prima di parlare di tecnologia, budget o date di consegna, c'è una domanda a cui vale la pena rispondere per prima: dovremmo davvero costruirlo? Perché LSR a volte consiglia di acquistare un prodotto, collegare i sistemi esistenti o correggere il processo.
Quando un'organizzazione si rivolge a un'azienda di sviluppo software, di solito ci si aspetta che la conversazione si concluda con una proposta di costruire qualcosa: una nuova applicazione, la sostituzione di un sistema obsoleto, una piattaforma che unisca processi scollegati. È un'assunzione comprensibile, ma salta una domanda a cui andrebbe data risposta prima che qualcuno parli di tecnologia, budget o date di consegna.
Dovremmo davvero costruirlo?
In Libertas Software Research (LSR) crediamo che sapere se sviluppare software conti quanto sapere come. A volte un'applicazione su misura è esattamente ciò che serve. A volte una piattaforma SaaS consolidata soddisfa perfettamente l'esigenza, oppure collegare i sistemi che già avete porta al risultato senza il costo e l'interruzione di sostituirli. L'obiettivo è migliorare il funzionamento di un'organizzazione, non aggiungere un'altra applicazione a un ambiente già complicato.
Le organizzazioni tendono a descrivere la soluzione che pensano di aver bisogno anziché il problema che hanno. «Una dashboard di reportistica» o «un'app per sostituire i nostri fogli di calcolo» sembra ben definito, ma dice poco su cosa abbia generato la richiesta.
Si pensi a un report di gestione mensile compilato a mano da diversi fogli di calcolo e sistemi. Richiede giorni e, quando arriva, i dati sono già vecchi. La conclusione ovvia è che serve un software di reportistica. A uno sguardo più attento, il vero problema è spesso dati scollegati e processi incoerenti: un modesto progetto di integrazione, non una nuova applicazione. E se l'indagine mostra che servono flussi di lavoro o controlli specialistici che nessun prodotto supporta, è quello il momento in cui lo sviluppo su misura si guadagna il suo posto.
Il mercato commerciale è maturo. CRM, contabilità, pianificazione, gestione documentale e business intelligence hanno prodotti con anni di perfezionamento alle spalle. Se uno soddisfa le vostre esigenze senza restrizioni irragionevoli, una sostituzione su misura aggiunge poco valore.
Ma confrontate il costo totale di proprietà, non i prezzi dell'abbonamento. Un prodotto da 500 £ al mese sono 30.000 £ in cinque anni, prima di aggiungere configurazione, integrazioni, licenze aggiuntive o modifiche ai vostri processi. Verificate come scala il prezzo, se potete esportare i dati e cosa accade se il fornitore cambia modello. E diffidate dal costringere l'azienda ad abbandonare attività che la distinguono davvero solo perché un prodotto presume altrimenti.
La maggior parte delle organizzazioni accumula sistemi nel tempo: la finanza su uno, le operazioni su un altro, l'assistenza clienti su un terzo. Ognuno funziona bene; semplicemente non dialogano tra loro, e ne derivano ritardi, doppio lavoro e informazioni incoerenti.
Sostituire tutto con un'unica applicazione è allettante, ma rischioso. Le piattaforme esistenti custodiscono anni di conoscenza operativa e integrazioni nascoste. Un livello di integrazione progettato con cura (collegamento di API, automazione dei trasferimenti, consolidamento della reportistica da fonti autorevoli) può prolungare la vita di quegli investimenti. Richiede una riflessione attenta su autenticazione, proprietà dei dati, gestione degli errori e verificabilità, ma raccomandare l'integrazione anziché la sostituzione non è ingegneria di serie B. Spesso è la decisione architetturale più ponderata.
Alcuni requisiti non si adattano davvero ai prodotti di mercato: operazioni specialistiche, esigenze insolite di sicurezza o di dati, o software che è esso stesso un vantaggio competitivo. Qui il software su misura permette all'architettura di seguire il modo in cui l'azienda lavora davvero.
Quella flessibilità comporta una responsabilità a lungo termine per manutenzione, sicurezza, test e supporto. Un sistema può rispettare la specifica originale ed essere comunque un cattivo investimento se è difficile da mantenere o non può adattarsi. Lo sviluppo su misura è giustificato quando i benefici di una soluzione costruita su misura superano sia il costo iniziale sia l'impegno continuo di possederla.
A volte il problema è il processo. Approvazioni, report e passaggi amministrativi si accumulano negli anni, molto dopo che le circostanze che li hanno creati sono scomparse. Automatizzarli esattamente come sono si limita a preservare la complessità.
Se un documento richiede cinque approvazioni, non chiedetevi come automatizzare cinque approvazioni, chiedetevi perché ognuna esista e quale rischio copra. Il software è eccellente nell'applicare regole coerenti, ma non può dirvi se il processo abbia senso. Semplificare un flusso di lavoro o chiarire le responsabilità può dare benefici reali senza un altro sistema da imparare e supportare.
I progetti su misura comportano un grande costo iniziale mentre il SaaS distribuisce il suo costo sugli abbonamenti, il che fa sembrare il confronto sbilanciato. Un confronto equo copre l'intero ciclo di vita: implementazione, licenze, hosting, supporto, manutenzione, integrazione, formazione e cambiamenti futuri.
Includete anche il costo di non fare nulla. Un processo inefficiente che consuma 20 ore di personale a settimana sono circa 1.040 ore all'anno. A una tariffa illustrativa di 35 £ all'ora, sono circa 36.400 £ all'anno, ipotizzando che il tempo possa davvero essere recuperato e reindirizzato. Aggiungete la scarsa qualità dei dati e le decisioni lente, più difficili da quantificare ma altrettanto reali. L'opzione migliore non è la più economica, ma quella con il miglior mix di valore, rischio accettabile e sostenibilità a lungo termine.
È una domanda legittima. Se raccomandiamo un prodotto o una piccola integrazione, sulla carta c'è meno lavoro di sviluppo.
Ma c'è differenza tra fornire capacità di sviluppo e agire come partner di ricerca e architettura software. Il nostro lavoro comincia prima che esista la specifica: capire il problema, valutare le opzioni e aiutarvi a decidere dove investire. Questo ha valore a prescindere dall'esito, e di solito resta comunque lavoro di analisi, architettura, pianificazione e integrazione anche quando lo sviluppo su misura non è la risposta.
Raccomandare uno sviluppo di cui non avete bisogno è controproducente. Un progetto consegnato in tempo e secondo specifica fallisce comunque se non era la soluzione giusta. Aiutare un cliente a evitare spese inutili costruisce una fiducia che dura.
L'IA e gli strumenti moderni rendono il codice più veloce ed economico da produrre. È utile, ma rende il pensiero iniziale più importante, non meno, perché lo sforzo che un tempo costringeva a chiedersi «ne abbiamo davvero bisogno?» sta scomparendo. È perfettamente possibile costruire qualcosa di tecnicamente eccellente, consegnarlo in modo efficiente e scoprire che era la risposta sbagliata.
Prima che inizi lo sviluppo, vogliamo risposte chiare sul problema di business, sul costo di lasciarlo irrisolto, su quali requisiti i prodotti esistenti non possono soddisfare, su come sarà misurato il successo (tempi di elaborazione, accuratezza, visibilità, conformità, non numero di funzioni) e su chi gestirà e supporterà la soluzione in seguito.
Ci saranno progetti in cui il software su misura è chiaramente giusto, altri in cui l'integrazione offre più valore e altri ancora in cui una piattaforma pronta all'uso fa il lavoro. Ciò che conta è che la raccomandazione nasca dalla comprensione della vostra organizzazione, non da un'ipotesi su ciò che un'azienda di software vuole vendere.
Prima di chiederci come dovremmo costruire qualcosa, vale la pena stabilire se dovremmo costruirlo del tutto.
Libertas Software Research collabora con le organizzazioni per ricercare, valutare, progettare e sviluppare soluzioni software, con un'attenzione alla manutenibilità a lungo termine, al valore operativo e a investimenti tecnologici consapevoli.