Epigraf:
A fost odată ca niciodată, Ariciul și Ursușul s-au întâlnit în pădure.
- Bună, ariciul!
- Bună, ursulețule!
Așa că, cuvânt cu cuvânt, glumă cu glumă, Ariciul a fost lovit în față de ursulețul...
Mai jos este o discuție a liderului nostru de echipă, precum și a Directorului Dezvoltare Produs RAS Igor Marnat, despre specificul conflictelor de muncă și posibilele metode de gestionare a acestora.
Majoritatea conflictelor pe care le întâlnim la locul de muncă se dezvoltă după un scenariu similar celui descris în epigraful de mai sus. Există mai mulți participanți care sunt la început destul de favorabil unul față de celălalt; ei încearcă să rezolve o problemă, dar până la urmă problema rămâne nerezolvată și, din anumite motive, relațiile dintre participanții la discuție se dovedesc a fi stricate.
Viața este diversă, iar în scenariul descris mai sus apar variații. Uneori relația dintre participanți nu este foarte bună inițial, alteori nu există nici măcar o problemă care necesită o soluție directă (ca, de exemplu, în epigrafe), uneori după discuție relația rămâne aceeași ca înainte de a începe, dar problema nu este rezolvată până la urmă.
Ce este comun în toate situațiile care pot fi definite ca o situație de conflict de muncă?
În primul rând, există două sau mai multe părți. Aceste părți pot ocupa locuri diferite în organizație, pot fi într-o relație de egalitate (colegi dintr-o echipă), sau la diferite niveluri ale ierarhiei (șef - subordonat), pot fi individuale (angajat) sau de grup (în cazuri de conflict între un angajat și o echipă sau două echipe) și așa mai departe. Probabilitatea conflictului și ușurința rezolvării acestuia sunt influențate în mare măsură de nivelul de încredere dintre participanți. Cu cât părțile se cunosc mai bine, cu atât este mai mare nivelul de încredere, cu atât sunt mai mari șansele ca acestea să ajungă la un acord. De exemplu, membrii unei echipe distribuite care nu au interacționat niciodată față în față au mai multe șanse de a experimenta conflicte în legătură cu o problemă simplă de muncă decât persoanele care au avut cel puțin câteva interacțiuni față în față. Prin urmare, atunci când lucrați în echipe distribuite, este foarte important să vă asigurați că toți membrii echipei se întâlnesc periodic în persoană.
În al doilea rând, într-o situație de conflict la locul de muncă, părțile se află în situația de a rezolva o problemă care este importantă pentru una dintre părți, pentru ambele sau pentru organizație în ansamblu. În același timp, datorită specificului situației, părțile au, de obicei, suficient timp și o varietate de modalități pentru a o rezolva (formale, informale, întâlniri, scrisori, decizii de management, prezența obiectivelor și planurilor echipei, faptul unei ierarhii etc.). Aceasta este diferită de situația rezolvării unei probleme de muncă (sau non-muncă) într-o organizație față de, de exemplu, rezolvarea unei întrebări importante: „Eh, puștiule, din ce zonă ești?!” pe stradă, sau conflictul din epigraf. În cazul rezolvării unei probleme de lucru, contează calitatea procesului de lucru și cultura rezolvării problemelor în echipă.
În al treilea rând, factorul determinant al conflictului (din punctul de vedere al discuției noastre) este faptul că părțile din proces nu pot ajunge în mod independent la o soluție a problemei care să se potrivească tuturor părților. Situația necesită intervenția unui terț, un arbitru extern. Acest punct poate părea controversat, dar, în esență, dacă situația conflictuală a fost 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 spre care ar trebui să ne străduim. . Cel mai probabil nici nu vom ști despre un astfel de conflict, sau vom afla întâmplător după ce acesta va fi rezolvat. Cu cât o echipă poate rezolva mai multe probleme singură, cu atât va fi mai eficientă.
O altă trăsătură caracteristică a conflictului care merită atinsă este gradul de intensitate emoțională în timpul deciziei. Conflictul nu este neapărat asociat cu un nivel emoțional ridicat. Participanții nu trebuie să strige și să fluture brațele pentru ca situația să fie, în esență, un conflict. Problema nu este rezolvată, este prezentă o anumită tensiune emoțională (poate că nu este exprimată clar în exterior), ceea ce înseamnă că ne confruntăm cu o situație de conflict.
Este deloc necesar să intervenim în situații de conflict sau este mai bine să lăsăm rezolvarea lor să-și urmeze cursul și să așteptăm ca problema să se rezolve de la sine? Trebuie sa. Nu este întotdeauna în puterea sau competența ta să rezolvi complet conflictul, dar în orice situație, într-un conflict de orice amploare, poți lua o poziție adultă, aducând astfel mai mulți oameni în jurul tău, atenuând consecințele negative ale conflict și contribuie la rezolvarea acestuia.
Înainte de a analiza câteva exemple de situații conflictuale, să ne uităm la câteva puncte importante comune tuturor conflictelor.
Atunci când rezolvăm un conflict, este important să fii deasupra luptei, și nu în interiorul acesteia (aceasta se mai numește și „a lua o meta-poziție”), adică să nu faci parte din una dintre părțile procesului de rezolvare. În caz contrar, asistența unui arbitru extern la decizie nu va face decât să întărească poziția uneia dintre părți în detrimentul celeilalte părți. Atunci când luați o decizie, este important ca aceasta să fie acceptată moral de către toate părțile, așa cum se spune, „cumpărată”. Astfel încât, chiar dacă părțile nu au fost încântate de decizia luată, au fost cel puțin sincer de acord să o pună în aplicare. După cum se spune, să nu fii de acord și să te angajezi. În caz contrar, conflictul își va schimba pur și simplu aspectul, focul mocnit va rămâne sub turbăra și la un moment dat inevitabil va izbucni din nou.
Al doilea punct, parțial legat de primul, este că, dacă ați decis deja să participați la soluționarea conflictului, luați-l cât mai în serios posibil din punct de vedere al comunicării și al studierii contextului. Discutați personal cu fiecare dintre părți. Separat cu fiecare, pentru început. Nu vă mulțumiți cu corespondența. În cazul unei echipe distribuite, cel puțin vorbiți prin link video. Nu vă mulțumiți cu auzite și rapoarte ale martorilor oculari. Înțelegeți povestea, ce își dorește fiecare parte, de ce o doresc, ce se așteaptă, au încercat oare să rezolve această problemă înainte, ce se va întâmpla dacă nu este rezolvată, ce soluții văd, cum își imaginează poziția cealaltă parte, ce cred ei, corect sau greșit etc. Încarcă tot contextul posibil în capul tău, cu mintea deschisă, presupunând că toată lumea are dreptate. Nu ești în interiorul conflictului, ești în afara lui, într-o metapoziție. Dacă contextul este disponibil doar într-un thread de postare, cel puțin citiți-l în întregime și firele și documentele aferente acestuia. După ce l-ai citit, vorbește în continuare cu vocea ta. Sunteți aproape garantat că veți auzi ceva important care nu este prin poștă.
Al treilea punct important este abordarea generală a comunicării. Acestea sunt lucruri obișnuite, nimic cosmic, dar sunt foarte importante. Nu încercăm să economisim timp, vorbim cu toți participanții, nu criticăm persoana, dar luăm în considerare consecințele acțiunilor sale (nu „ești nepoliticos”, ci „poate că băieții ar putea fi jigniți de chestia asta”), dăm ocazia să salvăm fața, purtăm discuții personal, nu în față.
Conflictele sunt de obicei cauzate de unul dintre cele două motive. Prima este legată de faptul dacă o persoană în momentul conflictului se află în poziția unui adult sau în poziția unui copil (mai multe despre asta mai jos). Acest lucru se datorează maturității sale emoționale, capacității de a-și gestiona emoțiile (care, de altfel, nu este întotdeauna legată de vârsta lui). Al doilea motiv comun este imperfecțiunea procesului de lucru, care creează situații de zone gri în care responsabilitatea este răspândită între participanți, așteptările părților nu sunt transparente unele față de altele, iar rolurile din proces sunt estompate.
În consecință, în rezolvarea unui conflict (ca și a oricărei alte probleme), un manager trebuie să aibă în vedere trei perspective: pe termen scurt - pentru a rezolva problema/conflictul aici și acum, pe termen mediu - pentru a minimiza probabilitatea apariției unui alt conflict. din același motiv și pe termen lung - pentru a cultiva o cultură adultă în persoana de echipă.
Fiecare dintre noi avem un copil interior, de vreo trei sau patru ani. Doarme de cele mai multe ori la serviciu, dar uneori se trezește și preia controlul. Copilul are propriile sale priorități. Este important pentru el să insiste că acesta este cutia lui de nisip, mama lui îl iubește mai mult, mașina lui este cea mai bună (designul este cel mai bun, el programează cel mai bine, ...). Într-o situație de conflict, un copil poate apăsa jucăriile, călca cu picioarele și își sparge spatula, dar nu poate rezolva problemele adulților (arhitectura soluțiilor, abordări ale testării automate, date de lansare etc.), nu gândește în ceea ce privește beneficiile. pentru echipă. Un copil aflat în conflict poate fi încurajat, consolat și trimis la culcare cerându-i să-și sune adultul. Înainte de a începe o discuție într-o situație conflictuală, asigură-te că vorbești cu un adult, nu cu un copil și că tu însuți te afli în postura unui adult. Dacă scopul tău sincer în acest moment este să rezolvi o problemă serioasă, te afli în postura unui adult. Dacă scopul tău este să-ți călci cu picioarele și să-ți spargi omoplatul, aceasta este o poziție copilărească. Trimite-ți copilul interior în pat și cheamă un adult sau reprogramează discuția. O persoană ia o decizie emoțională și apoi caută o justificare rațională pentru aceasta. O decizie luată de un copil pe baza priorităților copiilor nu va fi optimă.
Pe lângă comportamentul în momentul conflictului, poziția unui copil sau a unui adult este caracterizată și de nivelul de responsabilitate pe care o persoană este gata să-l asume. În manifestările sale extreme, poziția copilărească a unui programator, pe care l-am întâlnit de mai multe ori, arată astfel: am scris codul, l-am trimis spre revizuire - munca mea este terminată. Evaluatorii ar trebui să îl revizuiască și să îl aprobe, QA ar trebui să îl verifice, dacă există probleme, mă vor anunța. Destul de ciudat, chiar și oamenii destul de maturi și cu experiență se comportă uneori în acest fel. Celălalt capăt al scalei este că o persoană se consideră responsabilă pentru a se asigura că codul său funcționează, este acoperit de teste, a fost verificat personal de el, a trecut cu succes revizuirea (dacă este necesar, nu există nicio problemă să pună ping la recenzenți, să discute probleme prin voce etc.) și a fost suprimat, QA va oferi asistență dacă este necesar, vor fi descrise scenarii de testare etc. În cazuri normale, programatorul fie începe mai aproape de capătul adult al scalei, fie se mută acolo pe măsură ce câștigă experiență (cu condiția să fie cultivată cultura potrivită în cadrul echipei). În cazuri extreme, el continuă să lucreze, luând de obicei o poziție copilărească, apoi el și echipa au periodic probleme și conflicte.
Promovarea unei culturi corecte și mature într-o echipă este o sarcină importantă pentru orice manager. Este nevoie de mult timp și efort zilnic, dar rezultatul merită. Există două modalități de a influența cultura echipei - a conduce prin exemplu (care va fi urmat cu siguranță; echipa se uită întotdeauna la lider) și a discuta și a recompensa comportamentul potrivit. Nici aici nu este nimic abstrus sau foarte formal, doar când discutați probleme, observați că aici s-ar fi putut face ceva, subliniați că ați observat când s-a hotărât corect, laudă, notează în timpul revizuirii lansării etc.
Să luăm în considerare câteva situații de conflict tipice, de la simple la complexe:
Conflicte care nu au legătură cu problemele de muncă
Destul de des există conflicte la locul de muncă care nu au legătură cu problemele de muncă. Apariția și ușurința lor de rezolvare sunt de obicei direct legate 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 mașina de spălat sau dușul suficient de des, ceea ce altora nu le place, cineva este înfundat, în timp ce alții bate vânt dacă deschid fereastra, cineva este prea zgomotos și alții au nevoie de liniște pentru a lucra și curând. Este mai bine să nu întârziem rezolvarea conflictelor de acest fel și să nu le lăsați să-și urmeze cursul. Nu se vor rezolva de la sine și vă vor distrage atenția de la muncă în fiecare zi și otrăvesc atmosfera din echipă. Din fericire, rezolvarea acestora nu este de obicei o mare problemă - doar vorbește calm (unu la unu, desigur) cu un coleg care neglijează igiena, asigură locuri confortabile pentru persoanele care preferă liniștea/răcirea, cumpără căști fonoabsorbante sau instalează pereți despărțitori. , etc.
Un alt exemplu pe care l-am întâlnit de mai multe ori în timpul muncii mele este incompatibilitatea psihologică a membrilor echipei. Din anumite motive, oamenii pur și simplu nu pot lucra împreună; fiecare interacțiune se termină într-un scandal. Uneori, acest lucru se datorează faptului că oamenii au opinii polare asupra unor probleme presante (de obicei politice) și nu știu cum să-i lase în afara serviciului. A-i convinge să se tolereze reciproc sau să-și schimbe comportamentul este o sarcină destul de inutilă. Singura excepție pe care am întâlnit-o sunt colegii tineri cu percepții deschise; comportamentul lor poate fi încă modificat treptat prin conversații periodice. De obicei, problema este rezolvată cu succes prin separarea lor în echipe diferite sau, cel puțin, oferind foarte rar oportunitatea de a se suprapune la locul de muncă.
În toate situațiile de mai sus, merită să discutați personal cu toți participanții, să discutați situația, să întrebați dacă văd vreo problemă în acest caz, să întrebați care sunt, după părerea lor, soluțiile și să vă asigurați participarea la realizarea acestui lucru. decizie.
Din punctul de vedere al optimizării procesului de lucru (perspectiva pe termen mediu despre care am menționat), aici nu se poate face mare lucru; singurul punct de optimizare este să ținem cont de factorul de compatibilitate la formarea unei echipe și nu să punem oameni. împreună în prealabil cine va intra în conflict.
Din perspectiva culturii de echipă, astfel de situații apar mult mai rar în echipele cu o cultură matură, în care oamenii respectă echipa și colegii și știu să rezolve problemele în mod independent. În plus, astfel de conflicte se rezolvă mult mai ușor (de multe ori automat) în echipele în care există un nivel ridicat de încredere, oamenii au lucrat împreună de mult timp și/sau comunică frecvent în afara serviciului.
Conflicte legate de probleme de muncă:
Astfel de conflicte sunt de obicei cauzate de ambele motive simultan, atât emoționale (faptul că unul dintre participanți nu se află în postura unui adult), cât și imperfecțiunea procesului de lucru în sine. Poate că cel mai frecvent tip de conflicte pe care l-am întâlnit sunt conflictele în timpul revizuirii codului sau discuțiilor de arhitectură între dezvoltatori.
Aș evidenția aici două cazuri tipice:
1) În primul caz, dezvoltatorul nu poate obține o revizuire a codului de la un coleg. Patch-ul este trimis pentru revizuire și nu se întâmplă nimic. La prima vedere, nu există un conflict evident între cele două părți, dar dacă vă gândiți bine, acesta este un conflict. Problema muncii nu este rezolvată, una dintre părți (în așteptarea unei revizuiri) experimentează un disconfort evident. Un subtip extrem al acestui caz este dezvoltarea într-o comunitate sau în echipe diferite, în timp ce examinatorul poate să nu fie interesat de acest cod special, din cauza încărcării sau a altor circumstanțe, poate să nu acorde deloc atenție cererii de revizuire, iar arbitrul extern (un manager comun ambelor părți) ) poate să nu existe deloc.
Abordarea soluției care ajută într-o astfel de situație se referă tocmai la perspectiva pe termen lung, la cultura unui adult. În primul rând, activitatea inteligentă funcționează. Nu trebuie să vă așteptați ca codul agățat pe recenzie să atragă atenția recenzorului însuși. Trebuie să ajutăm recenzenții să-l observe. Pingani câțiva oameni, pun o întrebare despre syncape, participă la discuții. Evident, importunitatea are mai multe șanse să dăuneze decât să ajute, trebuie să folosiți bunul simț. În al doilea rând, pregătirea prealabilă funcționează bine. Dacă echipa înțelege ce se întâmplă și de ce, de ce este nevoie de acest cod, designul a fost discutat și convenit în prealabil cu toată lumea, este mai probabil ca oamenii să acorde atenție unui astfel de cod și să-l accepte pentru muncă. În al treilea rând, autoritatea funcționează. Dacă doriți să fiți evaluat, faceți singuri multe recenzii. Faceți recenzii de înaltă calitate, cu verificări reale, teste reale și comentarii utile. Dacă porecla ta este bine cunoscută în echipă, există o șansă mai mare ca codul tău să fie observat.
Din punct de vedere al fluxului de lucru, posibilele îmbunătățiri aici sunt stabilirea corectă a priorităților menite să ajute dezvoltatorul să-și atingă obiectivele sale și ale echipei (revizuiește pe alții, scrie scrisori către comunitate, însoțește codul cu o descriere a arhitecturii, documentație, teste, participă la discuții cu comunitate, etc.), împiedică patch-urile să rămână în coadă prea mult timp și așa mai departe.
2) Al doilea caz obișnuit de conflicte în timpul revizuirilor de cod sau design este viziunile diferite asupra problemelor tehnice, stilului de codare și alegerea instrumentelor. De mare importanță în acest caz este nivelul de încredere între participanți, apartenența la aceeași echipă și experiența de a lucra împreună. O fundătură apare atunci când unul dintre participanți ia o poziție copilărească și nu încearcă să audă ceea ce interlocutorul vrea să-i transmită. Adesea, atât abordarea propusă de cealaltă parte, cât și abordarea propusă inițial pot funcționa cu succes și nu contează în principiu pe care să o alegeți.
Într-o zi, un programator din echipa mea (să-i spunem Pasha) a pregătit un patch cu modificări ale sistemului de implementare a pachetelor, care a fost dezvoltat și susținut de colegii dintr-un departament vecin. Unul dintre ei (Igor) avea propria sa opinie puternică cu privire la modul exact în care ar trebui să fie configurate serviciile Linux la implementarea pachetelor. Această opinie a fost diferită de abordarea propusă în patch și nu au putut fi de acord. Ca de obicei, termenele se scurgeau și era necesar să se ia o decizie; era necesar ca unul dintre ei să ocupe o poziție de adult. Pașa a recunoscut că ambele abordări au dreptul la viață, dar și-a dorit ca opțiunea să treacă, pentru că Nici una, nici a doua nu au avut avantaje tehnice evidente.
Discuția noastră a arătat cam așa (foarte schematic, desigur, conversația a durat o jumătate de oră):
- Pașa, avem o funcție înghețată în câteva zile. Este important să punem totul împreună și să începem testarea cât mai curând posibil. Cum putem trece prin Igor?
— Vrea să configureze serviciile altfel, mi-a pus comentarii acolo...
- Și ce este acolo, modificări mari, multă agitație?
- Nu, este de lucru pentru câteva ore, dar până la urmă nu este nicio diferență, va funcționa în orice caz, de ce este necesar? Am făcut ceva care funcționează, hai să-l acceptăm.
- Ascultă, de cât timp ai discutat despre toate astea?
- Da, am marcat timpul de o săptămână și jumătate acum.
- Hm... putem rezolva o problemă în câteva ore care a durat deja o săptămână și jumătate și să nu o facem?
- Ei bine, da, dar nu vreau ca Igor să creadă că am cedat...
- Ascultă, ce este mai important pentru tine, să emiti o eliberare, împreună cu decizia ta în interior, sau să-l ucizi pe Igor? Îl putem bloca, atunci, totuși, există o șansă bună de a zbura prin eliberare.
- Păi... ar fi mișto, desigur, să-i ștergi nasul lui Igor, dar bine, eliberarea este mai importantă, sunt de acord.
- Este chiar atât de important pentru tine ceea ce crede Igor? Sincer să fiu, nu îi pasă deloc, vrea doar o abordare unitară în diferite locuri a lucrului pentru care este responsabil.
- Ei bine, lasă-mă să fac ce cere el în comentarii și să începem testarea.
- Mulțumesc, Pașa! Eram sigur că dintre voi doi veți fi cel mai matur, deși Igorek este mai în vârstă decât voi :)
Problema a fost rezolvată, eliberarea a fost lansată la timp, Pașa nu a simțit prea multe nemulțumiri, pentru că el însuși a propus o soluție și a pus-o în aplicare. Igor a fost în general mulțumit, pentru că... Opinia lui a fost luată în considerare și au făcut ceea ce a sugerat el.
Un alt tip de conflict în esență același este alegerea între soluții tehnice/biblioteci/abordări într-un proiect, mai ales într-o echipă distribuită. Într-unul dintre proiecte, care a fost poziționat ca folosind C/C++, sa dovedit că managementul tehnic al proiectului a fost categoric împotriva utilizării STL (Standard Template Library). Aceasta este o bibliotecă în limbaj standard care simplifică dezvoltarea, iar echipa noastră este foarte obișnuită cu aceasta. S-a dovedit că proiectul este mult mai aproape de C decât de C++, ceea ce nu a inspirat foarte mult echipa, deoarece conducerea a făcut tot posibilul și a recrutat jucători foarte cool plus. În același timp, partea americană a echipei, atât ingineri, cât și manageri, lucrase în companie de mult timp, erau obișnuiți cu situația existentă și erau mulțumiți de toate. Partea rusă a echipei a fost reunită destul de recent, în câteva săptămâni (inclusiv eu). Partea rusă a echipei nu a vrut categoric să renunțe la abordarea obișnuită a dezvoltării.
Între cele două continente au început nesfârșite discuții scrise, scrisori pe trei sau patru ecrane zburau înainte și înapoi, în mailing-uri de grup și personale, de la programatori la programatori și manageri. După cum se întâmplă de obicei, scrisorile de această lungime nu au fost citite de nimeni, cu excepția autorilor și a susținătorilor lor înfocați. Chaturile scârțâiau de tensiune, trecând gânduri pe mai multe ecrane în direcții diferite cu privire la avantajele tehnice ale STL-ului, cât de bine testat este, cât de sigur este și, în general, cât de minunată este viața cu el și cât de groaznică este fără el. .
Toate acestea au durat destul de mult, până când mi-am dat seama în sfârșit că discutam aspectele tehnice ale problemei, dar problema în realitate nu era tehnică. Problema nu sunt avantajele sau dezavantajele STL sau dificultatea de a lucra fără el. Problema este mai degrabă organizatorică. Trebuia doar să înțelegem cum funcționează compania pentru care lucram. Niciunul dintre noi nu a avut experiență de lucru într-o astfel de companie înainte. Chestia a fost că, după ce codul a fost dezvoltat și lansat în producție, suportul a fost gestionat de oameni complet diferiți din alte echipe, din alte țări. Această echipă uriașă de ingineri formată din câteva zeci de mii de ingineri (în total) și-a putut permite doar un minim complet de bază de echipament tehnic, ca să spunem așa, un minim minimorum. Orice lucru care a depășit standardul de inginerie stabilit în companie din punct de vedere fizic nu a putut fi susținut în viitor. Nivelul unei echipe este determinat de nivelul celor mai slabi membri ai ei. După ce am înțeles motivație reală acțiunile părții americane a echipei, această problemă a fost eliminată de pe ordinea de zi și împreună am dezvoltat și lansat cu succes produsul folosind standardele adoptate de companie. Scrisorile și chaturile în acest caz nu au funcționat bine; a fost nevoie de mai multe călătorii și de multă comunicare personală pentru a ajunge la un numitor comun.
Din punctul de vedere al fluxului de lucru, în acest caz particular, ar ajuta să existe o descriere a instrumentelor utilizate, cerințele pentru acestea, restricțiile privind adăugarea altora noi și justificarea acestor restricții. Astfel de documente corespund aproximativ cu cele descrise în paragrafele Strategia de reutilizare și Mediul de dezvoltare din „Manualul managerului pentru dezvoltarea software”, elaborat în . În ciuda vechimii sale, descrie perfect toate activitățile principale și etapele de planificare ale dezvoltării software de acest fel. Având astfel de documente, este foarte ușor să discutați ce componente și abordări pot fi utilizate într-un produs și de ce.
Din punct de vedere cultural, evident, cu o poziție mai matură, în care părțile încearcă să audă și să înțeleagă motivația reală a acțiunilor colegilor și să acționeze în funcție de prioritățile proiectului și ale echipei, și nu de ego-ul personal. , conflictul s-ar rezolva mai ușor și mai rapid.
Într-un alt conflict legat de alegerea unei soluții tehnice, mi-a luat și un timp considerabil să înțeleg motivația uneia dintre părți (era un caz foarte neobișnuit), dar după ce motivația a fost clară, soluția a fost evidentă.
Situația este următoarea: un nou dezvoltator apare într-o echipă de aproximativ 20 de oameni, să-i spunem Stas. La acea vreme, instrumentul nostru standard de comunicare ca echipă era Skype. După cum sa dovedit mai târziu, Stas era un mare fan al standardelor deschise și al software-ului open source și a folosit doar instrumente și sisteme de operare ale căror surse erau disponibile public și care foloseau protocoale descrise public. Skype nu este unul dintre aceste instrumente. Am petrecut mult timp discutând despre avantajele și dezavantajele acestei abordări, încercările de a lansa analogi Skype pe diferite sisteme de operare, încercările lui Stas de a convinge echipa să treacă la alte standarde, să-i scriem personal prin poștă, să-l sunăm personal pe telefon, cumpără-i un al doilea computer special pentru Skype etc. În cele din urmă, mi-am dat seama că această problemă, în esență, nu este tehnică sau organizatorică, este mai degrabă ideologică, chiar, s-ar putea spune, religioasă (pentru Stas). Chiar dacă în cele din urmă am conectat Stas și Skype (care a durat câteva luni), problema ar apărea din nou pe orice instrument ulterior. Nu aveam la dispoziție mijloace reale pentru a schimba viziunea lui Stas asupra lumii și nu exista niciun motiv să încerc să schimb viziunea asupra unei echipe care a funcționat perfect în acest mediu. Persoana și compania erau pur și simplu ortogonale în viziunea lor asupra lumii. În astfel de situații, o soluție bună este organizatorică. L-am transferat pe Stas la o altă echipă, unde era mai organic.
Motivul acestui conflict, în opinia mea, este discrepanța dintre cultura personală a unei anumite persoane (care are o părere puternică care nu îi permite să facă compromisuri) și cultura companiei. În acest caz, este, desigur, greșeala managerului. Inițial a fost greșit să-l duc într-un proiect de acest gen. Stas s-a mutat în cele din urmă la un proiect de dezvoltare software open source și a excelat acolo.
Un bun exemplu de conflict cauzat atât de atitudinea copilărească a dezvoltatorului, cât și de neajunsurile procesului de lucru este o situație în care, în lipsa unei definiții a faptului, dezvoltatorul și echipa QA au așteptări diferite în ceea ce privește pregătirea caracteristica transferată către QA. Dezvoltatorul a crezut că este suficient să scrie codul și să arunce caracteristica peste gard la QA - o vor rezolva acolo. Un programator destul de matur și experimentat, de altfel, dar acesta era pragul său intern pentru calitate. QA nu a fost de acord cu acest lucru și a cerut să le arate și să le descrie ceea ce a verificat el însuși și a cerut un script de testare pentru ei. Au avut probleme cu funcționalitatea acestui dezvoltator în trecut și nu au vrut să-și piardă din nou timpul. Apropo, au avut dreptate - caracteristica chiar nu a funcționat, el nu a verificat codul înainte de a-l trimite la QA.
Pentru a rezolva situația, l-am rugat să-mi arate că totul a funcționat cu adevărat (nu a funcționat, și a trebuit să o repare), am discutat cu echipa și cu definiția QA a lui done (nu au ajuns în scris, pentru că nu am vrut să facem procesul prea birocratic), ei bine, curând ne-am despărțit de acest specialist (spre ușurare generală).
Din punct de vedere al fluxului de lucru, posibilele îmbunătățiri în acest caz sunt prezența unei definiții a terminat, cerințele de suport pentru fiecare caracteristică a unității și testele de integrare și o descriere a testării efectuate de dezvoltator. Într-unul dintre proiecte, am măsurat nivelul de acoperire a codului prin teste în timpul CI și dacă nivelul de acoperire a scăzut după adăugarea unui patch, testele au fost marcate ca eșuate, de exemplu. orice cod nou ar putea fi adăugat numai dacă existau teste noi pentru el.
Un alt exemplu tipic de conflict strâns legat de organizarea procesului de muncă. Avem un produs, o echipă de dezvoltare a produsului, o echipă de asistență și un client. Clientul are probleme cu produsul și contactează asistența. Suportul analizează problema și înțelege că problema se află în produs și transferă problema echipei de produs. Echipa de produs se află într-o perioadă aglomerată, se apropie o lansare, așa că un bilet cu o problemă de la un client, pierdut printre celelalte bilete ale dezvoltatorului căruia i-a fost atribuit, se blochează câteva săptămâni fără atenție. Suportul consideră că dezvoltatorul lucrează la problema clientului. Clientul așteaptă și speră că se rezolvă problema lui. În realitate, încă nu se întâmplă nimic. După câteva săptămâni, clientul decide în sfârșit să se intereseze de progres și solicită asistență cum merg lucrurile. Sprijinul cere dezvoltare. Dezvoltatorul se cutremură, se uită prin lista de bilete și găsește acolo un bilet de la client. Citind un bilet de la un client, el înțelege că nu există suficiente informații pentru a rezolva problema și are nevoie de mai multe loguri și depozite. Asistența solicită informații suplimentare de la client. Și atunci clientul își dă seama că nimeni nu a lucrat la problema lui în tot acest timp. Și tunetul va lovi...
În această situație, soluția conflictului în sine este destul de evidentă și liniară (remediați produsul, actualizați documentația și testele, liniștiți clientul, lansați o remediere rapidă etc.). Este important să analizăm procesul de lucru și să înțelegem cine este responsabil de organizarea interacțiunii dintre cele două echipe și de ce această situație a devenit posibilă în primul rând. Este clar ce trebuie remediat în proces - cineva trebuie să monitorizeze imaginea de ansamblu fără mementouri de la clienți, în mod proactiv. Biletele de la client ar trebui să iasă în evidență printre alte bilete de la dezvoltatori. Asistența ar trebui să vadă dacă echipa de dezvoltare lucrează în prezent la tichetele sale și, dacă nu, când poate începe să lucreze și când pot fi așteptate rezultate. Suportul și dezvoltarea ar trebui să comunice și să discute periodic starea tichetelor, colectarea informațiilor necesare pentru depanare ar trebui să fie automatizată cât mai mult posibil etc.
Așa cum în război inamicul încearcă să lovească joncțiunea dintre două unități, tot așa în muncă punctul cel mai delicat și vulnerabil este de obicei interacțiunea dintre echipe. Dacă managerii de suport și dezvoltare sunt suficient de mari, vor putea să repare singuri procesul, dacă nu, procesul va continua să genereze conflicte și probleme până va interveni un manager care poate remedia situația.
Un alt exemplu tipic pe care l-am văzut în repetate rânduri în diferite companii este o situație în care un produs este scris de o echipă, testele automate de integrare pentru acesta sunt scrise de o a doua echipă, iar infrastructura pe care este operat totul este însoțită de o a treia. echipă. Problemele la rularea testelor apar tot timpul, iar cauza problemelor din acestea poate fi atât produsul, cât și testele și infrastructura. De obicei, este problematic să ajungeți de acord cu privire la cine ar trebui să efectueze analiza inițială a problemelor, erori de fișiere, jurnalele de analiză ale produsului, teste și infrastructură etc. Conflictele aici sunt foarte frecvente și, în același timp, uniforme. În cazul unei intensități emoționale ridicate, participanții cad adesea într-o poziție copilărească și discuțiile încep în serie: „de ce ar trebui să mă joc cu asta”, „se strică mai des” etc.
Din perspectiva fluxului de lucru, pașii specifici pentru a rezolva o problemă depind de componența echipelor, de tipul de teste și de produs etc. Într-unul dintre proiecte, am introdus serviciul periodic, în care echipele monitorizau testele pe rând, săptămână de săptămână. În cealaltă, analiza inițială a fost făcută întotdeauna de dezvoltatorii de teste, dar analiza a fost foarte simplă și produsul a fost destul de stabil, așa că a funcționat bine. Cheia este să ne asigurăm că procesul este transparent, că așteptările sunt clare pentru toate părțile și că situația este corectă pentru toată lumea.
Este conflictul chiar o problemă într-o organizație? Este un semn rău că conflictele apar adesea (sau doar periodic) în echipa ta? În general, nu, pentru că dacă există creștere, dezvoltare, există un fel de dinamică, atunci apar probleme care nu au fost niciodată rezolvate până acum, iar la rezolvarea lor pot apărea conflicte. Acesta este un indicator că unele zone necesită atenție, că există zone de îmbunătățire. Este rău dacă conflictele apar foarte des, sunt greu de rezolvat sau durează mult. Acesta este cel mai probabil un semn al proceselor de lucru insuficient raționalizate și al unei maturități insuficiente a echipei.
Sursa: www.habr.com