(luKa)

Sacrosanta verita', il conflitto di per se stesso non e' un concetto negativo, non necessariamente.

Nella mia esperienza pero' lo scenario e' comunque piu' complicato: a volte tu sai perfettamente e senza ombra di dubbio che un'obiezione che stai sollevando e' prettamente tecnico-operativa, ma non c'e' verso che chi ti sta di fronte non ignori completamente i contenuti tecnici da te espressi e si limiti a prendere il tutto come un'offesa personale.

Insomma, purtroppo non e' mai un problema di semplici "contenuti", bensi' ancora e sempre un problema di "persone", personalita' e a volte di livelli di competenza (quando il knowledge gap fra gli interlocutori e' troppo grande, o c'e' la fiducia oppure non c'e' niente da fare).

-LV

Faccio un esempio concreto, dove il confine fra cio' che e' "pratico" e cio' che non lo e' alla fin fine e' del tutto arbitrario: http://blogs.ugidotnet.org/Franny/archive/2007/09/07/88180.aspx

Tralasciando che sono parte in causa, la qual cosa ha influenza zero in questa sede, mi, ti e vi chiedo: ma esistono davvero conflitti positivi e negativi, oppure esistono solo persone positive e negative? E un "team vivo" non e' forse alla fin fine solo un team composto di "persone vive"?

Queste domande non sono retoriche...

-LV

> xkè sia cosi IMHO aiuta molto quando si considera che ogni opinione ha la medesima dignità , che possono esistere più opinioni differenti e altrettanto valide

Concordo sul *possono* esistere piu' opinioni differenti e altrettanto valide, ma non concordo che *a priori* (che e' un *devono*) ogni opinione ha la stessa dignita'. A volte semplicemente un concetto (o soluzione, ecc.) e' corretto oppure sbagliato (magari meglio: e' piu' corretto di, e' piu' sbagliato di), e questo tanto piu' se ci limitiamo alle questioni tangibili/materiali.

> trovo che diventa un conflitto sterile quando la discussione è una competizione per decidere chi ha ragione e chi torto e chi perde perde la dignità

Trovo molto saggia questa tua considerazione sul legame fra il conflitto e la difesa della "dignita'". Mi sembra d'altra parte la conferma che il problema reale viaggia su ambiti strettamente personali, cioe' il contrario del tangibile/materiale che ne dovrebbe constituire il contenuto ideale.

Ti diro' che ad oggi sono arrivato a distinguere 4 modalita' di gestione dei conflitti, che per ora mi limito a citare brevemente:

1) Bandire il conflitto: nella forma gerarchico/dirigista, ma anche nella forma il branco vince;

2) Sminuire il conflitto: nella forma tutte le opinione hanno pari dignita', come nella forma in cui tutto e' ridotto a una questione di stile personale;

3) Razionalizzare il conflitto: forse e' la forma piu' vicina all'ideale che stiamo cercando, ma presenta il rischio della iper-razionalizzazione e iper-astrazione, cioe' ci si puo' perdere a parlare dei massimi sistemi;

4) Alimentare il conflitto: rara in azienda, e' tipica delle strategie divide et impera.

Ciascuna di queste modalita' ha i suoi pregi e difetti, ovvero, per meglio dire, i suoi limiti di applicabilita'.

