Epigraf:
Egyszer találkozott az erdőben Süni és Medvebocs.
— Helló, Süni!
— Helló, Medvebocs!
Nos, szóra szót, poénra poént, és Süni kapott egy pofont Medvebocstól...
A cikk alatt a csapatvezetőnk, valamint a termékfejlesztési igazgató, Igor Marnat gondolatai a munkahelyi konfliktusok sajátosságairól és a lehetséges kezelési módszerekről.
A munkahelyi konfliktusok többsége az előző epigrammban leírt forgatókönyv mentén fejlődik. Van néhány résztvevő, akik eredetileg kedvezően állnak egymáshoz, próbálnak megoldani egy kérdést, de végül a probléma megoldatlan marad, és a diskurzus résztvevői között valamiért elromlanak a kapcsolatok.
Az élet sokszínű, az előző forgatókönyvben variációk fordulhatnak elő. Néha a résztvevők közötti kapcsolatok nem túl kedvezőek, néha nincs is olyan kérdés, ami közvetlen megoldást igényelne (mint az epigrammban), néha a diskurzus után a kapcsolatok ugyanazok maradnak, mint előtte, de a kérdés végül megoldatlan marad.
Mi közös a munkahelyi konfliktusként átadható helyzetekben?
Először is, két vagy több fél jelenléte. Ezek a felek foglalhatnak el különböző helyet a szervezetben, lehetnek egyenlő viszonyban (kollegák a csapatban), vagy különböző hierarchiai szinteken (főnök—beosztott), lehetnek egyéni (alkalmazott) vagy csoportos (például egy alkalmazott és egy csapat vagy két csapat közötti konfliktusok), és így tovább. A résztvevők közötti bizalom szintje nagyban befolyásolja a konfliktus valószínűségét és a megoldás egyszerűségét. Minél jobban ismerik egymást a felek, annál magasabb a bizalom szintje, annál nagyobb az esély, hogy megbeszélik a dolgot. Például a távoli csapat tagjai, akik soha nem kommunikáltak személyesen, nagyobb valószínűséggel kerülnek konfliktushelyzetbe egy egyszerű munkakérdés megoldása során, mint azok, akik legalább néhány alkalommal beszéltek személyesen. Ezért a távoli csapatok munkája során fontos, hogy rendszeres személyes találkozókat biztosítsunk a csapat minden tagja között.
Másodszor, egy munkahelyi konfliktushelyzetben a felek egy olyan kérdés megoldására próbálnak megoldást találni, amely fontos az egyik fél számára, mindkettőjük számára vagy a szervezet egészének. A helyzet sajátosságai miatt a felek általában elegendő idővel és különböző megoldási módszerekkel rendelkeznek (formális, informális, találkozók, levelek, vezetői döntések, a csapat céljai és tervei, a hierarchia megléte stb.). Ez a különbség a munkahelyi (vagy nem munkahelyi) kérdés megoldása és például egy fontos kérdés megvitatása között: „Hé, gyerek, melyik környékről jöttél?” az utcán, vagy az epigrammban szereplő konfliktus. A munkahelyi kérdés megoldásánál a munka folyamatának minősége és a kérdések megoldásának kultúrája a csapatban kulcsszerepet játszik.
Harmadszor, a konfliktus meghatározó tényezője (a mi beszélgetésünk szempontjából) az az tény, hogy a folyamatban részt vevő felek nem tudnak önállóan olyan megoldásra jutni, amely minden fél számára elfogadható. A helyzet megköveteli egy harmadik fél, külső döntnök beavatkozását. Ez a pont vitathatónak tűnhet, de lényegében, ha a konfliktushelyzet sikeresen megoldódott külső döntnök beavatkozása nélkül, akkor a kérdést sikeresen megoldották, és a felek kapcsolata nem romlott, ez az a helyzet, amelyre törekedni kell. Az ilyen konfliktusról valószínűleg nem is fogunk tudomást szerezni, vagy véletlenül értesülünk a megoldása után. Minél több kérdést tud a csapat önállóan megoldani, annál hatékonyabban fog működni.
Még egy jellemző vonása a konfliktusnak, amelyről érdemes szót ejteni – az érzelmi feszültség mértéke a megoldás során. A konfliktus nem feltétlenül jár magas érzelmi hőfokkal. A résztvevőknek nem kell kiabálniuk és gesztikulálniuk ahhoz, hogy a helyzet lényegében konfliktusos legyen. Ha a kérdés nem oldódik meg, és egy bizonyos érzelmi feszültség jelen van (lehetséges, hogy az nem nyilvánvalóan fejeződik ki), akkor konfliktushelyzettel állunk szemben.
Vajon szükséges beavatkozni a konfliktushelyzetekbe, vagy jobb, ha hagyjuk, hogy maguktól megoldódjanak, és várunk, amíg a probléma magától elsimul? Szükséges. Nem mindig a hatalmunkban vagy kompetenciánkban áll a konfliktus teljes megoldása, de bármilyen helyzetben, bármely konfliktus méretétől függetlenül, fel tudunk venni egy felnőtt pozíciót, ezzel másokat is aktiválva körülöttünk, mérsékelhetjük a konfliktus negatív következményeit, és hozzájárulhatunk a megoldásához.
Mielőtt néhány konfliktushelyzetet megvizsgálnánk, álljunk meg néhány fontos szempontnál, amelyek minden konfliktusra vonatkoznak.
A konfliktus megoldásakor fontos, hogy kívül álljunk a harcon, és ne a belső részesei legyünk (ezt nevezik még „metapozíciónak”), vagyis ne kerüljünk bele a problémamegoldás folyamatába egyik fél oldalán sem. Ellenkező esetben, ha külső arbiterként segítünk, csak egy fél pozícióját erősítjük a másik rovására. A döntés meghozatalakor fontos, hogy minden fél morálisan elfogadja azt, ahogy mondani szokás: „meg legyen vásárolva”. Így, még ha a felek nem is voltak elragadtatva a döntéstől, legalább őszintén egyetértenek abban, hogy végrehajtják azt. Úgy mondják, hogy képesek legyenek nem egyetérteni, de vállalni a döntést. Ellenkező esetben a konfliktus csupán átváltozik, a parázs a tőzeg alatt rejtőzik, és egy idő után elkerülhetetlenül újra fellángol.
A második szempont, amely részben kapcsolódik az elsőhöz — ha már részt vesz a konfliktus megoldásában, vegye ezt a lehető legkomolyabban a kommunikáció és a kontextus megértése szempontjából. Beszéljen személyesen mindkét féllel. Először külön-külön. Ne elégedjen meg az e-maillel. Ha elosztott csapatról van szó, legalább videohíváson beszéljen. Ne hagyatkozzon pletykákra és tanúk beszámolóira. Értse meg a történetet, hogy mit akar mindkét fél, miért akarja azt, mit vár el, próbálták-e már megoldani ezt a problémát, mi történik, ha nem oldják meg, milyen megoldási lehetőségeket látnak, hogyan képzelik el a másik fél álláspontját, mi a véleményük szerint helyes vagy helytelen, stb. Töltse fel az agyát minden lehetséges kontextussal, elfogulatlanul, feltételezve, hogy mindenki igazat mond. Ön nem a konfliktusban van, hanem kívül van rajta, metapozícióban. Ha a kontextus csak az e-mail szálban érhető el, legalább olvassa el teljes egészében azt és a kapcsolódó vitás szálakat és dokumentumokat. Miután elolvasta — akkor is beszéljen hangosan. Szinte garantáltan hallani fog valami fontosat, ami nincs az e-mailben.
A harmadik fontos szempont — az általános hozzáállás a kommunikációhoz. Ezek mindennapi dolgok, semmi különös, de nagyon nagy jelentőségük van. Ne próbáljon időt spórolni, beszéljen minden résztvevővel, ne a személyt kritizálja, hanem annak cselekedeteinek következményeit vizsgálja (ne mondja azt, hogy „te bunkó vagy”, hanem azt, hogy „talán a srácok megharagszanak emiatt a dolog miatt”), adjon lehetőséget az arc megőrzésére, a beszélgetéseket személyesen folytassa, ne nyilvánosan.
A konfliktusokat általában két ok valamelyike váltja ki. Az első azzal függ össze, hogy az érintett felnőtt vagy gyermek pozíciójában van-e a konfliktus pillanatában (erről lentebb). Ez kapcsolódik érzelmi érettségéhez, érzelmeinake kezelésének képességéhez (amely, mellesleg, nem mindenkor korhoz kötött). A második gyakori ok — a munkafolyamat hiányosságai, amelyek szürke zónákat hoznak létre, ahol a felelősség megoszlik a résztvevők között, a felek elvárásai nem átláthatók egymás számára, és a folyamatban betöltött szerepek elmosódnak.
Ennek megfelelően a konfliktus (akárcsak bármely más kérdés) megoldásakor a menedzsernek három perspektívát kell figyelembe venni: a rövid távú — a probléma/kontaktus azonnali megoldása, a középtávú — minimalizálni a hasonló okból adódó jövőbeli konfliktusok valószínűségét, és a hosszú távú — a csapatban a felnőtt kultúra kiépítése.
Mindenkiben van egy belső gyermek, körülbelül három-négy éves. A munka nagy részében alszik, de néha felébred és átveszi az irányítást. A gyereknek saját prioritásai vannak. Fontos számára, hogy kitartson amellett, hogy ez az ő homokozója, anya jobban szereti őt, a kisautója jobb mint a többi (a dizájn a legjobb, ő programozik a legjobban, stb.). Konfliktushelyzetben a gyerek megöleli a játékait, topog a lábával, és belecsap a lapáttal, de nem tud felnőtt kérdésekről dönteni (megoldás architektúra, automatizált tesztelési megközelítések, kiadási határidők stb.), nem gondolkodik a csapat számára nyújtott előnyök alapján. A gyermeket a konfliktus során lehet bátorítani, megnyugtatni és aludni küldeni, kérve, hogy hívja a felnőttet. A konfliktus körüli megbeszélés előtt győződjön meg róla, hogy most felnőttel beszél, nem pedig gyerekkel, és önmagát is felnőtt perspektívából kell megközelítenie. Ha az őszinte célja ebben a pillanatban egy komoly kérdés megoldása, akkor felnőtt álláspontból van. Ha a célja, hogy topogjon és belecsapjon a lapáttal — az egy gyermeki álláspont. Küldje el a belső gyermekét aludni, és hívja a felnőttet, vagy halassza el a megbeszélést. Az ember érzelmi döntést hoz, majd ehhez keres racionális érvet. A gyermek által hozott döntés, amely gyermekei prioritásai alapján készült, nem lesz optimális.
A konfliktus pillanatában megnyilvánuló viselkedés mellett a gyermek vagy felnőtt pozíciót az is jellemzi, hogy mennyi felelősséget hajlandó vállalni az ember. A legszélsőségesebb megnyilvánulásokban a programozó gyermek pozíciója, amellyel többször is találkoztam, így néz ki: megírtam a kódot, elküldtem ellenőrzésre — a munkám véget ért. Az ellenőröknek át kell nézniük és össze kell olvasztaniuk, a QA-nak ellenőriznie kell, ha probléma merül fel — ők szólnak nekem. Furcsa módon, még viszonylag érett és tapasztalt emberek is néha így viselkednek. A skála másik végén az ember úgy érzi, hogy felelősséggel tartozik azért, hogy a kódja működjön, tesztelést kapjon, ő maga ellenőrizze, sikeresen átmenjen az ellenőrzésen (ha szükséges, nincs probléma, hogy megkeresse az ellenőröket, megbeszélje a kérdéseket hangosan, stb.), és olvasszák össze, a QA-nak szükség esetén segítséget nyújtanak, a tesztelési forgatókönyveket leírják, stb. Normális esetekben a programozó vagy eredetileg közelebb áll a felnőtt skála végéhez, vagy tapasztalataik során oda fejlődnek (feltéve, hogy a csapatban a helyes kultúrát ápolják). Extrém esetekben viszont továbbra is dolgozik, általában gyermek pozíciót foglalva el, ekkor a neki és a csapatának időnként problémái és konfliktusai adódnak.
A csapatban a helyes, felnőtt kultúra kialakítása fontos feladata minden menedzsernek. Ez hosszú időt és napi erőfeszítéseket igényel, de megéri az árát. Két módja van a csapat kultúrájára való hatásnak — a személyes példa (amelyet biztosan követni fognak, a csapat mindig a vezetőre figyel) és a helyes viselkedés megbeszélése és ösztönzése. Itt semmi különös vagy túl formális nincs, csupán a problémák megvitatása során figyelje meg, hogy ezt hogyan lehetne másképp csinálni, hangsúlyozza, hogy észrevette, amikor a helyes megoldást választották, dicsérje meg, emelje ki a kiadás elemzésén stb.
Nézzünk meg néhány tipikus konfliktushelyzetet, az egyszerűtől a bonyolultig:
Konfliktusok, amelyek nem munkával kapcsolatos kérdésekkel függenek össze
Elég gyakran előfordulnak a munkahelyen olyan konfliktusok, amelyek nem kapcsolódnak a munkával kapcsolatos kérdésekhez. Ezek keletkezése és könnyű megoldása általában közvetlenül kapcsolódik a résztvevők érzelmi intelligenciájának szintjéhez, érettségük szintjéhez, és nem kapcsolódik a munkafolyamat tökéletességéhez vagy tökéletlenségéhez.
Tipikus példák — valaki nem használja elég gyakran a mosógépet vagy a zuhanyt, ami nem tetszik a többieknek, valakinek melege van, míg a másiknak huzatot okoz, ha kinyitja az ablakot, egyesek túl hangosak, miközben másoknak csendre van szükségük a munkához, és így tovább. Az ilyen típusú konfliktusokkal nem érdemes sokáig késlekedni, és nem szabad szabadjára engedni őket. Maguktól nem fognak megoldódni, és nap mint nap elvonják a figyelmet a munkától, valamint mérgezik a csapat légkörét. Szerencsére az ilyen problémák általában nem okoznak nagy gondot — elég, ha nyugodtan beszélünk (természetesen egyedül) a higiénát mellőző kollégával, kényelmes ülőhelyet biztosítunk azoknak, akik a csendet/hűvösséget részesítik előnyben, zajcsökkentő fejhallgatót vásárolunk, vagy válaszfalakat állítunk fel, stb.
Egy másik példa, amellyel a munkám során többször is találkoztam — a csapattagok pszichológiai összeférhetetlensége. Valamilyen okból fogva az emberek egyszerűen nem tudnak együtt dolgozni, minden kommunikáció botrányba fullad. Néha ez abból adódik, hogy az emberek polarizált nézeteket vallanak egy aktuális kérdésről (általában politikai), és nem tudják ezeket a munkahelyen kívül hagyni. Meggyőzni őket arról, hogy tartsák el egymást, vagy változtassanak a viselkedésükön — meglehetősen reménytelen feladat. Az egyetlen kivétel, amellyel találkoztam — fiatal kollégák, akik nyitott hozzáállással bírnak, az ő viselkedésük még fokozatosan megváltoztatható periódikus beszélgetések révén. Általában a kérdést sikeresen megoldják azzal, hogy különböző csapatokba osztják őket, vagy legalábbis biztosítják, hogy rendkívül ritkán kereszteződjenek a munkájuk során.
Minden említett helyzetben érdemes személyesen beszélni az érintettekkel, megvitatni a szituációt, megkérdezni, hogy egyáltalán látják-e problémának a helyzetet, és érdeklődni arról, milyen megoldási javaslatokat tartanak helyénvalónak, valamint biztosítani számukra a részvételt a döntéshozatalban.
A munkafolyamat optimalizálása szempontjából (középtávú perspektíva, amire korábban utaltam) itt nem sok mindent lehet tenni, az egyetlen optimalizálási lehetőség — figyelembe venni a kompatibilitás tényezőt a csapatok kialakításakor, és előre elkerülni azokat az embereket, akik konfliktust okozhatnak.
A csapat kultúrája szempontjából az ilyen helyzetek sokkal ritkábban fordulnak elő érett kultúrájú csapatokban, ahol az emberek tiszteletben tartják a csapatot és kollégáikat, és képesek önállóan megoldani a problémákat. Ezenkívül az ilyen konfliktusok sokkal könnyebben oldódnak meg (gyakran automatikusan) olyan csapatokban, ahol magas a bizalom szintje, az emberek régóta dolgoznak együtt és/vagy gyakran beszélgetnek munkaidőn kívül.
A munkával kapcsolatos konfliktusok:
Az ilyen konfliktusokat általában mindkét ok együttesen okozza: érzelmi (amikor az egyik résztvevő nem felnőttként viselkedik) és a munkafolyamat tökéletlensége. Talán a leggyakoribb konfliktustípus, amivel találkoztam, a kódellenőrzés vagy az architektúrával kapcsolatos megbeszélések során fellépő konfliktusok a fejlesztők között.
Két tipikus esetet emelnék ki itt:
1) Az első esetben a fejlesztő nem tudja elérni a kolléga kódellenőrzését. A javítás elküldve van ellenőrzésre, és semmi nem történik. Első ránézésre nyilvánvaló konfliktus nincs a két fél között, de ha jobban belegondolunk, ez valóban konfliktus. A munkakérdés nem oldódik meg, az egyik fél (a kódellenőrzést váró) nyilvánvaló kényelmetlenséget érez. Az ilyen eset extrém változata, amikor közösségi vagy különböző csapatokban dolgoznak, a véleményező nem lehet érdeklődő a konkrét kód iránt, és a leterheltség vagy más körülmények miatt teljesen figyelmen kívül hagyhatja a kódellenőrzési kérelmet, és külső döntéshozó (a két fél közös menedzsere) nem is áll rendelkezésre.
A megoldás megközelítése, amely segít az ilyen helyzetekben, a hosszú távú perspektívához és a felnőtt ember kultúrájához kapcsolódik. Először is, a racionális aktivitás működik. Ne várd, hogy a review alatt álló kód magára vonja a reviewer figyelmét. Segíteni kell a reviewereket, hogy észrevegyék. Pingelj néhány embert, tegyél fel kérdéseket a szinkronizáción, vegyél részt a megbeszéléseken. Nyilvánvaló, hogy a zaklatás inkább árt, mint használ, érdemes a józan észre támaszkodni. Másodszor, a megfelelő előkészítés jól működik. Ha a csapat érti, hogy mi és miért zajlik, hogy miért van szükség erre a kódra, a dizájn előre mindenki által meg lett vitatva és elfogadva, az emberek nagyobb valószínűséggel fognak figyelni ilyen kódra, és el fogják fogadni azt. Harmadszor, a tekintély működik. Ha szeretnéd, hogy review olvassanak el, akkor csinálj sok review-t te is. Csinálj minőségi review-kat, valós ellenőrzésekkel, valós tesztekkel, hasznos megjegyzésekkel. Ha a nicked jól ismert a csapatban és jó fényben tűnsz fel, akkor nagyobb eséllyel figyelnek majd a kódodra.
A munka folyamatát tekintve, a lehetséges fejlesztések itt a megfelelő prioritások felállítása, amely segíti a fejlesztőt céljai elérésében és a csapat céljaiban (mások review-jának elvégzése, levelek írása a közösségbe, a kód kísérése az architektúra leírásával, dokumentációval, tesztekkel, részvétel a közösségi megbeszélésekben stb.), a patch-ek túl hosszú várakoztatásának elkerülése, és így tovább.
2) A kód vagy dizájn review-ja során a konfliktusok második gyakori esete a technikai kérdésekkel, kódolási stílussal, eszközválasztással kapcsolatos eltérő nézőpontok. Ekkor óriási jelentősége van a résztvevők közötti bizalom szintjének, a közös csapatba való tartozásnak, a közös munkában szerzett tapasztalatnak. Bonyodalom akkor lép fel, amikor valamelyik résztvevő gyermekes pozíciót foglal el, és nem próbálja meghallani, mit akar közölni vele a beszélgetőpartnere. Gyakran előfordul, hogy a másik fél által javasolt megközelítés és az eredetileg javasolt megközelítés is teljesen sikeresen működhet, és nem lényeges, hogy melyiket választjuk.
Egyszer a csapatomból az egyik programozó (nevezzük őt Pashának) készített egy javítást a csomagtelepítő rendszer módosításairól, amelyet a szomszédos osztály kollégái fejlesztettek és tartottak karban. Az egyikük (Igor) erősen vélekedett arról, hogyan kellene beállítani a Linux szolgáltatásokat a csomagok telepítésekor. Ez a vélemény eltért attól az megközelítéstől, amit a javítás javasolt, és nem tudtak megállapodni. Mint általában, a határidők szorítottak minket, és valamilyen megoldásra volt szükség, valakinek a felnőtt szerepét kellett betöltenie. Pasha elismerte, hogy mindkét megközelítésnek van létjogosultsága, de szeretné, ha az ő verziója nyerne, mivel egyik változatnak sem voltak egyértelmű technikai előnyei.
A megbeszélésünk körülbelül így zajlott (nagyon vázlatosan, persze, a beszélgetés fél óráig tartott):
— Pasha, pár napon belül feature freeze van. Fontos, hogy mindent összegyűjtsünk és minél hamarabb elkezdjük a tesztelést. Hogyan tudnánk átkelni Igoron?
— Ő másképp szeretné beállítani a szolgáltatásokat, sok megjegyzést ragasztott abba ...
— És mi a helyzet? Nagy átvariálások, sok munka?
— Dehogy, ott pár órás munka van, de végül is nincs különbség, így is, úgy is működni fog, minek szükség erre? Készítettem egy működő megoldást, fogadjuk el azt.
— Figyelj, hány hete beszélgettek erről már?
— Már másfél hete jövünk ezzel.
— Uh ... két órában meg tudnánk oldani a kérdést, ami már másfél hete tart, és nem tesszük?
— Hát, igen, de nem akarom, hogy Igor azt gondolja, megadtam magam ...
— Figyelj, neked tényleg az a fontosabb, hogy a kiadást megcsináljátok a te megoldásoddal, vagy hogy legyőzd Igort? Meg tudjuk verni, de akkor van egy jó esély arra, hogy késlekednünk kell a kiadással.
— Nos ... jó lenne egy kicsit Igor orrát megfújni, de rendben, a kiadás fontosabb, egyetértek.
— Tényleg ennyire fontos neked, mit gondol Igor? Őszintén, neki egyáltalán mindegy, ő csak egységes megközelítést akar különböző helyeken azzal a dologgal kapcsolatban, amiért ő felelős.
— Rendben, akkor úgy csinálom, ahogy ő kérte a megjegyzésekben, és elkezdjük a tesztelést.
— Köszönöm, Pasha! Biztos voltam benne, hogy közülöttetek te fogsz felnőttebbnek bizonyulni, bár Igor nálad idősebb :)
A kérdés megoldódott, a kiadást időben elindították, Pasha nem érzett különösebb elégedetlenséget, mivel ő maga javasolta a megoldást és valósította meg azt. Igor egyáltalán elégedett volt, mivel figyelembe vették a véleményét, és úgy csinálták, ahogy ő javasolta.
Egy másik típusú ugyanilyen konfliktus — a választás a technikai megoldások / könyvtárak / megközelítések között a projektben, különösen elosztott csapat esetén. Az egyik projektben, amely C/C++-t használt, végül kiderült, hogy a projekt technikai menedzsmentje kategorikusan ellenzi az STL (Standard Template Library) használatát. Ez egy szabványos nyelvi könyvtár, amely megkönnyíti a fejlesztést, csapatunk nagyon hozzászokott. Kiderült, hogy a projekt sokkal közelebb áll C-hez, mint C++-hoz, ami nem igazán inspirálta a csapatot, mivel a menedzsment próbálkozott és igazán jó C++ fejlesztőket szerzett. Eközben az amerikai csapat, mind a mérnökök, mind a menedzserek, régen dolgozott a cégnél, hozzászoktak a meglévő állapothoz, őket mindez elégedettséggel töltötte el. A orosz csapatot pedig egészen nemrég gyűjtötték össze, pár héten belül (köztük engem is). Az orosz csapat kategorikusan elutasította a megszokott fejlesztési megközelítésről való lemondást.
Kezdődtek a végtelen írásos viták a két kontinenst között, a levelek három-négy képernyőt is elfoglalóan jártak oda-vissza, csoportos és személyes levelek a programozóktól — programozóknak és menedzsereknek. Ahogy az lenni szokott, az ilyen méretű leveleket senki, csak a szerzők és lelkes támogatóik olvasták. A csevegések remegtek a feszültségtől, megosztva sok képernyőnyi érvet az STL technikai előnyeiről, mennyire jól tesztelt, biztonságos, és hogy mennyire csodás az élet vele, és mennyire szörnyű nélküle.
Ez az egész eléggé sokáig tartott, amíg végre meg nem értettem, hogy a technikai részleteket vitatjuk, pedig a probléma valójában nem technikai jellegű. A probléma nem az STL előnyeiben vagy hátrányaiban, vagy annak bonyolultságában rejlik, hogy nélküle dolgozunk. Inkább szervezeti kérdésről van szó. Egyszerűen meg kellett értenünk, hogyan működik a cég, ahol dolgoztunk. Korábban egyikünknek sem volt tapasztalata ilyen cégnél dolgozni. A gond az volt, hogy miután a kódot kifejlesztettük és élesbe állítottuk, a támogatást teljesen más emberek egy másik csapatból, más országokból biztosították. Ez a hatalmas mérnöki csapat, ami több ezer mérnökből állt (összesen), csak a legalapvetőbb műszaki eszközöket engedhette meg magának, úgynevezett minimum minimorumot. Minden, ami túllépett a cég által kialakított mérnöki szabvány keretein, fizikailag nem tudott fennmaradni később. A csapat szintje a leggyengébb tagjainak szintje határozza meg. Miután megértettük a valódi motivációt az amerikai csapat tettei mögött, ez a kérdés lekerült a napirendről, és mindannyian együtt sikeresen kidolgoztunk és kiadtunk egy terméket, a cég által elfogadott szabványok alapján. E-mail és csevegés esetén nem működtek jól, hogy közös nevezőre jussunk, több utazásra és sok személyes kapcsolatra volt szükség.
A munkafolyamat szempontjából, ebben az adott esetben, segített volna, ha van leírás a használt eszközökről, a követelményekről, a korlátozásokról az új eszközök hozzáadására és az ilyen korlátozások indoklásáról. Ezek a dokumentumok nagyjából megfelelnek a Reuse Strategy és a Development Environment részekben leírtaknak a „Manager’s Handbook for Software Development” című kézikönyvben, amely az . Kora ellenére nagyszerűen leírja az ilyen típusú szoftverfejlesztési folyamatok főbb tevékenységeit és lépéseit. Az ilyen dokumentumok megléte nagyban megkönnyíti a termékben felhasználható komponensek és megközelítések megvitatásának folyamatát, és azok okait.
A kultúra szempontjából egyértelmű, hogy egy érettebb attitűddel, ahol a felek megpróbálják meghallani és megérteni kollégáik cselekedeteinek valódi motivációját, és a projekt és a csapat prioritásai alapján cselekednek, nem pedig a személyes egó alapján, a konfliktus sokkal egyszerűbben és gyorsabban megoldódna.
Egy másik konfliktusban, amely a technikai megoldás kiválasztásából fakadt, szintén jelentős időre volt szükségem ahhoz, hogy megértsem az egyik fél motivációját (nagyon szokatlan eset volt), de miután a motiváció világossá vált, a megoldás egyértelművé vált.
A helyzet a következő: a csapatban, amely körülbelül 20 főből állt, megjelent egy új fejlesztő, nevezzük őt Sztyepánnak. Abban az időben a csapat kommunikációs eszköze a Skype volt. Ahogy később kiderült, Sztyepán nagy rajongója volt a nyílt szabványoknak és az open source szoftvereknek, és csak olyan eszközöket és operációs rendszereket használt, amelyek forráskódja nyilvánosan elérhető, és amelyek nyilvános protokollokat használnak. A Skype nem tartozik ezek közé az eszközök közé. Rengeteg időt töltöttünk el a megoldás és hátrányok megvitatásával, a Skype alternatíváinak beindításával különböző operációs rendszereken, Sztyepán próbálkozásaival, hogy meggyőzze a csapatot más szabványok használatára, személyesen e-mailben írjon neki, hívja őt telefonon, második számítógépet vásároljon csak a Skype számára stb. Végül rájöttem, hogy ez lényegében nem technikai és nem is szervezeti probléma, hanem inkább világnézeti, még mondhatni vallásos (Sztyepán számára). Még ha végül sikerült is összekötni Sztyepánt a Skype-pal (ami már hónapokat vett igénybe), bármelyik következő eszköz használatakor a probléma újra felmerült volna. Nem álltak rendelkezésemre valódi eszközök, hogy megváltoztassam Sztyepán világnézetét, és nem voltam jó okom, hogy a csapat világnézetét is próbáljam megváltoztatni, amely remekül működött ebben a környezetben. Az ember és a cég egyszerűen ortogonális volt a világnézetük alapján. Az ilyen helyzetekben a jó megoldás gyakran szervezeti. Átirányítottuk Sztyepánt egy másik csapatba, ahol megfelelőbben érezhette magát.
Ennek a konfliktusnak az okát véleményem szerint az adott személy személyes kultúrájának és a cég kultúrájának összeférhetetlensége jelenti (amelynek erős véleménye van, így nem hajlandó kompromisszumra lépni). Ebben az esetben természetesen a menedzser hibája volt. Eredetileg rossz döntés volt, hogy ilyen típusú projektre alkalmazzuk. Sztyepán végül egy nyílt szoftverfejlesztési projektbe került, és ott nagyszerűen teljesített.
Jó példa egy konfliktusra, amelyet a fejlesztő gyermeki álláspontja és a munkafolyamat hiányosságai váltottak ki — egy olyan helyzet, amikor a "definition of done" hiányában a fejlesztő és a QA csapat eltérő elvárásokkal rendelkezik a QA-nak átadott funkció elkészültségével kapcsolatban. A fejlesztő úgy gondolta, hogy elegendő megírni a kódot, és átpasszolni a funkciót a QA-nak — ott majd elintézik. Egyébként egy elég tapasztalt és felnőtt programozóról van szó, de ez volt a belső minőségi küszöbe. A QA ezzel nem értett egyet, és megkövetelték, hogy mutassa meg és írja le nekik, mit ellenőrzött önállóan, valamint kértek tőlük egy tesztelési forgatókönyvet. Már a múltban is voltak problémáik a funkcióval, amelyet ez a fejlesztő írt, és nem akarták újra feleslegesen pazarolni az idejüket. Egyébként igazuk volt — a funkció valóban nem működött, a kódot a QA-nak való átadás előtt nem ellenőrizte.
A helyzet megoldása érdekében megkértem, hogy mutassa meg nekem, hogy minden valóban működik (de nem működött, ezért javítania kellett), megbeszéltük a csapattal és a QA-val a "definition of done"-t (írásban nem akartuk rögzíteni, mivel nem akartuk túl bürokratikussá tenni a folyamatot), végül pedig hamarosan elváltunk ettől a szakembertől (mindenki megkönnyebbülésére).
A munkafolyamat szempontjából lehetséges javítások ebben az esetben a "definition of done" megléte, valamint az, hogy minden funkcióhoz egység- és integrációs tesztekkel kell rendelkezni, továbbá a fejlesztő által végzett tesztelés leírása. Egy projekt során a CI során mértük a kód tesztjelöltségét, és ha a tesztlefedettség csökkent a javítás hozzáadásakor, a teszteket nem teljesítettnek jelöltük meg, azaz bármilyen új kód csak új tesztek esetén kerülhetett hozzáadásra.
Még egy tipikus példa a konfliktusra, amely szorosan kapcsolódik a munkafolyamat szervezéséhez. Van egy termékünk, a termék fejlesztőcsapata, egy támogatói csapatunk és egy megrendelőnk. A megrendelő problémákkal küzd a termékkel, ezért a támogatáshoz fordul. A támogatás elemzi a problémát, és megérti, hogy a probléma a termékben keresendő, ezt továbbítja a termékfejlesztő csapatnak. A termékfejlesztő csapatnak forgalmas időszaka van, közeledik a kiadás, ezért a megrendelőtől érkező problémajegy, amely a fejlesztő által elvállalt többi jegy között elveszett, heteken át figyelmen kívül marad. A támogatási csapat azt hiszi, hogy a fejlesztő dolgozik a megrendelő problémáján. A megrendelő várakozik, és reméli, hogy dolgoznak a problémáján. Valójában azonban semmi sem történik. Néhány hét elteltével a megrendelő végre úgy dönt, hogy érdeklődik a haladásról, és megkérdezi a támogatást, hogy állnak a dolgok. A támogatás a fejlesztéshez fordul. A fejlesztő meglepődik, átnézi a jegyek listáját, és észreveszi a megrendelőtől érkezett jegyet. Olvasva a megrendelő jegyét rájön, hogy az információk nem elegendőek a probléma megoldásához, és további naplókra és dumpokra van szüksége. A támogatás kéri a megrendelőtől a kiegészítő információkat. Ekkor a megrendelő rájön, hogy senki sem dolgozott a problémáján ezen az idő alatt. És kezdődnek a bonyodalmak…
Ebben a helyzetben a konfliktus megoldása meglehetősen nyilvánvaló és lineáris (javítani a terméket, frissíteni a dokumentációt és a teszteket, megnyugtatni a megrendelőt, kiadni egy hotfix-et, stb.). Fontos elemezni a munkafolyamatot, és megérteni, ki a felelős a két csapat közötti interakció szervezéséért, és miért vált lehetővé ez a helyzet egyáltalán. Nyilvánvaló, hogy a folyamatban javítani kell – valakinek proaktívan kell figyelnie a teljes képet anélkül, hogy emlékeztetőket kérnének a megrendelőktől. A megrendelőktől érkező jegyeknek ki kell emelkedniük a fejlesztők többi jegye közül. A támogatásnak látnia kell, hogy a fejlesztés dolgozik-e a jegyeiken, és ha nem, mikor kezdhetik el a munkát, mikorra várható eredmény. A támogatásnak és a fejlesztésnek időnként kommunikálnia kell, és meg kell beszélniük a jegyek állapotát, az információgyűjtés a hibakereséshez pedig a lehető legjobban automatizált legyen, stb.
Ahogyan a háborúban az ellenfél igyekszik ütni a két alegység közötti résen, úgy a munkában a leggyengébb és legsebezhetőbb pont általában a csapatok közötti együttműködés. Ha a támogatási és fejlesztési menedzserek eléggé érettek, képesek lesznek önállóan orvosolni a folyamatot, ha nem, a folyamat továbbra is konfliktusokat és problémákat generál, amíg be nem avatkozik egy menedzser, aki képes rendbe tenni a helyzetet.
Egy másik jellemző példa, amellyel több különböző cégnél is találkoztam — olyan helyzet, ahol a terméket egy csapat írja, az automatikus integrációs teszteket egy másik csapat, a infrastruktúrát pedig egy harmadik csapat kezeli. A tesztek futtatása során folyamatosan problémák merülnek fel, és ezek okai lehetnek a termék, a tesztek vagy az infrastruktúra. Általában nehéz megállapodni abban, hogy ki végezze el az elsődleges problémaelemzést, ki készítse a hibajegyeket, ki parszolja a termék, a tesztek és az infrastruktúra naplóit, stb. A konfliktusok itt meglehetősen gyakoriak, ugyanakkor egyformák. Magas érzelmi feszültség esetén a résztvevők gyakran visszaesnek egy gyermeki pozícióba, és olyan viták kezdődnek, mint: „miért kell ezzel foglalkoznom”, „náluk gyakrabban romlik el”, stb.
A munkafolyamat szempontjából a kérdés megoldásának konkrét lépései a csapatok összetételétől, a tesztek típusától és a terméktől függenek, stb. Egyik projektünkben bevezettük a rendszeres ügyeleti szolgálatokat, amikor a csapatok hetente váltották egymást a tesztek figyelemmel kísérésében. Egy másik esetben az elsődleges elemzést mindig a tesztfejlesztők végezték, de az elemzés meglehetősen alapvető volt, és a termék elég stabil volt, így ez elég jól működött. A legfontosabb az, hogy biztosítsuk a folyamat átláthatóságát, a várakozások világosságát minden érintett fél számára, és a helyzet igazságosnak érezhető legyen mindenki számára.
Vajon a konfliktus a szervezetekben valóban probléma, vagy rossz jel, ha a csapatodban gyakran (vagy csak időnként) előfordulnak konfliktusok? Általánosságban nem, hiszen ha fejlődés történik, van valamilyen dinamika, akkor felmerülnek olyan kérdések, amelyeket korábban soha nem oldottak meg, és ezek megoldása során konfliktusok léphetnek fel. Ez azt jelzi, hogy van néhány terület, amelyre figyelmet kell fordítani, hogy vannak lehetőségek a fejlesztésre. Rossz, ha a konfliktusok túl gyakran merülnek fel, nehezen vagy hosszú idő alatt oldják meg őket. Ez valószínűleg a munkafolyamatok nem megfelelő beállításának és a csapat elégtelen érettségének jele.
Forrás: habr.com
