Epigrafe:
Un giorno si incontrarono nel bosco Riccio e Orsetto.
— Ciao, Riccio!
— Ciao, Orsetto!
Così, parola dopo parola, battuta dopo battuta, Riccio ricevette da Orsetto un bel colpo …
Di seguito le riflessioni del nostro team leader, nonché del direttore dello sviluppo prodotto RAS — Igor Marnat, sulla specificità dei conflitti lavorativi e sui possibili metodi per gestirli.
La maggior parte dei conflitti che affrontiamo sul lavoro si sviluppa seguendo uno schema simile a quello descritto sopra nell'epigrafe. Ci sono diversi partecipanti, inizialmente ben disposti l'uno verso l'altro, che cercano di risolvere una questione, ma alla fine il problema rimane irrisolto e, per qualche motivo, i rapporti tra i partecipanti alla discussione risultano rovinati.
La vita è varia, nello scenario descritto sopra si verificano delle variazioni. A volte i rapporti tra i partecipanti non sono molto buoni all'inizio, a volte non c'è nemmeno una questione che richiede una soluzione immediata (come, ad esempio, nell'epigrafe), altre volte, dopo la discussione, i rapporti rimangono come prima, ma la questione alla fine non viene risolta.
Cosa hanno in comune tutte le situazioni che possiamo definire come situazioni di conflitto lavorativo?
Innanzitutto, ci sono due o più parti coinvolte. Queste parti possono occupare posizioni diverse all'interno dell'organizzazione, trovarsi in relazioni di parità (colleghi nel team), o su diversi livelli gerarchici (superiore - subordinato), essere individuali (dipendente) o di gruppo (nei casi di conflitto tra un dipendente e il team o tra due team), e così via. Il livello di fiducia tra i partecipanti influisce molto sulla probabilità del conflitto e sulla facilità di risolverlo. Più le parti si conoscono bene, maggiore è il livello di fiducia, più alta è la possibilità che raggiungano un accordo. Ad esempio, i membri di un team distribuito che non si sono mai incontrati di persona hanno una probabilità maggiore di trovarsi in una situazione di conflitto quando affrontano una semplice questione lavorativa, rispetto a persone che si sono incontrate di persona almeno un paio di volte. Pertanto, lavorando in team distribuiti, è molto importante garantire incontri periodici di persona tra tutti i membri del team.
In secondo luogo, in una situazione di conflitto sul lavoro, le parti si trovano a dover risolvere una questione importante per una delle parti, per entrambe o per l'organizzazione nel suo complesso. Dato il contesto specifico, di solito le parti hanno a disposizione tempo sufficiente e vari modi per arrivare a una soluzione (formali, informali, incontri, lettere, decisioni della direzione, obiettivi e piani del team, la presenza di gerarchie, ecc.). Questo differenzia la situazione di risoluzione delle questioni lavorative (o non lavorative) all'interno dell'organizzazione da, per esempio, la risoluzione di una domanda importante: “Ehi, ragazzo, di che zona sei?!” per strada, o il conflitto menzionato nell'epigrafe. Nel caso di una questione lavorativa, sono importanti la qualità del processo lavorativo e la cultura della risoluzione dei problemi nel team.
In terzo luogo, un fattore determinante del conflitto (dal punto di vista della nostra discussione) è il fatto che le parti coinvolte non riescono a trovare autonomamente una soluzione che soddisfi tutte le parti. La situazione richiede l'intervento di un terzo, un arbitro esterno. Questo punto può sembrare controverso, ma in sostanza, se una situazione conflittuale si risolve con successo senza l'intervento di un arbitro esterno, se la questione è risolta con successo e le relazioni tra le parti non sono peggiorate, si tratta di una situazione a cui dovremmo aspirare. Probabilmente non ci accorgeremo nemmeno di tale conflitto, o lo scopriremo per caso dopo che è stato risolto. Più domande il team è in grado di risolvere autonomamente, più efficacemente lavorerà.
Un altro aspetto caratteristico del conflitto di cui vale la pena parlare è il grado di intensità emotiva durante la risoluzione. Un conflitto non è necessariamente accompagnato da un alto grado di emozioni. I partecipanti non devono necessariamente urlare e agitare le mani affinché la situazione possa essere considerata sostanzialmente conflittuale. Se la questione non viene risolta e c'è una certa tensione emotiva presente (anche se non espressa apertamente), allora ci troviamo di fronte a una situazione di conflitto.
È necessario intervenire nelle situazioni di conflitto, o è meglio lasciare che la loro soluzione fluisca da sé e aspettare che il problema si risolva da solo? Sì. Non sempre è nelle vostre possibilità o competenze risolvere completamente un conflitto, ma in ogni situazione, in un conflitto di qualsiasi scala, potete assumere una posizione adulta, coinvolgendo così altre persone intorno a voi, attenuare le conseguenze negative del conflitto e contribuire alla sua soluzione.
Prima di esaminare alcuni esempi di situazioni di conflitto, fermiamoci su alcuni punti importanti, comuni a tutti i conflitti.
Quando si risolve un conflitto, è importante rimanere al di sopra della mischia, e non all'interno di essa (questo è conosciuto anche come “assumere una metapositiva”), cioè, non trovarsi nel processo decisionale come parte di uno dei lati. Altrimenti, da arbitro esterno che aiuta nella risoluzione, finirete per rafforzare la posizione di una delle parti a danno dell'altra. È fondamentale che la decisione venga accettata moralmente da tutte le parti, come si suol dire, “acquistata”. Affinché, anche se le parti non fossero entusiaste della decisione presa, almeno fosse concorde nel suo rispetto. In altre parole, essere in grado di dissentire e impegnarsi. Altrimenti, il conflitto cambierà semplicemente forma, il fuoco smouldering rimarrà sotto il torbido e a un certo punto si riaccenderà inevitabilmente.
Il secondo punto, parzialmente legato al primo, è che se hai deciso di partecipare alla risoluzione del conflitto, affrontalo con la massima serietà dal punto di vista della comunicazione e della comprensione del contesto. Parla personalmente con ciascuna delle parti. Separatamente, per iniziare. Non accontentarti delle email. In caso di una squadra distribuita, parla almeno per videochiamata. Non fidarti di voci e racconti di testimoni. Comprendi la storia, cosa vuole ciascuna delle parti, perché lo vuole, quali sono le aspettative, se hanno cercato di risolvere prima questa questione, cosa succederà se non viene risolta, quali soluzioni vedono, come immaginano la posizione dell'altra parte, cosa ritengono giusto o sbagliato, e così via. Carica nella tua mente tutto il contesto possibile, in modo imparziale, supponendo che tutte le parti abbiano ragione. Non sei dentro il conflitto, sei all'esterno, in una posizione meta. Se il contesto è accessibile solo nella conversazione via email, leggi almeno l'intera discussione e i documenti ad essa relativi. Dopo aver letto, parla comunque a voce. È quasi garantito che sentirai qualcosa di importante che non è nelle email.
Il terzo punto importante è un approccio generale alla comunicazione. Si tratta di cose comuni, nulla di straordinario, ma rivestono un'importanza enorme. Non cerchiamo di risparmiare tempo, parliamo con tutti i partecipanti, critichiamo non la persona, ma consideriamo le conseguenze delle sue azioni (non "sei scortese", ma "forse i ragazzi potrebbero offendersi per questa cosa"), diamo la possibilità di mantenere la dignità, conduciamo discussioni di persona, non davanti a un gruppo.
I conflitti sono solitamente causati da una delle due ragioni. La prima è legata al fatto che la persona coinvolta nel conflitto si trovi in una posizione adulta o infantile (di questo parleremo più avanti). Ciò è legato alla sua maturità emotiva, alla capacità di gestire le proprie emozioni (il che, per inciso, non è sempre collegato all'età). La seconda causa comune è l'imperfezione del processo lavorativo, che crea situazioni di zone grigie, in cui la responsabilità è dispersa tra i partecipanti, le aspettative delle parti non sono chiare l'una per l'altra, i ruoli nel processo sono sfumati.
Pertanto, nel risolvere un conflitto (come qualsiasi altra questione), un manager deve tenere a mente tre prospettive: a breve termine — risolvere la questione/conflitto qui e ora, a medio termine — ridurre la probabilità di un altro conflitto per la stessa ragione e a lungo termine — coltivare una cultura dell’adulto all'interno del team.
Dentro ognuno di noi c'è un bambino interiore, di circa tre o quattro anni. Per la maggior parte del tempo al lavoro dorme, ma a volte si sveglia e prende il controllo. Il bambino ha le sue priorità. È importante per lui insistere sul fatto che questa è la sua sabbiera, che la mamma lo ama di più, che la sua macchina è la migliore (il design è il migliore, programma meglio di chiunque altro, ...). In situazioni di conflitto, il bambino può stringere i giocattoli, battere i piedi e colpire con la paletta, ma non è in grado di risolvere questioni da adulto (architettura della soluzione, approcci ai test automatici, scadenze di rilascio, ecc.), non pensa in termini di utilità per il team. Il bambino in conflitto può essere incoraggiato, consolato e mandato a dormire, invitandolo a chiamare il suo adulto. Prima di iniziare la discussione in una situazione di conflitto, assicurati di parlare con l'adulto e non con il bambino e di rimanere tu stesso nella posizione di adulto. Se il tuo obiettivo sincero in questo momento è risolvere una questione seria, sei nella posizione di un adulto. Se il tuo obiettivo è battere i piedi e colpire con la paletta, allora questa è una posizione infantile. Manda a dormire il tuo bambino interiore e chiama l'adulto, oppure rimanda la discussione. L'individuo prende decisioni emotive e poi cerca di trovare una giustificazione razionale. Una decisione presa dal bambino, sulla base delle priorità infantili, non sarà ottimale.
Oltre al comportamento durante un conflitto, la posizione di un bambino o di un adulto è caratterizzata anche dal livello di responsabilità che la persona è disposta a prendersi. In manifestazioni estreme, la posizione infantile di un programmatore, che ho incontrato più volte, si presenta così: ho scritto il codice, l'ho inviato per la revisione — il mio lavoro è finito. I revisori devono esaminarlo e approvarlo, il QA deve verificarlo, se ci sono problemi — mi avviseranno. Stranamente, anche persone piuttosto adulti ed esperti a volte si comportano in questo modo. L'altro estremo della scala è una persona che si sente responsabile affinché il suo codice funzioni, sia coperto da test, sia verificato personalmente da lui, superi con successo la revisione (se necessario, non ci sono problemi a contattare i revisori, discutere le questioni a voce, ecc.) e venga approvato, con l'assistenza del QA se necessario, scenari di test descritti, ecc. Nei casi normali, il programmatore si trova inizialmente più vicino all'estremità adulta della scala o si sposta in quella direzione man mano che accumula esperienza (a condizione che nel team venga coltivata la giusta cultura). Nei casi estremi, continua a lavorare, di solito assumendo una posizione infantile, quindi lui e il suo team incontrano periodicamente problemi e conflitti.
Coltivare nella squadra una cultura corretta e adulta è un compito importante per ogni manager. Richiede tempo prolungato e sforzi quotidiani, ma il risultato ne vale la pena. Ci sono due modi per influenzare la cultura del team: l'esempio personale (a cui sicuramente si farà riferimento, il team guarda sempre al leader) e discutere e incoraggiare il comportamento corretto. Anche qui non c'è nulla di complicato o eccessivamente formale, basta notare durante le discussioni sui problemi che si sarebbe potuto fare in questo modo, sottolineare quando si nota una soluzione corretta, lodare, evidenziare durante l'analisi del rilascio, ecc.
Consideriamo alcune situazioni conflittuali tipiche, dal semplice al complesso:
Conflitti non correlati a questioni di lavoro
Molto spesso si verificano conflitti sul lavoro che non sono legati a questioni di lavoro. La loro insorgenza e la facilità di risoluzione sono solitamente collegate direttamente al livello di intelligenza emotiva dei partecipanti, al loro livello di maturità e non alla perfezione o imperfezione del processo lavorativo.
Esempi tipici: qualcuno non usa abbastanza spesso la lavatrice o la doccia, il che non piace agli altri; qualcuno ha caldo, mentre un altro ha freddo quando apre la finestra; qualcuno è troppo rumoroso, mentre gli altri hanno bisogno di silenzio per lavorare, e così via. È meglio non procrastinare nella risoluzione di conflitti di questo tipo e non lasciarli andare per conto loro. Non si risolveranno da soli e continueranno a distrarre dal lavoro e avvelenare l'atmosfera nel team. Fortunatamente, risolverli di solito non è un grande problema: basta parlarne pacificamente (naturalmente, uno a uno) con un collega che trascura le norme igieniche, garantire una sistemazione confortevole per le persone che preferiscono silenzio/fresco, acquistare cuffie fonoassorbenti o installare paratie, e così via.
Un altro esempio che mi è capitato di incontrare più volte durante il mio lavoro è la compatibilità psicologica dei membri del team. Per qualche motivo, le persone non riescono semplicemente a lavorare insieme, ogni comunicazione finisce in uno scandalo. A volte ciò è legato al fatto che le persone hanno opinioni diametralmente opposte su qualche questione scottante (di solito politica) e non riescono a lasciarle fuori dal lavoro. Convincerle a sopportarsi o a cambiare il proprio comportamento è un compito piuttosto senza speranza. L'unica eccezione che ho riscontrato sono stati i giovani colleghi con una mentalità aperta, il cui comportamento può ancora essere gradualmente cambiato attraverso conversazioni periodiche. Di solito, il problema si risolve con la loro assegnazione a team diversi, o almeno garantendo loro la possibilità di incrociarsi raramente per lavoro.
In tutte le situazioni descritte, è utile parlare individualmente con tutti i soggetti coinvolti, discutere la situazione, chiedere se vedono effettivamente un problema in questo caso, e domandare quali, a loro avviso, siano le possibili soluzioni, garantendo la loro partecipazione al processo decisionale.
Dal punto di vista dell'ottimizzazione del processo lavorativo (prospettiva a medio termine di cui ho parlato), non si può fare molto, l'unico aspetto da ottimizzare è considerare il fattore di compatibilità durante la formazione del team e non riunire anticipatamente persone che entreranno in conflitto.
Dalla prospettiva della cultura del team, tali situazioni si verificano molto meno frequentemente nei team con una cultura matura, dove le persone rispettano i colleghi e sanno affrontare le questioni in modo autonomo. Inoltre, tali conflitti vengono risolti molto più facilmente (spesso automaticamente) nei team con un alto livello di fiducia, dove le persone lavorano insieme da tempo e/o comunicano frequentemente al di fuori del lavoro.
Conflitti legati a questioni lavorative:
Tali conflitti sono solitamente causati da entrambe le motivazioni contemporaneamente, sia quella emotiva (quando uno dei partecipanti non si trova nella posizione di adulto), sia dalla imperfezione stessa del processo lavorativo. Il tipo più comune di conflitti che ho incontrato sono stati quelli durante il processo di revisione del codice o le discussioni sulla architettura tra sviluppatori.
Vorrei evidenziare qui due casi tipici:
1) Nel primo caso, uno sviluppatore non riesce a ottenere la revisione del codice da un collega. Il patch è stato inviato per la revisione, ma non succede nulla. A prima vista, non c'è un conflitto evidente tra le due parti, ma se si riflette, si tratta di un vero e proprio conflitto. La questione lavorativa non viene risolta, una delle parti (quella che aspetta la revisione) prova un evidente disagio. Una sottocategoria estrema di questo caso è lo sviluppo in comunità o in team diversi, in cui il revisore potrebbe non essere interessato a quel codice specifico e, a causa di sovraccarico o altre circostanze, potrebbe non prestare affatto attenzione alla richiesta di revisione, e potrebbe non esserci affatto un arbitro esterno (un manager comune per entrambe le parti).
L'approccio alla soluzione che aiuta in questa situazione si riferisce proprio a una prospettiva a lungo termine, alla cultura di un adulto. In primo luogo, funziona l'attività razionale. Non ci si deve aspettare che il codice in attesa di revisione attiri da solo l'attenzione del revisore. È necessario aiutare i revisori a notarlo. Contatta un paio di persone, fai una domanda nello sync-up, partecipa alle discussioni. È evidente che la fastidiosità tende a danneggiare piuttosto che aiutare, quindi è necessario usare il buon senso. In secondo luogo, una preparazione preliminare funziona bene. Se il team comprende cosa e perché sta accadendo, perché quel codice è necessario, se il design è stato discusso e concordato in anticipo con tutti, le persone saranno più propense a notare quel codice e ad accettarlo. In terzo luogo, funziona l'autorità. Se desideri che il tuo codice venga revisionato, fai molte revisioni tu stesso. Fai revisioni di qualità, con controlli reali, test reali, commenti utili. Se il tuo nickname è conosciuto nel team in modo positivo, ci sono maggiori probabilità che venga prestata attenzione al tuo codice.
Dal punto di vista del flusso di lavoro, i possibili miglioramenti qui sono una corretta assegnazione delle priorità, volta ad aiutare lo sviluppatore a raggiungere i propri obiettivi e quelli del team (fare revisioni per gli altri, scrivere lettere nella comunità, accompagnare il codice con descrizioni architetturali, documentazione, test, partecipare a discussioni con la comunità, ecc.), evitare che i patch rimangano troppo a lungo in coda, e così via.
2) Il secondo caso comune di conflitti durante la revisione del codice o del design è la divergenza di opinioni su questioni tecniche, stile di codifica, scelta degli strumenti. In questo caso, il livello di fiducia tra i partecipanti, il fatto di appartenere allo stesso team, e l'esperienza lavorativa condivisa rivestono un'enorme importanza. Si arriva a un punto morto quando uno dei partecipanti assume una posizione infantile, non cercando di capire cosa il suo interlocutore desidera comunicare. Spesso sia l'approccio proposto dall'altra parte, sia l'approccio originario, possono funzionare con successo e non ha importanza fondamentale quale scegliere.
Una volta, un programmatore del mio team (lo chiamiamo Pasha) ha preparato una patch con modifiche al sistema di distribuzione dei pacchetti, sviluppata e supportata dai colleghi di un dipartimento vicino. Uno di loro (Igor) aveva una forte opinione su come dovessero essere configurati i servizi Linux durante la distribuzione dei pacchetti. Questa opinione differiva dall'approccio proposto nella patch, e non riuscivano a trovare un accordo. Come al solito, i tempi stringevano, e dovevamo arrivare a una decisione, era necessario che qualcuno di loro assumesse una posizione adulta. Pasha riconosceva che entrambi gli approcci avevano diritto di esistere, ma voleva che la sua variante fosse accettata, poiché non c'erano vantaggi tecnici evidenti né nell'uno né nell'altro.
La nostra discussione è andata più o meno così (in modo molto schematico, ovviamente, la conversazione è durata mezz'ora):
— Pasha, tra pochi giorni abbiamo il feature freeze. È importante che raccogliamo tutto e iniziamo i test il prima possibile. Come possiamo superare Igor?
— Vuole configurare i servizi in un altro modo, ha lasciato commenti…
— E cosa c'è, grandi modifiche, molta fatica?
— No, ci vogliono un paio d'ore, ma alla fine non fa differenza, funzionerebbe comunque, a cosa serve? Ho fatto una cosa funzionante, prendiamola e accettiamola.
— Senti, da quanto tempo ne state discutendo?
— Già da circa una settimana e mezza.
— Ehm… possiamo risolvere in un paio d'ore una questione che è già durata una settimana e mezza e non lo facciamo?
— Beh, sì, ma non mi piace che Igor pensi che mi sia piegato…
— Senti, cosa è più importante per te, rilasciare la versione con la tua soluzione o battere Igor? Possiamo batterlo, ma c'è una buona possibilità che il rilascio salti.
— Beh… sarebbe divertente, certo, umiliare Igor, ma va bene, il rilascio è più importante, sono d'accordo.
— Ti importa davvero così tanto quello che pensa Igor? A dire la verità, a lui non importa affatto, vuole solo un approccio uniforme in vari luoghi della cosa di cui si occupa.
— Va bene, allora farò come chiede nei commenti e inizieremo i test.
— Grazie, Pasha! Ero sicuro che tra voi due saresti risultato il più maturo, anche se Igor è più grande di te :)
La questione è stata risolta, il rilascio è avvenuto nei tempi stabiliti, Pasha non ha manifestato un particolare discontento, poiché è stato lui a proporre la soluzione e a realizzarla. Igor, in generale, era soddisfatto, poiché la sua opinione è stata presa in considerazione e hanno fatto come lui aveva suggerito.
Un altro tipo di conflitto simile è la scelta tra soluzioni tecniche/librerie/approcci nel progetto, soprattutto in un team distribuito. In uno dei progetti, che si presentava come utilizzante C/C++, si è scoperto che la gestione tecnica del progetto era categoricamente contraria all'uso di STL (Standard Template Library). Questa è una libreria standard del linguaggio che semplifica lo sviluppo, la nostra squadra ci era molto abituata. Si è rivelato che il progetto era molto più vicino a C che a C++, il che non ispirava molto la squadra, poiché la gestione si era data da fare ed aveva reclutato dei veri esperti in C++. Tuttavia, la parte americana del team, sia ingegneri che manager, lavorava in azienda da tempo, si era abituata alla situazione attuale e tutto andava bene per loro. La parte russa del team è stata riunita solo di recente, in poche settimane (incluso me). La parte russa del team non voleva assolutamente rinunciare al proprio approccio abituale allo sviluppo.
Hanno avuto inizio discussioni scritte infinite tra due continenti, lettere di tre-quattro schermi volavano da una parte all'altra, nelle mailing list e nei messaggi personali, dai programmatori ai programmatori e ai manager. Come accade spesso, nessuno, oltre agli autori e ai loro accesi sostenitori, leggeva lettere di tale lunghezza. Le chat scricchiolavano per la tensione, trasmettendo in varie direzioni considerazioni a schermo multiplo riguardo ai vantaggi tecnici di STL, quanto fosse ben testata, sicura e, in generale, quanto fosse bella la vita con essa e quanto fosse terribile senza di essa.
È durata piuttosto a lungo, fino a quando non ho finalmente capito che stavamo discutendo degli aspetti tecnici del problema, mentre il problema in realtà non era tecnico. Non si trattava dei pro e dei contro dello STL o della difficoltà di lavorare senza di esso. Era piuttosto una questione organizzativa. Dovevamo semplicemente capire come era strutturata l'azienda in cui lavoravamo. Nessuno di noi aveva esperienza in un'azienda simile. La questione era che dopo che il codice era stato sviluppato e rilasciato in produzione, il supporto era gestito da persone completamente diverse di altri team, di altri paesi. Questa enorme squadra di ingegneri composta da decine di migliaia di persone (in totale) poteva permettersi solo il minimo indispensabile di strumenti tecnici, per così dire, il minimum minimorum. Tutto ciò che andava oltre lo standard ingegneristico stabilito in azienda non poteva essere supportato in seguito. Il livello di una squadra è definito dal livello dei suoi membri più deboli. Dopo aver capito la motivazione reale delle azioni della parte americana del team, questa questione è stata tolta dall'ordine del giorno e insieme abbiamo sviluppato e rilasciato con successo il prodotto, utilizzando gli standard adottati in azienda. In questo caso, le email e le chat hanno funzionato male e sono stati necessari diversi viaggi e molta comunicazione personale per arrivare a un denominatore comune.
Dal punto di vista del flusso di lavoro, in questo caso specifico, avrebbe aiutato avere una descrizione degli strumenti utilizzati, i requisiti per essi, le limitazioni per l'aggiunta di nuovi, la giustificazione di tali limitazioni. Tali documenti corrispondono circa a quanto descritto nei punti Reuse Strategy e Development Environment del manuale “Manager’s Handbook for Software Development”, sviluppato presso . Nonostante la sua età, descrive perfettamente tutte le principali attività e fasi di pianificazione dello sviluppo software di questo tipo. La presenza di documenti simili semplifica notevolmente il processo di discussione di quali componenti e approcci possano essere utilizzati nel prodotto e perché.
Dal punto di vista culturale, è chiaro che con una prospettiva più matura, in cui le parti cercano di ascoltare e comprendere la reale motivazione delle azioni dei colleghi e agire in base alle priorità del progetto e del team, e non all'ego personale, il conflitto si sarebbe risolto più facilmente e rapidamente.
In un altro conflitto legato alla scelta di una soluzione tecnica, ho impiegato molto tempo per comprendere la motivazione di una delle parti (era davvero un caso insolito), ma dopo aver chiarito la motivazione, la decisione è diventata ovvia.
La situazione è questa: in un team di circa 20 persone entra un nuovo sviluppatore, chiamiamolo Stas. Il nostro strumento standard di comunicazione era a quel tempo Skype. Come si è poi rivelato, Stas era un grande fan degli standard aperti e del software open source, e usava solo strumenti e sistemi operativi di cui il codice sorgente è disponibile pubblicamente, e che utilizzano protocolli pubblicamente descritti. Skype non rientra in questa categoria di strumenti. Abbiamo speso molto tempo a discutere i pro e i contro di questo approccio, a provare alternativi a Skype su diversi sistemi operativi, a cercare di convincere Stas a far passare il team su altri standard, a scrivergli personalmente via email, a chiamarlo al telefono, a comprare un secondo computer apposta per Skype, e così via. Alla fine ho capito che il problema non era sostanzialmente né tecnico né organizzativo, era piuttosto di visione del mondo, anzi, si potrebbe dire quasi religioso (per Stas). Anche se alla fine fossimo riusciti a collegare Stas a Skype (a cosa abbiamo già dedicato diversi mesi), ci avrebbe comunque presentato lo stesso problema con qualsiasi strumento successivo. Non avevo a disposizione reali mezzi per cambiare la visione del mondo di Stas, e non c'erano motivi per tentare di cambiare la mentalità del team, che lavorava bene in quel contesto. L'individuo e l'azienda erano semplicemente ortogonali nelle loro visioni. In situazioni del genere, una buona soluzione è di tipo organizzativo. Abbiamo trasferito Stas in un altro team, dove era più integrato.
A mio avviso, la causa di questo conflitto risiede nell'inadeguatezza della cultura personale di un individuo specifico (che ha un'opinione forte, che non gli consente di scendere a compromessi) rispetto alla cultura aziendale. In questo caso, ovviamente, si tratta di un errore del manager. È stata una scelta inizialmente errata quella di coinvolgerlo in un progetto di questo tipo. Alla fine, Stas è passato a un progetto di sviluppo di software open source e ha avuto grande successo.
Un buon esempio di conflitto, causato dalla posizione infantile dello sviluppatore e dalle carenze nel processo di lavoro, è una situazione in cui, in assenza di una definition of done, lo sviluppatore e il team QA hanno aspettative diverse riguardo alla prontezza della funzionalità inviata al QA. Lo sviluppatore pensava che fosse sufficiente scrivere il codice e passarla al QA - lì si sarebbero sistemati. È un programmatore piuttosto maturo ed esperto, ma questo era il suo limite interno di qualità. Il QA non era d'accordo e richiedeva di mostrare e descrivere cosa avesse controllato e richiedeva uno scenario di testing per loro. Avevano già avuto problemi in passato con la funzionalità di questo sviluppatore e non volevano sprecare tempo inutilmente una seconda volta. A proposito, avevano ragione: la funzionalità non funzionava, e non aveva controllato il codice prima di passarla al QA.
Per risolvere la situazione, gli ho chiesto di mostrarmi che tutto funzionava davvero (e non funzionava, e ha dovuto sistemarlo), abbiamo discusso con il team e con il QA la definition of done (non l'abbiamo scritta, poiché non volevamo burocratizzare eccessivamente il processo), e con questo specialista ci siamo presto separati (con sollievo generale).
Dal punto di vista del processo di lavoro, i miglioramenti potenziali in questo caso includono l'esistenza di una definition of done, requisiti per accompagnare ogni funzionalità con test unitari e di integrazione, e la descrizione dei test eseguiti dallo sviluppatore. In uno dei progetti abbiamo misurato il livello di copertura del codice con i test durante il CI, e nel caso in cui il livello di copertura diminuisse dopo l'aggiunta di una patch, i test venivano segnati come falliti, ovvero qualsiasi nuovo codice poteva essere aggiunto solo in presenza di nuovi test per esso.
Un altro tipico esempio di conflitto, strettamente legato all'organizzazione del processo di lavoro. Abbiamo un prodotto, un team di sviluppo di questo prodotto, un team di supporto e un cliente. Il cliente ha problemi con il prodotto e si rivolge al supporto. Il supporto analizza il problema e capisce che è un problema del prodotto, quindi lo passa al team di prodotto. Il team di prodotto è in un periodo di intensa attività, il rilascio è imminente, quindi il ticket con il problema del cliente, perso tra gli altri ticket dello sviluppatore a cui è stato assegnato, rimane senza attenzione per alcune settimane. Il supporto pensa che lo sviluppatore stia lavorando sul problema del cliente. Il cliente aspetta e spera che qualcuno stia lavorando al suo problema. In realtà, non sta succedendo nulla. Dopo alcune settimane, il cliente decide finalmente di informarsi sul progresso e chiede al supporto come stanno le cose. Il supporto contatta lo sviluppo. Lo sviluppatore sobbalza, controlla l'elenco dei ticket e trova il ticket del cliente. Leggendo il ticket del cliente, comprende che non ha informazioni sufficienti per risolvere il problema e ha bisogno di ulteriori log e dump. Il supporto richiede informazioni aggiuntive al cliente. E qui il cliente comprende che per tutto questo tempo nessuno ha lavorato al suo problema. E ci sarà una tempesta...
In questa situazione, la soluzione del conflitto stesso è piuttosto ovvia e lineare (riparare il prodotto, aggiornare la documentazione e i test, placare il cliente, rilasciare un hotfix, ecc.). È importante analizzare il processo di lavoro e capire chi è responsabile per l'organizzazione dell'interazione tra i due team e perché una situazione del genere sia stata possibile. È chiaro che è necessario apportare delle modifiche al processo: qualcuno deve monitorare la situazione complessiva senza necessità di solleciti da parte dei clienti, in modo proattivo. I ticket del cliente devono distinguersi dagli altri ticket degli sviluppatori. Il supporto deve poter vedere se lo sviluppo sta lavorando sui suoi ticket in quel momento; se no, quando potrà iniziare a lavorare e quando si può aspettare un risultato. Il supporto e lo sviluppo dovrebbero comunicare periodicamente e discutere lo stato dei ticket, la raccolta delle informazioni necessarie per il debug dovrebbe essere quanto più automatizzata possibile, ecc.
Come in guerra il nemico cerca di colpire nel punto di giunzione tra due reparti, così nel lavoro il punto più delicato e vulnerabile è spesso rappresentato dall'interazione fra i team. Se i manager del supporto e dello sviluppo sono suficientemente esperti, possono riparare il processo autonomamente; in caso contrario, il processo continuerà a generare conflitti e problemi fino all'intervento di un manager in grado di risolvere la situazione.
Un altro esempio caratteristico che ho riscontrato più volte in diverse aziende è la situazione in cui un prodotto è sviluppato da un team, i test di integrazione automatizzati da un secondo team, mentre l'infrastruttura su cui tutto ciò è gestito è mantenuta da un terzo team. I problemi durante l'esecuzione dei test si verificano costantemente, e le cause possono essere attribuite sia al prodotto che ai test e all'infrastruttura. Risulta spesso problematico concordare su chi debba effettuare la prima analisi dei problemi, segnalare bug, analizzare i log del prodotto, dei test e dell'infrastruttura, e così via. I conflitti sono piuttosto frequenti e, allo stesso tempo, uniformi. In caso di elevata tensione emotiva, i partecipanti tendono spesso a cadere in una posizione infantile, iniziando discussioni come: “perché dovrei occuparmi di questo?”, “loro hanno più guasti”, ecc.
Dal punto di vista del flusso di lavoro, i passi specifici per risolvere il problema dipendono dalla composizione dei team, dal tipo di test e dal prodotto, ecc. In uno dei progetti abbiamo introdotto turni periodici, durante i quali i team monitoravano i test a turno, per una settimana. In un altro progetto, l'analisi iniziale era sempre condotta dagli sviluppatori dei test, ma era piuttosto superficiale e il prodotto era abbastanza stabile, quindi questo funzionava bene. L'importante è garantire la trasparenza del processo, la chiarezza delle aspettative per tutte le parti coinvolte e un senso di equità nella situazione per tutti.
È un problema il conflitto all'interno di un'organizzazione? È un cattivo segno se ci sono conflitti frequenti (o anche solo periodici) nel tuo team? In generale, no, poiché se c'è crescita, sviluppo e dinamismo, sorgono questioni che non sono mai state risolte prima e nella loro risoluzione possono emergere conflitti. Questo è un indicatore che ci sono aree che necessitano di attenzione e possibilità di miglioramento. È negativo se i conflitti si verificano molto spesso, se sono difficili o lunghi da risolvere. Questo è probabilmente un segno di processi di lavoro non sufficientemente ottimizzati e di una maturità insufficiente del team.
Fonte: habr.com
