Direct naar de inhoud
Qoode
  • Guide

Come descrivere il software che vi serve

Due pagine scritte bene valgono più di un capitolato di quaranta. Le sei risposte che servono a un fornitore per darvi un numero serio.

Qoode7 min leestijd
Le sei cose che un fornitore deve sapere per fare un preventivo serio: quale problema costa più tempo oggi, chi userà il software e in quali momenti, con quali sistemi deve parlare, quali dati esistono già e in che stato, quali regole vostre non sono negoziabili e cosa deve essere vero perché il progetto sia riuscito.

La prima difficoltà di chi cerca un software su misura non è trovare il fornitore: è spiegare cosa serve. E siccome è difficile, quasi tutti fanno una delle due cose sbagliate — mandano tre righe generiche, oppure passano un mese a scrivere un capitolato che nessuno leggerà fino in fondo.

Serve una via di mezzo che esiste ed è corta. Sei risposte, due pagine, e qualunque fornitore serio può darvi un ordine di grandezza invece di una riunione conoscitiva.

Perché conviene a voi, non solo a chi legge

Una descrizione vaga non produce un preventivo più libero: produce un preventivo più alto. Chi non sa cosa dovrà fare mette un margine per l'ignoto, e quel margine lo pagate anche se poi il progetto era semplice.

Peggio: produce preventivi che non si possono confrontare. Se tre fornitori hanno immaginato tre progetti diversi, il più basso non è il più conveniente, è quello che ha immaginato di meno.

Ogni cosa che non avete scritto verrà decisa da qualcun altro, gratis per lui e a pagamento per voi.

Le sei risposte

Le sei cose che un fornitore deve sapere per fare un preventivo serio: quale problema costa più tempo oggi, chi userà il software e in quali momenti, con quali sistemi deve parlare, quali dati esistono già e in che stato, quali regole vostre non sono negoziabili e cosa deve essere vero perché il progetto sia riuscito.
Sei risposte su due pagine. È la differenza fra un preventivo e un'ipotesi travestita da preventivo.

1. Quale problema vi costa più tempo oggi

Non «ci serve un gestionale», ma: «ogni ordine viene ribattuto tre volte, dal preventivo alla bolla alla fattura, e due persone ci passano mezza giornata». Un numero, anche approssimativo, vale dieci aggettivi. È anche l'unica frase che permette di capire se il progetto si ripaga.

2. Chi lo userà, e in quali momenti

Quante persone, con quali ruoli, e soprattutto dove e quando. Cinque persone in ufficio davanti a uno schermo grande sono un software diverso da cinque persone in cantiere col telefono in mano. È la risposta che determina metà delle scelte tecniche, e quasi nessuno la dà spontaneamente.

3. Con quali sistemi deve parlare

Fate l'elenco di tutto quello che c'è: gestionale, contabilità, e-commerce, magazzino, il file che il commercialista vuole in un certo formato. Per ciascuno scrivete come si chiama e chi lo fornisce. Le integrazioni sono la voce che sposta di più i preventivi, e sono anche quella che si scopre più tardi quando non è scritta.

4. Quali dati esistono già, e in che stato

Quante anagrafiche, quanti anni di storico, dove stanno adesso e quanto sono puliti. Un fornitore che sa di dover migrare ventimila clienti con duplicati fa un preventivo diverso da uno che lo scopre a marzo. Se sapete che i dati sono sporchi, ditelo: è una posizione di forza, non una debolezza.

5. Quali regole vostre non sono negoziabili

Sono le eccezioni: lo sconto che vale solo per i clienti storici, il fornitore che si paga a sessanta giorni ma quell'altro no, il pezzo che va tracciato per lotto. Ogni eccezione è una regola in più da scrivere e mantenere, e sono la ragione per cui un prodotto già pronto non vi basta. Se non le scrivete, il fornitore proporrà lo standard e ve ne accorgerete al collaudo.

6. Cosa deve essere vero perché il progetto sia riuscito

Una frase, misurabile: «gli ordini si inseriscono una volta sola», «chiudiamo il mese in due giorni invece che in sei», «il cliente vede lo stato senza telefonare». Serve a voi più che al fornitore: è il metro con cui giudicherete il risultato, e deciderlo prima evita la discussione di dopo.

Il trucco che funziona meglio di qualunque elenco: raccontare una giornata

Se dovete scegliere una cosa sola da scrivere, scrivete la storia di un ordine — o di una pratica, o di un paziente — dall'inizio alla fine. Chi lo riceve, cosa succede dopo, chi lo tocca, dove viene ricopiato, cosa va storto di solito.

Una pagina di racconto contiene più informazione utile di trenta voci di un elenco funzionale, perché mostra i passaggi fra le persone. È lì che stanno i problemi veri, e gli elenchi di funzioni per costruzione non li vedono.

Il modo in cui si scrive una richiesta cambia il prezzo

Confronto fra una richiesta scritta come soluzione e la stessa richiesta scritta come problema: la prima produce un preventivo generico e ampie variazioni in corso d'opera, la seconda produce una stima più stretta e meno modifiche dopo l'inizio.
La stessa esigenza, scritta in due modi. Il secondo costa meno perché lascia meno cose da scoprire dopo.

