<\/a><\/noindex>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: \u201cEhi, ragazzo, di che zona sei?!\u201d per strada, o il conflitto menzionato nell'epigrafe. Nel caso di una questione lavorativa, sono importanti la qualit\u00e0 del processo lavorativo e la cultura della risoluzione dei problemi nel team.<\/p>\n
In terzo luogo, un fattore determinante del conflitto (dal punto di vista della nostra discussione) \u00e8 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\u00f2 sembrare controverso, ma in sostanza, se una situazione conflittuale si risolve con successo senza l'intervento di un arbitro esterno, se la questione \u00e8 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 \u00e8 stato risolto. Pi\u00f9 domande il team \u00e8 in grado di risolvere autonomamente, pi\u00f9 efficacemente lavorer\u00e0.<\/p>\n
Un altro aspetto caratteristico del conflitto di cui vale la pena parlare \u00e8 il grado di intensit\u00e0 emotiva durante la risoluzione. Un conflitto non \u00e8 necessariamente accompagnato da un alto grado di emozioni. I partecipanti non devono necessariamente urlare e agitare le mani affinch\u00e9 la situazione possa essere considerata sostanzialmente conflittuale. Se la questione non viene risolta e c'\u00e8 una certa tensione emotiva presente (anche se non espressa apertamente), allora ci troviamo di fronte a una situazione di conflitto.<\/p>\n
\u00c8 necessario intervenire nelle situazioni di conflitto, o \u00e8 meglio lasciare che la loro soluzione fluisca da s\u00e9 e aspettare che il problema si risolva da solo? S\u00ec. Non sempre \u00e8 nelle vostre possibilit\u00e0 o competenze risolvere completamente un conflitto, ma in ogni situazione, in un conflitto di qualsiasi scala, potete assumere una posizione adulta, coinvolgendo cos\u00ec altre persone intorno a voi, attenuare le conseguenze negative del conflitto e contribuire alla sua soluzione.<\/p>\n
Prima di esaminare alcuni esempi di situazioni di conflitto, fermiamoci su alcuni punti importanti, comuni a tutti i conflitti.<\/p>\n
Quando si risolve un conflitto, \u00e8 importante rimanere al di sopra della mischia, e non all'interno di essa (questo \u00e8 conosciuto anche come \u201cassumere una metapositiva\u201d), cio\u00e8, 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. \u00c8 fondamentale che la decisione venga accettata moralmente da tutte le parti, come si suol dire, \u201cacquistata\u201d. Affinch\u00e9, 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\u00e0 semplicemente forma, il fuoco smouldering rimarr\u00e0 sotto il torbido e a un certo punto si riaccender\u00e0 inevitabilmente.<\/p>\n
Il secondo punto, parzialmente legato al primo, \u00e8 che se hai deciso di partecipare alla risoluzione del conflitto, affrontalo con la massima seriet\u00e0 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\u00e9 lo vuole, quali sono le aspettative, se hanno cercato di risolvere prima questa questione, cosa succeder\u00e0 se non viene risolta, quali soluzioni vedono, come immaginano la posizione dell'altra parte, cosa ritengono giusto o sbagliato, e cos\u00ec 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 \u00e8 accessibile solo nella conversazione via email, leggi almeno l'intera discussione e i documenti ad essa relativi. Dopo aver letto, parla comunque a voce. \u00c8 quasi garantito che sentirai qualcosa di importante che non \u00e8 nelle email.<\/p>\n
Il terzo punto importante \u00e8 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\u00e0 di mantenere la dignit\u00e0, conduciamo discussioni di persona, non davanti a un gruppo.<\/p>\n
I conflitti sono solitamente causati da una delle due ragioni. La prima \u00e8 legata al fatto che la persona coinvolta nel conflitto si trovi in una posizione adulta o infantile (di questo parleremo pi\u00f9 avanti). Ci\u00f2 \u00e8 legato alla sua maturit\u00e0 emotiva, alla capacit\u00e0 di gestire le proprie emozioni (il che, per inciso, non \u00e8 sempre collegato all'et\u00e0). La seconda causa comune \u00e8 l'imperfezione del processo lavorativo, che crea situazioni di zone grigie, in cui la responsabilit\u00e0 \u00e8 dispersa tra i partecipanti, le aspettative delle parti non sono chiare l'una per l'altra, i ruoli nel processo sono sfumati. <\/p>\n
Pertanto, nel risolvere un conflitto (come qualsiasi altra questione), un manager deve tenere a mente tre prospettive: a breve termine \u2014 risolvere la questione\/conflitto qui e ora, a medio termine \u2014 ridurre la probabilit\u00e0 di un altro conflitto per la stessa ragione e a lungo termine \u2014 coltivare una cultura dell\u2019adulto all'interno del team. <\/p>\n
Dentro ognuno di noi c'\u00e8 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\u00e0. \u00c8 importante per lui insistere sul fatto che questa \u00e8 la sua sabbiera, che la mamma lo ama di pi\u00f9, che la sua macchina \u00e8 la migliore (il design \u00e8 il migliore, programma meglio di chiunque altro, ...). In situazioni di conflitto, il bambino pu\u00f2 stringere i giocattoli, battere i piedi e colpire con la paletta, ma non \u00e8 in grado di risolvere questioni da adulto (architettura della soluzione, approcci ai test automatici, scadenze di rilascio, ecc.), non pensa in termini di utilit\u00e0 per il team. Il bambino in conflitto pu\u00f2 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 \u00e8 risolvere una questione seria, sei nella posizione di un adulto. Se il tuo obiettivo \u00e8 battere i piedi e colpire con la paletta, allora questa \u00e8 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\u00e0 infantili, non sar\u00e0 ottimale.<\/p>\n
Oltre al comportamento durante un conflitto, la posizione di un bambino o di un adulto \u00e8 caratterizzata anche dal livello di responsabilit\u00e0 che la persona \u00e8 disposta a prendersi. In manifestazioni estreme, la posizione infantile di un programmatore, che ho incontrato pi\u00f9 volte, si presenta cos\u00ec: ho scritto il codice, l'ho inviato per la revisione \u2014 il mio lavoro \u00e8 finito. I revisori devono esaminarlo e approvarlo, il QA deve verificarlo, se ci sono problemi \u2014 mi avviseranno. Stranamente, anche persone piuttosto adulti ed esperti a volte si comportano in questo modo. L'altro estremo della scala \u00e8 una persona che si sente responsabile affinch\u00e9 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\u00f9 vicino all'estremit\u00e0 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.<\/p>\n
Coltivare nella squadra una cultura corretta e adulta \u00e8 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\u00e0 riferimento, il team guarda sempre al leader) e discutere e incoraggiare il comportamento corretto. Anche qui non c'\u00e8 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.<\/p>\n
Consideriamo alcune situazioni conflittuali tipiche, dal semplice al complesso:<\/p>\n
Conflitti non correlati a questioni di lavoro<\/b><\/p>\n
Molto spesso si verificano conflitti sul lavoro che non sono legati a questioni di lavoro. La loro insorgenza e la facilit\u00e0 di risoluzione sono solitamente collegate direttamente al livello di intelligenza emotiva dei partecipanti, al loro livello di maturit\u00e0 e non alla perfezione o imperfezione del processo lavorativo.<\/p>\n
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 \u00e8 troppo rumoroso, mentre gli altri hanno bisogno di silenzio per lavorare, e cos\u00ec via. \u00c8 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 \u00e8 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\u00ec via. <\/p>\n
Un altro esempio che mi \u00e8 capitato di incontrare pi\u00f9 volte durante il mio lavoro \u00e8 la compatibilit\u00e0 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\u00f2 \u00e8 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 \u00e8 un compito piuttosto senza speranza. L'unica eccezione che ho riscontrato sono stati i giovani colleghi con una mentalit\u00e0 aperta, il cui comportamento pu\u00f2 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\u00e0 di incrociarsi raramente per lavoro.<\/p>\n
In tutte le situazioni descritte, \u00e8 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.<\/p>\n
Dal punto di vista dell'ottimizzazione del processo lavorativo (prospettiva a medio termine di cui ho parlato), non si pu\u00f2 fare molto, l'unico aspetto da ottimizzare \u00e8 considerare il fattore di compatibilit\u00e0 durante la formazione del team e non riunire anticipatamente persone che entreranno in conflitto. <\/p>\n
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\u00f9 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.<\/p>\n
Conflitti legati a questioni lavorative:<\/b><\/p>\n
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\u00f9 comune di conflitti che ho incontrato sono stati quelli durante il processo di revisione del codice o le discussioni sulla architettura tra sviluppatori. <\/p>\n
Vorrei evidenziare qui due casi tipici:<\/p>\n
1) Nel primo caso, uno sviluppatore non riesce a ottenere la revisione del codice da un collega. Il patch \u00e8 stato inviato per la revisione, ma non succede nulla. A prima vista, non c'\u00e8 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 \u00e8 lo sviluppo in comunit\u00e0 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). <\/p>\n
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\u00e0 razionale. Non ci si deve aspettare che il codice in attesa di revisione attiri da solo l'attenzione del revisore. \u00c8 necessario aiutare i revisori a notarlo. Contatta un paio di persone, fai una domanda nello sync-up, partecipa alle discussioni. \u00c8 evidente che la fastidiosit\u00e0 tende a danneggiare piuttosto che aiutare, quindi \u00e8 necessario usare il buon senso. In secondo luogo, una preparazione preliminare funziona bene. Se il team comprende cosa e perch\u00e9 sta accadendo, perch\u00e9 quel codice \u00e8 necessario, se il design \u00e8 stato discusso e concordato in anticipo con tutti, le persone saranno pi\u00f9 propense a notare quel codice e ad accettarlo. In terzo luogo, funziona l'autorit\u00e0. Se desideri che il tuo codice venga revisionato, fai molte revisioni tu stesso. Fai revisioni di qualit\u00e0, con controlli reali, test reali, commenti utili. Se il tuo nickname \u00e8 conosciuto nel team in modo positivo, ci sono maggiori probabilit\u00e0 che venga prestata attenzione al tuo codice.<\/p>\n
Dal punto di vista del flusso di lavoro, i possibili miglioramenti qui sono una corretta assegnazione delle priorit\u00e0, volta ad aiutare lo sviluppatore a raggiungere i propri obiettivi e quelli del team (fare revisioni per gli altri, scrivere lettere nella comunit\u00e0, accompagnare il codice con descrizioni architetturali, documentazione, test, partecipare a discussioni con la comunit\u00e0, ecc.), evitare che i patch rimangano troppo a lungo in coda, e cos\u00ec via. <\/p>\n
2) Il secondo caso comune di conflitti durante la revisione del codice o del design \u00e8 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. <\/p>\n
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\u00e9 non c'erano vantaggi tecnici evidenti n\u00e9 nell'uno n\u00e9 nell'altro. <\/p>\n
La nostra discussione \u00e8 andata pi\u00f9 o meno cos\u00ec (in modo molto schematico, ovviamente, la conversazione \u00e8 durata mezz'ora): <\/p>\n
\u2014 Pasha, tra pochi giorni abbiamo il feature freeze. \u00c8 importante che raccogliamo tutto e iniziamo i test il prima possibile. Come possiamo superare Igor?
La questione \u00e8 stata risolta, il rilascio \u00e8 avvenuto nei tempi stabiliti, Pasha non ha manifestato un particolare discontento, poich\u00e9 \u00e8 stato lui a proporre la soluzione e a realizzarla. Igor, in generale, era soddisfatto, poich\u00e9 la sua opinione \u00e8 stata presa in considerazione e hanno fatto come lui aveva suggerito.<\/p>\n
Un altro tipo di conflitto simile \u00e8 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 \u00e8 scoperto che la gestione tecnica del progetto era categoricamente contraria all'uso di STL (Standard Template Library). Questa \u00e8 una libreria standard del linguaggio che semplifica lo sviluppo, la nostra squadra ci era molto abituata. Si \u00e8 rivelato che il progetto era molto pi\u00f9 vicino a C che a C++, il che non ispirava molto la squadra, poich\u00e9 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 \u00e8 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.<\/p>\n
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. <\/p>\n
\u00c8 durata piuttosto a lungo, fino a quando non ho finalmente capito che stavamo discutendo degli aspetti tecnici del problema, mentre il problema in realt\u00e0 non era tecnico. Non si trattava dei pro e dei contro dello STL o della difficolt\u00e0 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\u00ec dire, il minimum minimorum. Tutto ci\u00f2 che andava oltre lo standard ingegneristico stabilito in azienda non poteva essere supportato in seguito. Il livello di una squadra \u00e8 definito dal livello dei suoi membri pi\u00f9 deboli. Dopo aver capito la motivazione reale<\/i> delle azioni della parte americana del team, questa questione \u00e8 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.<\/p>\n
Dal punto di vista del flusso di lavoro, in questo caso specifico, sarebbe utile avere una descrizione degli strumenti utilizzati, i requisiti per essi, le limitazioni nell'aggiunta di nuovi strumenti e una giustificazione di tali limitazioni. Questi documenti corrispondono approssimativamente a quelli descritti nei punti Reuse Strategy e Development Environment del manuale \u201cManager's Handbook for Software Development\u201d, sviluppato in NASA<\/a><\/noindex>. Nonostante la sua et\u00e0, descrive perfettamente tutte le principali attivit\u00e0 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\u00e9.<\/p>\nDal punto di vista culturale, \u00e8 chiaro che con una prospettiva pi\u00f9 matura, in cui le parti cercano di ascoltare e comprendere la reale motivazione delle azioni dei colleghi e agire in base alle priorit\u00e0 del progetto e del team, e non all'ego personale, il conflitto si sarebbe risolto pi\u00f9 facilmente e rapidamente.<\/p>\n
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 \u00e8 diventata ovvia. <\/p>\n
La situazione \u00e8 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 \u00e8 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 \u00e8 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\u00ec via. Alla fine ho capito che il problema non era sostanzialmente n\u00e9 tecnico n\u00e9 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\u00e0 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\u00e0 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 \u00e8 di tipo organizzativo. Abbiamo trasferito Stas in un altro team, dove era pi\u00f9 integrato.<\/p>\n
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. \u00c8 stata una scelta inizialmente errata quella di coinvolgerlo in un progetto di questo tipo. Alla fine, Stas \u00e8 passato a un progetto di sviluppo di software open source e ha avuto grande successo.<\/p>\n
Un buon esempio di conflitto, causato dalla posizione infantile dello sviluppatore e dalle carenze nel processo di lavoro, \u00e8 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\u00e0 inviata al QA. Lo sviluppatore pensava che fosse sufficiente scrivere il codice e passarla al QA - l\u00ec si sarebbero sistemati. \u00c8 un programmatore piuttosto maturo ed esperto, ma questo era il suo limite interno di qualit\u00e0. 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\u00e0 avuto problemi in passato con la funzionalit\u00e0 di questo sviluppatore e non volevano sprecare tempo inutilmente una seconda volta. A proposito, avevano ragione: la funzionalit\u00e0 non funzionava, e non aveva controllato il codice prima di passarla al QA. <\/p>\n
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\u00e9 non volevamo burocratizzare eccessivamente il processo), e con questo specialista ci siamo presto separati (con sollievo generale).<\/p>\n
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\u00e0 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. <\/p>\n
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 \u00e8 un problema del prodotto, quindi lo passa al team di prodotto. Il team di prodotto \u00e8 in un periodo di intensa attivit\u00e0, il rilascio \u00e8 imminente, quindi il ticket con il problema del cliente, perso tra gli altri ticket dello sviluppatore a cui \u00e8 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\u00e0, 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\u00e0 una tempesta...<\/p>\n
In questa situazione, la soluzione del conflitto stesso \u00e8 piuttosto ovvia e lineare (riparare il prodotto, aggiornare la documentazione e i test, placare il cliente, rilasciare un hotfix, ecc.). \u00c8 importante analizzare il processo di lavoro e capire chi \u00e8 responsabile per l'organizzazione dell'interazione tra i due team e perch\u00e9 una situazione del genere sia stata possibile. \u00c8 chiaro che \u00e8 necessario apportare delle modifiche al processo: qualcuno deve monitorare la situazione complessiva senza necessit\u00e0 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\u00e0 iniziare a lavorare e quando si pu\u00f2 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\u00f9 automatizzata possibile, ecc.<\/p>\n
Come in guerra il nemico cerca di colpire nel punto di giunzione tra due reparti, cos\u00ec nel lavoro il punto pi\u00f9 delicato e vulnerabile \u00e8 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\u00e0 a generare conflitti e problemi fino all'intervento di un manager in grado di risolvere la situazione.<\/p>\n
Un altro esempio caratteristico che ho riscontrato pi\u00f9 volte in diverse aziende \u00e8 la situazione in cui un prodotto \u00e8 sviluppato da un team, i test di integrazione automatizzati da un secondo team, mentre l'infrastruttura su cui tutto ci\u00f2 \u00e8 gestito \u00e8 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\u00ec 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: \u201cperch\u00e9 dovrei occuparmi di questo?\u201d, \u201cloro hanno pi\u00f9 guasti\u201d, ecc. <\/p>\n
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 \u00e8 garantire la trasparenza del processo, la chiarezza delle aspettative per tutte le parti coinvolte e un senso di equit\u00e0 nella situazione per tutti.<\/p>\n
\u00c8 un problema il conflitto all'interno di un'organizzazione? \u00c8 un cattivo segno se ci sono conflitti frequenti (o anche solo periodici) nel tuo team? In generale, no, poich\u00e9 se c'\u00e8 crescita, sviluppo e dinamismo, sorgono questioni che non sono mai state risolte prima e nella loro risoluzione possono emergere conflitti. Questo \u00e8 un indicatore che ci sono aree che necessitano di attenzione e possibilit\u00e0 di miglioramento. \u00c8 negativo se i conflitti si verificano molto spesso, se sono difficili o lunghi da risolvere. Questo \u00e8 probabilmente un segno di processi di lavoro non sufficientemente ottimizzati e di una maturit\u00e0 insufficiente del team.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u042d\u043f\u0438\u0433\u0440\u0430\u0444: \u0412\u0441\u0442\u0440\u0435\u0442\u0438\u043b\u0438\u0441\u044c \u043a\u0430\u043a-\u0442\u043e \u0432 \u043b\u0435\u0441\u0443 \u0401\u0436\u0438\u043a \u0438 \u041c\u0435\u0434\u0432\u0435\u0436\u043e\u043d\u043e\u043a. \u2014 \u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439, \u0401\u0436\u0438\u043a! \u2014 \u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439, \u041c\u0435\u0434\u0432\u0435\u0436\u043e\u043d\u043e\u043a! \u0422\u0430\u043a, \u0441\u043b\u043e\u0432\u043e \u0437\u0430 \u0441\u043b\u043e\u0432\u043e, \u0448\u0443\u0442\u043a\u0430 \u0437\u0430 \u0448\u0443\u0442\u043a\u043e\u0439, \u0438 \u043f\u043e\u043b\u0443\u0447\u0438\u043b \u0401\u0436\u0438\u043a \u043e\u0442 \u041c\u0435\u0434\u0432\u0435\u0436\u043e\u043d\u043a\u0430 \u043f\u043e \u043c\u043e\u0440\u0434\u0435 \u2026 \u041f\u043e\u0434 \u043a\u0430\u0442\u043e\u043c \u0440\u0430\u0441\u0441\u0443\u0436\u0434\u0435\u043d\u0438\u044f \u043d\u0430\u0448\u0435\u0433\u043e \u0442\u0438\u043c\u043b\u0438\u0434\u0430, \u0430 \u0442\u0430\u043a\u0436\u0435 \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440\u0430 \u043f\u043e \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044e \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430 RAS \u2014 \u0418\u0433\u043e\u0440\u044f \u041c\u0430\u0440\u043d\u0430\u0442\u0430 \u043e \u0441\u043f\u0435\u0446\u0438\u0444\u0438\u043a\u0435 \u0440\u0430\u0431\u043e\u0447\u0438\u0445 \u043a\u043e\u043d\u0444\u043b\u0438\u043a\u0442\u043e\u0432 \u0438 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u044b\u0445 \u043c\u0435\u0442\u043e\u0434\u0430\u0445 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u0438\u043c\u0438. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043a\u043e\u043d\u0444\u043b\u0438\u043a\u0442\u043e\u0432, […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27283,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[702],"tags":[],"class_list":["post-36457","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"La](\"\/wp-content\/uploads\/2019\/07\/de379c9eedec8cecda6651b5339a0277.jpg\")