Un articolo scritto da un fornitore su come valutare i fornitori. Le domande, le risposte che dovreste sentire, quelle che dovrebbero farvi rallentare, e le cinque righe che devono stare nel contratto.
di Nadia Maar ·
Questo è l'unico pezzo della serie che non ha un'applicazione da aprire, perché non parla di un prodotto: parla della decisione che viene prima: a chi affidare il lavoro. È anche il più scomodo da scrivere, perché sono uno dei fornitori che state valutando, e ogni criterio che propongo è un criterio con cui potete misurare anche me.
Lo scrivo lo stesso per una ragione pratica: quasi tutti i progetti di software su misura che vanno male non vanno male per ragioni tecniche. Vanno male perché è stata scelta la persona sbagliata per il problema giusto, e la scelta si è basata su un preventivo, una simpatia e un portfolio. Le sette domande qui sotto costano mezz'ora e scremano molto più di quelle tre cose insieme.
La prima cosa da verificare non riguarda il fornitore, riguarda voi. Un software su misura è la risposta giusta a un problema preciso, ed è una risposta cara e lenta a tutto il resto. Prima di aprire una gara, tre controlli.
Un fornitore serio, davanti a un problema che un prodotto pronto risolve meglio, ve lo dice al primo incontro e perde il progetto. Non è generosità: è che un cliente a cui hai venduto la cosa sbagliata torna, e torna arrabbiato. Se nessuno dei fornitori che state sentendo vi ha mai suggerito di comprare invece di costruire, il problema non è la loro fortuna — è che nessuno sta guardando il vostro caso.
Fatele tutte, nello stesso ordine, a ogni fornitore. Le prime due costano poco e scremano molto; le ultime sono quelle che si dimenticano e che poi determinano come finisce. Aprite una domanda per leggere perché conta e che cosa dovreste sentirvi rispondere.
È la domanda che separa un investimento da un affitto. Un software su misura di cui non possedete il codice vi lega a un fornitore che fra cinque anni potrebbe non esistere, e il prezzo del rinnovo lo deciderà lui sapendo che non potete andarvene.
Una risposta che tranquillizza: «Vostro, alla consegna, con il repository e la documentazione per lavorarci. È scritto nel contratto.» Nessuna esitazione, nessun distinguo sulle librerie interne.
Una risposta che deve farvi rallentare: «Il codice resta nostro ma voi avete una licenza d'uso perpetua.» Sembra equivalente e non lo è: una licenza non si può dare a un altro sviluppatore, e senza il repository non si può nemmeno correggere un bug.
In molte gare la persona che vi convince non è quella che lavorerà. È prassi diffusa e non è sempre un male, ma dovete saperlo prima, perché la qualità di un software è la qualità di chi lo scrive, non di chi lo presenta.
Una risposta che tranquillizza: «Io, e queste sono altre due cose che ho costruito.» Oppure, in una struttura più grande: «questa persona, che partecipa da adesso agli incontri tecnici».
Una risposta che deve farvi rallentare: «Abbiamo un team dedicato.» Una risposta che non contiene nomi non è una risposta. Chiedete chi, e se la risposta resta collettiva chiedete di parlare con chi scriverà.
Succede quasi sempre, e non perché qualcuno abbia sbagliato: si capisce il proprio processo mentre lo si descrive. Il punto non è evitarlo, è sapere come verrà gestito prima che accada.
Una risposta che tranquillizza: «Lo quantifichiamo prima di farlo e decidete voi se entra ora o dopo. Le stime si aggiornano quando cambiano i fatti.» Vi mostra anche come è successo l'ultima volta.
Una risposta che deve farvi rallentare: «Nel prezzo è tutto compreso.» O il preventivo è gonfiato per coprire l'ignoto, o le modifiche verranno rifiutate, o il progetto verrà consegnato scontento. Un prezzo fisso su un ambito vago non protegge nessuno dei due.
La manutenzione è la voce che nessuno mette nel confronto fra preventivi, e quella che si paga per anni. Un software vive cinque o dieci anni; quello che costa nel primo è meno della metà della storia.
Una risposta che tranquillizza: Una cifra o una fascia, e che cosa comprende: correzioni, aggiornamenti di sicurezza, piccole modifiche. Con un tempo di risposta dichiarato per i guasti che fermano il lavoro.
Una risposta che deve farvi rallentare: «Ci sentiamo quando serve.» Va benissimo finché non serve di sabato. Senza un accordo scritto, la priorità la deciderà il fornitore in base a chi ha gridato più forte quel giorno.
Molti fornitori costruiscono su piattaforme proprietarie che gestiscono loro. Non è di per sé sbagliato — spesso costa meno — ma cambia radicalmente che cosa possedete alla fine, e va saputo prima e non dopo.
Una risposta che tranquillizza: Un elenco di tecnologie note e diffuse, e dove gira ciascuna. «Se domani cambiate fornitore, questo lo può riprendere in mano chiunque conosca queste cose.»
Una risposta che deve farvi rallentare: «Usiamo la nostra piattaforma.» Chiedete allora che cosa succede se un domani il rapporto finisce, e fatevelo scrivere. Se la risposta è che il software smette di funzionare, non state comprando un software: state affittandolo.
Nei progetti che vanno male, la brutta notizia arriva sempre alla fine. In quelli che vanno bene arriva presto e piccola. La differenza non è la fortuna: è che qualcuno aveva stabilito prima come si misura l'avanzamento.
Una risposta che tranquillizza: «Ogni due settimane vedete qualcosa che funziona, anche se piccolo, e potete usarlo.» Non un rapporto sullo stato: una cosa che si apre e si prova.
Una risposta che deve farvi rallentare: «Vi mandiamo un aggiornamento settimanale.» Un aggiornamento è un testo, e un testo può dire per due mesi che va tutto bene. Chiedete di vedere il software, non di leggerne.
Il portfolio mostra come una cosa appariva alla consegna. Un cliente di un anno fa vi dice come si è comportata dopo — che è l'unica informazione che conta e l'unica che il fornitore non controlla.
Una risposta che tranquillizza: Un nome e un numero, con la sola cortesia di avvisarlo prima. E, quando chiamate, una persona che parla anche di quello che non ha funzionato.
Una risposta che deve farvi rallentare: «Per riservatezza non possiamo.» Capita davvero, ma non su tutti i clienti e non sempre. Se dopo dieci anni di lavoro non esiste nessuno disposto a parlare bene di voi con il nome e cognome, è un'informazione anche quella.
Le risposte a voce servono a scegliere; il contratto serve a non litigare fra un anno. Questi cinque punti sono quelli che ho visto fare la differenza — non un parere legale, che per quello serve chi lo fa di mestiere, ma le frasi da cercare fra le pagine prima di firmare.
Deve dire che il codice sorgente è vostro e che vi viene consegnato. Attenzione alle formule che concedono l'uso ma trattengono la proprietà: sono la stessa frase con un esito opposto.
La frase da cercare: «Alla consegna, il committente acquisisce la piena titolarità del codice sorgente sviluppato su commessa, che gli viene consegnato integralmente insieme alla documentazione tecnica.»
Repository, server, chiavi. Non alla consegna: dal primo giorno. Un progetto in cui non potete vedere il codice mentre viene scritto è un progetto di cui saprete lo stato solo quando ve lo dicono.
La frase da cercare: «Il committente ha accesso in sola lettura al repository e agli ambienti di sviluppo per l'intera durata del progetto.»
La causa più comune di lite non è la qualità: è che le due parti avevano in testa due traguardi diversi. Serve un elenco di cose che devono funzionare, scritto prima, e un modo per verificarle che non sia un'opinione.
La frase da cercare: «La fornitura si intende completata al superamento dei casi di collaudo elencati nell'allegato tecnico, verificabili dal committente.»
Un periodo in cui i difetti si correggono senza costo. Non serve che sia lungo: serve che esista e che sia scritto, perché è la sola differenza fra «lo sistemiamo» e «quello è un intervento aggiuntivo».
La frase da cercare: «Per dodici mesi dalla consegna, la correzione di difetti riconducibili allo sviluppo è a carico del fornitore.»
La clausola che nessuno vuole scrivere all'inizio ed è la sola che si legge davvero, quando serve. Deve dire che cosa vi viene consegnato se il rapporto finisce, e in quanti giorni.
La frase da cercare: «In caso di cessazione, il fornitore consegna entro trenta giorni codice, dati, documentazione e credenziali, prestando l'assistenza necessaria al passaggio.»
Se un fornitore accetta tutte e cinque senza discutere, è un buon segno. Se ne discute una motivandola, è un ottimo segno: significa che ha letto. Se le rifiuta in blocco dicendo che «sono standard di settore», chiedete quale settore — perché in quello del software su misura queste cinque righe sono la norma da vent'anni.
Arrivano tre numeri molto diversi e la tentazione è ordinare per prezzo. Prima però vanno resi confrontabili, perché quasi mai descrivono la stessa cosa.
Non è quasi mai perché qualcuno è più efficiente: la differenza fra due sviluppatori esperti non è del 60%. Di solito è una di tre cose — ha capito un ambito più piccolo, ha intenzione di recuperare sulle varianti, oppure non ha ancora capito quanto è complicato. La terza è la più pericolosa per entrambi, perché a metà progetto qualcuno dovrà scegliere fra rimetterci e consegnare male.
Se state valutando qualcuno per un progetto, la mezz'ora di audit potete usarla per questo: portate le sette domande e mettetemi alla prova. Sono le stesse che troverete qui sopra, e non ci sono risposte diverse per chi le fa a me.
Se invece siete ancora alla sezione uno — non è chiaro se serva davvero un software — quella mezz'ora vale ancora di più, perché è la domanda su cui si spende peggio. E se la risposta è che vi basta un prodotto pronto ve lo dico, come ho scritto sopra che dovrebbe fare chiunque.
Sviluppo applicazioni web su misura
Sette, in quest'ordine: di chi è il codice quando il progetto finisce; chi lo scrive materialmente; che cosa succede quando cambia un requisito; che cosa comprende la manutenzione e quanto costa; su quali componenti proprietari poggia il lavoro; come si misura l'avanzamento settimana per settimana; e se esiste un cliente con almeno un anno di sistema in produzione con cui parlare. Le prime due costano poco a chiedere e scremano moltissimo.
Dipende da che cosa dice il contratto, e il silenzio non gioca a vostro favore. La clausola da cercare assegna al committente la titolarità del codice prodotto su commessa, con accesso al repository e agli ambienti dal primo giorno, non alla consegna. Senza quella riga si può pagare un sistema per intero e non poterlo far manutenere da nessun altro: è il modo più comune di restare legati a un fornitore senza averlo scelto.
Si rendono confrontabili prima di leggerli. Si allineano gli ambiti, perché di solito il preventivo basso esclude qualcosa; si aggiungono a ciascuno tre anni di manutenzione; si sottraggono le ore che ricadono su di voi — inserimento dati, collaudi, formazione; e si diffida della precisione eccessiva. Un numero al singolo euro su sei mesi di lavoro non è rigore, è una stima presentata come certezza: la differenza la pagherete in varianti.
Cinque: titolarità del codice; accesso agli ambienti dal primo giorno; una definizione scritta di che cosa vuol dire «completato»; una garanzia con una durata dichiarata; e una clausola di uscita che descriva come si separano le strade — chi consegna che cosa, in quanto tempo, a quale costo. L'ultima è quella che nessuno vuole discutere al momento della firma, ed è l'unica che conta quando serve.