Gestione dei conflitti in una squadra: un atto di equilibrio o una necessità vitale?

motto:
C'erano una volta il Riccio e l'Orsetto che si incontravano nella foresta.
- Ciao, riccio!
- Ciao, orsetto!
Così, parola dopo parola, battuta dopo battuta, il Riccio venne colpito in faccia dall'Orsetto...

Di seguito è riportata una discussione del nostro team leader, nonché del direttore dello sviluppo prodotto RAS Igor Marnat, sulle specificità dei conflitti di lavoro e sui possibili metodi per gestirli.

La maggior parte dei conflitti che incontriamo sul lavoro si sviluppano secondo uno scenario simile a quello descritto nell'epigrafe sopra. Ci sono diversi partecipanti che inizialmente sono abbastanza favorevoli l'uno verso l'altro, cercano di risolvere qualche problema, ma alla fine il problema rimane irrisolto e per qualche motivo i rapporti tra i partecipanti alla discussione risultano rovinati.

La vita è varia e si verificano variazioni nello scenario sopra descritto. A volte il rapporto tra i partecipanti inizialmente non è molto buono, a volte non c'è nemmeno un problema che richieda una soluzione diretta (come, ad esempio, nell'epigrafe), a volte dopo la discussione il rapporto rimane lo stesso di prima che iniziasse, ma il problema alla fine non è risolto.

Cosa accomuna tutte le situazioni che possono essere definite situazioni di conflitto lavorativo?



Innanzitutto, ci sono due o più lati. Questi soggetti possono occupare posti diversi nell'organizzazione, essere in un rapporto di uguaglianza (colleghi di una squadra), o a diversi livelli della gerarchia (capo - subordinato), essere individuali (dipendente) o di gruppo (in caso di conflitto tra un dipendente e una squadra o due squadre) e così via. La probabilità del conflitto e la facilità della sua risoluzione sono fortemente influenzate dal livello di fiducia tra i partecipanti. Quanto meglio le parti si conoscono, tanto più alto è il livello di fiducia, tanto maggiori sono le possibilità che raggiungano un accordo. Ad esempio, i membri di un team distribuito che non hanno mai interagito faccia a faccia hanno maggiori probabilità di sperimentare conflitti su una semplice questione lavorativa rispetto alle persone che hanno avuto almeno alcune interazioni faccia a faccia. Pertanto, quando si lavora in team distribuiti, è molto importante garantire che tutti i membri del team si incontrino periodicamente di persona.

In secondo luogo, in una situazione di conflitto sul lavoro, le parti si trovano nella situazione di risolvere qualche questione importante per una delle parti, per entrambe o per l'organizzazione nel suo insieme. Allo stesso tempo, a causa delle specificità della situazione, le parti di solito hanno tempo sufficiente e una varietà di modi per risolverla (riunioni formali, informali, lettere, decisioni del management, presenza di obiettivi e piani del team, fatto di una gerarchia, ecc.). Questo è diverso dalla situazione in cui si risolve un problema lavorativo (o non lavorativo) in un’organizzazione, ad esempio, dalla risoluzione di una domanda importante: “Eh, ragazzo, da che zona vieni?!” per strada, o il conflitto dall'epigrafe. Nel caso della risoluzione di un problema di lavoro, la qualità del processo di lavoro e la cultura della risoluzione dei problemi nel team sono importanti.

In terzo luogo, il fattore determinante del conflitto (dal punto di vista della nostra discussione) è il fatto che le parti coinvolte nel processo non possono giungere autonomamente a una soluzione alla questione adatta a tutte le parti. La situazione richiede l'intervento di una terza parte, un arbitro esterno. Questo punto può sembrare controverso, ma, in sostanza, se la situazione di conflitto è stata risolta con successo senza l'intervento di un arbitro esterno, la questione è stata risolta con successo e i rapporti tra le parti non si sono deteriorati, questa è la situazione a cui dovremmo tendere . Molto probabilmente non sapremo nemmeno di un simile conflitto, o lo scopriremo per caso dopo che sarà risolto. Quanti più problemi un team riesce a risolvere da solo, tanto più efficace sarà.

