<\/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. Tuttavia, a causa della specificit\u00e0 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 \u00e8 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: \u201cEhi, amico, di che quartiere sei?\u201d per strada, o il conflitto menzionato nell'epigrafe. Nel caso di questioni lavorative, la qualit\u00e0 del processo lavorativo e la cultura della risoluzione delle questioni all'interno del team sono di fondamentale importanza.<\/p>\n
In terzo luogo, un fattore decisivo del conflitto (dal punto di vista della nostra discussione) \u00e8 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\u00f2 sembrare controverso, ma in sostanza, se la situazione conflittuale viene risolta con successo senza l'intervento di un arbitro esterno, significa che la questione \u00e8 stata risolta efficacemente e le relazioni tra le parti non sono deteriorate; \u00e8 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\u00f9 questioni una squadra \u00e8 in grado di risolvere autonomamente, pi\u00f9 efficacemente lavorer\u00e0.<\/p>\n
Un'altra caratteristica distintiva del conflitto che merita di essere affrontata \u00e8 il grado di intensit\u00e0 emotiva nella risoluzione. Un conflitto non \u00e8 necessariamente caratterizzato da un alto grado di emotivit\u00e0. I partecipanti non devono necessariamente urlare e agitare le mani affinch\u00e9 la situazione possa essere considerata conflittuale. Se una questione non viene risolta, e vi \u00e8 una certa tensione emotiva presente (anche se potrebbe non essere espressa in modo evidente), si tratta quindi di una situazione di conflitto.<\/p>\n
\u00c8 necessario intervenire in situazioni conflittuali, o \u00e8 meglio lasciare che la loro risoluzione avvenga da sola e aspettare che il problema si risolva? 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 adottare un atteggiamento maturo, portando con voi anche altre persone intorno a voi, attenuando le conseguenze negative del conflitto e contribuendo alla sua risoluzione.<\/p>\n
Prima di esaminare alcuni esempi di situazioni conflittuali, ci soffermeremo su alcuni aspetti importanti comuni a tutti i conflitti.<\/p>\n
Quando si tratta di risolvere un conflitto, \u00e8 fondamentale mantenere una posizione esterna piuttosto che schierarsi all'interno della lotta (questo \u00e8 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. \u00c8 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\u00e0 solo forma, una fiamma smorza rimarr\u00e0 sotto la torba e, prima o dopo, riapparir\u00e0 inevitabilmente.<\/p>\n
Un secondo aspetto, in parte collegato al primo, \u00e8 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\u00e9 lo desidera, quali aspettative ha, se ha gi\u00e0 provato a risolvere questa situazione in passato, cosa accadr\u00e0 se non verr\u00e0 risolta, quali soluzioni vedono, come percepiscono la posizione dell'altra parte, cosa credono sia giusto o sbagliato, e cos\u00ec 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 \u00e8 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. \u00c8 quasi garantito che sentirai qualcosa di importante che non \u00e8 presente nelle email.<\/p>\n
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.<\/p>\n
I conflitti sono solitamente causati da una delle due ragioni. La prima \u00e8 legata al fatto che una persona, in quel momento, si trova nella posizione di adulto o in quella di bambino (ne parler\u00f2 di seguito). Questo \u00e8 correlato alla sua maturit\u00e0 emotiva e alla capacit\u00e0 di gestire le proprie emozioni (che, tra l'altro, non \u00e8 sempre legata alla sua et\u00e0). La seconda ragione comune \u00e8 l'imperfezione del processo lavorativo, che crea situazioni di zone grigie, in cui la responsabilit\u00e0 \u00e8 sfumata tra i partecipanti, le aspettative delle parti non sono chiare l'una per l'altra e i ruoli nel processo sono indefiniti. <\/p>\n
Di conseguenza, nella risoluzione dei conflitti (come in qualsiasi altra questione), un manager deve considerare tre prospettive: quella a breve termine \u2014 risolvere il problema\/conflitto qui e ora, quella a medio termine \u2014 ridurre al minimo la probabilit\u00e0 di un altro conflitto per la stessa ragione, e quella a lungo termine \u2014 instillare una cultura di adultit\u00e0 nel team. <\/p>\n
In ognuno di noi c'\u00e8 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\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 macchinina \u00e8 la migliore (il design \u00e8 il migliore, programma meglio di tutti, ...). In una situazione di conflitto, il bambino pu\u00f2 stringere i giocattoli, battere i piedi e colpire con la paletta, ma non pu\u00f2 risolvere questioni da adulti (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, 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 \u00e8 risolvere una questione seria, sei nella posizione di una persona adulta. Se il tuo obiettivo \u00e8 sbattere i piedi e colpire con la paletta, questa \u00e8 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\u00e0 infantili, non sar\u00e0 ottimale.<\/p>\n
Oltre al comportamento in momenti di conflitto, la posizione di un bambino o di un adulto si caratterizza anche attraverso il livello di responsabilit\u00e0 che la persona \u00e8 disposta ad assumersi. Nelle espressioni estreme, la posizione 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 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\u00e0 della scala, c'\u00e8 chi si considera responsabile affinch\u00e9 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\u00e0 supportato, verranno descritti gli scenari di test, ecc. In genere, un programmatore si trova inizialmente pi\u00f9 vicino all'estremit\u00e0 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\u00e9 che per il team.<\/p>\n
Allevare una cultura giusta e matura all'interno del team \u00e8 una delle principali responsabilit\u00e0 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\u00e9 il team osserva sempre il leader) e discutere e incoraggiare i comportamenti appropriati. Anche qui non c'\u00e8 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\u00ec via.<\/p>\n
Esaminiamo alcune situazioni conflittuali tipiche, dalle pi\u00f9 semplici alle pi\u00f9 complesse:<\/p>\n
Conflitti non legati a questioni lavorative<\/b><\/p>\n
Spesso sul lavoro si verificano conflitti non legati a questioni lavorative. La loro insorgenza e facilit\u00e0 di risoluzione sono generalmente collegate al livello di intelligenza emotiva dei partecipanti, al loro grado di maturit\u00e0, e non sono correlate alla perfezione o imperfezione del processo lavorativo.<\/p>\n
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 \u00e8 troppo rumoroso, mentre gli altri necessitano di silenzio per lavorare, e cos\u00ec via. \u00c8 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 \u00e8 un grande problema affrontarli: \u00e8 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. <\/p>\n
Un altro esempio che ho incontrato pi\u00f9 volte durante il mio lavoro \u00e8 la discompatibilit\u00e0 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 \u00e8 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 \u00e8 un compito piuttosto futile. L'unica eccezione che ho riscontrato sono stati i giovani colleghi con una mentalit\u00e0 aperta, il cui comportamento pu\u00f2 essere modificato gradualmente tramite conversazioni periodiche. Di solito, la situazione si risolve con una separazione in diversi team, o almeno garantendo che hanno possibilit\u00e0 di incrociarsi raramente sul lavoro.<\/p>\n
In tutte le situazioni descritte, \u00e8 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.<\/p>\n
Dal punto di vista dell'ottimizzazione del flusso di lavoro (prospettiva a medio termine di cui ho parlato), non si pu\u00f2 fare molto qui; l'unico aspetto da ottimizzare \u00e8 considerare il fattore della compatibilit\u00e0 nella formazione del team e non mettere insieme in anticipo persone che entreranno in conflitto. <\/p>\n
Dal punto di vista della cultura del team, tali situazioni si verificano molto pi\u00f9 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\u00f9 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.<\/p>\n
Conflitti legati a questioni lavorative:<\/b><\/p>\n
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\u00f9 comune che ho incontrato sono i conflitti durante la revisione del codice o la discussione dell'architettura tra gli sviluppatori. <\/p>\n
Qui distinguerei due casi tipici:<\/p>\n
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). <\/p>\n
L'approccio alla soluzione che aiuta in una situazione del genere \u00e8 proprio legato a una prospettiva a lungo termine e alla cultura di un adulto. In primo luogo, \u00e8 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. \u00c8 ovvio che essere troppo insistente pu\u00f2 danneggiare pi\u00f9 di quanto aiuti, \u00e8 necessario usare il buon senso. In secondo luogo, una buona preparazione funziona bene. Se il team capisce cosa e perch\u00e9 sta succedendo, e perch\u00e9 quel codice \u00e8 necessario, e se il design \u00e8 stato discusso e concordato in anticipo con tutti, le persone saranno pi\u00f9 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\u00e0, con verifiche reali, test concreti e commenti utili. Se il tuo nickname \u00e8 conosciuto positivamente nel team, avrai pi\u00f9 probabilit\u00e0 che il tuo codice venga notato.<\/p>\n
Dal punto di vista del flusso di lavoro, i possibili miglioramenti qui includono una corretta attribuzione delle priorit\u00e0, 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\u00ec via. <\/p>\n
2) Un secondo caso comune di conflitti durante la revisione del codice o del design \u00e8 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\u00f2 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. <\/p>\n
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\u00e9 non c'erano evidenti vantaggi tecnici in nessuna delle due soluzioni. <\/p>\n
La nostra discussione \u00e8 andata all'incirca cos\u00ec (ovviamente, in modo molto schematizzato, il colloquio \u00e8 durato mezz'ora): <\/p>\n
\u2014 Pasha, tra qualche giorno abbiamo il feature freeze. \u00c8 importante che raccogliamo tutto e iniziamo i test il prima possibile. Come possiamo fare per passare da Igor?
La questione si \u00e8 risolta, il rilascio \u00e8 avvenuto in tempo, Pasha non ha manifestato particolari disagi, poich\u00e9 \u00e8 stato lui a suggerire la soluzione e a realizzarla. Igor era molto soddisfatto, poich\u00e9 il suo parere \u00e8 stato preso in considerazione e hanno fatto come proponeva.<\/p>\n
Un altro tipo di conflitto simile \u00e8 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 \u00e8 scoperto che la direzione tecnica del progetto era categoricamente contraria all'uso della STL (Standard Template Library). Questa \u00e8 una libreria standard del linguaggio che semplifica lo sviluppo, alla quale il nostro team era molto abituato. \u00c8 emerso che il progetto era molto pi\u00f9 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 \u00e8 stata riunita di recente, solo negli ultimi giorni (incluso me). La parte russa del team non desiderava affatto rinunciare all'approccio di sviluppo abituale.<\/p>\n
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. <\/p>\n
\u00c8 durata a lungo, finch\u00e9 non ho finalmente capito che stavamo discutendo gli aspetti tecnici, mentre il problema in realt\u00e0 non era tecnico. Non riguardava i vantaggi o gli svantaggi di STL o la difficolt\u00e0 di lavorare senza di essa. La questione era pi\u00f9 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\u00f2 che andava oltre lo standard ingegneristico stabilito nell'azienda non poteva fisicamente essere supportato in seguito. Il livello di una squadra \u00e8 determinato dal livello dei membri pi\u00f9 deboli. Dopo aver capito la reale motivazione<\/i> Le azioni della parte americana del team hanno fatto s\u00ec 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.<\/p>\n
\u0421 \u0442\u043e\u0447\u043a\u0438 \u0437\u0440\u0435\u043d\u0438\u044f \u0440\u0430\u0431\u043e\u0447\u0435\u0433\u043e \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430, \u0432 \u044d\u0442\u043e\u043c \u043a\u043e\u043d\u043a\u0440\u0435\u0442\u043d\u043e\u043c \u0441\u043b\u0443\u0447\u0430\u0435, \u043f\u043e\u043c\u043e\u0433\u043b\u043e \u0431\u044b \u043d\u0430\u043b\u0438\u0447\u0438\u0435 \u043e\u043f\u0438\u0441\u0430\u043d\u0438\u044f \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c\u044b\u0445 \u0441\u0440\u0435\u0434\u0441\u0442\u0432, \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u044f \u043a \u043d\u0438\u043c, \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0435\u043d\u0438\u044f \u043d\u0430 \u0434\u043e\u0431\u0430\u0432\u043b\u0435\u043d\u0438\u0435 \u043d\u043e\u0432\u044b\u0445, \u043e\u0431\u043e\u0441\u043d\u043e\u0432\u0430\u043d\u0438\u0435 \u0442\u0430\u043a\u0438\u0445 \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0435\u043d\u0438\u0439. \u0422\u0430\u043a\u0438\u0435 \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u044b \u043f\u0440\u0438\u043c\u0435\u0440\u043d\u043e \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u044e\u0442 \u043e\u043f\u0438\u0441\u0430\u043d\u043d\u044b\u043c \u0432 \u043f\u0443\u043d\u043a\u0442\u0430\u0445 Reuse Strategy \u0438 Development Environment \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0441\u0442\u0432\u0430 \u201cManager’s Handbook for Software Development\u201d, \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043d\u043d\u043e\u0433\u043e \u0432 NASA<\/a><\/noindex>. Nonostante la sua et\u00e0, descrive perfettamente tutte le attivit\u00e0 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\u00e9.<\/p>\nDal punto di vista culturale, \u00e8 evidente che con un atteggiamento pi\u00f9 maturo, in cui le parti cercano di ascoltare e comprendere la reale motivazione delle azioni dei colleghi e agiscono in base alle priorit\u00e0 del progetto e del team, piuttosto che su un ego personale, il conflitto si risolverebbe in modo pi\u00f9 semplice e veloce.<\/p>\n
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 \u00e8 stata chiara, la soluzione \u00e8 diventata ovvia. <\/p>\n
La situazione \u00e8 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 \u00e8 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\u00ec 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\u00f2 persino dire religioso (per Stas). Anche se alla fine avessimo unito Stas a Skype (cosa che gi\u00e0 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 \u00e8 organizzativa. Abbiamo trasferito Stas in un altro team, dove era pi\u00f9 adatto.<\/p>\n
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, \u00e8 sicuramente un errore del manager. \u00c8 stato inizialmente sbagliato farlo lavorare su un progetto di questo tipo. Alla fine, Stas \u00e8 passato a un progetto di sviluppo di software open source e l\u00ec ha avuto un grande successo.<\/p>\n
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\u00e0 inviata al QA. Lo sviluppatore riteneva che fosse sufficiente scrivere il codice e passarla al QA \u2014 l\u00e0 se ne sarebbero occupati. \u00c8 un programmatore abbastanza maturo e esperto, ma questo era il suo livello interno di qualit\u00e0. Il QA non era d'accordo e richiedeva di mostrargli e descrivere ci\u00f2 che lui aveva controllato, oltre a esigere uno scenario di test. Avevano gi\u00e0 avuto problemi in passato con la funzionalit\u00e0 di questo sviluppatore e non volevano sprecare di nuovo il loro tempo. Peraltro, avevano ragione: la funzionalit\u00e0 non funzionava, e lui non aveva controllato il codice prima di inviarlo al QA. <\/p>\n
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\u00e9 non volevamo burocratizzare troppo il processo), e con questo specialista ci siamo presto separati (con sollievo generale).<\/p>\n
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\u00e0 con unit\u00e0 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\u00e8 qualsiasi nuovo codice poteva essere aggiunto solo se accompagnato da nuovi test. <\/p>\n
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 \u00e8 un problema del prodotto, quindi lo inoltra al team di prodotto. Il team di prodotto \u00e8 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\u00e0, 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...<\/p>\n
In questa situazione, la soluzione del conflitto \u00e8 abbastanza ovvia e lineare (riparare il prodotto, aggiornare la documentazione e i test, placare il cliente, emettere un hotfix, ecc.). \u00c8 importante analizzare il flusso di lavoro e capire chi \u00e8 responsabile dell'organizzazione dell'interazione tra i due team, e perch\u00e9 questa situazione \u00e8 diventata possibile. \u00c8 chiaro che \u00e8 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\u00f9 automatizzata possibile, ecc.<\/p>\n
Cos\u00ec come in guerra il nemico cerca di colpire il punto di contatto tra due reparti, anche nel lavoro il punto pi\u00f9 sottile e vulnerabile \u00e8 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\u00e0 a generare conflitti e problemi finch\u00e9 non interverr\u00e0 un manager in grado di sistemare la situazione.<\/p>\n
Un altro esempio caratteristico che ho incontrato ripetutamente in diverse aziende \u00e8 la situazione in cui un prodotto \u00e8 sviluppato da un team, i test di integrazione automatizzati da un secondo team, e l'infrastruttura su cui tutto questo \u00e8 in esecuzione \u00e8 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 \u00e8 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: \u201cperch\u00e9 dovrei occuparmi di questo?\u201d, \u201cloro si rompono pi\u00f9 spesso\u201d, ecc. <\/p>\n
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 \u00e8 garantire la trasparenza del processo, chiarezza nelle aspettative per tutte le parti coinvolte e un senso di equit\u00e0 nella situazione per tutti.<\/p>\n
Il conflitto \u00e8 un problema all'interno dell'organizzazione? \u00c8 un segno negativo se nella tua squadra ci sono conflitti frequenti (o anche solo occasionali)? In generale, no. Quando c'\u00e8 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. \u00c8 problematico se i conflitti si manifestano troppo spesso e sono difficili o lunghi da risolvere. Questo \u00e8 probabilmente un segnale di processi di lavoro non ben definiti e di una squadra non sufficientemente matura.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-novosti-interneta"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Gestione](\"\/wp-content\/uploads\/2019\/07\/de379c9eedec8cecda6651b5339a0277.jpg\")