Epigrafas:
Kartą miške susitiko Ežiukas ir Meškiukas.
- Labas, Ežiuke!
- Labas, meškiukas!
Taigi, žodis po žodžio, pokštas po juoko, Ežiukui į veidą trenkė Meškiukas...
Žemiau – mūsų komandos vadovo, taip pat RAS produktų plėtros direktoriaus Igorio Marnato diskusija apie darbo konfliktų specifiką ir galimus jų valdymo būdus.
Dauguma konfliktų, su kuriais susiduriame darbe, vystosi pagal scenarijų, panašų į aprašytą aukščiau esančiame epigrafe. Yra keletas dalyvių, kurie iš pradžių gana palankiai nusiteikę vienas kito atžvilgiu, bando išspręsti kokį nors klausimą, tačiau galiausiai problema lieka neišspręsta, o diskusijos dalyvių santykiai kažkodėl būna pašliję.
Gyvenimas yra įvairus, o aukščiau aprašytame scenarijuje pasitaiko variacijų. Kartais santykiai tarp dalyvių iš pradžių būna ne itin geri, kartais net nebūna tiesioginio sprendimo reikalaujančio klausimo (kaip, pavyzdžiui, epigrafe), kartais po diskusijos santykiai išlieka tokie patys kaip ir prieš prasidedant, tačiau problema galiausiai neišspręsta.
Kas bendro visose situacijose, kurias galima apibrėžti kaip darbo konflikto situaciją?
Pirma, yra dvi ar daugiau pusių. Šios šalys gali užimti skirtingas vietas organizacijoje, būti lygiateisiuose santykiuose (kolegos komandoje) arba skirtinguose hierarchijos lygiuose (viršininkas – pavaldinys), būti individualios (darbuotojos) arba grupinės (kilus konfliktui tarp darbuotojas ir komanda ar dvi komandos) ir pan. Konflikto tikimybei ir jo sprendimo lengvumui didelę įtaką turi dalyvių tarpusavio pasitikėjimo lygis. Kuo geriau šalys viena kitą pažįsta, tuo didesnis pasitikėjimas, tuo didesnė tikimybė, kad jos susitars. Pavyzdžiui, paskirstytos komandos nariai, kurie niekada nebendravo akis į akį, labiau linkę patirti konfliktą dėl paprastos darbo problemos nei žmonės, kurie bent kelis kartus bendravo akis į akį. Todėl dirbant paskirstytose komandose labai svarbu užtikrinti, kad visi komandos nariai periodiškai susitiktų asmeniškai vienas su kitu.
Antra, konflikto situacijoje darbe šalys sprendžia kažkokį klausimą, kuris yra svarbus vienai iš šalių, abiem arba visai organizacijai. Tuo pačiu metu, dėl situacijos specifikos, šalys dažniausiai turi pakankamai laiko ir įvairių būdų jai išspręsti (formalūs, neformalūs, susitikimai, laiškai, vadovybės sprendimai, komandos tikslų ir planų buvimas, hierarchijos faktas ir pan.). Tai skiriasi nuo situacijos, kai organizacijoje sprendžiamas darbo (ar ne darbo) klausimas, pavyzdžiui, išsprendžiamas svarbus klausimas: „Ech, vaikeli, iš kokios tu srities?“ gatvėje arba konfliktas iš epigrafo. Sprendžiant darbo klausimą – darbo proceso kokybė ir problemų sprendimo kultūra komandoje.
Trečia, lemiamas konflikto veiksnys (mūsų diskusijos požiūriu) yra tai, kad proceso šalys negali savarankiškai rasti visoms šalims tinkamo klausimo sprendimo. Situacija reikalauja trečiosios šalies – išorinio arbitro – įsikišimo. Šis punktas gali atrodyti prieštaringas, tačiau iš esmės, jei konfliktinė situacija buvo sėkmingai išspręsta be išorinio arbitro įsikišimo, klausimas buvo sėkmingai išspręstas ir šalių santykiai nepablogėjo, tai yra situacija, kurios reikia siekti. . Greičiausiai apie tokį konfliktą net nesužinosime arba sužinosime atsitiktinai jį išsprendę. Kuo daugiau problemų komanda gali išspręsti pati, tuo ji bus efektyvesnė.
Kitas būdingas konflikto bruožas, kurį verta paliesti, yra emocinio intensyvumo laipsnis priimant sprendimą. Konfliktas nebūtinai siejamas su aukštu emociniu lygiu. Dalyviai neturi šaukti ir mosuoti rankomis, kad situacija iš esmės būtų konfliktas. Klausimas neišspręstas, yra tam tikra emocinė įtampa (galbūt ji nėra aiškiai išreikšta išorėje), vadinasi, susiduriame su konfliktine situacija.
Ar apskritai reikia kištis į konfliktines situacijas, ar geriau leisti jų sprendimui eiti savaime ir laukti, kol problema išsispręs savaime? Reikia. Ne visada jūsų galia ar kompetencija visiškai išspręsti konfliktą, tačiau bet kokioje situacijoje, bet kokio masto konflikte galite užimti suaugusiojo poziciją, taip pritraukdami į ją dar kelis aplinkinius žmones, sušvelninkite neigiamas konflikto pasekmes. konfliktą ir prisidėti prie jo sprendimo.
Prieš pažvelgdami į kelis konfliktinių situacijų pavyzdžius, pažvelkime į keletą svarbių punktų, būdingų visiems konfliktams.
Sprendžiant konfliktą svarbu būti aukščiau kovos, o ne jos viduje (tai dar vadinama „metapozicijos užėmimu“), ty nebūti vienos iš sprendimo proceso šalių dalimi. Priešingu atveju išorinio arbitro padėjimas priimti sprendimą tik sustiprins vienos iš šalių poziciją kitos šalies nenaudai. Priimant sprendimą svarbu, kad jį morališkai priimtų visos šalys, kaip sakoma „nusipirkau“. Taigi, net jei šalys nebuvo patenkintos priimtu sprendimu, jos bent nuoširdžiai sutiko jį įgyvendinti. Kaip sakoma, mokėti nesutikti ir įsipareigoti. Priešingu atveju konfliktas tiesiog pakeis savo išvaizdą, rusenanti ugnis liks po durpynu ir kažkuriuo metu neišvengiamai vėl įsiliepsnos.
Antras dalykas, iš dalies susijęs su pirmuoju, yra tas, kad jei jau nusprendėte dalyvauti sprendžiant konfliktą, žiūrėkite į jį kuo rimčiau bendravimo ir konteksto tyrimo požiūriu. Pasikalbėkite asmeniškai su kiekviena iš šalių. Pradedantiesiems su kiekviena atskirai. Netenkinkite paštu. Jei komanda yra paskirstyta, kalbėkite bent per vaizdo nuorodą. Netenkinkite nuogirdomis ir liudininkų pranešimais. Suprasti istoriją, ko kiekviena pusė nori, kodėl to nori, ko tikisi, ar bandė šią problemą išspręsti anksčiau, kas bus, jei ji nebus išspręsta, kokius sprendimus mato, kaip įsivaizduoja kita pusė, ką jie mano, teisinga ar neteisinga ir pan. Įkelkite į savo galvą visą įmanomą kontekstą atviru protu, darydami prielaidą, kad visi yra teisūs. Jūs nesate konflikto viduje, esate už jo ribų, metapozicijoje. Jei kontekstas pasiekiamas tik pranešimų gijoje, bent jau perskaitykite jį visą ir su juo susijusias gijas bei dokumentus. Ją perskaitę, vis tiek kalbėkite savo balsu. Beveik garantuotai išgirsite ką nors svarbaus, ko nėra laiške.
Trečias svarbus momentas – bendras požiūris į bendravimą. Tai įprasti dalykai, nieko kosminio, bet jie labai svarbūs. Nesistengiame taupyti laiko, kalbamės su visais dalyviais, nekritikuojame žmogaus, bet svarstome jo veiksmų pasekmes (ne „tu grubus“, o „gal vaikinai gali įsižeisti šis dalykas“), suteikiame galimybę išsaugoti veidą, diskutuojame asmeniškai, o ne prieš eilę.
Konfliktai dažniausiai kyla dėl vienos iš dviejų priežasčių. Pirmasis susijęs su tuo, ar žmogus konflikto metu yra suaugusiojo ar vaiko padėtyje (apie tai plačiau žemiau). Tai lemia jo emocinė branda, gebėjimas valdyti emocijas (kuris, beje, ne visada susijęs su amžiumi). Antra dažna priežastis – darbo proceso netobulumas, sukuriantis pilkųjų zonų situacijas, kai atsakomybė pasiskirsto tarp dalyvių, šalių lūkesčiai nėra skaidrūs viena kitai, vaidmenys procese susilieja.
Atitinkamai, spręsdamas konfliktą (kaip ir bet kurį kitą klausimą), vadovas turi turėti omenyje tris perspektyvas: trumpalaikis – išspręsti problemą/konfliktą čia ir dabar, vidutinės trukmės – sumažinti kito konflikto tikimybę. dėl tos pačios priežasties ir ilgalaikės – ugdyti suaugusiųjų kultūrą kolektyvo žmoguje.
Kiekvienas iš mūsų turime vidinį vaiką, maždaug trejų ar ketverių metų. Darbe jis didžiąją laiko dalį miega, bet kartais pabunda ir perima kontrolę. Vaikas turi savo prioritetus. Jam svarbu primygtinai reikalauti, kad tai yra jo smėlio dėžė, mama jį myli labiau, jo mašina geriausia (dizainas geriausias, jis geriausiai programuoja, ...). Konflikto situacijoje vaikas gali spausti žaislus, trypti kojomis ir traiškyti mentelę, tačiau negali išspręsti suaugusiųjų klausimų (sprendimo architektūra, automatinio testavimo būdai, išleidimo datos ir pan.), negalvoja apie naudą. už komandą. Konfliktuojantį vaiką galima padrąsinti, paguosti ir nusiųsti į lovą, paprašius paskambinti savo suaugusiajam. Prieš pradėdami diskusiją konfliktinėje situacijoje, įsitikinkite, kad kalbate su suaugusiuoju, o ne su vaiku, o jūs pats esate suaugusiojo pozicijoje. Jei šiuo metu jūsų sąžiningas tikslas yra išspręsti rimtą problemą, esate suaugusio žmogaus padėtyje. Jei jūsų tikslas yra trypti kojas ir sulaužyti pečių ašmenis, tai vaikiška pozicija. Nusiųskite savo vidinį vaiką į lovą ir paskambinkite suaugusiajam arba suplanuokite diskusiją iš naujo. Žmogus priima emocinį sprendimą, o tada ieško jam racionalaus pagrindimo. Sprendimas, kurį vaikas priima pagal vaikų prioritetus, nebus optimalus.
Be elgesio konflikto metu, vaiko ar suaugusiojo pozicijai taip pat būdinga atsakomybės lygis, kurį žmogus yra pasirengęs prisiimti pats. Kraštutinėmis apraiškomis ne kartą sutikta vaikiška programuotojo pozicija atrodo taip: parašiau kodą, nusiunčiau peržiūrai – darbas baigtas. Recenzentai turėtų jį peržiūrėti ir patvirtinti, QA turėtų patikrinti, jei bus problemų, jie man praneš. Kaip bebūtų keista, net gana subrendę ir patyrę žmonės kartais taip elgiasi. Kitas skalės galas yra tai, kad žmogus laiko save atsakingu už tai, kad jo kodas veiktų, būtų atliktas testų, buvo asmeniškai patikrintas, sėkmingai išlaikė peržiūrą (jei reikia, nėra problemų pinguoti recenzentus, aptarti problemas). balsu ir pan.) ir buvo nuslopintas, prireikus QA suteiks pagalbą, bus aprašyti bandymų scenarijai ir pan. Įprastais atvejais programuotojas arba pradeda dirbti arčiau suaugusiojo skalės galo, arba pereina ten, kai įgyja patirties (jei komandoje ugdoma tinkama kultūra). Kraštutiniais atvejais jis ir toliau dirba, dažniausiai užima vaikišką poziciją, tada jam ir komandai periodiškai kyla problemų ir konfliktų.
Puoselėti tinkamą, brandžią kultūrą komandoje yra svarbi užduotis bet kuriam vadovui. Tai užima daug laiko ir kasdienių pastangų, tačiau rezultatas to vertas. Yra du būdai paveikti komandos kultūrą – rodyti pavyzdį (kurio tikrai bus sekama; komanda visada žiūri į lyderį) ir aptarti bei apdovanoti už tinkamą elgesį. Čia taip pat nėra nieko abstrakčio ar labai formalaus, tiesiog aptardami problemas pastebėkite, kad čia buvo galima ką nors padaryti, akcentuokite, kad pastebėjote, kada buvo nuspręsta teisingai, pagirkite, pažymėkite per laidos peržiūrą ir pan.
Panagrinėkime keletą tipiškų konfliktinių situacijų, nuo paprastų iki sudėtingų:
Konfliktai nesusiję su darbo problemomis
Gana dažnai darbe kyla konfliktų, nesusijusių su darbo reikalais. Jų atsiradimas ir sprendimo lengvumas dažniausiai yra tiesiogiai susiję su dalyvių emocinio intelekto lygiu, jų brandos lygiu ir nėra susiję su darbo proceso tobulumu ar netobulumu.
Tipiški pavyzdžiai: kažkas nepakankamai dažnai naudojasi skalbimo mašina ar dušu, kas nemėgsta kitiems, kam nors tvanku, o kitiems, atidarius langą, pučia vėjas, kažkas per daug triukšmauja, o kitiems darbui reikia tylos ir taip toliau. Tokio pobūdžio konfliktų sprendimo geriau neatidėlioti ir neleisti jiems eiti savo eiga. Jie patys neišsispręs ir kasdien atitrauks jus nuo darbų bei nuodys atmosferą kolektyve. Laimei, jas išspręsti dažniausiai nekyla problemų – tereikia ramiai (žinoma, vienas prieš vieną) pasikalbėti su higienos nepaisančiu kolega, pasirūpinti patogiomis sėdėjimo vietomis tylos/vėsumos mėgstantiems žmonėms, įsigyti garsą sugeriančias ausines ar įrengti pertvaras. ir kt.
Kitas pavyzdys, su kuriuo ne kartą susidūriau savo darbo metu – psichologinis komandos narių nesuderinamumas. Dėl tam tikrų priežasčių žmonės tiesiog negali dirbti kartu, kiekvienas bendravimas baigiasi skandalu. Kartais taip nutinka dėl to, kad žmonės laikosi poliarinių požiūrių į kokį nors aktualų klausimą (dažniausiai politinį) ir nežino, kaip juos palikti už darbo ribų. Įtikinti juos toleruoti vienas kitą ar pakeisti savo elgesį yra gana bergždžia užduotis. Vienintelė išimtis, su kuria susidūriau, yra jauni kolegos, turintys atvirą požiūrį, jų elgesį vis dar galima palaipsniui pakeisti periodiškais pokalbiais. Dažniausiai problema sėkmingai išsprendžiama išskiriant juos į skirtingas komandas arba bent jau suteikiant galimybę labai retai darbe sutapti.
Visose aukščiau paminėtose situacijose verta pasikalbėti su visais dalyviais asmeniškai, aptarti situaciją, pasiteirauti, ar jie apskritai įžvelgia problemą šiuo atveju, pasiteirauti, kokie, jų nuomone, yra sprendimai ir užtikrinti jų dalyvavimą tai darant. sprendimą.
Darbo proceso optimizavimo požiūriu (taip jau minėjau vidutinės trukmės perspektyvą), čia nelabai ką galima padaryti, vienintelis optimizavimo momentas – formuojant komandą atsižvelgti į suderinamumo faktorių, o ne dėti žmones. kartu iš anksto, kas konfliktuos.
Žvelgiant iš komandos kultūros perspektyvos, tokios situacijos kur kas rečiau iškyla brandžios kultūros kolektyvuose, kur žmonės gerbia komandą ir kolegas bei moka savarankiškai spręsti iškilusias problemas. Be to, tokie konfliktai daug lengviau (dažnai automatiškai) išsprendžiami komandose, kuriose yra didelis pasitikėjimas, žmonės ilgą laiką dirbo kartu ir/ar dažnai bendrauja ne darbo metu.
Konfliktai, susiję su darbo problemomis:
Tokius konfliktus dažniausiai sukelia abi priežastys iš karto – tiek emocinės (tai, kad vienas iš dalyvių nėra suaugusiojo pozicijoje), tiek paties darbo proceso netobulumas. Bene dažniausiai pasitaikantys konfliktai, su kuriais susidūriau, yra konfliktai per kodo peržiūras arba kūrėjų diskusijų apie architektūrą metu.
Išskirčiau du tipiškus atvejus:
1) Pirmuoju atveju kūrėjas negali gauti kodo peržiūros iš kolegos. Pleistras siunčiamas peržiūrėti ir nieko neįvyksta. Iš pirmo žvilgsnio akivaizdaus konflikto tarp abiejų pusių nėra, bet gerai pagalvojus, tai nemažas konfliktas. Darbo klausimas neišspręstas, viena iš šalių (laukianti peržiūros) patiria akivaizdų diskomfortą. Ekstremalus šio atvejo potipis yra plėtra bendruomenėje ar skirtingose komandose, tuo tarpu recenzentas gali nesidomėti šiuo kodu dėl įkėlimo ar kitų aplinkybių, gali visai nekreipti dėmesio į peržiūros prašymą, o išorinis arbitras. (abiem pusėms bendras vadovas) ) gali iš viso nebūti.
Sprendimo metodas, padedantis tokioje situacijoje, yra susijęs būtent su ilgalaike perspektyva, suaugusio žmogaus kultūra. Pirma, protinga veikla veikia. Nereikėtų tikėtis, kad ant apžvalgos kabantis kodas patrauks paties recenzento dėmesį. Turime padėti apžvalgininkams jį pastebėti. Pingani porą žmonių, užduokite klausimą apie sinkapą, dalyvaukite diskusijose. Akivaizdu, kad beatodairiškumas labiau pakenks nei padės, reikia vadovautis sveiku protu. Antra, gerai veikia išankstinis pasiruošimas. Jei komanda supranta, kas ir kodėl vyksta, kam šis kodas iš viso reikalingas, dizainas buvo iš anksto su visais aptartas ir sutartas, žmonės labiau linkę į tokį kodą atkreipti dėmesį ir priimti jį darbui. Trečia, veikia autoritetas. Jei norite, kad jus peržiūrėtų, daug peržiūrų atlikite patys. Atlikite aukštos kokybės apžvalgas su tikrais patikrinimais, tikrais testais ir naudingais komentarais. Jei jūsų slapyvardis yra gerai žinomas komandoje, yra didesnė tikimybė, kad jūsų kodas bus pastebėtas.
Darbo eigos požiūriu galimi patobulinimai čia yra teisingas prioritetų nustatymas, skirtas padėti kūrėjui pasiekti savo ir komandos tikslus (peržiūrėti kitus, rašyti laiškus bendruomenei, palydėti kodą su architektūros aprašymu, dokumentacija, bandymais, dalyvauti diskusijose su bendruomenė ir pan.), neleidžia pataisoms per ilgai kabėti eilėje ir pan.
2) Antras dažnas konfliktų atvejis per kodo ar dizaino peržiūras yra skirtingi požiūriai į techninius klausimus, kodavimo stilių ir įrankių pasirinkimą. Didelę reikšmę šiuo atveju turi dalyvių tarpusavio pasitikėjimo lygis, priklausymas tai pačiai komandai, darbo kartu patirtis. Aklavietė ištinka tada, kai vienas iš dalyvių užima vaikišką poziciją ir nebando išgirsti, ką pašnekovas nori jam perteikti. Dažnai tiek kitos šalies pasiūlytas, tiek iš pradžių pasiūlytas požiūris gali būti sėkmingas ir iš esmės nesvarbu, kurį iš jų pasirinkti.
Vieną dieną mano komandos programuotojas (vadinkime jį Pasha) paruošė pataisą su paketų diegimo sistemos pakeitimais, kurį sukūrė ir palaikė kolegos iš kaimyninio skyriaus. Vienas iš jų (Igoris) turėjo savo tvirtą nuomonę apie tai, kaip tiksliai turėtų būti sukonfigūruotos Linux paslaugos diegiant paketus. Ši nuomonė skyrėsi nuo pataisoje siūlomo požiūrio ir jie negalėjo sutikti. Kaip įprasta, terminai baigėsi, reikėjo priimti kažkokį sprendimą, vienam iš jų reikėjo užimti suaugusiųjų pareigas. Paša pripažino, kad abu požiūriai turi teisę į gyvybę, bet norėjo, kad jo pasirinkimas būtų priimtas, nes Nei vienas, nei antras variantas neturėjo akivaizdžių techninių pranašumų.
Mūsų diskusija atrodė maždaug taip (labai schematiškai, žinoma, pokalbis truko pusvalandį):
- Paša, po kelių dienų funkcijos sustoja. Svarbu viską suderinti ir kuo greičiau pradėti bandymus. Kaip mes galime įveikti Igorį?
— Jis nori kitaip susidėlioti tarnybas, man ten prikišo komentarus...
– O kas ten, dideli pertvarkymai, daug šurmulio?
– Ne, porą valandų yra darbo, bet galiausiai jokio skirtumo, pavyks ir taip, kam to reikia? Sukūriau tai, kas veikia, priimkime.
- Klausyk, kiek laiko tu visa tai diskutavoji?
- Taip, jau pusantros savaitės žymėjome laiką.
- Hm... ar galime per porą valandų išspręsti klausimą, kuris jau užtruko pusantros savaitės, ir to nepadaryti?
- Na, taip, bet aš nenoriu, kad Igoris manytų, kad aš pasidaviau...
- Klausyk, kas tau svarbiau, išleisti paleidimą kartu su savo sprendimu viduje, ar nužudyti Igorį? Mes galime jį užblokuoti, tačiau yra didelė tikimybė, kad išleis.
- Na... būtų šaunu, žinoma, nušluostyti Igoriui nosį, bet gerai, paleidimas svarbiau, sutinku.
– Ar tikrai jums taip svarbu, ką galvoja Igoris? Tiesą sakant, jis visai nesirūpina, jis tiesiog nori vieningo požiūrio į skirtingas dalykų, už kuriuos jis yra atsakingas, vietose.
- Na, gerai, leisk man padaryti, kaip jis prašo komentaruose, ir pradėkime testuoti.
- Ačiū, Paša! Buvau tikra, kad iš jūsų dviejų būsite labiau subrendę, nors Igorekas už jus vyresnis :)
Problema buvo išspręsta, leidimas išleistas laiku, Paša nejautė didelio nepasitenkinimo, nes jis pats pasiūlė sprendimą ir jį įgyvendino. Igoris apskritai buvo patenkintas, nes... Į jo nuomonę buvo atsižvelgta ir jie padarė, kaip jis siūlė.
Kitas iš esmės to paties konflikto tipas yra pasirinkimas tarp techninių sprendimų/bibliotekų/požiūrių projekte, ypač paskirstytoje komandoje. Viename iš projektų, kuris buvo pozicionuotas kaip naudojant C/C++, paaiškėjo, kad techninis projekto valdymas kategoriškai nusiteikęs prieš STL (Standard Template Library) naudojimą. Tai standartinė kalbų biblioteka, kuri supaprastina kūrimą, ir mūsų komanda yra prie jos labai pripratusi. Paaiškėjo, kad projektas yra daug arčiau C nei C++, o tai komandos nelabai įkvėpė, nes vadovybė stengėsi iš visų jėgų ir įdarbino tikrai šaunius žaidėjus. Tuo pat metu amerikietiška komandos dalis – tiek inžinieriai, tiek vadovai – įmonėje dirbo ilgą laiką, buvo pripratę prie esamos padėties ir buvo viskuo patenkinti. Rusiška komandos dalis buvo suburta visai neseniai, per kelias savaites (taip pat ir aš). Rusiška komandos dalis kategoriškai nenorėjo atsisakyti įprasto požiūrio į plėtrą.
Prasidėjo nesibaigiančios rašytinės diskusijos tarp dviejų žemynų, laiškai trijuose ar keturiuose ekranuose skraidė pirmyn ir atgal – grupiniais ir asmeniniais laiškais – nuo programuotojų iki programuotojų ir vadybininkų. Tokio ilgio laiškus, kaip dažniausiai būna, perskaitė niekas, išskyrus autorius ir karštus jų šalininkus. Pokalbiai girgždėjo iš įtampos, įvairiomis kryptimis perleisdami įvairias mintis apie STL techninius pranašumus, kaip jis patikrintas, koks saugumas ir apskritai koks nuostabus gyvenimas su juo ir kaip baisu be jo. .
Visa tai truko gana ilgai, kol galiausiai supratau, kad diskutuojame apie techninius problemos aspektus, tačiau problema iš tikrųjų buvo ne techninė. Problema yra ne STL privalumai ar trūkumai ar sunkumas dirbant be jo. Problema yra gana organizacinė. Mums tiesiog reikėjo suprasti, kaip dirbo įmonė, kurioje dirbome. Nė vienas iš mūsų anksčiau neturėjome patirties dirbant tokioje įmonėje. Reikalas tas, kad po to, kai kodas buvo sukurtas ir išleistas į gamybą, palaikymą tvarkė visiškai kiti žmonės iš kitų komandų, iš kitų šalių. Ši didžiulė kelių dešimčių tūkstančių inžinierių komanda (iš viso) galėjo sau leisti tik visiškai pagrindinį techninių priemonių minimumą, taip sakant, minimalų minimumą. Viskas, kas fiziškai viršijo įmonėje nustatytą inžinerinį standartą, ateityje negalės būti palaikoma. Komandos lygį lemia silpniausių jos narių lygis. Po to, kai supratome tikra motyvacija amerikietiškos komandos dalies veiksmai, šis klausimas buvo išbrauktas iš darbotvarkės, o kartu sėkmingai sukūrėme ir išleidome produktą pagal įmonės priimtus standartus. Laiškai ir pokalbiai šiuo atveju nepasiteisino, prireikė kelių kelionių ir daug asmeninio bendravimo, kad būtų pasiektas bendras vardiklis.
Darbo eigos požiūriu šiuo konkrečiu atveju padėtų turėti naudojamų priemonių aprašymą, joms keliamus reikalavimus, naujų papildymo apribojimus ir tokių apribojimų pagrindimą. Tokie dokumentai apytiksliai atitinka tuos, kurie aprašyti „Programinės įrangos kūrimo vadovo vadovo“ pastraipose „Pakartotinio naudojimo strategija ir kūrimo aplinka“, parengto m. . Nepaisant savo amžiaus, jis puikiai apibūdina visas pagrindines tokio pobūdžio programinės įrangos kūrimo veiklas ir planavimo etapus. Turint tokius dokumentus, labai lengva aptarti, kokie komponentai ir metodai gali būti naudojami gaminyje ir kodėl.
Kultūriniu požiūriu, akivaizdu, su brandesne pozicija, kurioje šalys stengiasi išgirsti ir suprasti tikrąją kolegų veiksmų motyvaciją ir veikti vadovaudamosi projekto bei komandos prioritetais, o ne asmeniniu ego. , konfliktas išsispręstų lengviau ir greičiau.
Kitame konflikte dėl techninio sprendimo pasirinkimo man taip pat prireikė pastebimai daug laiko, kol supratau vienos iš šalių motyvaciją (tai buvo labai neįprastas atvejis), tačiau paaiškėjus motyvacijai sprendimas buvo akivaizdus.
Situacija tokia: apie 20 žmonių komandoje atsiranda naujas kūrėjas, pavadinkime jį Stasu. Tuo metu mūsų standartinis komandos bendravimo įrankis buvo „Skype“. Kaip vėliau paaiškėjo, Stas buvo didelis atvirųjų standartų ir atvirojo kodo programinės įrangos gerbėjas ir naudojo tik įrankius ir operacines sistemas, kurių šaltiniai buvo viešai prieinami ir kurios naudojo viešai aprašytus protokolus. „Skype“ nėra vienas iš šių įrankių. Daug laiko praleidome aptardami šio požiūrio privalumus ir trūkumus, bandymus paleisti „Skype“ analogus skirtingose operacinėse sistemose, Staso bandymus įtikinti komandą pereiti prie kitų standartų, rašyti jam asmeniškai paštu, skambinti asmeniškai tel. telefoną, nupirk jam antrą kompiuterį specialiai Skype ir pan. Galiausiai supratau, kad ši problema iš esmės nėra techninė ar organizacinė, ji greičiau ideologinė, netgi, galima sakyti, religinė (Stasui). Net jei galiausiai sujungtume Stas ir Skype (tai užtruko kelis mėnesius), problema vėl iškiltų bet kuriame vėlesniame instrumente. Neturėjau jokių realių priemonių Stasio pasaulėžiūrai pakeisti, nebuvo jokio pagrindo bandyti pakeisti puikiai šioje aplinkoje dirbusios komandos pasaulėžiūrą. Asmuo ir kompanija savo pasaulėžiūroje buvo tiesiog stačiakampiai. Tokiose situacijose geras sprendimas yra organizacinis. Stasį perkėlėme į kitą komandą, kur jis buvo organiškesnis.
Šio konflikto priežastis, mano nuomone, yra neatitikimas tarp konkretaus žmogaus (turinčio tvirtą nuomonę, neleidžiančią eiti į kompromisus) asmeninės kultūros ir įmonės kultūros. Šiuo atveju tai, žinoma, vadovo klaida. Iš pradžių buvo neteisinga priimti jį į tokio pobūdžio projektą. Stasas galiausiai persikėlė į atvirojo kodo programinės įrangos kūrimo projektą ir ten puikiai sekėsi.
Geras konflikto, kurį sukelia tiek vaikiškas kūrėjo požiūris, tiek darbo proceso trūkumai, pavyzdys yra situacija, kai, nesant atlikta apibrėžimo, kūrėjas ir kokybės užtikrinimo komanda turi skirtingus lūkesčius dėl pasirengimo funkcija perkelta į QA. Kūrėjas tikėjo, kad užtenka parašyti kodą ir permesti funkciją per tvorą QA – jie ten sutvarkys. Beje, gana subrendęs ir patyręs programuotojas, bet tai buvo jo vidinis kokybės slenkstis. QA su tuo nesutiko ir pareikalavo jiems parodyti bei aprašyti, ką jis pats patikrino, ir pareikalavo jiems testavimo scenarijaus. Jie anksčiau turėjo problemų dėl šio kūrėjo funkcijų ir nenorėjo vėl gaišti laiko. Beje, jie buvo teisūs – funkcija tikrai neveikė, jis netikrino kodo prieš išsiųsdamas jį į QA.
Siekdamas išspręsti situaciją, paprašiau jo parodyti, kad viskas iš tikrųjų veikia (neveikė, ir jis turėjo tai ištaisyti), kalbėjomės su komanda ir su kokybės užtikrinimo apibrėžimu „atlikta“ (jie to nepadarė rašyti, nes nenorėjome, kad procesas būtų per daug biurokratiškas ), na, greitai išsiskyrėme su šia specialiste (bendram palengvėjimui).
Darbo eigos požiūriu galimi patobulinimai šiuo atveju yra atlikto apibrėžimo buvimas, kiekvienos įrenginio funkcijos palaikymo ir integravimo testų reikalavimai bei kūrėjo atlikto testavimo aprašymas. Viename iš projektų CI metu testais matavome kodo aprėpties lygį ir jei aprėpties lygis nukrito pridėjus pataisą, testai buvo pažymėti kaip nepavykę, t.y. bet koks naujas kodas gali būti pridėtas tik tuo atveju, jei būtų nauji jo testai.
Kitas tipiškas konflikto, glaudžiai susijusio su darbo proceso organizavimu, pavyzdys. Turime produktą, produkto kūrimo komandą, palaikymo komandą ir klientą. Klientas turi problemų su produktu ir susisiekia su palaikymo tarnyba. Pagalba analizuoja problemą ir supranta, kad problema yra gaminyje, ir perduoda problemą produkto komandai. Produkto komandai užimtas metas, artėja leidimas, todėl kliento bilietas su problema, pamestas tarp kitų kūrėjo, kuriam jis priskirtas, bilietų, be dėmesio kabo kelias savaites. Pagalba mano, kad kūrėjas sprendžia kliento problemą. Klientas laukia ir tikisi, kad jo problema bus išspręsta. Realiai kol kas nieko nevyksta. Po kelių savaičių klientas pagaliau nusprendžia pasidomėti eiga ir pasiteirauja palaikymo, kaip sekasi. Parama prašo plėtros. Kūrėjas pašiurpo, peržiūri bilietų sąrašą ir ten randa kliento bilietą. Skaitydamas kliento bilietą, jis supranta, kad trūksta informacijos problemai išspręsti, reikia daugiau rąstų ir sąvartynų. Pagalba prašo kliento papildomos informacijos. Ir tada klientas supranta, kad visą šį laiką niekas nedirbo su jo problema. Ir griaustinis trenks...
Esant tokiai situacijai, pats konflikto sprendimas yra gana akivaizdus ir linijinis (pataisyti produktą, atnaujinti dokumentaciją ir testus, nuraminti klientą, išleisti karštąsias pataisas ir pan.). Svarbu išanalizuoti darbo procesą ir suprasti, kas atsakingas už dviejų komandų sąveikos organizavimą ir kodėl tokia situacija apskritai tapo įmanoma. Aišku, ką reikia taisyti procese – kažkas turi stebėti bendrą vaizdą be klientų priminimų, aktyviai. Kliento bilietai turėtų išsiskirti iš kitų kūrėjų bilietų. Pagalba turėtų pamatyti, ar kūrimo komanda šiuo metu dirba su savo bilietais, o jei ne, kada ji gali pradėti dirbti ir kada galima tikėtis rezultatų. Pagalba ir plėtra turėtų periodiškai bendrauti ir aptarti bilietų būseną, derinimui reikalingos informacijos rinkimas turėtų būti kiek įmanoma automatizuotas ir pan.
Kaip kare priešas bando pataikyti į dviejų padalinių sandūrą, taip ir darbe subtiliausias ir pažeidžiamiausias taškas dažniausiai būna komandų tarpusavio sąveika. Jei palaikymo ir plėtros vadovai yra pakankamai suaugę, jie galės patys taisyti procesą, jei ne, procesas ir toliau generuos konfliktus ir problemas, kol įsikiš vadovas, galintis sutvarkyti situaciją.
Kitas tipiškas pavyzdys, kurį ne kartą mačiau įvairiose įmonėse, yra situacija, kai produktą rašo viena komanda, automatinius jo integravimo testus rašo antra komanda, o infrastruktūrą, kurioje visa tai veikia, lydi trečioji komanda. komanda. Problemų vykdant testus kyla nuolat, o problemų juose priežastis gali būti ir produktas, ir testai, ir infrastruktūra. Paprastai sunku susitarti, kas turėtų atlikti pirminę problemų analizę, failų klaidas, analizuoti produkto žurnalus, testus ir infrastruktūrą ir pan. Konfliktai čia yra labai dažni, o kartu ir vienodi. Esant dideliam emociniam intensyvumui, dalyviai dažnai atsiduria vaikiškoje pozicijoje ir seriale prasideda diskusijos: „kodėl aš turėčiau tai knisti“, „jie dažniau genda“ ir pan.
Žvelgiant iš darbo eigos perspektyvos, konkretūs problemos sprendimo veiksmai priklauso nuo komandų sudėties, testų tipo, produkto ir kt. Viename iš projektų įvedėme periodinį budėjimą, kai komandos kiekvieną savaitę stebėjo testus po vieną. Kitu atveju pirminę analizę visada atlikdavo testų kūrėjai, tačiau analizė buvo labai paprasta ir produktas buvo gana stabilus, todėl veikė gerai. Svarbiausia yra užtikrinti, kad procesas būtų skaidrus, kad visų šalių lūkesčiai būtų aiškūs ir situacija būtų teisinga visiems.
Ar organizacijoje konfliktas netgi yra problema?Ar tai blogas ženklas, kad konfliktai dažnai (ar tik periodiškai) kyla jūsų komandoje? Apskritai – ne, nes jei yra augimas, vystymasis, kažkokia dinamika, tada iškyla klausimai, kurie iki tol nebuvo sprendžiami, o juos sprendžiant gali kilti konfliktų. Tai yra rodiklis, kad kai kurioms sritims reikia dėmesio, kad yra tobulintinų sričių. Blogai, jei konfliktai kyla labai dažnai, juos sunku išspręsti arba užtrunka ilgai. Greičiausiai tai yra nepakankamai sutvarkytų darbo procesų ir nepakankamos komandos brandos požymis.
Šaltinis: www.habr.com