Un'altra caratteristica del conflitto che vale la pena toccare è il grado di intensità emotiva durante la decisione. Il conflitto non è necessariamente associato a un livello emotivo elevato. Non è necessario che i partecipanti gridino e agitino le braccia perché la situazione sia, in sostanza, un conflitto. La questione non è risolta, è presente una certa tensione emotiva (forse non espressa chiaramente all'esterno), il che significa che ci troviamo di fronte a una situazione di conflitto.

È necessario intervenire in situazioni di conflitto o è meglio lasciare che la loro risoluzione faccia il suo corso e aspettare che il problema si risolva da solo? Bisogno di. Non è sempre in tuo potere o competenza risolvere completamente il conflitto, ma in qualsiasi situazione, in un conflitto di qualsiasi portata, puoi assumere una posizione adulta, portando così molte più persone intorno a te, mitigando le conseguenze negative del conflitto. conflitto e contribuire alla sua risoluzione.

Prima di considerare alcuni esempi di situazioni di conflitto, esaminiamo alcuni punti importanti comuni a tutti i conflitti.

Quando si risolve un conflitto, è importante essere al di sopra del conflitto e non al suo interno (questo è anche chiamato “assumere una meta-posizione”), cioè non far parte di una delle parti nel processo di risoluzione. Altrimenti, avere un arbitro esterno che assiste la decisione non farà altro che rafforzare la posizione di una delle parti a scapito dell'altra parte. Quando si prende una decisione, è importante che sia moralmente accettata da tutte le parti, come si suol dire, "comprata". In modo che, anche se le parti non fossero soddisfatte della decisione presa, almeno accettarono sinceramente di attuarla. Come si suol dire, essere in grado di non essere d'accordo e impegnarsi. Altrimenti, il conflitto cambierà semplicemente aspetto, il fuoco covante rimarrà sotto la torbiera e ad un certo punto inevitabilmente divamperà di nuovo.

Il secondo punto, in parte legato al primo, è che se avete già deciso di partecipare alla risoluzione del conflitto, prendetelo il più seriamente possibile dal punto di vista della comunicazione e dello studio del contesto. Parla personalmente con ciascuna delle parti. Separatamente con ciascuno, per cominciare. Non accontentarti della posta. In caso di team distribuito, parlare almeno tramite collegamento video. Non accontentatevi delle dicerie e delle testimonianze oculari. Comprendere la storia, cosa vuole ciascuna parte, perché lo vuole, cosa si aspetta, ha già provato a risolvere questo problema, cosa accadrà se non viene risolto, quali soluzioni vedono, come immaginano la posizione dei dall'altra parte, cosa pensano, giusto o sbagliato, ecc. Carica nella tua testa tutto il contesto possibile, con una mente aperta, dando per scontato che tutti abbiano ragione. Non sei dentro al conflitto, sei fuori, in una metaposizione. Se il contesto è disponibile solo in un thread del post, leggilo almeno nella sua interezza e nei thread e nei documenti ad esso correlati. Dopo averlo letto, parla ancora con la tua voce. Hai quasi la certezza di sentire qualcosa di importante che non è nella posta.

Il terzo punto importante è l’approccio generale alla comunicazione. Queste sono cose ordinarie, niente di cosmico, ma sono molto importanti. Non cerchiamo di risparmiare tempo, parliamo con tutti i partecipanti, non critichiamo 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 salvare la faccia, conduciamo le discussioni di persona, non davanti alla fila.

I conflitti sono solitamente causati da uno dei due motivi. Il primo è legato al fatto se una persona al momento del conflitto si trova nella posizione di un adulto o nella posizione di un bambino (ne parleremo più avanti). Ciò è dovuto alla sua maturità emotiva, 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 di lavoro, che crea situazioni di aree grigie in cui la responsabilità è distribuita tra i partecipanti, le aspettative delle parti non sono trasparenti tra loro e i ruoli nel processo sono sfumati.

Di conseguenza, nel risolvere un conflitto (così come qualsiasi altra questione), un manager deve tenere a mente tre prospettive: a breve termine - per risolvere la questione/conflitto qui e ora, a medio termine - per ridurre al minimo la probabilità che si verifichi un altro conflitto per lo stesso motivo, e a lungo termine, coltivare una cultura adulta nella persona del team.

