Da cosa dipende il costo di un software su misura e come tenerlo sotto controllo

Due aziende chiedono "un semplice portale per i nostri clienti" e ricevono preventivi lontanissimi tra loro. Nella maggior parte dei casi nessuno dei due fornitori è disonesto. Stanno preventivando cose diverse, perché la richiesta lascia aperte quasi tutte le decisioni reali: chi userà il portale, a quali sistemi si collega, cosa succede quando qualcosa non funziona.

Nel software su misura il costo dipende meno dal numero di schermate e più dal numero di regole, ruoli e collegamenti che ci sono dietro. Uno studio di McKinsey e dell'Università di Oxford su più di 5.400 progetti IT ha rilevato che i grandi progetti hanno sforato il budget in media del 45% e hanno prodotto il 56% di valore in meno rispetto alle previsioni. Gran parte di questo scarto nasce da aspetti che nessuno aveva definito all'inizio.

Di seguito i fattori di costo che incontriamo più spesso e le abitudini di lavoro che li tengono sotto controllo.

I principali fattori di costo

Perimetro e numero di ruoli

Ogni tipo di utente aggiunge molto più di una schermata di accesso. Un sistema usato da un solo gruppo (ad esempio il personale d'ufficio) è molto più semplice di uno usato da personale, manager, clienti, fornitori e revisori, ognuno dei quali vede dati diversi e può compiere azioni diverse. Ogni ruolo moltiplica le regole sui permessi, le schermate, le notifiche e i casi di test. Quando elencate i vostri utenti, annotate anche cosa ciascuno di loro non deve vedere.

Integrazioni

Il collegamento a un sistema contabile, a un ERP, a una banca, a un corriere, a un'autorità fiscale o a un fornitore di servizi di pagamento è spesso la singola voce più consistente di un progetto. L'impegno dipende dall'altra parte: c'è un'API documentata, un ambiente di test, un formato dati stabile, qualcuno che risponde alle domande? Un collegamento a un servizio ben documentato può richiedere pochi giorni. Un collegamento a un vecchio sistema che esporta file solo una volta a notte può richiedere settimane, e avrà bisogno di attenzione ogni volta che quel sistema cambia.

Migrazione dei dati

Trasferire i dati da fogli di calcolo o da un vecchio sistema sembra un semplice copia e incolla. In realtà significa eliminare i duplicati, completare i campi mancanti, far corrispondere i vecchi codici ai nuovi e decidere cosa fare dei record che non trovano posto da nessuna parte. La migrazione è anche la fase in cui le persone dell'azienda devono investire più tempo, perché solo loro sanno se "ABC Ltd" e "A.B.C. Limited" sono lo stesso cliente.

Requisiti di qualità e sicurezza

Uno strumento usato da cinque colleghi e un sistema che gestisce pagamenti o dati personali sono prodotti diversi, anche quando le schermate si somigliano. I requisiti di disponibilità, tempi di risposta, tracciabilità delle attività, backup, controllo degli accessi e protezione dei dati aggiungono lavoro di progettazione, test e documentazione. Gli standard pubblicati aiutano a renderlo concreto. La ISO/IEC 25010 descrive caratteristiche di qualità del prodotto come affidabilità, sicurezza e manutenibilità, e l'OWASP Application Security Verification Standard fornisce un elenco di requisiti di sicurezza a diversi livelli di rigore. Scegliere il livello adeguato al vostro rischio reale evita di investire troppo poco o troppo.

Piattaforme

Un'applicazione web che funziona bene nei browser desktop e mobile è un solo prodotto. App native per iOS e Android, una modalità offline per il personale di magazzino o il supporto a vecchi browser nella rete di un cliente aggiungono ciascuno lavoro di sviluppo, test e rilascio. Prima di puntare sugli store, verificate se un'applicazione web responsive copre già l'esigenza reale.

Modello di team

Team interno, freelance, team esterno o una combinazione: ognuno ha un profilo di costo diverso. Una tariffa giornaliera più bassa non porta sempre a un costo totale più basso se coordinamento, rifacimenti e passaggi di consegne richiedono più tempo. Ciò che conta è chi prende le decisioni, quanto velocemente arrivano le risposte alle domande e come la conoscenza resta in azienda quando le persone cambiano.

Come tenere sotto controllo il costo

Partite da un prodotto minimo funzionante

Definite la versione più piccola che offre valore reale a utenti reali e realizzate prima quella. Per un portale clienti potrebbe trattarsi di accesso, stato degli ordini e download dei documenti, senza chat, strumenti di analisi o app mobile. Un MVP non è una demo: le persone devono poterlo usare nel lavoro quotidiano. Il suo scopo è confermare ciò che conta prima di spendere denaro per ciò che potrebbe contare.

Rilasciate per fasi

Suddividete il lavoro in fasi brevi, ognuna delle quali si conclude con software funzionante da provare. Il principio del Manifesto Agile resta valido: rilasciare frequentemente software funzionante, da un paio di settimane a un paio di mesi. Ogni fase è il momento naturale per rivedere la spesa, spostare le priorità o fermarsi. Un progetto lungo con un'unica consegna finale non vi lascia nessuna di queste possibilità.

Scrivete criteri di accettazione chiari

Per ogni funzionalità concordate per iscritto come capirete che è completata. "Le fatture si possono esportare" è vago. "Un contabile può esportare tutte le fatture di un mese selezionato in un file che il sistema contabile importa senza modifiche manuali" si può testare. Criteri chiari riducono discussioni, rifacimenti e il costo nascosto di funzionalità che restano "quasi finite" per mesi.

Gestite le modifiche in modo consapevole

I requisiti cambieranno, ed è giusto che cambino quando imparate qualcosa di nuovo. Il vero problema sono le modifiche non gestite. Seguite una regola semplice: ogni nuova richiesta riceve una breve descrizione scritta, una stima e una decisione su cosa slitta in avanti per farle spazio. Così il budget resta visibile e la prima versione non cresce senza che nessuno se ne accorga.

Considerate il costo totale di possesso

Il primo rilascio è solo una parte del costo. Nel corso della vita di un sistema pagate anche:

• hosting, domini, certificati e backup
• licenze di terze parti e costi delle API
• aggiornamenti di sicurezza e delle librerie su cui si basa il software
• monitoraggio e assistenza quando qualcosa si guasta
• piccole modifiche man mano che cambiano i vostri processi e la legge
• il tempo che il vostro personale dedica alla gestione del sistema

Anche le scorciatoie prese per rispettare una scadenza ravvicinata hanno un prezzo. Martin Fowler lo descrive come debito tecnico: un codice interno disordinato rallenta ogni modifica futura, come gli interessi su un prestito. Un po' di debito è una scelta sensata per un MVP, purché sia una decisione consapevole e lo ripaghiate nelle fasi successive.

Una checklist prima di chiedere un preventivo

• Elencate i ruoli utente e cosa ciascuno può vedere e fare.
• Elencate tutti i sistemi a cui il software deve collegarsi, con un referente per ciascuno.
• Descrivete i dati di cui disponete oggi e dove sono conservati.
• Annotate i requisiti legali e di sicurezza: dati personali, fatturazione elettronica, audit, conservazione.
• Decidete quali piattaforme vi servono subito e quali possono aspettare.
• Definite cosa deve includere la prima versione utilizzabile e cosa deve escludere.

Un fornitore che riceve questo elenco può fare una stima basata su fatti anziché su supposizioni, e voi potete confrontare i preventivi a parità di condizioni.

Come può aiutarvi MTV GROUP

Aiutiamo le aziende a trasformare un'idea ancora vaga in un perimetro chiaro, una prima versione utilizzabile e un piano per fasi con criteri di accettazione, prima che inizi qualsiasi spesa importante. Sviluppiamo per fasi brevi e pianifichiamo hosting, manutenzione e assistenza fin dal primo giorno, così il costo complessivo è visibile da subito. Se state preparando un progetto e desiderate un secondo parere su perimetro o budget, contattateci.