Se i diritti di committente e programmatori venissero osservati, si massimizzerebbe il mutuo beneficio da parte di entrambi, dando origine ad un circolo virtuoso che porterebbe a maggior fiducia tra le parti e all'osservanza in primo luogo del rispetto reciproco e del miglioramento delle relazioni. Penso infatti di poter affermare che siamo tutti d'accordo in merito al fatto che l'osservanza dei diritti sia alla base di una reale condivisione di valori e necessaria alla costante messa in opera di pratiche di qualità. Come già affermato in precedenza, l'espletare i diritti di ogni parte vuole essere un modo di garantire quella serenità nei rapporti che è alla base di un business proficuo e duraturo, minimizzando le paure e le azioni difensive che per definizione tendono a diminuire la trasparenza dei rapporti.
Ma come garantire che l'osservanza di tali diritti sia supportata da ogni punto di vista, arrivando fino a ciò che regola concretamente dal punto di vista del business le relazioni? In altre parole, come fare in modo che un contratto possa porsi come garanzia della riduzione dei conflitti invece che contrapporre gli interessi delle parti?

Prima di entrare nel merito immaginiamo un attimo uno scalatore che compia la sua scalata con una forte paura di cadere: questa paura lo porterebbe ad irrigidire tutto il corpo, a salire in modo impacciato, a piazzare le protezioni ogni metro, quando il suo stato di forma fisica raggiunto con migliaia di ore di allenamento gli permetterebbe di piazzarle ogni 4 metri, ed a sprecare energie fisiche e mentali inutilmente. Molto probabilmente quello scalatore finirebbe per cadere, esausto su una via molto al di sotto del suo limite, troppo concentrato sul non cadere invece che sull'avere una visione di insieme alla ricerca della via più semplice, e a costruire movimento dopo movimento una strategia di salita.
In poche parole quello scalatore giocherebbe per non perdere e non per vincere.
Lo stesso scalatore in uno stato mentale "illuminato", che percepisca la paura semplicemente come un messaggio della natura sull'eventualità di un pericolo e come invito alla massima concentrazione, scalerebbe quella stessa via con movimenti fluidi, con il giusto numero di protezioni, scorgendo i riposi naturali che la via stessa gli offre, individuando prese nascoste, in poche parole scalerebbe con coraggio e concentrato sulle cose davvero importanti, con una precisa consapevolezza dei propri limiti, fiducioso del rapporto millenario tra uomo e roccia.

Tornando al mondo dell'informatica un processo di sviluppo vuole stabilire regole e pratiche che garantiscano i diritti di cui ho parlato nei precedenti post, affrontando in modo costruttivo e con un'interpretazione efficace ed efficiente le paure che tali diritti vengano violati, suggerendo pratiche che permettano di concentrarsi su ciò che è davvero importante per vincere, minimizzando le inutili zavorre finalizzate esclusivamente a non perdere.
Alla base di ogni processo di sviluppo e di ogni relazione di business vi è la stipulazione di un contratto, che vuole essere la dimostrazione della condivisione di un progetto e della promessa da parte di committente e fornitore di garantire i diritti dell'altro. Ecco quindi che i contenuti di tale contratto diventano fondamentali per la buona riuscita del progetto.

Brevemente riporto le paure dei programmatori, alle quali la carta dei diritti del programmatore vuole dare una risposta. Nei prossimi post ragionerò con voi su come rispettare i diritti di committente e programmatore giorno dopo giorno, senza dare origine a conflitti.

I programmatori hanno paura che:

• Gli verrà chiesto di fare cose che non sanno fare.
• Gli verrà chiesto di fare cose che non hanno senso.
• Di essere stupidi.
• Commetteranno errori sul piano tecnico/tecnologico.
• Gli verranno assegnate responsabilità senza l'autorità necessaria per espletarle.
• Non gli verrà detto chiaramente cosa fare.
• Dovranno sacrificare la qualità per rispettare le scadenze.
• Dovranno risolvere problemi difficili senza nessun aiuto.
• Non avranno sufficiente tempo.