Ognuno di noi ha un bambino interiore, di circa tre o quattro anni. Dorme la maggior parte del tempo al lavoro, 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 sandbox, sua madre lo ama di più, la sua macchina è la migliore (il design è il migliore, lui programma il meglio, ...). In una situazione di conflitto, un bambino può premere i giocattoli, battere i piedi e schioccare la spatola, ma non può risolvere i problemi degli adulti (architettura della soluzione, approcci ai test automatizzati, date di rilascio, ecc.), non pensa in termini di benefici per il team. Un bambino in conflitto può essere incoraggiato, consolato e mandato a letto chiedendogli di chiamare il suo adulto. Prima di iniziare una discussione in una situazione di conflitto, assicurati di parlare con un adulto, non con un bambino, e di essere tu stesso nella posizione di un adulto. Se il tuo obiettivo onesto in questo momento è risolvere un problema serio, sei nella posizione di un adulto. Se il tuo obiettivo è battere i piedi e far schioccare la scapola, questa è una posizione infantile. Manda a letto il tuo bambino interiore e chiama un adulto o riprogramma la discussione. Una persona prende una decisione emotiva e poi cerca una giustificazione razionale per essa. Una decisione presa da un bambino in base alle sue priorità non sarà ottimale.

Oltre al comportamento al momento del conflitto, la posizione di un bambino o di un adulto è caratterizzata anche dal livello di responsabilità che una persona è disposta ad assumersi. Nelle sue manifestazioni estreme, la posizione infantile di un programmatore, che ho incontrato più di una volta, assomiglia a questa: ho scritto il codice, l'ho inviato per la revisione: il mio lavoro è finito. I revisori dovrebbero esaminarlo e approvarlo, il QA dovrebbe controllarlo, se ci sono problemi me lo faranno sapere. Stranamente, anche le persone abbastanza mature ed esperte a volte si comportano in questo modo. L'altra estremità della scala è che una persona si considera responsabile di garantire che il suo codice funzioni, sia coperto da test, sia stato controllato personalmente da lui, abbia superato con successo la revisione (se necessario, non ci sono problemi a contattare i revisori, discutere problemi tramite voce, ecc.) ed è stato soppresso, il QA fornirà assistenza se necessario, verranno descritti gli scenari di test, ecc. In casi normali, il programmatore inizia più vicino all'estremità adulta della scala, oppure si sposta lì man mano che acquisisce esperienza (a condizione che venga coltivata la giusta cultura all'interno del team). In casi estremi, continua a lavorare, di solito assumendo una posizione infantile, quindi periodicamente lui e la squadra hanno problemi e conflitti.

Promuovere la cultura giusta e matura in una squadra è un compito importante per qualsiasi manager. Richiede molto tempo e impegno quotidiano, ma ne vale la pena. Esistono due modi per influenzare la cultura della squadra: dare l'esempio (che sarà sicuramente seguito; la squadra guarda sempre al leader) e discutere e premiare il comportamento giusto. Anche qui non c'è niente di astruso o di molto formale, solo quando si discute di problemi, si nota che si sarebbe potuto fare qualcosa qui, si sottolinea che si è notato quando è stato deciso correttamente, si loda, si nota durante la revisione del rilascio, ecc.

Consideriamo diverse situazioni tipiche di conflitto, da semplici a complesse:

Conflitti non legati a questioni lavorative

Molto spesso ci sono conflitti sul lavoro che non sono legati a questioni lavorative. La loro insorgenza e la facilità di risoluzione sono solitamente direttamente correlate al livello di intelligenza emotiva dei partecipanti, al loro livello di maturità e non sono correlate alla perfezione o imperfezione del processo lavorativo.

Esempi tipici: qualcuno usa la lavatrice o la doccia non abbastanza spesso, cosa che ad altri non piace, qualcuno sente l'aria soffocante, mentre altri prendono vento se aprono la finestra, qualcuno è troppo rumoroso e altri hanno bisogno del silenzio per lavorare, e Presto. È meglio non ritardare la risoluzione di conflitti di questo tipo e non lasciare che facciano il loro corso. Non si risolveranno da soli e ti distrarranno dal lavoro ogni giorno e avveleneranno l'atmosfera nella squadra. Fortunatamente, risolverli di solito non è un grosso problema: basta parlare con calma (uno a uno, ovviamente) con un collega che trascura l'igiene, fornire posti a sedere comodi per le persone che preferiscono il silenzio/freschezza, acquistare cuffie fonoassorbenti o installare pareti divisorie. , eccetera.

