Epigrafe:
Un giorno si incontrarono nel bosco Riccio e Orsetto.
— Ciao, Riccio!
— Ciao, Orsetto!
Così, parola dopo parola, scherzo dopo scherzo, Riccio prese un colpo da Orsetto ...
Sotto trovi i ragionamenti del nostro team leader e del direttore dello sviluppo prodotto RAS — Igor Marnat sulla natura dei conflitti lavorativi e sui possibili metodi per gestirli.
La maggior parte dei conflitti che affrontiamo al lavoro si sviluppano secondo 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 danneggiati.
La vita è complessa, nello scenario descritto sopra si verificano variazioni. A volte le relazioni tra i partecipanti non sono molto buone sin dall'inizio, talvolta non c'è nemmeno una questione che richiede una soluzione immediata (come nel caso dell'epigrafe), e a volte dopo la discussione le relazioni rimangono le stesse di prima, ma la questione alla fine non viene risolta.
Qual è il comune denominatore in tutte le situazioni che possono essere definite come conflitti lavorativi?
In primo luogo, 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 trovarsi su livelli gerarchici differenti (superiore e subordinato), essere individuali (un dipendente) o collettive (nel caso di conflitti tra dipendente e team o tra due team), e così via. Il livello di fiducia tra i partecipanti influisce notevolmente sulla probabilità di conflitto e sulla sua facilità di risoluzione. Più le parti si conoscono e maggiore è il livello di fiducia, più è probabile che raggiungano un accordo. Ad esempio, i membri di un team distribuito che non hanno mai comunicato di persona sono più propensi a entrare in conflitto nel risolvere una semplice questione lavorativa rispetto a persone che si sono incontrate almeno un paio di volte di persona. Pertanto, lavorando in team distribuiti, è fondamentale garantire incontri personali periodicità 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. Tuttavia, a causa della specificità della situazione, le parti di solito hanno abbastanza tempo e vari modi per affrontarla (formali, informali, incontri, lettere, decisioni della direzione, obiettivi e piani del team, presenza di gerarchie, ecc.). Questo è diverso dal modo in cui si risolvono questioni lavorative (o non lavorative) all'interno dell'organizzazione, rispetto a, per esempio, risolvere un'importante questione del tipo: “Ehi, amico, di che quartiere sei?” per strada, o il conflitto menzionato nell'epigrafe. Nel caso di questioni lavorative, la qualità del processo lavorativo e la cultura della risoluzione delle questioni all'interno del team sono di fondamentale importanza.
In terzo luogo, un fattore decisivo del conflitto (dal punto di vista della nostra discussione) è il fatto che le parti coinvolte nel processo non possono raggiungere autonomamente una soluzione che soddisfi tutti. La situazione richiede l'intervento di una terza parte, un arbitro esterno. Questo punto può sembrare controverso, ma in sostanza, se la situazione conflittuale viene risolta con successo senza l'intervento di un arbitro esterno, significa che la questione è stata risolta efficacemente e le relazioni tra le parti non sono deteriorate; è questa la situazione verso cui dovremmo tendere. Di tale conflitto, probabilmente, non ne verremo nemmeno a conoscenza, o ne scopriremo l'esito per caso dopo la sua risoluzione. Più questioni una squadra è in grado di risolvere autonomamente, più efficacemente lavorerà.
Un'altra caratteristica distintiva del conflitto che merita di essere affrontata è il grado di intensità emotiva nella risoluzione. Un conflitto non è necessariamente caratterizzato da un alto grado di emotività. I partecipanti non devono necessariamente urlare e agitare le mani affinché la situazione possa essere considerata conflittuale. Se una questione non viene risolta, e vi è una certa tensione emotiva presente (anche se potrebbe non essere espressa in modo evidente), si tratta quindi di una situazione di conflitto.
È necessario intervenire in situazioni conflittuali, o è meglio lasciare che la loro risoluzione avvenga da sola e aspettare che il problema si risolva? Sì. Non sempre è nelle vostre possibilità o competenze risolvere completamente un conflitto, ma in ogni situazione, in un conflitto di qualsiasi scala, potete adottare un atteggiamento maturo, portando con voi anche altre persone intorno a voi, attenuando le conseguenze negative del conflitto e contribuendo alla sua risoluzione.
Prima di esaminare alcuni esempi di situazioni conflittuali, ci soffermeremo su alcuni aspetti importanti comuni a tutti i conflitti.
Quando si tratta di risolvere un conflitto, è fondamentale mantenere una posizione esterna piuttosto che schierarsi all'interno della lotta (questo è conosciuto come "prendere una metaposizione"). In altre parole, non bisognerebbe diventare parte di uno dei lati coinvolti nella risoluzione. In caso contrario, da arbitro esterno, non farete altro che rafforzare una delle parti a scapito dell'altra. È essenziale che la decisione presa sia moralmente accettata da tutte le parti coinvolte, tanto che, come si suol dire, sia "acquistata". Anche se le parti possono non essere entusiaste della decisione finale, devono essere almeno sinceramente concordi nel rispettarla. Si parla, quindi, di essere in grado di "disagree and commit". Altrimenti, il conflitto cambierà solo forma, una fiamma smorza rimarrà sotto la torba e, prima o dopo, riapparirà inevitabilmente.
Un secondo aspetto, in parte collegato al primo, è che se decidi di partecipare alla risoluzione del conflitto, dovresti prendere molto sul serio la questione della comunicazione e della comprensione del contesto. Parla personalmente con ciascuna delle parti. Separatamente, per cominciare. Non accontentarti di comunicazioni via email. Nel caso di un team distribuito, cerca almeno di parlare in videochiamata. Evita di basarti su rumor e racconti di testimoni. Comprendi la storia, cosa desidera ciascuna parte, perché lo desidera, quali aspettative ha, se ha già provato a risolvere questa situazione in passato, cosa accadrà se non verrà risolta, quali soluzioni vedono, come percepiscono la posizione dell'altra parte, cosa credono sia giusto o sbagliato, e così via. Carica nella tua mente tutto il contesto possibile, senza pregiudizi, supponendo che tutti abbiano ragione. Non sei dentro il conflitto, ma al di fuori, in una posizione meta. Se il contesto è accessibile solo tramite una catena di email, leggila almeno per intero, insieme alle discussioni e ai documenti pertinenti. Dopo aver letto, parla comunque a voce. È quasi garantito che sentirai qualcosa di importante che non è presente nelle email.
Il terzo punto importante riguarda l'approccio alla comunicazione. Sono cose comuni, nulla di straordinario, ma hanno un grande significato. 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"), permettiamo di mantenere la faccia, e svolgiamo le discussioni di persona, non davanti al gruppo.
I conflitti sono solitamente causati da una delle due ragioni. La prima è legata al fatto che una persona, in quel momento, si trova nella posizione di adulto o in quella di bambino (ne parlerò di seguito). Questo è correlato alla sua maturità emotiva e alla capacità di gestire le proprie emozioni (che, tra l'altro, non è sempre legata alla sua età). La seconda ragione comune è l'imperfezione del processo lavorativo, che crea situazioni di zone grigie, in cui la responsabilità è sfumata tra i partecipanti, le aspettative delle parti non sono chiare l'una per l'altra e i ruoli nel processo sono indefiniti.
Di conseguenza, nella risoluzione dei conflitti (come in qualsiasi altra questione), un manager deve considerare tre prospettive: quella a breve termine — risolvere il problema/conflitto qui e ora, quella a medio termine — ridurre al minimo la probabilità di un altro conflitto per la stessa ragione, e quella a lungo termine — instillare una cultura di adultità nel team.
In ognuno di noi c'è un bambino interiore, di circa tre o quattro anni. La maggior parte del tempo al lavoro, dorme, ma a volte si sveglia e prende il controllo. Questo 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 macchinina è la migliore (il design è il migliore, programma meglio di tutti, ...). In una situazione di conflitto, il bambino può stringere i giocattoli, battere i piedi e colpire con la paletta, ma non può risolvere questioni da adulti (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, chiedendogli di chiamare il suo adulto. Prima di iniziare una discussione in condizioni di conflitto, assicurati di parlare con l'adulto e non con il bambino, e tu stesso devi occupare la posizione di adulto. Se il tuo obiettivo onesto in questo momento è risolvere una questione seria, sei nella posizione di una persona adulta. Se il tuo obiettivo è sbattere i piedi e colpire con la paletta, questa è una posizione infantile. Metti a dormire il tuo bambino interiore e chiama l'adulto, oppure rimanda la discussione. La persona prende una decisione emotiva e poi cerca una giustificazione razionale. Una decisione presa dal bambino, basata sulle priorità infantili, non sarà ottimale.
Oltre al comportamento in momenti di conflitto, la posizione di un bambino o di un adulto si caratterizza anche attraverso il livello di responsabilità che la persona è disposta ad assumersi. Nelle espressioni estreme, la posizione 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 fonderlo, e il QA deve verificarlo; se ci sono problemi, me lo faranno sapere. Stranamente, anche persone abbastanza adulte e esperte si comportano talvolta in questo modo. Dall'altra estremità della scala, c'è chi si considera responsabile affinché il proprio codice funzioni, sia coperto da test, verificato personalmente, superi con successo la revisione (se necessario, non ci sono problemi a contattare i revisori, discutere questioni a voce, ecc.) e venga fuso; se necessario, il QA sarà supportato, verranno descritti gli scenari di test, ecc. In genere, un programmatore si trova inizialmente più vicino all'estremità adulta della scala o si sposta verso quella direzione man mano che accumula esperienza (a condizione che nel team venga coltivata la giusta cultura). Nei casi estremi continuano a lavorare, assumendo solitamente una posizione infantile, e allora hanno di frequente problemi e conflitti sia per sé che per il team.
Allevare una cultura giusta e matura all'interno del team è una delle principali responsabilità di qualsiasi manager. Richiede tempo e sforzi quotidiani, ma ne vale la pena. Ci sono due modi per influenzare la cultura del team: dare l'esempio personale (al quale tutti si adegueranno, poiché il team osserva sempre il leader) e discutere e incoraggiare i comportamenti appropriati. Anche qui non c'è nulla di complicato o eccessivamente formale; durante le discussioni sui problemi, evidenziate cosa si sarebbe potuto fare in un certo modo, sottolineate quando notate una soluzione corretta, lodate e menzionate durante l'analisi della release, e così via.
Esaminiamo alcune situazioni conflittuali tipiche, dalle più semplici alle più complesse:
Conflitti non legati a questioni lavorative
Spesso sul lavoro si verificano conflitti non legati a questioni lavorative. La loro insorgenza e facilità di risoluzione sono generalmente collegate al livello di intelligenza emotiva dei partecipanti, al loro grado di maturità, e non sono correlate alla perfezione o imperfezione del processo lavorativo.
Esempi comuni: qualcuno non utilizza abbastanza spesso la lavatrice o la doccia, il che infastidisce gli altri; qualcuno trova troppo caldo, mentre un altro sente corrente se apre la finestra; qualcuno è troppo rumoroso, mentre gli altri necessitano di silenzio per lavorare, e così via. È meglio non procrastinare nella risoluzione di conflitti di questo tipo e non lasciarli andare da soli. Non si risolveranno da soli e continueranno a distrarre dal lavoro e a creare un'atmosfera tossica nel team. Fortunatamente, solitamente non è un grande problema affrontarli: è sufficiente avere una conversazione tranquilla (naturalmente, uno a uno) con un collega che trascura l'igiene, garantire una disposizione confortevole per le persone che preferiscono silenzio/freschezza, acquistare cuffie fonoassorbenti o installare divisori, ecc.
Un altro esempio che ho incontrato più volte durante il mio lavoro è la discompatibilità psicologica tra i membri del team. Per qualche motivo, le persone semplicemente non riescono a lavorare insieme, ogni interazione finisce in una lite. A volte questo è legato al fatto che le persone hanno opinioni polarizzate su qualche questione di grande rilevanza (di solito politica) e non riescono a mantenerle al di fuori del lavoro. Convincerle a tollerarsi a vicenda o a cambiare il loro comportamento è un compito piuttosto futile. L'unica eccezione che ho riscontrato sono stati i giovani colleghi con una mentalità aperta, il cui comportamento può essere modificato gradualmente tramite conversazioni periodiche. Di solito, la situazione si risolve con una separazione in diversi team, o almeno garantendo che hanno possibilità di incrociarsi raramente sul lavoro.
In tutte le situazioni descritte, è utile parlare con ciascun partecipante personalmente, discutere la situazione, chiedere se vedono un problema e quali, secondo loro, potrebbero essere le soluzioni, assicurando la loro partecipazione nel processo decisionale.
Dal punto di vista dell'ottimizzazione del flusso di lavoro (prospettiva a medio termine di cui ho parlato), non si può fare molto qui; l'unico aspetto da ottimizzare è considerare il fattore della compatibilità nella formazione del team e non mettere insieme in anticipo persone che entreranno in conflitto.
Dal punto di vista della cultura del team, tali situazioni si verificano molto più raramente nei team con una cultura matura, dove le persone rispettano il team e i colleghi e sono in grado di risolvere questioni in autonomia. Inoltre, tali conflitti vengono risolti molto più facilmente (spesso in modo automatico) nei team con un alto livello di fiducia, dove le persone lavorano insieme da molto tempo e/o comunicano spesso al di fuori del lavoro.
Conflitti legati a questioni lavorative:
Questi conflitti sono generalmente causati da entrambe le ragioni contemporaneamente, sia quella emotiva (quando uno dei partecipanti non si trova in una posizione adulta) sia l'imperfezione del processo lavorativo stesso. Forse il tipo di conflitto più comune che ho incontrato sono i conflitti durante la revisione del codice o la discussione dell'architettura tra gli sviluppatori.
Qui distinguerei due casi tipici:
1) In the first case, the developer cannot get code review from a colleague. The patch has been submitted for review, and nothing happens. At first glance, there seems to be no clear conflict between the two parties, but upon closer examination, this is indeed a conflict. The working issue is not being resolved, and one party (the one awaiting review) is clearly experiencing discomfort. An extreme variation of this scenario occurs in a community development or in different teams, where the reviewer may not be interested in this specific code due to their workload or other circumstances and may not pay attention to the review request at all, and there may not be an external arbitrator (a common manager for both parties).
L'approccio alla soluzione che aiuta in una situazione del genere è proprio legato a una prospettiva a lungo termine e alla cultura di un adulto. In primo luogo, è importante essere attivi in modo ragionevole. Non aspettarti che il codice in attesa di revisione attiri l'attenzione del revisore da solo. Devi aiutare i revisori a notarlo. Contatta alcune persone, poni domande nei meeting, partecipa alle discussioni. È ovvio che essere troppo insistente può danneggiare più di quanto aiuti, è necessario usare il buon senso. In secondo luogo, una buona preparazione funziona bene. Se il team capisce cosa e perché sta succedendo, e perché quel codice è necessario, e se il design è stato discusso e concordato in anticipo con tutti, le persone saranno più propense a prestare attenzione a quel codice e ad accettarlo nel lavoro. In terzo luogo, il tuo prestigio conta. Se vuoi che il tuo codice venga revisionato, fai molti revisioni tu stesso. Fai revisioni di qualità, con verifiche reali, test concreti e commenti utili. Se il tuo nickname è conosciuto positivamente nel team, avrai più probabilità che il tuo codice venga notato.
Dal punto di vista del flusso di lavoro, i possibili miglioramenti qui includono una corretta attribuzione delle priorità, mirata ad aiutare lo sviluppatore a raggiungere i suoi obiettivi e quelli del team (come rivedere il lavoro degli altri, scrivere lettere alla community, accompagnare il codice con descrizioni architettoniche, documentazione, test, partecipare a discussioni con la community, ecc.), evitando che le patch rimangano troppo a lungo in coda, e così via.
2) Un secondo caso comune di conflitti durante la revisione del codice o del design è rappresentato da punti di vista diversi su questioni tecniche, stile di codifica, scelta degli strumenti. In questo contesto, il livello di fiducia tra i partecipanti, l'appartenenza a un unico team e l'esperienza di collaborazione hanno un'importanza enorme. Si crea un vicolo cieco quando uno dei partecipanti adotta una posizione immatura, senza cercare di comprendere ciò che l'interlocutore vuole comunicare. Spesso, sia l'approccio proposto dall'altra parte sia quello inizialmente suggerito possono funzionare con successo e non ha rilevanza fondamentale quale scegliere.
Una volta, un programmatore del mio team (chiamiamolo Pasha) ha preparato una patch con delle modifiche al sistema di distribuzione dei pacchetti, sviluppato e mantenuto dai colleghi del dipartimento vicino. Uno di loro (Igor) aveva un forte parere su come configurare i servizi Linux durante la distribuzione dei pacchetti. Questa opinione era diversa dall'approccio suggerito nella patch e non riuscivano a trovare un accordo. Come al solito, i tempi stringevano e doveva arrivare a una soluzione; era necessario che uno di loro adottasse un atteggiamento maturo. Pasha riconosceva che entrambi gli approcci avevano diritto di esistere, ma sperava che la sua proposta venisse accettata, poiché non c'erano evidenti vantaggi tecnici in nessuna delle due soluzioni.
La nostra discussione è andata all'incirca così (ovviamente, in modo molto schematizzato, il colloquio è durato mezz'ora):
— Pasha, tra qualche giorno abbiamo il feature freeze. È importante che raccogliamo tutto e iniziamo i test il prima possibile. Come possiamo fare per passare da Igor?
— Vuole configurare i servizi in modo diverso, mi ha lasciato un sacco di commenti ...
— E quindi, ci sono grandi modifiche, molta fatica da fare?
— No, lì ci sono solo un paio d'ore di lavoro, ma alla fine non cambia nulla, funzionerà in entrambi i modi, a cosa serve? Ho fatto una cosa funzionante, accettiamola così.
— Senti, da quanto state discutendo tutto questo?
— Già da un paio di settimane ci stiamo bloccando.
— Ehm… possiamo risolvere in poche ore una questione che è già durata un paio di settimane e non lo facciamo?
— Beh, sì, ma non voglio che Igor pensi che mi sono piegato…
— Senti, per te cosa è più importante, pubblicare il rilascio con la tua soluzione o superare Igor? Possiamo superarlo, ma in tal caso c'è una buona possibilità che il rilascio salti.
— Beh… sarebbe bello, certo, darla a Igor, ma va bene, il rilascio è più importante, sei d'accordo.
— Ti importa davvero così tanto di cosa pensa Igor? A dire il vero, a lui non interessa molto, vuole solo un approccio unificato in posti diversi della cosa di cui è responsabile.
— Ok, farò come chiede nei commenti e iniziamo i test.
— Grazie, Pasha! Ero sicuro che tra voi due saresti stato tu il più maturo, anche se Igor è più grande di te :)
La questione si è risolta, il rilascio è avvenuto in tempo, Pasha non ha manifestato particolari disagi, poiché è stato lui a suggerire la soluzione e a realizzarla. Igor era molto soddisfatto, poiché il suo parere è stato preso in considerazione e hanno fatto come proponeva.
Un altro tipo di conflitto simile è la scelta tra soluzioni tecniche/biblioteche/approcci in un progetto, specialmente in un team distribuito. In uno dei progetti, che si presentava come un utilizzo di C/C++, alla fine si è scoperto che la direzione tecnica del progetto era categoricamente contraria all'uso della STL (Standard Template Library). Questa è una libreria standard del linguaggio che semplifica lo sviluppo, alla quale il nostro team era molto abituato. È emerso che il progetto era molto più vicino al C che al C++, il che non era molto stimolante per il team, dato che la direzione aveva cercato di assumere veramente bravi programmatori C++. Nel frattempo, la parte americana del team, sia ingegneri che manager, lavorava in azienda da lungo tempo, abituata alla situazione esistente, ed erano soddisfatti. La parte russa del team è stata riunita di recente, solo negli ultimi giorni (incluso me). La parte russa del team non desiderava affatto rinunciare all'approccio di sviluppo abituale.
Sono iniziati interminabili scambi di email tra due continenti, lettere lunghe tre o quattro schermi volavano da una parte all'altra, in mailing list e messaggi personali, da programmatori a programmatori e manager. Come spesso accade, nessuno al di fuori degli autori e dei loro ardenti sostenitori leggeva lettoni di tale lunghezza. Le chat cigolavano per la tensione, scambiando considerazioni articolate sui numerosi vantaggi tecnici di STL, su quanto fosse ben testata, sicura e, in generale, su quanto fosse meravigliosa la vita con essa e terribile senza.
È durata a lungo, finché non ho finalmente capito che stavamo discutendo gli aspetti tecnici, mentre il problema in realtà non era tecnico. Non riguardava i vantaggi o gli svantaggi di STL o la difficoltà di lavorare senza di essa. La questione era più organizzativa. Dovevamo semplicemente comprendere come funzionava l'azienda in cui lavoravamo. Nessuno di noi aveva esperienza in un'azienda di questo tipo. Il problema era che dopo lo sviluppo del codice e il suo rilascio in produzione, il supporto era gestito da persone completamente diverse, di altri team e di altri paesi. Questa enorme squadra di ingegneri, che contava diverse decine di migliaia di membri, poteva permettersi solo il minimo indispensabile di strumenti tecnici, il cosiddetto minimum minimorum. Tutto ciò che andava oltre lo standard ingegneristico stabilito nell'azienda non poteva fisicamente essere supportato in seguito. Il livello di una squadra è determinato dal livello dei membri più deboli. Dopo aver capito la reale motivazione Le azioni della parte americana del team hanno fatto sì che questa questione venisse rimossa dall'ordine del giorno e siamo riusciti a sviluppare e lanciare il prodotto insieme, seguendo gli standard adottati dall'azienda. In questo caso, le email e le chat hanno funzionato male; ci sono voluti diversi viaggi e molta comunicazione personale per trovare un terreno comune.
Dal punto di vista del flusso di lavoro, in questo caso specifico, sarebbe stato utile avere una descrizione degli strumenti utilizzati, i requisiti per questi, le limitazioni all'aggiunta di nuovi strumenti e la motivazione di tali limitazioni. Questi documenti corrispondono più o meno a quanto descritto nei punti della Strategia di Riutilizzo e dell'Ambiente di Sviluppo nel manuale ‘Manager’s Handbook for Software Development’, sviluppato in . Nonostante la sua età, descrive perfettamente tutte le attività principali e le fasi di pianificazione dello sviluppo di software di questo tipo. La presenza di documenti simili semplifica notevolmente il processo di discussione su quali componenti e approcci possano essere utilizzati nel prodotto e perché.
Dal punto di vista culturale, è evidente che con un atteggiamento più maturo, in cui le parti cercano di ascoltare e comprendere la reale motivazione delle azioni dei colleghi e agiscono in base alle priorità del progetto e del team, piuttosto che su un ego personale, il conflitto si risolverebbe in modo più semplice e veloce.
In un altro conflitto riguardante la scelta di una soluzione tecnica, ho impiegato anche un tempo considerevole per capire la motivazione di una delle parti (il caso era molto singolare), ma dopo che la motivazione è stata chiara, la soluzione è diventata ovvia.
La situazione è questa: nel team di circa 20 persone arriva un nuovo sviluppatore, chiamiamolo Stas. Il nostro strumento standard per comunicare in team era, a quel tempo, Skype. Come si è poi scoperto, Stas era un grande fan degli standard aperti e del software open source, e usava solo strumenti e sistemi operativi i cui sorgenti sono disponibili pubblicamente e che utilizzano protocolli pubblicamente descritti. Skype non rientra tra questi strumenti. Abbiamo speso un sacco di tempo a discutere i pregi e i difetti di questo approccio, nel tentativo di avviare alternative a Skype su diversi sistemi operativi, tentando di convincere Stas a far passare il team ad altri standard, scrivendogli personalmente via email, chiamandolo direttamente al telefono, comprandogli un secondo computer appositamente per Skype, e così via. Alla fine ho capito che si trattava di un problema, in sostanza, non tecnico e non organizzativo, ma piuttosto di visione del mondo, si può persino dire religioso (per Stas). Anche se alla fine avessimo unito Stas a Skype (cosa che già aveva richiesto diversi mesi), il problema sarebbe riemerso con qualsiasi nuovo strumento utilizzato. Non avevo mezzi reali per cambiare la visione del mondo di Stas, e non c'erano motivi per cercare di cambiare la visione del team, che lavorava benissimo in questo ambiente. La persona e l'azienda erano semplicemente ortogonali nella loro visione. In situazioni simili, una buona soluzione è organizzativa. Abbiamo trasferito Stas in un altro team, dove era più adatto.
Ritengo che la causa di questo conflitto risieda nella discrepanza tra la cultura personale di un individuo (che ha un'opinione forte che non gli consente di scendere a compromessi) e la cultura aziendale. In questo caso, è sicuramente un errore del manager. È stato inizialmente sbagliato farlo lavorare su un progetto di questo tipo. Alla fine, Stas è passato a un progetto di sviluppo di software open source e lì ha avuto un grande successo.
Un buon esempio di conflitto, causato sia dalla posizione immatura dello sviluppatore che dalle carenze del 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 riteneva che fosse sufficiente scrivere il codice e passarla al QA — là se ne sarebbero occupati. È un programmatore abbastanza maturo e esperto, ma questo era il suo livello interno di qualità. Il QA non era d'accordo e richiedeva di mostrargli e descrivere ciò che lui aveva controllato, oltre a esigere uno scenario di test. Avevano già avuto problemi in passato con la funzionalità di questo sviluppatore e non volevano sprecare di nuovo il loro tempo. Peraltro, avevano ragione: la funzionalità non funzionava, e lui non aveva controllato il codice prima di inviarlo al QA.
Per affrontare la situazione, ho chiesto di mostrarmi che tutto funzionava davvero (non funzionava, e ha dovuto ripararlo). Abbiamo discusso con il team e con il QA la definizione di fatto (non l'abbiamo scritta, poiché non volevamo burocratizzare troppo il processo), e con questo specialista ci siamo presto separati (con sollievo generale).
Dal punto di vista del flusso di lavoro, possibili miglioramenti in questo caso sono la presenza di una definizione di fatto, requisiti di supporto per ciascuna funzionalità con unità e test di integrazione, e la documentazione del testing eseguito 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 diminuiva dopo l'aggiunta di una patch, i test venivano contrassegnati come non superati, cioè qualsiasi nuovo codice poteva essere aggiunto solo se accompagnato da nuovi test.
Un altro tipico esempio di conflitto, strettamente legato all'organizzazione del flusso di lavoro. Abbiamo un prodotto, un team di sviluppo per 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 inoltra al team di prodotto. Il team di prodotto è sotto pressione, con un rilascio imminente, quindi il ticket con il problema del cliente, perso tra gli altri ticket assegnati allo sviluppatore, rimane inattivo per settimane. Il supporto pensa che lo sviluppatore stia lavorando sul problema del cliente. Il cliente attende e spera che qualcuno stia lavorando sul suo problema. In realtà, nulla sta accadendo. Dopo alcune settimane, il cliente decide finalmente di chiedere aggiornamenti e contatta il supporto per sapere come sta procedendo. Il supporto chiede allo sviluppo. Lo sviluppatore si scuote, esamina l'elenco dei ticket e trova il ticket del cliente. Leggendo il ticket del cliente, capisce che le informazioni per risolvere il problema non sono sufficienti e ha bisogno di ulteriori log e dump. Il supporto richiede ulteriori informazioni al cliente. E a questo punto, il cliente realizza che nessuno ha lavorato sul suo problema per tutto questo tempo. E scoppia il temporale...
In questa situazione, la soluzione del conflitto è abbastanza ovvia e lineare (riparare il prodotto, aggiornare la documentazione e i test, placare il cliente, emettere un hotfix, ecc.). È importante analizzare il flusso di lavoro e capire chi è responsabile dell'organizzazione dell'interazione tra i due team, e perché questa situazione è diventata possibile. È chiaro che è necessario correggere il processo: qualcuno deve monitorare il quadro generale senza promemoria da parte dei clienti, in modo proattivo. I ticket dei clienti devono distinguersi tra gli altri ticket per gli sviluppatori. Il supporto deve vedere se il team di sviluppo sta lavorando sui suoi ticket in questo momento; se non lo fanno, devono sapere quando potranno iniziare e quando aspettarsi un risultato. Il supporto e lo sviluppo devono comunicare periodicamente e discutere lo stato dei ticket, la raccolta delle informazioni necessarie per il debug deve essere il più automatizzata possibile, ecc.
Così come in guerra il nemico cerca di colpire il punto di contatto tra due reparti, anche nel lavoro il punto più sottile e vulnerabile è solitamente l'interazione tra i team. Se i manager del supporto e dello sviluppo sono abbastanza maturi, potranno riparare il processo autonomamente; in caso contrario, il processo continuerà a generare conflitti e problemi finché non interverrà un manager in grado di sistemare la situazione.
Un altro esempio caratteristico che ho incontrato ripetutamente in diverse aziende è la situazione in cui un prodotto è sviluppato da un team, i test di integrazione automatizzati da un secondo team, e l'infrastruttura su cui tutto questo è in esecuzione è gestita da un terzo team. Problemi durante l'esecuzione dei test sorgono costantemente, e le cause di tali problemi possono riguardare sia il prodotto, sia i test che l'infrastruttura. Spesso è problematico mettere d'accordo chi dovrebbe effettuare la prima analisi dei problemi, segnalare i bug, analizzare i log del prodotto, dei test e dell'infrastruttura, ecc. I conflitti qui sono piuttosto comuni e, allo stesso tempo, sistematici. In situazioni di alta tensione emotiva, i partecipanti tendono a cadere in una posizione infantile e cominciano discussioni del tipo: “perché dovrei occuparmi di questo?”, “loro si rompono più spesso”, ecc.
Dal punto di vista del flusso di lavoro, i passaggi specifici per affrontare la questione dipendono dalla composizione dei team, dal tipo di test e dal prodotto, ecc. In uno dei progetti, abbiamo introdotto dei turni periodici in cui i team monitoravano i test a turno, per una settimana. In un altro progetto, l'analisi preliminare era sempre effettuata dagli sviluppatori dei test, ma era piuttosto basica e il prodotto era abbastanza stabile, quindi funzionava bene. L'importante è garantire la trasparenza del processo, chiarezza nelle aspettative per tutte le parti coinvolte e un senso di equità nella situazione per tutti.
Il conflitto è un problema all'interno dell'organizzazione? È un segno negativo se nella tua squadra ci sono conflitti frequenti (o anche solo occasionali)? In generale, no. Quando c'è crescita, sviluppo e dinamismo, sorgono questioni che prima non erano state affrontate e, nel loro risolvere, possono sorgere conflitti. Questo indica che ci sono aspetti su cui prestare attenzione, aree che possono essere migliorate. È problematico se i conflitti si manifestano troppo spesso e sono difficili o lunghi da risolvere. Questo è probabilmente un segnale di processi di lavoro non ben definiti e di una squadra non sufficientemente matura.
Fonte: habr.com