C'è un errore che sembra innocuo e non lo è: scrivere il requisito come soluzione. «Serve un pulsante che esporta l'elenco in Excel» è una soluzione. Il problema dietro potrebbe essere «il commercialista ci chiede i dati ogni mese in un certo formato», e in quel caso la risposta giusta non è un pulsante: è un invio automatico, che costa uguale e vi toglie un lavoro invece di renderlo più veloce.

La regola è semplice: scrivete cosa deve succedere e perché, non come. Il come è il lavoro che state comprando.

  • Invece di «un campo note sulla scheda cliente», scrivete cosa ci finirebbe dentro e chi lo rileggerebbe.
  • Invece di «un cruscotto con i grafici», scrivete quale decisione dovrebbe aiutarvi a prendere, e ogni quanto.
  • Invece di «deve essere veloce», scrivete quante righe ha la lista più lunga che aprite e quante volte al giorno la aprite.
  • Invece di «come il software X», scrivete cosa di quel software vi piace. Quasi mai è l'aspetto: di solito sono due o tre comportamenti precisi.

Cosa non serve mettere

Alcune sezioni dei capitolati fanno perdere tempo a tutti, e ometterle migliora il preventivo che ricevete.

  • Le tecnologie. Sceglierle è lavoro del fornitore, e imporle senza motivo restringe il campo e alza il prezzo. L'eccezione è quando avete un vincolo vero — un sistema esistente, una policy interna — e allora scrivete il vincolo, non la tecnologia.
  • Il disegno delle schermate. Fatto prima dell'analisi, quasi sempre si butta. Serve invece dire quali informazioni devono stare insieme sotto gli occhi.
  • L'elenco esaustivo delle funzioni future. Le cose che nessuno sa ancora descrivere non sono pronte per essere costruite né quotate: mettetele in una sezione a parte, chiamata «più avanti».
  • Le clausole copiate da un altro bando. Se non sapete perché c'è una riga, toglietela: rischiate di aver chiesto una certificazione che vi esclude metà dei fornitori bravi.

Le due pagine, in ordine

  1. 01Chi siete e cosa fate, in cinque righe. Serve a inquadrare il resto.
  2. 02Il problema con un numero, dal punto uno.
  3. 03La storia di una giornata o di un ordine, una pagina.
  4. 04Gli utenti e i contesti d'uso.
  5. 05I sistemi esistenti e i dati da migrare.
  6. 06Le regole non negoziabili.
  7. 07Il risultato atteso, misurabile.
  8. 08I vincoli veri: una data che conta e perché, un tetto di budget se ce l'avete.

Sul budget vale la pena dire una cosa impopolare: scriverlo conviene. Il timore è che il fornitore «spenda tutto quello che c'è», ma l'effetto reale è opposto — un fornitore serio, sapendo il tetto, vi dice cosa ci sta dentro e cosa no, invece di consegnarvi un preventivo fuori scala che vi fa perdere entrambi un mese.

Se non avete idea di che numero scrivere, le fasce reali stanno in quanto costa un gestionale su misura, e le domande da fare a chi vi risponde in come scegliere una software house.

Domande frequenti

Devo scriverlo io o me lo può fare il fornitore?

Le sei risposte le potete dare solo voi: riguardano il vostro lavoro. Metterle in forma di documento tecnico è invece lavoro del fornitore, e diffidate di chi vi chiede di consegnare un'analisi già fatta prima di quotare — significa che intende costruire quello che c'è scritto, senza verificare se risolve il problema.

Quanto deve essere lungo?

Due o tre pagine. Oltre le dieci, la probabilità che venga letto tutto scende, e la parte importante si perde in mezzo. Meglio corto e con gli allegati: un paio di schermate del sistema attuale, un esempio del documento che uscirà.

E se non so ancora cosa voglio?

È normale, e c'è una risposta: fatevi pagare un'analisi breve, delimitata, con un risultato che resta vostro anche se poi cambiate fornitore. Costa qualche migliaio di euro, dura poche settimane e produce il documento che qui state cercando di scrivere. È anche un'ottima prova per capire come lavora chi la fa.

Devo mandare lo stesso documento a tutti i fornitori?

Sì, identico. È l'unico modo perché i preventivi siano confrontabili. Se poi un fornitore vi fa domande che gli altri non hanno fatto, giratele a tutti insieme alla risposta: chi ha visto il problema per primo merita credito, non un vantaggio informativo.

Il documento vincola il progetto?

Non deve. Serve a far partire il lavoro con lo stesso quadro in testa, non a congelarlo. Le cose cambieranno, ed è giusto così: quello che deve essere fissato è il modo in cui si gestiscono i cambiamenti — una stima scritta prima di procedere — non l'illusione che non ce ne saranno.

In sintesi

Sei risposte su due pagine — il problema con un numero, chi usa cosa e dove, i sistemi esistenti, i dati, le regole non negoziabili e il risultato atteso — bastano a ottenere preventivi seri e confrontabili. Scrivete i problemi, non le soluzioni, e raccontate una giornata invece di elencare funzioni. Il budget, scritto, lavora a vostro favore.

Se preferite ragionarci a voce prima di scrivere, funziona anche così: le sei domande le facciamo noi. Si parte da una conversazione.

  • Requisiti
  • Preventivi
  • Software su misura
  • Progetti
Alle artikelen