Un altro esempio che ho riscontrato più volte durante il mio lavoro è l'incompatibilità psicologica dei membri del team. Per qualche ragione, le persone semplicemente non possono lavorare insieme; ogni interazione finisce in uno scandalo. A volte ciò è dovuto al fatto che le persone hanno opinioni polari su alcune questioni urgenti (di solito politiche) e non sanno come lasciarle fuori dal lavoro. Convincerli a tollerarsi a vicenda o a cambiare il loro comportamento è un compito piuttosto futile. L'unica eccezione che ho riscontrato sono i colleghi giovani con percezioni aperte; il loro comportamento può ancora essere gradualmente modificato attraverso conversazioni periodiche. Di solito il problema viene risolto con successo separandoli in team diversi, o almeno offrendo molto raramente la possibilità di sovrapporsi sul lavoro.

In tutte le situazioni di cui sopra, vale la pena parlare personalmente con tutti i partecipanti, discutere la situazione, chiedere se vedono un problema in questo caso, chiedere quali sono, secondo loro, le soluzioni e garantire la loro partecipazione nella realizzazione di questo decisione.

Dal punto di vista dell’ottimizzazione del processo di lavoro (la prospettiva a medio termine di cui ho parlato), qui non si può fare molto; l’unico punto di ottimizzazione è tenere conto del fattore di compatibilità quando si forma una squadra e non mettere le persone insieme in anticipo chi entrerà in conflitto.

Dal punto di vista della cultura del team, tali situazioni si verificano molto meno spesso nei team con una cultura matura, dove le persone rispettano il team e i colleghi e sanno come risolvere i problemi in modo indipendente. Inoltre, tali conflitti vengono risolti molto più facilmente (spesso automaticamente) nei team in cui esiste un elevato livello di fiducia, le persone lavorano insieme da molto tempo e/o comunicano frequentemente al di fuori del lavoro.

Conflitti legati a questioni lavorative:

Tali conflitti sono solitamente causati da entrambi i motivi contemporaneamente, sia emotivi (il fatto che uno dei partecipanti non è nella posizione di un adulto) sia dall'imperfezione del processo lavorativo stesso. Forse il tipo più comune di conflitti che ho riscontrato sono i conflitti durante le revisioni del codice o le discussioni sull'architettura tra sviluppatori.

Vorrei evidenziare qui due casi tipici:

1) Nel primo caso lo sviluppatore non può ottenere una revisione del codice da un collega. La patch viene inviata per la revisione e non succede nulla. A prima vista, non c’è alcun conflitto evidente tra le due parti, ma se ci pensi, è un vero conflitto. La questione lavorativa non è risolta, una delle parti (in attesa di una revisione) avverte un evidente disagio. Un sottotipo estremo di questo caso è lo sviluppo in una comunità o in team diversi, mentre il revisore potrebbe non essere interessato a questo particolare codice, a causa del caricamento o di altre circostanze, potrebbe non prestare alcuna attenzione alla richiesta di revisione e l'arbitro esterno (un manager comune ad entrambe le parti)) potrebbe non esistere affatto.

L'approccio risolutivo che aiuta in una situazione del genere riguarda proprio la prospettiva a lungo termine, la cultura di un adulto. Innanzitutto, l’attività intelligente funziona. Non dovresti aspettarti che il codice appeso alla recensione attiri l'attenzione del revisore stesso. Dobbiamo aiutare i revisori a notarlo. Pingani un paio di persone, fanno una domanda sul sincope, partecipano alle discussioni. Ovviamente, l'importunità ha più probabilità di nuocere che di aiutare, è necessario usare il buon senso. In secondo luogo, la pre-preparazione funziona bene. Se il team capisce cosa sta succedendo e perché, perché questo codice è necessario, se il progetto è stato discusso e concordato in anticipo con tutti, è più probabile che le persone prestino attenzione a tale codice e lo accettino per lavoro. In terzo luogo, l’autorità funziona. Se vuoi essere recensito, fai molte recensioni tu stesso. Esegui revisioni di alta qualità, con controlli reali, test reali e commenti utili. Se il tuo nickname è ben noto nel team, ci sono maggiori possibilità che il tuo codice venga notato.