La stavate aspettando, lo so, ed eccovi qui la carta dei diritti del programmatore secondo Kent Beck e Martin Fowler:

La carta dei diritti del Programmatore:

• Hai il diritto di sapere cosa c'è da fare, con definizioni chiare delle priorità.
• Hai il diritto di produrre sempre, in qualsiasi momento, software di qualità.
• Hai il diritto di chiedere e ricevere aiuto dai tuoi colleghi, dai tuoi superiori e dal committente.
• Hai il diritto di fare delle stime e di aggiornarle.
• Hai il diritto di accettare le tue responsabilità invece che subirne la loro assegnazione.

Prima di scrivere la carta dei diritti del programmatore, vorrei riportare anche le motivazioni che risiedono dietro ogni diritto del committente.
Le carte dei diritti vogliono infatti essere la risposta alle paure che hanno committenti e programmatori quando decidono di stipulare un contratto che regolerà la loro collaborazione nella creazione del software.
Beck e Fowler vedono nelle paure di entrambi le cause vere dei fallimenti delle relazioni tra committente e fornitore e quindi del progetto. La paura porta infatti ad atteggiamenti difensivi e spesso a nascondere la realtà delle cose o a poca trasparenza e fiducia nei rapporti: la vera causa di tutti i mali.

I committenti hanno paura che:

• Non avranno ciò che desiderano ed hanno chiesto.
• Desiderano la cosa sbagliata.
• Pagheranno troppo per avere troppo poco.
• Dovranno delegare il controllo del loro business e del loro lavoro a tecnici ai quali non interessa.
• Non vedranno mai un piano serio e sensato.
• I piani che gli presenteranno si riveleranno delle frottole.
• Non saranno informati di cosa i programmatori stanno realmente facendo.
• Saranno indissolubilmente legati alle loro prime decisioni e non saranno messi nelle condizioni di poter reagire ai cambiamenti di business.
• Nessuno gli dirà la verità.

Personalmente a queste paure aggiungerei una paura comune a molti clienti: quella di assumersi delle responsabilità. Questa a mio parere è la peggiore di tutte.
Tra le cause la paura di commettere errori, amplificata dal dover avviare una relazione con persone mai viste prima. Altri motivi risiedono spesso nella maglia di relazioni e nella struttura dell'azienda di cui fa parte il committente, spesso poco meritocratica e poco consapevole dei vantaggi che possono derivare dalla traduzione in software del proprio business.
Inoltre a volte la paura di responsabilità nasce da precedenti esperienze conclusesi male e con fallimenti rovinosi.

Penso comunque che anche al timore di assumersi responsabilità la carta dei diritti dia una risposta, che risiede in primo luogo nell'esistenza della stessa e quindi nella presentazione della relazione committente-fornitore sotto forma di opportunità e non di regole ferree, responsabilità pressanti o problemi da risolvere. Esplicitare i diritti del committente è senza dubbio il primo passo verso la costruzione di una relazione basata sulla fiducia al fine di massimizzare il mutuo beneficio di entrambe le parti e minimizzare i conflitti.

Liberamente tradotto da "Kent Beck, Martin Fowler: Planning XP 2nd draft":

La carta dei diritti del Committente:

• Hai diritto ad avere un piano generale, per sapere cosa può essere rilasciato, quando ed a quale prezzo.
• Hai diritto ad avere ogni settimana il software con il più alto valore di business possibile.
• Hai diritto a vedere i progressi sottoforma di software funzionante e ad avere una prova del suo corretto funzionamento attraverso una serie di test ripetibili che tu stesso hai specificato.
• Hai diritto a cambiare idea in qualsiasi momento, a sostituire funzionalità e a cambiare le priorità senza pagare costi esorbitanti.
• Hai diritto ad essere informato dei cambiamenti del piano, in tempo per poter scegliere come ridurre l'insieme delle funzionalità da rilasciare al fine di rimanere nei tempi stabiliti. Puoi decidere di rompere la relazione con il tuo fornitore in ogni momento, ed avere comunque un sistema utile e funzionante che rifletta gli investimenti fatti fino a quel momento.

Al prossimo post la carta dei diritti del programmatore.