(Sono stato molto sintetico. Posso espandere un po' se occorre, comunque preferirei farlo a partire da quesiti specifici.)

-LV

Due precisazione le faccio subito:

> non concordo che *a priori* (che e' un *devono*) ogni opinione ha la stessa dignita'

Dico dignita' ma intendo validita'. Cioe' sulla dignita' intesa come "diritto umano fondamentale", e quindi sul diritto generale alla parola, non ci piove. E' sul fatto che in una discussione alla fin fine tutte le posizioni e conclusioni sono altrettanto ammissibili che non concordo.

> Razionalizzare il conflitto: ... ci si puo' perdere a parlare dei massimi sistemi

In concreto, si tende a degenerare nei cavilli da vocabolario. Problema che a certi livelli, quando ottenere risultati e' questione critica, si risolve con il supporto di consulenti e facilitatori che aiutano a non perdere il focus.

-LV

Permettimi una semi-battuta: a parte cose come Maurizio Constanzo, Marta Flavi, Amici, e compagnia bella, che ce ne facciamo delle "questioni di opinione"? A mio avviso, non dovrebbero avere spazio ne' in azienda ne' in nessun altro contesto che richieda un approccio "razionale".

Questa potrebbe sembrare e' una posizione radicale... una posizione che e' a sua volta una questione di opinione? Ritengo di no! La trovo una questione di "logica" invece, tant'e che ha il pregio di semplificare alquanto lo scenario. Permettimi una rapida progressione:

1. le "questioni di opinione" semplicemente non hanno ragione di esistere, perlomeno nei contesti produttivi et similia; (intendo, in quesi contesti non hanno proprio senso!)

2. le "questioni tecnico/materiali" sono le uniche ad avere ragione di esistere, e qui la difficolta' si riduce, come secondo me giustamente segnali, alle situazioni ad alta complessita', dove una risposta oggettiva non e' scontata.

Possiamo dunque restringere il campo dei "conflitti legittimi" (quelli buoni e giusti) alle sole questioni "complesse" (produrre software ad es.) o addirittura irrisolte (la struttura fine della materia ad es.), e tentare un ulteriore passo:

3. in realta', non e' forse sempre vero (come per l'Analisi software che non puo' essere mai completa) che: la conoscenza "oggettiva e completa" e' in se' una chimera, un ideale, ma non lo dovrebbe essere la nostra capacita' di mantenere il focus e di sapere dov'e' il limite di tale nostra conoscenza?

Provo a dirlo meglio: la conoscenza oggettiva non e' l'onniscienza; la conoscenza oggettiva e' conoscenza che risolve le porzioni logico/tecniche (la parte "acquisita") del problema con il rigore della logica e della tecnica, e la' dove non arriva, dichiara il proprio limite! In questo senso, *tutte* le questioni, quando non sono inquinate da motivi di "opinione" bensi' mantengono un focus razionale e la consapevolezza dei propri limiti concettuali e di applicabilita', *tutte* dicevo sono "questioni oggettive", per definizione logica appunto.

Restano ancora fuori le "questioni di stile". Ti anticipo che ritengo facilmente liquidabili anche quelle, ma direi di lasciarle ad un altro post/topic visto che qui ci concentriamo sulle "questioni di opinione".

-LV

P.S. Sono molto critico sui i vari concetti di "utilita'". Comunque questo aprirebbe questioni ancora piu' complesse, per cui per adesso ho ignorato... :)

BTW, ho citato Costanzo, ma ho dimenticato di citare La Domenica Sportiva...

Insomma che il mondo oggi sia un "mondo di opinioni" e' una questione culturale termonucleare globale... che fa tutt'uno con l'altra: che la "comunicazione" e' principio fondamentale, sacro e supremo.

-LV

Mmm, il fatto e' che davvero personalmente non contemplo l'esistenza di "conflitti di opinione".

Se io e il mio "contendente" non siamo d'accordo, sfatare il mito che si tratta solo di una divergenza di opinione oppure di una divergenza di stile e' proprio la prima cosa che tento di fare.

Quando questo concetto passa, ed e' solo una questione di tempo e pazienza, come per la trasmissione di qualunque concetto o pratica "nuovi" per il team, quel che succede non e' la definitiva scomparsa di divergenze, ma perlomeno si riesce a mantenere il focus e a discutere di aspetti tecnici invece che di "aria fresca"... e, quando proprio non si trova un accordo, vale la regola generale che "qualcuno" (probabilmente il team o project leader) deve prendere una decisione finale e assumersi la responsabilita' del risultato, cioe' di nuovo un approccio strettamente "tecnico".

Detto questo, sulle "divergenze legittime" (tecniche) adotto un approccio che non rientra in nessuna delle 4 pratiche di management che ho indicato in un precedente commento. Personalmente uso la seguente:

5) PROVOCARE IL CONFLITTO: il concetto base qui e' che se individui un qualunque problema potenziale, fai scoppiare la crisi subito invece di aspettare che scoppi da sola in un momento imprecisato nel futuro... perche', come ci ricorda Murphy, quel che puo' succedere succedera'.

Per illustrare il senso di questa pratica, cito un aneddoto: ero studentello a Bologna e un giorno chiedevo ad un pilota rally locale alcune dritte sulla giuda sulla pioggia, in particolare quando devi affrontare una curva "intermedia" dove non e' sicuro se conviene farla stile pista o di traverso. La risposta: "se non sono sicuro di quel che puo' succedere, la macchina di traverso ce la butto io."

Ti faccio un esempio concreto: il mio ruolo in azienda e' team leader e a volte lead engineer (una sorta di equivalente agile del direttore di produzione). La maggior parte dei miei conflitti sono con il management (cioe' i miei capi). Se i miei capi non mi danno retta, la prima cosa che faccio e' cominciare a disertare l'ufficio... il primo giorno mi presento alle 12, il secondo alle 15, il terzo non mi presento proprio. Occhio, nessuna dead line ne soffre, tutto e' sotto controllo, ma i capi non lo sanno e vanno subito in fibrillazione. Il risultato, strano ma vero, e' positivo: se ad esempio sollecito un meeting direttivo e mi cominciano a portare a spasso per una o due settimane, dopo il trattamento d'urto, la riunione si fa la mattina successiva... E, ti diro' di piu': se la riunione proprio non si fa, al quarto giorno mi dimetto.