Dal punto di vista del flusso di lavoro, i possibili miglioramenti qui sono la corretta definizione delle priorità volta ad aiutare lo sviluppatore a raggiungere gli obiettivi suoi e del team (recensire gli altri, scrivere lettere alla comunità, accompagnare il codice con una descrizione dell'architettura, documentazione, test, partecipare a discussioni con community, ecc.), evitare che le patch rimangano in coda per troppo tempo e così via.

2) Il secondo caso comune di conflitti durante le revisioni del codice o della progettazione sono i diversi punti di vista su questioni tecniche, stile di codifica e scelta degli strumenti. Di grande importanza in questo caso è il livello di fiducia tra i partecipanti, appartenenti allo stesso team, e l'esperienza di lavoro insieme. Un vicolo cieco si verifica quando uno dei partecipanti assume una posizione infantile e non cerca di ascoltare ciò che l'interlocutore vuole trasmettergli. Spesso sia l'approccio proposto dall'altra parte che quello proposto inizialmente possono funzionare con successo e in linea di principio non ha importanza quale scegliere.

Un giorno un programmatore del mio team (chiamiamolo Pasha) ha preparato una patch con modifiche al sistema di distribuzione dei pacchetti, che è stata sviluppata e supportata da colleghi di un dipartimento vicino. Uno di loro (Igor) aveva la sua forte opinione su come esattamente dovrebbero essere configurati i servizi Linux durante la distribuzione dei pacchetti. Questa opinione differiva dall'approccio proposto nella patch e non potevano essere d'accordo. Come al solito, i termini scadevano ed era necessario prendere una decisione; era necessario che uno di loro assumesse una posizione adulta. Pasha riconosceva che entrambi gli approcci davano diritto alla vita, ma voleva che la sua opzione passasse, perché Né l'una né la seconda opzione presentavano evidenti vantaggi tecnici.

La nostra discussione è stata più o meno questa (in modo molto schematico, ovviamente, la conversazione è durata mezz'ora):

- Pasha, tra pochi giorni avremo un blocco delle funzionalità. È importante mettere tutto insieme e iniziare i test il prima possibile. Come possiamo superare Igor?
— Vuole impostare i servizi in modo diverso, mi ha lasciato dei commenti...
- E cosa c'è, grandi cambiamenti, tanto clamore?
- No, c'è lavoro per un paio d'ore, ma alla fine non c'è differenza, funzionerà comunque, perché è necessario? Ho fatto qualcosa che funziona, accettiamolo.
- Ascolta, da quanto tempo discutete di tutto questo?
- Sì, stiamo segnando il passo ormai da una settimana e mezza.
- Uhm... possiamo risolvere in un paio d'ore un problema che ha già richiesto una settimana e mezza, e non farlo?
- Ebbene sì, ma non voglio che Igor pensi che ho ceduto...
- Ascolta, cosa è più importante per te, rilasciare un rilascio, insieme alla tua decisione all'interno, o uccidere Igor? Possiamo bloccarlo, ma poi ci sono buone possibilità di portare a termine il rilascio.
- Beh... sarebbe bello, ovviamente, pulire il naso di Igor, ma va bene, la liberazione è più importante, sono d'accordo.
- È davvero così importante per te quello che pensa Igor? Ad essere onesti, non gliene frega niente, vuole solo un approccio unificato in diversi punti della cosa di cui è responsabile.
- Bene, ok, lasciami fare quello che chiede nei commenti e iniziamo a testare.
- Grazie, Pascià! Ero sicuro che tra voi due sareste stato il più maturo, anche se Igorek è più vecchio di voi :)

Il problema è stato risolto, il rilascio è stato rilasciato in tempo, Pasha non si è sentito molto insoddisfatto, perché lui stesso ha proposto una soluzione e l'ha implementata. Igor era generalmente soddisfatto, perché... La sua opinione è stata presa in considerazione e hanno fatto come aveva suggerito.

