Consegnare il Prodotto Perfetto oppure Basta sia Funzionante? [Si può Salvare Capra e Cavoli?]

Rimandare la presentazione del prodotto al cliente fino a quando ogni dettaglio è al suo posto oppure puntare sulla velocità e consegnare un prodotto bruttino ma che fa il suo lavoro?

Dal punto di vista del cliente è ovvio: vuole il prodotto perfetto e subito!

Per quanto riguarda il dev* se potesse consegnerebbe il prodotto perfetto e con il tempo che ci vuole :-), ma dovendo rispettare una scadenza, per la quale al più è stato coinvolto marginalmente, preferirà consegnare la funzionalità rispetto alla finitura estetica.

Se hai a che fare con un dev devi tener conto anche di altri fattori: il dev è geloso del suo codice!

Una volta prodotto può essere disposto a migliorarlo ma accetterà con fatica eventuali critiche, specialmente dal cliente (che per sua estrema convinzione “non ne capisce niente!”).

Allora preferisce finire subito le funzionalità sulle quali il cliente può dire ben poco (o c’è o non c’è) per poi lasciare che si focalizzi sui colori, lo stile etc. relegando questo tipo di scelte al gusto personale e quindi in fondo non criticabile.

Ho descritto un dev introverso e un cliente rompiscatole.

Per un dev, ad ogni modo, nello svolgimento della sua attività trova bello indagare le possibilità che può percorrere, le implicazioni presenti e future delle sue scelte e l’occasione con il suo lavoro di gettare le basi per nuovi modi di lavorare.

Se ha abbastanza tempo non è insolito trovarlo a contemplare e compiacersi della soluzione che ha implementato, continuando a rifinirla, ad accarezzarla ed ammirarla luccicare nel suo splendore.

Per quanto possa sembrare strano per un dev questo è il piacere della programmazione e ricevere uno stipendio per fare ciò che gli piace genera in automatico una persona appagata.

Allora quando gli chiedi una consegna urgente senza un motivo ben specifico il dev si sente violentato!

Comincia a produrre codice abbozzato, che risolve i problema ma che non è stabile, è pieno di bug che prima o poi esplodono scegliendo il momento meno opportuno.

Lo vedo già scrivere quattro righe di codice, verificare il funzionamento e poi chiudere il task.

Ma non ha verificato la compatibilità con altri browser, non ha verificato la responsività, non ha scritto il test prima dell’implementazione etc, etc., tutte cose che prima o poi tornano indietro con gli interessi.

A questo punto sembra che, tra il cliente da una parte che vuole tutto e subito e lo sviluppatore dall’altra che messo in un catena di montaggio anche volendo non riesce ad accontentarlo, non ci sia una soluzione soddisfacente.

E invece no! (tadaaa, colpo di scena!)

Ci vogliono due ingredienti, del primo ho parlato già in questo articolo: PO: Il Direttore di Orchesta Agile

Del secondo ingrediente, fondamentale per uno sviluppatore, ne parliamo qui adesso.

Il dev per esprimere al massimo la sua capacità ha bisogno in primo luogo della stima di chi gli commissiona il lavoro. Una stima e fiducia che viene costruita giorno per giorno dimostrando al committente di essere in grado di realizzare cosa veramente gli serve con tutto l’impegno che serve per ottenere un grande risultato.

In secondo luogo gli deve essere concesso di fare il proprio lavoro nel modo che più ritiene opportuno, dopotutto se gli si è commissionato il lavoro lo si ritiene in grado di svolgerlo al meglio altrimenti bastava scegliere un’ altra persona.

Dal canto suo il dev si impegna a lavorare nel modo più veloce ed efficiente possibile per raggiungere l’obbiettivo, accettando di buon grado le dritte che i colleghi gli passano per fare un lavoro migliore e mettendo a disposizione il suo talento senza riserve nei confronti del team.

Diciamo che il dev introverso/solitario che ho descritto sopra non si adatta proprio alla descrizione che ho appena fatto;

se è per questo nemmeno il cliente che ho introdotto all’inizio dell’articolo è la fotografia del committente che ho appena descritto.

Tuttavia se ognuna delle parti cerca di fare correttamente la propria parte non ci sono dubbi in merito alla produttività tanto desiderata dal committente e al raggiungimento di standard qualitativi del codice tanto apprezzati dagli sviluppatori.

Questo perché lo sviluppatore non lavora da solo, ogni suo contributo è arricchito dalle esperienze degli altri membri del team, per cui come in un opera suonata da più strumenti il risultato e migliore della somma delle parti, così ogni parte del software è migliore del semplice elenco di funzionalità, comprendendo anche la visione di completezza e di integrazione che rendono il prodotto finito elegante!

Sono tutti felici e nessuno vuole crederci, ma è così che funziona in aziende di successo!