Altri esempi forse non sono necessari, soprattutto se hai osservato il mio modo di muovermi su forum e blog. Ci sarebbe da esplicitare meglio cosa vuol dire che questa pratica "funziona", ma mi fermo qui, in attesa di feedback. :)

-LV

Comunque, e' qualcosa di analogo al "Simulated annealing": http://en.wikipedia.org/wiki/Simulated_annealing, da qualcun altro ribattezzato "baby shake"...

-LV

> quando c'è un problema/conflitto, tipicamente nei confronti del management,
> ti impegni per farlo emergere _subito_ in modo controllato e sicuro e lo
> affronti di petto e questa strategia per te ha funzionato bene il più delle volte
> giusto ?

Direi di si', precisando che quello che tendo a far emergere e' il "problema", e al conflitto ci si arriva solo se il problema viene ignorato (o, che e' lo stesso, gestito secondo una delle strategie da 1 a 4).

Aggiungo anche un'altra considerazione, in linea anche con l'altra discussione sulle strategie negoziali e le strategie di gestione dei team e sulla differenza che a mio avviso passa fra le due cose. Il punto e' questo: quando pensiamo al team dovremmo pensare in termini di black box e white box. La black box e' quella che ti ho descritto sino ad ora, ed e' quello che ad esempio vede il management. La white box, cioe' quello che accade all'interno, viene gestito invece sulla base del principio di collaborazione, e in questo ambito il conflitto diventa un "problema", nel senso che e' un segnale che qualcosa non sta funzionando a dovere nel meccanismo collaborativo (per esempio: quando i problemi tecnici tendono a trasformarsi in problemi di opinione o ancora peggio di stile, magari cio' dipende da una debole cultura comune, da scarsa fiducia reciproca, ecc. ecc.).

Questa se vuoi e' la complicazione dei sistemi complessi: non possono essere compresi sulla base della riduzione ad una sola dimensione di analisi. Quando ragioniamo sui sistemi complessi dovremmo sempre ricordare che tutte le categorie almeno si sdoppiano: l'esterno e l'interno.

> e in una situazione di questo tipo "con il management non c'è un rapporto di tipo consulenziale invece è più di tipo relazione di lavoro continuativa dove la divisione di compiti e responsabilità si fa più confusa, gli incarichi vengono conferiti in modo parziale e informale, gli interessi e le interdipendenze reciproche sono intrecciati in modo indistricabile" cosa faresti ?

E' proprio questa (lavoro dipendente e continuativo) la mia dimensione standard. Nella misura in cui non aspiri a mantenere lo stesso posto di lavoro per tutta la vita, il tipo di contratto che hai con l'azienda fa ben poca differenza. Cioe' quello che ho fatto sopra e' un esempio, ma la cosiddetta strategia numero 5 e' un approccio possibile in generale, che si tratti di un incarico per la vita (ma tanto non esistono piu') o che si tratti di un progetto di poche settimane.

Sulla stessa linea mi sembra significativo aggioungere che - sempre a mio avviso - non c'e' alcuna differenza neanche dal punto di vista della chiarezza o meno dell'incarico e del contesto tecnico. Anzi, francamente non capisco perche' la metti in quei termini: quando faccio (raramente) il free-lance o consulente, sono molto flessibile su quello che trovo in azienda e fondamentalmente mi concentro sul raggiungimento dell'obiettivo specifico (la' dove ci sono problemi potenziali, magari cerco di isolare il piu' possibile i miei componenti dal resto, ecc. ecc., cioe' una strategia di evitamento); quando invece sono dipendente e' li' che la "confusione" non ha piu' ragione di esistere e non e' piu' tollerabile, e i problemi vanno *risolti*, non evitati. La confusione nel processo software *non* e' un fatto naturale: non c'e' nessuna confusione intrinseca alla produzione di software, semmai ci sono una endemica incompetenza e incapacita', soprattutto - lo devo ribadire, altrimenti si rischia di correggere il problema sbagliato - al livello di *management* dell'intero processo.

-LV