Un altro tipo di conflitto essenzialmente identico è la scelta tra soluzioni tecniche/biblioteche/approcci in un progetto, soprattutto in un team distribuito. In uno dei progetti, che veniva pubblicizzato come C/C++, si è scoperto che la direzione tecnica del progetto era categoricamente contraria all'utilizzo di STL (Standard Template Library). Questa è una libreria di linguaggi standard che semplifica lo sviluppo e il nostro team è molto abituato a ciò. Si è scoperto che il progetto è molto più vicino al C che al C++, il che non ha ispirato molto il team, perché la direzione ha fatto del suo meglio e ha reclutato giocatori davvero fantastici. Allo stesso tempo, la parte americana del team, sia ingegneri che manager, lavorava in azienda da molto tempo, era abituata alla situazione esistente ed era contenta di tutto. La parte russa della squadra si è riunita abbastanza recentemente, nel giro di poche settimane (me compreso). La parte russa del team non ha voluto categoricamente abbandonare il solito approccio allo sviluppo.

Tra i due continenti iniziarono interminabili discussioni scritte, lettere su tre o quattro schermi volavano avanti e indietro, in mailing di gruppo e personali, da programmatori a programmatori e manager. Come di solito accade, lettere di questa lunghezza non furono lette da nessuno tranne gli autori e i loro ardenti sostenitori. Le chat scricchiolavano di tensione, scambiandosi pensieri multischermo in direzioni diverse riguardo ai vantaggi tecnici dell'STL, quanto è ben testato, quanto è sicuro e, in generale, quanto è meravigliosa la vita con esso e quanto è terribile senza di esso .

Tutto ciò durò parecchio tempo, finché finalmente mi resi conto che stavamo discutendo degli aspetti tecnici della questione, ma in realtà il problema non era tecnico. Il problema non sono i vantaggi o gli svantaggi di STL o la difficoltà di lavorare senza di esso. Il problema è piuttosto organizzativo. Avevamo solo bisogno di capire come funzionava l’azienda per cui lavoravamo. Nessuno di noi aveva mai lavorato in un'azienda del genere. Il fatto è che dopo che il codice è stato sviluppato e messo in produzione, il supporto è stato gestito da persone completamente diverse provenienti da altri team, da altri paesi. Questo enorme team di ingegneri composto da diverse decine di migliaia di ingegneri (in totale) poteva permettersi solo un minimo di mezzi tecnici assolutamente basilari, per così dire, un minimo minimo. Tutto ciò che andava oltre lo standard ingegneristico stabilito fisicamente in azienda non poteva essere supportato in futuro. Il livello di una squadra è determinato dal livello dei suoi membri più deboli. Dopo che abbiamo capito vera motivazione azioni della parte americana del team, questo problema è stato rimosso dall'ordine del giorno e insieme abbiamo sviluppato e rilasciato con successo il prodotto utilizzando gli standard adottati dall'azienda. Lettere e chiacchierate in questo caso non hanno funzionato bene; ci sono voluti diversi viaggi e molta comunicazione personale per arrivare ad un denominatore comune.

Dal punto di vista del flusso di lavoro, in questo caso particolare, sarebbe utile avere una descrizione degli strumenti utilizzati, i relativi requisiti, le restrizioni sull'aggiunta di nuovi e la giustificazione di tali restrizioni. Tali documenti corrispondono grosso modo a quelli descritti nei paragrafi Strategia di riuso e Ambiente di sviluppo del “Manuale del manager per lo sviluppo del software”, sviluppato in NASA. Nonostante l'età, descrive perfettamente tutte le principali attività e fasi progettuali dello sviluppo di software di questo tipo. Avere documenti come questo rende molto facile discutere quali componenti e approcci possono essere utilizzati in un prodotto e perché.

Da un punto di vista culturale, ovviamente, con una posizione più matura, in cui le parti cercano di ascoltare e comprendere le reali motivazioni delle azioni dei colleghi e agiscono in base alle priorità del progetto e del team, e non all'ego personale , il conflitto verrebbe risolto più facilmente e rapidamente.

Anche in un altro conflitto sulla scelta di una soluzione tecnica, mi ci è voluto molto tempo per comprendere la motivazione di una delle parti (era un caso molto insolito), ma dopo che la motivazione era chiara, la soluzione era ovvia.

