Come seguire un progetto software quando non sei tecnico
Il vostro ruolo, in breve
Il codice non dovete capirlo. Dovete controllare che quello che vedete risolva il problema giusto, e decidere in fretta. Due compiti facili da dire e facilissimi da trascurare.
Molti progetti vanno storti anche con un fornitore che lavora bene, perché il cliente li guarda solo all'inizio e alla fine. In mezzo si accumulano piccole interpretazioni sbagliate che nessuno corregge. Seguire un progetto vuol dire esserci nei momenti in cui correggere costa poco, senza controllare ogni riga.
Come funzionano gli sprint di due settimane
Uno sprint è un blocco di lavoro breve che finisce con qualcosa di funzionante da provare. Due settimane sono una misura comoda. Bastano per costruire un pezzo utile, e sono poche per andare lontano nella direzione sbagliata.
All'inizio dello sprint si decide cosa entra, in ordine di priorità, e alla fine si guarda insieme il risultato. Da noi ogni sprint si chiude con una demo funzionante ogni 14 giorni. Niente slide o schermate statiche, il software vero su cui potete cliccare.
Per voi il vantaggio è vedere. Invece di aspettare mesi per scoprire se il prodotto somiglia a quello che avevate in mente, lo verificate ogni due settimane, un pezzo alla volta.
Cosa guardare a ogni demo
L'estetica può aspettare. Alla demo controllate che il flusso funzioni per chi lo userà ogni giorno, e per farlo bastano poche domande.
Funziona con un caso reale? Provate con un ordine, un cliente o una pratica vera, i dati di esempio non bastano. Le eccezioni saltano fuori lì.
Chi lo userà lo capisce? Se potete, portate alla demo una persona che userà il sistema tutti i giorni. Vede cose che a voi sfuggono.
Manca qualcosa di indispensabile? Tenete separato "manca" da "sarebbe bello". Solo il primo cambia le priorità dello sprint dopo.
E infine, cosa è cambiato rispetto al piano. Chiedete sempre cosa è stato rimandato e perché. Non è un problema, ma dovete saperlo.
Come commentare in modo utile
Un buon commento descrive il problema e lascia stare la soluzione. "Il magazziniere deve poter registrare un reso senza tornare alla home" aiuta molto più di "aggiungete un bottone in alto a destra".
Descrivendo il problema lasciate al team la libertà di trovare la soluzione migliore, che spesso è diversa da quella che vi era venuta in mente. Aiutano tre abitudini:
- Mandate i commenti entro uno o due giorni dalla demo, finché è tutto fresco.
- Raccoglieteli in un posto solo invece di spargerli fra email, messaggi e telefonate.
- Metteteli in ordine di importanza. Dieci osservazioni tutte urgenti equivalgono a nessuna priorità.
Quando volete cambiare qualcosa
Cambiare idea durante un progetto è normale, e spesso è giusto. Bisogna decidere con consapevolezza cosa esce per far posto a quello che entra.
Lavorando a sprint una modifica non manda all'aria il piano. Entra nella lista delle priorità e si valuta insieme al resto, e se è più importante di qualcosa già previsto ne prende il posto. Se richiede lavoro in più va detto subito e chiaramente, prima che lo scopriate in fattura. Molto dipende anche dal contratto, e ne parliamo in preventivo a corpo o a tempo.
Una persona che decide
La cosa che accelera di più un progetto è avere dalla vostra parte una sola persona con il mandato di decidere. Non deve sapere tutto. Deve sapere a chi chiedere e chiudere la questione in un giorno o due.
Con un comitato ogni domanda aperta ferma un pezzo di lavoro. Se poi più persone danno indicazioni diverse, il team finisce a costruire compromessi che non piacciono a nessuno. Nominare un referente all'inizio risolve entrambe le cose.
I segnali che qualcosa non va
Alcuni si riconoscono anche senza competenze tecniche, e se ne vedete più di uno è il momento di fare domande dirette.
- Le demo saltano, oppure mostrano solo slide. Senza software funzionante non sapete a che punto siete.
- La risposta è sempre "quasi pronto". Chiedete cosa manca, con un elenco.
- Non sapete chi sta lavorando al progetto. Chiedete se lo fa il team con cui parlate o se è stato passato ad altri. Da noi il team è interno e senza subappalti, ma la domanda va fatta a chiunque.
- Non avete accesso a niente. Codice, database e infrastruttura devono essere vostri e accessibili, e ne parliamo in di chi è il codice.
Se il vostro fornitore è anche l'unico riferimento tecnico che avete, leggete startup senza CTO.
Domande frequenti
Quanto tempo deve dedicare il cliente a un progetto software?
Meno di quanto si pensa, purché con regolarità. Servono la demo ogni due settimane, il tempo per provare e commentare e la disponibilità a rispondere alle domande in un paio di giorni. Conta più la costanza che il numero di ore.
Serve essere tecnici per seguire lo sviluppo di un software?
No. Il vostro compito è controllare che il software risolva il problema giusto per chi lo userà, e questo lo sapete meglio di chiunque. Le scelte tecniche spettano al fornitore, che però deve saperle spiegare in italiano semplice.
Cosa succede se a metà progetto cambiano le priorità?
Lavorando a sprint si riordina la lista. Quello che diventa più importante sale e qualcos'altro scende o viene rimandato. L'effetto su tempi e costi va detto prima di procedere, non dopo.
