“Quanto costa sviluppare una piattaforma?” è una domanda corretta.
Ma senza altre informazioni non ha una risposta utile.
Una piattaforma può essere un’area in cui pochi clienti inviano richieste. Oppure un sistema con pagamenti, abbonamenti, professionisti, documenti e molti tipi di utenti.
Chiedere un prezzo senza definire il progetto è come chiedere quanto costa costruire un edificio senza sapere quante stanze deve avere.
Una cifra data troppo presto può essere soltanto molto larga oppure ingannevole.
Il modo serio per stimare il costo è capire che cosa deve fare la prima versione, quali rischi contiene e quali parti possono aspettare.
Il numero di schermate conta meno del lavoro che c’è dietro
Una schermata semplice può nascondere regole complesse.
Un modulo di richiesta potrebbe:
- cambiare in base all’utente;
- controllare dati e documenti;
- calcolare un prezzo;
- assegnare il lavoro;
- richiedere un’approvazione;
- inviare informazioni ad altri sistemi.
Al contrario, dieci pagine informative possono richiedere poco lavoro.
Per questo stimare “a schermata” porta spesso fuori strada. Il costo dipende soprattutto da regole, percorsi e casi particolari.
Primo fattore: utenti e permessi
Chi usa la piattaforma?
Potrebbero esserci clienti, dipendenti, amministratori, professionisti e responsabili.
Ogni tipo di utente può vedere informazioni diverse e compiere azioni diverse.
Un cliente vede soltanto le proprie richieste. Un professionista vede quelle assegnate. Un responsabile controlla il gruppo. Un amministratore può modificare tutto.
Più ruoli e regole esistono, più il sistema richiede progettazione e verifiche.
La domanda non è quanti utenti avrai. È quanti modi diversi di usare la piattaforma devi gestire.
Secondo fattore: il percorso principale
Che cosa deve riuscire a completare l’utente?
Prenotare, acquistare, inviare una pratica, creare un preventivo o ricevere un servizio sono percorsi diversi.
Per ogni percorso bisogna definire:
- dati richiesti;
- controlli;
- stati;
- notifiche;
- decisioni;
- risultato finale.
Una prima versione con un solo percorso ben definito costa meno ed è più facile da provare di una piattaforma che tenta di gestire cinque servizi contemporaneamente.
Terzo fattore: pagamenti e abbonamenti
Incassare un pagamento singolo è diverso dal gestire:
- abbonamenti;
- rinnovi;
- prove gratuite;
- piani diversi;
- commissioni;
- rimborsi;
- fatture;
- mancati pagamenti.
Il servizio esterno usato per incassare svolge una parte importante del lavoro. La piattaforma deve comunque sapere che cosa è stato pagato, quali funzioni attivare e come comportarsi se qualcosa non va.
Più il modello commerciale è complesso, più cresce il lavoro.
Quarto fattore: dati e documenti
La piattaforma deve partire vuota oppure importare dati esistenti?
Trasferire clienti, pratiche, prodotti o documenti richiede controlli. I dati vecchi possono essere incompleti, duplicati o organizzati in modo diverso.
Anche i documenti possono aumentare il perimetro:
- caricamento e conservazione;
- creazione automatica;
- firma;
- versioni;
- scadenze;
- accessi riservati.
“Gestire documenti” può significare una cartella ordinata oppure un intero processo. La differenza di costo è grande.
Quinto fattore: collegamenti con altri software
La piattaforma potrebbe dover comunicare con gestionale, ecommerce, calendario, sistemi di pagamento o altri servizi.
Ogni collegamento va verificato.
Bisogna capire:
- quali dati sono disponibili;
- come possono essere letti o scritti;
- ogni quanto devono essere aggiornati;
- che cosa succede in caso di errore;
- chi gestisce l’altro sistema.
Il fatto che un software dichiari di avere delle API, cioè strumenti per comunicare, non garantisce che offra proprio le informazioni necessarie.
Sesto fattore: automazioni
“Automatizzare il processo” può voler dire cose molto diverse.
Inviare una conferma automatica è semplice. Assegnare un lavoro in base a molte regole, calcolare un prezzo particolare o generare documenti complessi richiede più analisi.
Per ogni automazione chiedi:
- quale attività elimina;
- quali dati usa;
- quali regole applica;
- che cosa succede nei casi non previsti;
- quanto spesso viene eseguita.
Un’automazione rara e complessa potrebbe costare più del lavoro manuale che elimina.
Settimo fattore: area di gestione
Ogni piattaforma ha una parte visibile agli utenti e una parte usata da chi la amministra.
Qualcuno deve controllare utenti, richieste, pagamenti, contenuti, errori e impostazioni.
L’area di gestione viene spesso dimenticata nei primi preventivi, ma è essenziale. Senza di essa anche una piccola modifica richiede l’intervento di uno sviluppatore.
Devi decidere che cosa il personale può gestire in autonomia e che cosa richiede assistenza tecnica.
Ottavo fattore: quanto deve essere completa la prima versione
La variabile più importante è il perimetro.
Vuoi provare un solo servizio con un gruppo limitato di utenti oppure lanciare subito una piattaforma pronta per molti casi?
Una prima versione può lasciare manuali alcune attività interne. Può limitarsi a un tipo di cliente o a un percorso.
Questo non significa costruire qualcosa da buttare. Significa investire prima nel nucleo e aggiungere il resto quando l’uso dimostra che serve.
Provare a prevedere tutto all’inizio aumenta costo e rischio. Soprattutto rende difficile distinguere ciò che è necessario da ciò che è soltanto immaginato.
I costi che arrivano dopo lo sviluppo
Il preventivo iniziale non è l’unico costo.
Considera anche:
- server e servizi esterni;
- manutenzione;
- assistenza;
- aggiornamenti;
- correzioni;
- nuove funzioni;
- controllo delle prestazioni;
- copie di sicurezza.
Una piattaforma utilizzata cambia nel tempo. Non perché sia stata progettata male, ma perché cambiano utenti, servizio e mercato.
Chiedere come verrà mantenuta è importante quanto chiedere come verrà sviluppata.
Come ottenere una stima utile
Per ricevere una stima credibile prepara queste informazioni:
- problema da risolvere;
- tipi di utenti;
- azione principale;
- passaggi del servizio;
- dati e documenti;
- pagamenti;
- software da collegare;
- attività che possono restare manuali;
- obiettivo della prima versione.
Non serve scrivere un documento tecnico. È compito di chi progetta trasformare queste informazioni in un perimetro.
Un buon preventivo dovrebbe indicare che cosa è compreso, che cosa è escluso, quali elementi devono ancora essere verificati e quali decisioni possono cambiare il costo.
La domanda giusta non è soltanto “quanto costa?”
È anche:
Qual è la versione più piccola che produce un risultato reale e ci permette di decidere il passo successivo?
Una piattaforma economica che non verifica niente è uno spreco.
Una piattaforma enorme costruita prima di avere utenti è un rischio.
Il costo sensato sta nel mezzo: abbastanza per mettere alla prova il nucleo del progetto, non abbastanza per costruire in anticipo ogni possibilità immaginata.
Definiamo il perimetro prima di parlare di costo
QUODE analizza utenti, flussi, dati e priorità per trasformare l’idea in una prima versione stimabile e realmente utilizzabile.