La situazione è questa: in un team di circa 20 persone appare un nuovo sviluppatore, chiamiamolo Stas. A quel tempo, il nostro strumento standard per la comunicazione in squadra era Skype. Come si è scoperto in seguito, Stas era un grande fan degli standard aperti e del software open source e utilizzava solo strumenti e sistemi operativi le cui fonti erano disponibili pubblicamente e che utilizzavano protocolli descritti pubblicamente. Skype non è uno di questi strumenti. Abbiamo trascorso molto tempo a discutere i vantaggi e gli svantaggi di questo approccio, i tentativi di lanciare analoghi di Skype su diversi sistemi operativi, i tentativi di Stas di convincere il team a passare ad altri standard, scrivergli personalmente per posta, chiamarlo personalmente al numero telefono, compragli un secondo computer appositamente per Skype, ecc. Alla fine, mi sono reso conto che questo problema, in sostanza, non è tecnico o organizzativo, è piuttosto ideologico, anche, si potrebbe dire, religioso (per Stas). Anche se alla fine collegassimo Stas e Skype (cosa che ha richiesto diversi mesi), il problema si ripresenterebbe su qualsiasi strumento successivo. Non avevo mezzi reali a mia disposizione per cambiare la visione del mondo di Stas, e non c'era motivo di provare a cambiare la visione del mondo di una squadra che funzionava perfettamente in questo ambiente. La persona e l'azienda erano semplicemente ortogonali nella loro visione del mondo. In tali situazioni, una buona soluzione è organizzativa. Abbiamo trasferito Stas in un'altra squadra, dove era più organico.

