Epigraful:
O dată, în pădure, s-au întâlnit Ariciul și Ursulețul.
— Bună, Ariciule!
— Bună, Ursulețule!
Așa, vorbind unul cu altul, glumă după glumă, iar Ariciul a primit un ciocan peste bot de la Ursuleț …
Sub titlu sunt reflecțiile liderului nostru de echipă și ale directorului de dezvoltare a produsului RAS — Igor Marnat, despre specificul conflictelor de muncă și metodele posibile de gestionare a acestora.
Cele mai multe conflicte cu care ne confruntăm la muncă se dezvoltă conform unui scenariu similar cu cel descris mai sus în epigraf. Sunt câțiva participanți, inițial binevoitori unii față de alții, care încearcă să rezolve o problemă, dar, în cele din urmă, problema rămâne nerezolvată, iar relațiile dintre participanții la discuție se deteriorează dintr-un motiv oarecare.
Viața este diversă, în scenariul descris mai sus există variații. Uneori, relațiile dintre participanți sunt de la început nu foarte bune, uneori nu există nici măcar o întrebare care să necesite o soluție directă (ca, de exemplu, în epigraf), alteori, după discuție, relațiile rămân aceleași ca înainte de începerea acesteia, dar problema tot nu este rezolvată.
Ce au în comun toate situațiile care pot fi definite ca situații de conflict de muncă?
În primul rând, acestea implică două sau mai multe părți. Aceste părți pot ocupa poziții diferite în organizație, pot fi în relații de egalitate (colegi din echipă), sau la niveluri ierarhice diferite (șef — subordonat), pot fi individuale (angajat) sau de grup (în cazurile de conflict între un angajat și o echipă sau între două echipe), și așa mai departe. Nivelul de încredere între participanți influențează foarte mult probabilitatea conflictului și ușurința de a-l rezolva. Cu cât părțile se cunosc mai bine, cu cât nivelul de încredere este mai mare, cu atât șansele de a ajunge la un acord sunt mai mari. De exemplu, angajații unei echipe distribuite care nu s-au întâlnit niciodată personal au o probabilitate mai mare de a intra într-o situație de conflict atunci când trebuie să rezolve o simplă problemă de muncă, comparativ cu cei care s-au întâlnit personal măcar de câteva ori. De aceea, lucrând în echipe distribuite, este foarte important să asigurăm întâlniri personale periodice între toți membrii echipei.
În al doilea rând, în situația unui conflict la locul de muncă, părțile se află într-o situație de soluționare a unei probleme, importantă pentru una dintre părți, pentru ambele sau pentru organizație în ansamblu. În acest sens, datorită specificului situației, părțile au, de obicei, suficient timp și diverse modalități de a o rezolva (formale, informale, întâlniri, scrisori, decizii ale conducerii, existența obiectivelor și planurilor echipei, faptul că există o ierarhie etc.). Aceasta este diferența dintre soluționarea unei probleme de muncă (sau nu) în organizație și, de exemplu, soluționarea unei întrebări importante: „Eh, băiete, din ce cartier ești?!” pe stradă, sau un conflict precum cel din epigraf. În cazul soluționării unei probleme de muncă, calitatea procesului de muncă și cultura soluționării problememelor în echipă sunt importante.
În al treilea rând, un factor decisiv al conflictului (din perspectiva discuției noastre) este acela că părțile procesului nu pot ajunge singure la o soluție care să fie satisfăcătoare pentru toți. Situația necesită intervenția unei terțe părți, a unui arbitru extern. Acest punct poate părea controversat, dar, în esență, dacă situația conflictuală s-a rezolvat cu succes fără intervenția unui arbitru extern, problema a fost rezolvată cu succes și relațiile părților nu s-au deteriorat, aceasta este situația la care trebuie să tindem. Despre un astfel de conflict probabil că nici nu vom auzi, sau vom afla întâmplător după ce s-a rezolvat. Cu cât mai multe probleme poate rezolva echipa de una singură, cu atât mai eficient va funcționa.
O altă caracteristică a conflictului, la care merită să ne referim, este gradul de tensiune emoțională în procesul de soluționare. Conflictul nu este neapărat asociat cu un nivel emoțional ridicat. Participanții nu trebuie să strige și să fluture mâinile pentru ca situația să fie, în esență, conflictuală. Problema nu se rezolvă, iar o anumită tensiune emoțională este prezentă (poate că aceasta nu este exprimată în mod evident în exterior), ceea ce înseamnă că ne confruntăm cu o situație de conflict.
Este necesar să interveniți în situațiile conflictuale sau este mai bine să lăsați problemele să se rezolve de la sine și să așteptați până când acestea se estompează? Este necesar. Nu întotdeauna aveți puterea sau competența de a rezolva complet un conflict, dar în orice situație, într-un conflict de orice amploare, puteți adopta o poziție matură, implicând astfel și alte persoane de jur împrejur, atenuând consecințele negative ale conflictului și contribuind la soluționarea acestuia.
Înainte de a analiza câteva exemple de situații conflictuale, să ne oprim la câteva puncte importante, comune tuturor conflictelor.
Când rezolvați un conflict, este esențial să fiți deasupra situației, nu în mijlocul ei (acest lucru se mai numește „a adopta o metapozitie”), adică să nu deveniți parte dintr-una dintre părți în procesul de soluționare. În caz contrar, dintr-un arbitru extern, care ajută la soluționare, veți întări doar poziția uneia dintre părți în detrimentul celeilalte. Atunci când luați o decizie, este important ca aceasta să fie moral acceptată de toate părțile, așa cum se spune, „cumpărată”. Astfel, chiar dacă părțile nu sunt entuziasmate de decizia luată, măcar să fie de acord sincer să o pună în aplicare. Ceea ce se numește să fii în stare să dezacord și să te angajezi. Altfel, conflictul se va transforma pur și simplu, focul mocnit va rămâne sub turbă și, la un moment dat, va izbucni inevitabil din nou.
Un al doilea aspect, parțial legat de primul — dacă te-ai decis să participi la soluționarea conflictului, abordează-l cu cea mai mare seriozitate din perspectiva comunicării și înțelegerii contextului. Vorbește personal cu fiecare dintre părți. Separat cu fiecare, la început. Nu te mulțumi cu e-mailul. În cazul unei echipe distribuite — vorbește măcar prin videoconferință. Nu te mulțumi cu zvonuri și povestiri ale martorilor. Înțelege istoria, ce își dorește fiecare parte, de ce vrea acest lucru, ce așteaptă, dacă au încercat să rezolve această problemă înainte, ce se va întâmpla dacă nu este rezolvată, ce soluții văd, cum își imaginează poziția celeilalte părți, ce consideră ei că este corect sau greșit etc. Încarcă-ți mintea cu tot contextul posibil, fără prejudecăți, presupunând că toți au dreptate. Nu ești în interiorul conflictului, ești în afara lui, într-o metapozitie. Dacă contextul este disponibil doar în firul de e-mail — citeste măcar tot firul și discuțiile și documentele relevante. După ce ai citit — totuși, vorbește vocal. Aproape garantat vei auzi ceva important, ce nu apare în e-mail.
Un al treilea aspect important — abordarea generală a comunicării. Aceasta sunt lucruri obișnuite, nimic extraordinar, dar au o mare importanță. Nu încercăm să economisim timp, discutăm cu toți participanții, nu criticăm persoana, ci analizăm consecințele acțiunilor sale (nu „ești rău”, ci „poate, băieții s-ar putea supăra din cauza acestui lucru”), oferim posibilitatea de a păstra aparențele, discuțiile le desfășurăm personal, nu în fața unei mulțimi.
Conflictele sunt de obicei cauzate de una dintre cele două motive. Primul se leagă de poziția în care se află persoana în momentul conflictului, fie că este în poziția unui adult sau în cea a unui copil (despre asta mai jos). Aceasta este legată de maturitatea emoțională a sa, abilitatea de a-și gestiona emoțiile (ceea ce, de altfel, nu este întotdeauna legat de vârsta sa). Al doilea motiv frecvent — imperfecțiunea procesului de lucru, care creează situații de zone gri, în care responsabilitatea este dispersată între participanți, așteptările părților nu sunt clare una pentru cealaltă, rolurile în proces sunt neclare.
În rezolvarea conflictelor (la fel ca în orice altă problemă), managerul trebuie să aibă în vedere trei perspective: pe termen scurt — să rezolve problema/conflictul aici și acum, pe termen mediu — să minimizeze probabilitatea apariției unui alt conflict din aceeași cauză, și pe termen lung — să dezvolte în echipă o cultură a adulților.
Fiecare dintre noi are un copil interior, de aproximativ trei-patru ani. Marea parte a timpului, el doarme la birou, dar uneori se trezește și preia controlul. Copilul are propriile sale priorități. Este important pentru el să-și impună că aceasta este nisiparia lui, mama îl iubește mai mult, mașinuța lui este cea mai bună (designul este cel mai bun, el programează cel mai bine, ...). Într-o situație de conflict, copilul poate strânge jucăriile, poate călca cu picioarele și poate lovi cu lopata, dar nu poate rezolva probleme adulte (architecura soluției, abordările testării automate, termenele de livrare etc.), el nu gândește în termeni de beneficii pentru echipă. Copilul într-un conflict poate fi încurajat, consolat și trimis la somn, cerându-i să-l cheme pe adultul său. Înainte de a începe discuția în condiții de conflict, asigurați-vă că vorbiți acum cu adultul și nu cu copilul și că și voi sunteți pe poziția unui adult. Dacă scopul vostru sincer în acel moment este să rezolvați o problemă serioasă, sunteți pe poziția unui adult. Dacă scopul vostru este să călcați cu picioarele și să loviți cu lopata — aceasta este o poziție de copil. Trimiteți-l pe copilul vostru interior la somn și chemați adultul, sau amânați discuția. Oamenii iau decizii emoționale și apoi caută o justificare rațională. O decizie luată de copil, având în vedere prioritățile copilărești, nu va fi optimă.
În afară de comportamentul în timpul unui conflict, poziția copilului sau a adultului se caracterizează și prin nivelul de responsabilitate pe care persoana este dispusă să și-l asume. În manifestările extreme, poziția copilului programmerului, pe care am întâlnit-o de multe ori, arată astfel: am scris codul, l-am trimis la revizie — munca mea s-a terminat. Revizorii trebuie să-l examineze și să-l îmbine, QA trebuie să-l verifice, iar dacă vor apărea probleme — ei mă vor informa. Ciudat, dar chiar și oameni destul de maturi și experimentați se comportă astfel din când în când. Cealaltă extremă a scalei — o persoană consideră că este responsabilă pentru ca codul să funcționeze, să fie acoperit de teste, să fie verificat personal de el, să treacă cu succes revizia (dacă e nevoie, nu e nicio problemă să contactez revizorii, să discut problemele vocal etc.) și să fie îmbinat. QA va primi ajutor, dacă este necesar, scenariile de testare vor fi descrise etc. În mod normal, programatorul fie se află inițial mai aproape de extremitatea adultă a scalei, fie se deplasează acolo pe măsură ce acumulează experiență (cu condiția ca în echipă să se cultiveze o cultură corectă). În cazuri extreme, el continuă să lucreze, de obicei adoptând o poziție de copil, atunci apar periodic probleme și conflicte pentru el și echipă.
Întemeierea unei culturi corecte și mature în echipă este o sarcină importantă pentru orice manager. Aceasta necesită timp îndelungat și eforturi zilnice, dar rezultatul merită. Există două modalități de a influența cultura echipei — exemplul personal (la care cu siguranță vor urma, echipa se uită întotdeauna la lider) și discutarea și încurajarea comportamentului corect. Aici nu există nimic complicat sau formal, pur și simplu, atunci când discutați despre probleme, observați ce s-ar fi putut face în acest mod, subliniați când ați observat că a fost rezolvat corect, lăudați, menționați în analiza de lansare etc.
Să analizăm câteva situații tipice de conflict, de la simple la complexe:
Conflicte care nu sunt legate de problemele de muncă
Destul de des, la locul de muncă apar conflicte care nu sunt legate de problemele de muncă. Apariția acestora și ușurința de rezolvare sunt, de obicei, legate direct de nivelul de inteligență emoțională a participanților, de nivelul lor de maturitate și nu sunt legate de perfecțiunea sau imperfecțiunea procesului de lucru.
Exemple tipice — cineva nu folosește suficient de des mașina de spălat sau dușul, ceea ce nu-i place celor din jur, unora le este cald, iar altora le este o adiere dacă deschid fereastra, unii sunt prea zgomotoși, iar ceilalți au nevoie de liniște pentru a lucra, și așa mai departe. Este mai bine să nu amâni soluționarea conflictelor de acest tip și să nu le lași să decurgă de la sine. Ele nu se vor rezolva de la sine și vor distrage atenția de la muncă, otrăvind atmosfera din echipă. Din fericire, rezolvarea acestora nu este de obicei o mare problemă — este suficient să discuți calm (desigur, unul la unul) cu colegul care ignoră igiena, să asiguri o aranjare confortabilă pentru persoanele care preferă liniștea/păcătoasa, să cumpere căști fonoabsorbtive sau să montezi paravane, etc.
Un alt exemplu pe care l-am întâlnit de mai multe ori în timpul activității este incompatibilitatea psihologică a membrilor echipei. Din diverse motive, oamenii pur și simplu nu pot lucra împreună, fiecare interacțiune se termină cu un scandal. Uneori, acest lucru se datorează faptului că oamenii au opinii opuse asupra unei probleme sensibile (de obicei politice) și nu știu să le lase deoparte când vin la muncă. A-i determina să se suporte unii pe alții sau să-și schimbe comportamentul este o activitate destul de lipsită de perspective. Singurul excepție pe care am întâlnit-o a fost tinerii colegi cu o mentalitate deschisă, comportamentul lor mai poate fi schimbat treptat prin discuții ocazionale. De obicei, problema se rezolvă cu succes prin separarea lor în echipe diferite sau, cel puțin, prin asigurarea unei posibilități foarte rare de a colabora.
În toate situațiile prezentate, este important să discuți personal cu toți participanții, să discuți situația, să întrebi dacă ei văd de fapt problema în acest caz, să întrebi ce soluții consideră că ar putea fi aplicate și să le asiguri implicarea în luarea acestei decizii.
Din perspectiva optimizării procesului de lucru (pe termen mediu, despre care am menționat), ceea ce se poate face aici nu este foarte mult, singurul aspect pentru optimizare — considerarea factorului de compatibilitate în formarea echipei și să nu pui împreună dinainte oameni care vor avea conflicte.
Din punct de vedere al culturii echipei, astfel de situații apar mult mai rar în echipele cu o cultură matură, unde oamenii respectă echipa și colegii și pot rezolva problemele pe cont propriu. În plus, astfel de conflicte se rezolvă mult mai ușor (adesea automat) în echipele în care nivelul de încredere este ridicat, oamenii au lucrat împreună de mult timp și/sau comunică frecvent în afara muncii.
Conflictele legate de probleme de muncă:
Aceste conflicte sunt cauzate de obicei de ambele motive simultan, atât emoțional (faptul că cineva dintre participanți nu se află într-o poziție matură), cât și de imperfecțiunea procesului de muncă în sine. Cel mai frecvent tip de conflicte pe care l-am întâlnit sunt conflictele în procesul de revizuire a codului sau în discuțiile despre arhitectură între dezvoltatori.
Aș distinge aici două cazuri tipice:
1) În primul caz, dezvoltatorul nu poate obține revizuirea codului de la coleg. Patch-ul a fost trimis pentru revizuire, dar nu se întâmplă nimic. La prima vedere, nu există un conflict evident între cele două părți, dar, dacă te gândești bine, acesta este un conflict. Problema de muncă nu se rezolvă, iar una dintre părți (cea care așteaptă revizuirea) resimte un disconfort evident. O variantă extremă a acestui caz este dezvoltarea în comunitate sau în echipe diferite, iar revizorul poate să nu fie interesat de acest cod specific, din cauza încărcării de muncă sau altor circumstanțe, și poate să nu acorde deloc atenție cererii de revizuire, iar un arbitru extern (un manager comun pentru ambele părți) poate să nu existe deloc.
Abordarea unei soluții care ajută în astfel de situații se încadrează exact în perspectiva pe termen lung, cultura unui adult. În primul rând, funcționează activitatea rațională. Nu trebuie să ne așteptăm ca un cod suspendat în revizie să atragă automat atenția revizorului. Trebuie să ajutăm revizorii să-l observe. Trimite mesaje câtorva persoane, pune o întrebare pe canalul de sinteză, participă la discuții. Evident, insistența excesivă mai degrabă dăunează decât ajută, așa că trebuie să aplicăm bunul simț. În al doilea rând, pregătirea prealabilă funcționează bine. Dacă echipa înțelege ce și de ce se întâmplă, de ce este necesar acest cod, dacă designul a fost discutat și aprobat anterior de toți, oamenii vor acorda mai multă atenție unui astfel de cod și îl vor accepta în muncă. În al treilea rând, autoritatea este importantă. Dacă dorești să fii revizuit — fă multe revizuiri tu însuți. Realizează revizuiri de calitate, cu verificări reale, teste reale și comentarii utile. Dacă pseudonimul tău este cunoscut în echipă dintr-o latură pozitivă, există mai multe șanse ca codul tău să fie observat.
Din perspectiva fluxului de lucru, posibile îmbunătățiri aici sunt o prioritizare corectă, menită să ajute dezvoltatorul să își atingă obiectivele și obiectivele echipei (revizuind alții, scriind mesaje în comunitate, însoțind codul cu o descriere a arhitecturii, documentație, teste, participând la discuții cu comunitatea etc.), prevenind starea de blocaj a patch-urilor în coadă prea mult timp, și așa mai departe.
2) Un alt caz răspândit de conflicte în cadrul revizuirii codului sau designului — perspective diferite asupra problemelor tehnice, stilului de codare, alegerii instrumentelor. Un aspect deosebit de important în acest sens este nivelul de încredere între participanți, apartenența la aceeași echipă, experiența colaborării anterioare. Situația devine problematică atunci când unul dintre participanți adoptă o poziție infantilă, refuzând să încerce să înțeleagă ce vrea să transmită interlocutorul. Adesea, atât abordarea propusă de cealaltă parte, cât și abordarea inițială pot funcționa cu succes și nu are o importanță fundamentală pe care anume să o alegi.
Odată, un programator din echipa mea (să-i spunem Pasha) a pregătit un patch cu modificări pentru sistemul de desfășurare a pachetelor, care a fost dezvoltat și este întreținut de colegii din departamentul vecin. Unul dintre ei (Igor) avea o opinie puternică despre cum ar trebui să fie configurate serviciile Linux la desfășurarea pachetelor. Această opinie diferea de abordarea propusă în patch, iar ei nu reușeau să ajungă la un consens. Ca de obicei, termenele se apropiau, și trebuia să ajungem la o soluție, trebuia ca cineva să adopte o poziție de adult. Pasha recunoștea că ambele abordări aveau dreptul la viață, dar își dorea ca varianta sa să fie acceptată, deoarece nu existau avantaje tehnice evidente nici pentru una, nici pentru cealaltă variantă.
Discuția noastră a decurs cam așa (foarte schematic, desigur, conversația a durat o jumătate de oră):
— Pasha, în câteva zile avem feature freeze. Este important să adunăm totul și să începem testarea cât mai curând posibil. Cum putem trece peste Igor?
— Vrea să configureze serviciile diferit, mi-a lăsat comentarii acolo ...
— Și ce, sunt modificări mari, mult de muncă?
— Nu, de fapt, este muncă de câteva ore, dar, la final, nu contează, va funcționa oricum, de ce este nevoie? Am creat ceva funcțional, hai să-l acceptăm.
— Ascultă, de cât timp discutați despre asta?
— Da, deja de vreo două săptămâni ne tot bălăcărim.
— Em ... putem rezolva o problemă care a durat o săptămână și jumătate în câteva ore și nu facem asta?
— Păi, da, dar nu vreau ca Igor să creadă că am cedat ...
— Ascultă, ce este mai important pentru tine, să lansezi produsul, inclusiv soluția ta, sau să-l înfrunți pe Igor? Putem să-l înfruntăm, dar, totuși, există o șansă bună să pierdem lansarea.
— Păi ... ar fi fost amuzant, desigur, să-i arăt lui Igor că m-am impus, dar bine, lansarea e mai importantă, sunt de acord.
— Îți pasă atât de mult de ce crede Igor? Sincer, lui nu-i pasă prea mult, vrea doar o abordare unificată în diferite locuri ale acelei chestiuni pentru care este responsabil.
— Bine, hai să fac așa cum cere în comentarii și să începem testarea.
— Mersi, Pasha! Eram sigur că dintre voi doi tu vei fi cel mai matur, deși Igor e mai mare decât tine :)
Problema s-a rezolvat, lansarea a avut loc la timp, Pasha nu a fost deosebit de nemulțumit, deoarece el însuși a propus soluția și a implementat-o. Igor a fost, în general, mulțumit, deoarece opinia lui a fost luată în considerare și s-a făcut așa cum a sugerat.
O altă formă a aceluiași conflict este alegerea între soluții tehnice / biblioteci / abordări în proiect, în special într-o echipă distribuită. Într-unul dintre proiectele care se poziționau ca utilizând C / C++, s-a dovedit în cele din urmă că managementul tehnic al proiectului era categoric împotriva utilizării STL (Standard Template Library). Aceasta este o bibliotecă standard a limbajului care simplifică dezvoltarea, echipa noastră era foarte obișnuită cu ea. S-a dovedit că proiectul era mult mai aproape de C decât de C++, ceea ce nu a fost foarte încurajator pentru echipă, având în vedere că managementul a făcut eforturi și a adunat cu adevărat programatori buni. În același timp, partea americană a echipei, atât inginerii cât și managerii, lucra de mult timp în companie, era obișnuită cu situația existentă, totul îi mulțumea. Partea rusă a echipei a fost adunată recent, în câteva săptămâni (inclusiv eu). Partea rusă a echipei nu dorea să renunțe categoric la abordarea obișnuită în dezvoltare.
Au început discuții scrise nesfârșite între cele două continente, scrisori de trei-patru pagini zburau încoace și încolo, în e-mailuri de grup și personale, de la programatori — către programatori și manageri. Așa cum se întâmplă de obicei, astfel de scrisori nu erau citite de nimeni, în afară de autori și susținătorii lor aprinși. Chat-urile scârțâiau de tensiune, transmițând în direcții diferite considerații extensive privind avantajele tehnice ale STL, cât de bine a fost testată, cât de sigură este, și în general, cât de minunată este viața cu ea și cât de teribilă fără ea.
Aceasta a durat destul de mult, până când am înțeles în cele din urmă că discutăm despre aspectele tehnice, iar problema, de fapt, nu este tehnică. Problema nu este în avantajele sau dezavantajele STL sau în complexitatea muncii fără aceasta. Problema este mai degrabă organizațională. Trebuia să înțelegem cum este structurat compania în care lucrăm. Până atunci, niciunul dintre noi nu avea experiență de lucru într-o astfel de companie. Problema era că, după dezvoltarea codului și lansarea acestuia în producție, întreținerea era realizată de oameni complet diferiți, din echipe diferite, din alte țări. Această uriașă echipă de inginerie, formată din câteva zeci de mii de ingineri (în total), își permitea doar un minim tehnic de bază, așa cum s-ar spune, minimum minimorum. Tot ceea ce depășea standardul ingineresc stabilit în companie nu putea fi susținut ulterior. Nivelul unei echipe este determinat de nivelul celor mai slabi membri ai săi. După ce am înțeles motivația reală a acțiunilor echipei americane, această problemă a fost eliminată de pe agenda noastră, iar noi toți, împreună, am dezvoltat și lansat cu succes produsul, folosind standardele acceptate în companie. Email-urile și chat-urile au funcționat prost în acest caz, iar pentru a ajunge la un numitor comun au fost necesare câteva călătorii și multă comunicare personală.
Din punctul de vedere al procesului de lucru, în acest caz specific, ar fi ajutat să existe o descriere a instrumentelor utilizate, cerințele acestora, restricțiile privind adăugarea de noi instrumente și justificarea acestor restricții. Aceste documente corespund aproximativ celor descrise în punctele Reuse Strategy și Development Environment din manualul „Manager’s Handbook for Software Development”, elaborat în . În ciuda vârstei sale, acesta descrie excelent toate activitățile principale și etapele planificării dezvoltării software-ului de acest tip. Existența unor astfel de documente simplifică foarte mult procesul de discuție despre ce componente și abordări pot fi utilizate în produs și de ce.
Din punct de vedere cultural, este evident că, într-o poziție mai matură, în care părțile încearcă să asculte și să înțeleagă motivația reală a acțiunilor colegilor și acționează pe baza priorităților proiectului și echipei, nu a ego-ului personal, conflictul s-ar fi rezolvat mai simplu și mai repede.
Într-un alt conflict legat de alegerea soluției tehnice, mi-a fost de asemenea nevoie de timp considerabil pentru a înțelege motivația uneia dintre părți (a fost un caz foarte neobișnuit), dar, după ce motivația a devenit clară, soluția a fost evidentă.
Situația este următoarea: în echipa de aproximativ 20 de persoane apare un nou dezvoltator, să-i spunem Stas. Instrumentul nostru standard pentru comunicarea în echipă era Skype. Așa cum s-a dovedit ulterior, Stas era un mare fan al standardelor deschise și al software-ului open source, folosind doar instrumente și sisteme de operare ale căror surse sunt disponibile public și care utilizează protocoale descrise public. Skype nu se încadrează în această categorie. Am petrecut o mulțime de timp discutând despre avantajele și dezavantajele acestei abordări, încercând să lansăm alternative la Skype pe diferite sisteme de operare, încercările lui Stas de a convinge echipa să adopte alte standarde, de a-i scrie personal pe email, de a-l suna personal la telefon, de a-i cumpăra un al doilea computer special pentru Skype etc. În cele din urmă, am realizat că problema nu era, în esență, tehnică sau organizațională, ci mai degrabă una de mentalitate, chiar aș putea spune religioasă (pentru Stas). Chiar dacă am fi reușit în final să-l conectăm pe Stas cu Skype (pentru care am dedicat deja câteva luni), problema ar fi apărut din nou la următorul instrument. Nu aveam resurse reale pentru a schimba mentalitatea lui Stas și nu aveam motive să încerc să schimb mentalitatea echipei, care funcționa perfect în acest mediu. Omul și compania erau pur și simplu ortogonali în ceea ce privește mentalitatea. În astfel de situații, o soluție bună este una organizațională. L-am mutat pe Stas într-o altă echipă, unde s-a integrat mai bine.
Motivul acestui conflict, în opinia mea, este neconformitatea culturii personale a unei anumite persoane (care are o opinie forte, ce nu îi permite să accepte compromisuri), cu cultura companiei. În acest caz, desigur, este o greșeală a managerului. A fost greșit de la bun început să-l luăm pe el într-un proiect de acest tip. Stas a ajuns ulterior să lucreze la un proiect de dezvoltare a software-ului open source și a reușit minunat acolo.
Un exemplu bun de conflict, cauzat simultan de poziția copilărească a dezvoltatorului și de defectele procesului de muncă — o situație în care, în lipsa unui definition of done, dezvoltatorul și echipa de QA au avut așteptări diferite cu privire la pregătirea funcției trimise către QA. Dezvoltatorul credea că este suficient să scrie codul și să arunce funcția peste gard în QA — acolo se vor descurca. De altfel, un programator destul de matur și experimentat, dar acesta era nivelul său intern de calitate. Echipa de QA nu era de acord cu asta și cerea să le arate și să le descrie ce a verificat el și cerea un scenariu de testare pentru ei. Ei deja întâmpinaseră probleme în trecut cu funcționalitatea acestui dezvoltator și nu voiau să își piardă timpul din nou. De altfel, aveau dreptate — funcția chiar nu funcționa, el nu a verificat codul înainte de a-l trimite la QA.
Pentru a rezolva situația, i-am cerut să îmi arate că totul funcționează cu adevărat (nu funcționa, și a trebuit să repare), am discutat cu echipa și cu QA definition of done (nu l-am făcut scris, deoarece nu voiam să birocratizăm prea mult procesul), iar cu acest specialist ne-am despărțit curând (pentru ușurarea generală).
Din perspectiva procesului de muncă, îmbunătățirile posibile în acest caz sunt: existența unui definition of done, cerințe de a însoți fiecare funcție cu teste unitare și de integrare, descrierea testării efectuate de dezvoltator. În unul dintre proiecte, am măsurat nivelul de acoperire a codului cu teste în timpul CI și în caz că nivelul de acoperire scădea după adăugarea unui patch, testele erau marcate ca nefinalizate, adică orice cod nou putea fi adăugat doar dacă existau teste noi pentru el.
Un alt exemplu tipic de conflict, strâns legat de organizarea fluxului de muncă. Avem un produs, o echipă de dezvoltare a acestui produs, o echipă de suport și un client. Clientul întâmpină probleme cu produsul și se adresează suportului. Suportul analizează problema și își dă seama că aceasta ține de produs, transmițând problema echipei de produse. Echipa de produse se află într-o perioadă aglomerată, lansarea se apropie, așadar tichetul cu problema clientului, pierdut printre celelalte tichete alocate dezvoltatorului, stagnează câteva săptămâni fără atenție. Suportul crede că dezvoltatorul lucrează la problema clientului. Clientul așteaptă și speră că cineva se ocupă de problema sa. În realitate, nimic nu se întâmplă. După câteva săptămâni, clientul, în sfârșit, decide să întrebe despre progres și întreabă suportul. Suportul întreabă echipa de dezvoltare. Dezvoltatorul tresare, răsfoiește lista de tichete și descoperă tichetul de la client. Citind tichetul, el își dă seama că informațiile pentru a rezolva problema sunt insuficiente și are nevoie de mai multe jurnale și dump-uri. Suportul solicită informații suplimentare de la client. Și atunci clientul își dă seama că nimeni nu a lucrat la problema sa în tot acest timp. Și urmează un tunet ...
În această situație, soluția conflictului este destul de evidentă și liniară (repararea produsului, actualizarea documentației și a testelor, liniștirea clientului, lansarea unei corecții rapide etc.). Este important să analizăm fluxul de muncă și să înțelegem cine este responsabil pentru organizarea interacțiunii între cele două echipe, de ce s-a ajuns la această situație. Este clar că trebuie corectat procesul — cineva ar trebui să monitorizeze situația generală fără a aștepta reamintiri de la clienți, proactiv. Tichetele de la clienți ar trebui să se evidențieze printre celelalte tichete de la dezvoltatori. Suportul ar trebui să știe dacă dezvoltarea lucrează în prezent la tichetele sale, și, dacă nu, când poate începe să lucreze, când se pot aștepta rezultate. Suportul și dezvoltarea ar trebui să comunice periodic și să discute despre starea tichetelor, iar colectarea informațiilor necesare pentru depanare ar trebui să fie cât mai automatizată, etc.
Așa cum inamicul încearcă să lovească în intersecția dintre două unități în timpul războiului, tot așa în muncă cel mai delicat și vulnerabil punct este, de obicei, interacțiunea dintre echipe. Dacă managerii de suport și dezvoltare sunt suficient de maturi, vor putea să repare procesul singuri; dacă nu, procesul va continua să genereze conflicte și probleme până când un manager care poate remedia situația va interveni.
Un alt exemplu caracteristic, pe care l-am întâlnit de mai multe ori în diferite companii, este situația în care produsul este dezvoltat de o echipă, testele de integrare automate sunt realizate de o a doua echipă, iar infrastructura pe care toate acestea funcționează este întreținută de o a treia echipă. Problemele care apar în timpul rulării testelor sunt constante, iar cauza acestor probleme poate fi atât produsul, cât și testele în sine sau infrastructura. De obicei, este problematic să ne înțelegem cine ar trebui să efectueze analiza inițială a problemelor, să înregistreze erorile, să parcurgă jurnalele produsului, ale testelor și ale infrastructurii etc. Conflictele sunt destul de frecvente și, în același timp, uniforme. În cazul unei intensități emoționale ridicate, participanții cad adesea în poziția de copil și încep discuții de genul: "de ce ar trebui să mă ocup cu asta", "la ei se strică mai des", etc.
Din perspectiva fluxului de muncă, pașii specifici pentru rezolvarea problemei depind de componența echipelor, tipul de teste și produs etc. Într-unul dintre proiecte, am implementat ture periodice în care echipele monitorizau testele pe rând, câte o săptămână. În altul, analiza inițială era întotdeauna efectuată de dezvoltatorii de teste, dar această analiză era destul de de bază și produsul era suficient de stabil, așa că funcționa destul de bine. Ceea ce este crucial este asigurarea transparenței procesului, claritatea așteptărilor pentru toate părțile implicate și sentimentul de justiție al situației pentru toți.
Este conflict în organizare o problemă, este un semn rău că echipa dumneavoastră se confruntă frecvent (sau periodic) cu conflicte? În general, nu, deoarece dacă există creștere, dezvoltare, există o dinamică, apar întrebări care nu au fost niciodată rezolvate înainte, iar conflictele pot apărea în procesul de rezolvare a acestora. Acest lucru este un indicator că anumite domenii trebuie să primească atenție, că există domenii de îmbunătățire. Este rău dacă conflictele apar foarte frecvent, sunt greu de soluționat sau durează mult. Acest lucru este cel mai probabil un semn al unei procese de lucru nestructurate și al unei maturități insuficiente a echipei.
Sursa: habr.com
