Qualità, holon, valori, frustrazione

Chi mi segue da questa piccola finestra (la puntata precedente è comunque qui) sa che da circa un mese non mi è più “permesso” di scrivere codice in PP: il mio attuale e unico collega infatti è allergico alle coppie. Non solo, purtroppo io ed il mio collega abbiamo anche principi prospettive di visione del codice molto differenti, direi addirittura opposte. Ma non è del mio collega (per altro simpatico e di vecchia data) che vi voglio parlare, quanto invece delle mie reazioni e dei miei peccati in questo mese.

Nell’ultimo mese e fino a qualche giorno fa ho prodotto software di bassa qualità, voglio cercare di capire il perché con voi. Sicuramente e per onestà nei miei confronti il motivo principale è la scarsissima conoscenza dei tool utilizzati. Ma questo lo sapete già. Più interessante è invece come il rapporto tra me ed il mio collega, i miei timori e il disallineamento di valori hanno influenzato la mia capacità di creare qualità.

Sostanzialmente ero entrato in un circolo vizioso, che mi ha fatto calpestare i valori in cui credo. Infatti il cercare una strada per lavorare in coppia, unita ad un approccio copy-and-paste e code-and-fix del mio collega, mi hanno portato a sacrificare i miei valori per arrivare ad un compromesso che permettesse un’interazione più profonda con il mio (mancato) pairer. In aggiunta il fatto di non stimare le storie in giorni/coppia, ha creato in me una certa competizione di produttività con il suo approccio, al fine di dimostrargli la validità del mio. Un eccessivo compromesso da parte mia mi ha però portato a sacrificare la qualità. Questo sacrificio da guardare da un punto di vista umano, di sensazioni, e “spirituale” ha portato inevitabilmente ad una crescente frustrazione. Giorno dopo giorno andavo a casa sempre più frustrato e con sempre minori motivazioni e stimoli. Chiudendo il cerchio, la frustrazione ha dato origine a minore produttività e così via. Inoltre era sempre dietro l’angolo, anche per le nobili motivazioni già espresse (=per cercare una convivenza non conflittuale) il seguente pensiero: “ma sì, per questa volta sacrifico la qualità, in fondo è solo un progettino di 80 giorni”.
In che modo sono riuscito a spezzare questo circolo vizioso? Con la qualità ovviamente! Finalmente dopo aver acquisito dimestichezza con i tool, sono riuscito a creare il primo unit test automatico, e da quel momento sono letteralmente rinato, riprendendo a seguire i valori di feedback, semplicità e di sperimenta-adatta perlomeno in solitaria.

Mi sono chiesto se la frustrazione provata si sarebbe manifestata nel mio collega se l’avessi “costretto” io o un’entità superiore, a seguire i miei valori. La risposta che mi do è sì, anche lui si sarebbe sentito frustrato se non avesse seguito i suoi valori. Ad ogni modo mi sento di affermare che perlomeno in quel caso avrei prodotto qualità e quindi avrei apportato un beneficio ad una persona in più: il cliente. Questa piccola esperienza mi ha insegnato aspetti che ritengo importanti.

• Un team nel quale non vengono condivisi i valori ha vita molto breve, è una bomba ad orologeria pronta a scoppiare: in due parole non è un’ambiente sostenibile.
• Personalmente ho imparato a fare molta attenzione a sacrificare valori quali la qualità per me (e per il mio lavoro) fondamentali: ho toccato con mano come sacrificare la qualità non paghi non solo a livello “tecnico”, ma anche umano(vedi soddisfazione personale)!
• Attenzione ad allineare i valori “al ribasso” per raggiungere una convivenza non conflittuale.
• Non arrendersi all’ambiente! Proattività!
• Riuscire a trovare uno zoccolo duro di valori condivisi può essere molto difficile, a volte impossibile.
• La barriera più grande al punto precedente risiede a mio modo di vedere nella mancata volontà di migliorarsi ed in un ridotto spirito di team che ha come contr’altare l’orgoglio e la bassa interazione con il resto del team.

Quest’ultimo punto è la precondizione ad uno sviluppo del software produttivo e di qualità. Se manca tale precondizione è davvero molto difficile costruire un vero team.
Spero con il tempo di affinare la mia capacità di creare non solo valore, ma anche valori condivisi ed allo stesso tempo diretti verso l’eccellenza.

[Qualche minuto fa, dopo avere fatto integrazione tra il mio codice e quello del mio collega, proprio lui ha cominciato a creare uno unit test a partire dalla struttura da me messa in piedi: che non sia tutto così nero in fondo? Questo mi porta di nuovo a pensare che non sempre il compromesso su alcuni valori sia da ricercare, e che invece sia da cercare sempre una strada per far "digerire" alcuni valori imprescindibili!]

Vorrei sottolineare per finire che non credo in un’entità superiore (un manager o chi per esso), che risolva questo tipo di conflitti obbligando una persona piuttosto che un’altra ad agire in un certo modo. Ritengo invece avrebbe potuto migliorare la mia situazione un modello organizzativo nel quale i cerchi di livello superiore pongono obiettivi di più alto livello a tutto il cerchio inferiore, cioè a tutto il team in quanto holon, e non in quanto somma di individui. In questo modo ci sarebbe un’obiettivo comune sul quale auto-organizzare il team. Infatti se questi obiettivi non vengono esplicitati o se sono differenti per ogni componente del team, allora il rischio di non riuscire ad ottenere un ecosistema omogeneo, aumenta pesantemente.