La ragione di questo conflitto, secondo me, è la discrepanza tra la cultura personale di una determinata persona (che ha un'opinione forte che non gli consente di scendere a compromessi) e la cultura dell'azienda. In questo caso, ovviamente, l'errore del manager. Inizialmente è stato sbagliato assumerlo per un progetto del genere. Alla fine Stas passò a un progetto di sviluppo di software open source e lì eccelleva.

Un buon esempio di conflitto causato sia dall'atteggiamento infantile dello sviluppatore che dalle carenze del processo di lavoro è una situazione in cui, in assenza di una definizione di fatto, lo sviluppatore e il team di QA hanno aspettative diverse riguardo alla preparazione del lavoro. la funzionalità trasferita al QA. Lo sviluppatore credeva che fosse sufficiente scrivere il codice e lanciare la funzionalità oltre il recinto al QA: avrebbero risolto la questione lì. Un programmatore abbastanza maturo ed esperto, tra l'altro, ma quella era la sua soglia interna di qualità. Il QA non è stato d'accordo con questo e ha chiesto di mostrare e descrivere loro ciò che aveva controllato personalmente, e ha chiesto loro uno script di test. In passato avevano avuto problemi con le funzionalità di questo sviluppatore e non volevano perdere di nuovo tempo. A proposito, avevano ragione: la funzione non funzionava davvero, non ha controllato il codice prima di inviarlo al QA.

Per risolvere la situazione, gli ho chiesto di mostrarmi che tutto funzionava davvero (non funzionava e doveva aggiustarlo), abbiamo parlato con il team e con la definizione di fatto del QA (non ce l'hanno fatta scrivendo, perché non volevamo rendere il processo troppo burocratico), ebbene, ci siamo presto separati da questo specialista (con sollievo generale).

Dal punto di vista del flusso di lavoro, i possibili miglioramenti in questo caso sono la presenza di una definizione di done, requisiti per il supporto di ciascuna funzionalità dell'unità e test di integrazione e una descrizione dei test eseguiti dallo sviluppatore. In uno dei progetti, abbiamo misurato il livello di copertura del codice mediante test durante la CI e se il livello di copertura diminuiva dopo l'aggiunta di una patch, i test venivano contrassegnati come falliti, ovvero qualsiasi nuovo codice potrebbe essere aggiunto solo se ci fossero nuovi test per esso.

Un altro tipico esempio di conflitto strettamente legato all'organizzazione del processo lavorativo. Abbiamo un prodotto, un team di sviluppo prodotto, un team di supporto e un cliente. Il cliente ha problemi con il prodotto e contatta l'assistenza. Il supporto analizza il problema e capisce che il problema è nel prodotto e trasferisce il problema al team del prodotto. Il team del prodotto è in un momento impegnativo, si avvicina un rilascio, quindi un ticket con un problema di un cliente, perso tra gli altri ticket dello sviluppatore a cui è assegnato, rimane sospeso per diverse settimane senza attenzione. Il supporto ritiene che lo sviluppatore stia lavorando al problema del cliente. Il cliente aspetta e spera che il suo problema venga risolto. In realtà non sta ancora accadendo nulla. Dopo alcune settimane, il cliente decide finalmente di interessarsi allo stato di avanzamento e chiede supporto su come stanno andando le cose. Il supporto richiede sviluppo. Lo sviluppatore rabbrividisce, esamina l'elenco dei ticket e trova lì un ticket del cliente. Leggendo un ticket di un cliente, capisce che non ci sono abbastanza informazioni per risolvere il problema e ha bisogno di più log e dump. Il supporto richiede ulteriori informazioni al cliente. E poi il cliente si rende conto che nessuno ha lavorato al suo problema per tutto questo tempo. E il tuono colpirà...

In questa situazione, la soluzione al conflitto stesso è abbastanza ovvia e lineare (correggere il prodotto, aggiornare la documentazione e i test, accontentare il cliente, rilasciare un hotfix, ecc.). È importante analizzare il processo di lavoro e capire chi è responsabile dell'organizzazione dell'interazione tra i due team e perché questa situazione è diventata possibile in primo luogo. Ciò che deve essere risolto nel processo è chiaro: qualcuno deve monitorare il quadro generale senza solleciti da parte dei clienti, in modo proattivo. I ticket del cliente dovrebbero distinguersi tra gli altri ticket degli sviluppatori. Il supporto dovrebbe vedere se il team di sviluppo sta attualmente lavorando sui suoi ticket e, in caso negativo, quando potrà iniziare a lavorare e quando si possono prevedere i risultati. Il supporto e lo sviluppo dovrebbero comunicare e discutere periodicamente lo stato dei ticket, la raccolta delle informazioni necessarie per il debug dovrebbe essere automatizzata il più possibile, ecc.

Proprio come in guerra il nemico cerca di colpire l'incrocio tra due unità, così nel lavoro il punto più delicato e vulnerabile è solitamente l'interazione tra le squadre. Se i responsabili del supporto e dello sviluppo sono abbastanza grandi, saranno in grado di sistemare il processo da soli, altrimenti il ​​processo continuerà a generare conflitti e problemi finché non interverrà un manager che possa risolvere la situazione.

Un altro tipico esempio che ho visto ripetutamente in diverse aziende è una situazione in cui un prodotto è scritto da un team, i test di integrazione automatica sono scritti da un secondo team e l'infrastruttura su cui tutto viene gestito è accompagnata da un terzo squadra. Problemi durante l'esecuzione dei test sorgono continuamente e la causa dei problemi può essere sia il prodotto che i test e l'infrastruttura. Di solito è problematico concordare chi dovrebbe eseguire l'analisi iniziale dei problemi, dei bug dei file, dei log di analisi del prodotto, dei test e dell'infrastruttura, ecc. I conflitti qui sono molto frequenti e, allo stesso tempo, uniformi. In caso di elevata intensità emotiva, i partecipanti spesso cadono in una posizione infantile e iniziano le discussioni in serie: "perché dovrei armeggiare con questo", "si rompono più spesso", ecc.

Dal punto di vista del flusso di lavoro, i passaggi specifici per risolvere un problema dipendono dalla composizione dei team, dal tipo di test e di prodotto, ecc. In uno dei progetti abbiamo introdotto un servizio periodico, in cui i team monitoravano i test uno alla volta, settimana per settimana. Nell'altro, l'analisi iniziale è stata sempre eseguita dagli sviluppatori del test, ma l'analisi era molto elementare e il prodotto era abbastanza stabile, quindi ha funzionato bene. La chiave è garantire che il processo sia trasparente, che le aspettative siano chiare per tutte le parti e che la situazione sia giusta per tutti.

Il conflitto è addirittura un problema in un'organizzazione? È un brutto segno il fatto che i conflitti si verifichino spesso (o solo periodicamente) nel tuo team? In generale, no, perché se c'è crescita, sviluppo, c'è qualche tipo di dinamica, allora sorgono problemi che non sono mai stati risolti prima e, quando li risolvono, possono sorgere conflitti. Questo è un indicatore del fatto che alcune aree necessitano di attenzione, che ci sono aree di miglioramento. È un male se i conflitti sorgono molto spesso, sono difficili da risolvere o richiedono molto tempo. Questo è molto probabilmente un segno di processi di lavoro non sufficientemente snelliti e di un’insufficiente maturità del team.

Fonte: habr.com