Konfliktuskezelés egy csapatban – egyensúlyozás vagy létszükséglet?

mottó:
Egyszer régen a Süni és a Kis Medve találkozott az erdőben.
- Szia Süni!
- Szia Kis Medve!
Szóval szóról szóra, viccről tréfára, a Sünit arcon ütötte a Kis Medve...

Az alábbiakban csoportvezetőnk, valamint Igor Marnat RAS termékfejlesztési igazgató beszélgetése olvasható a munkahelyi konfliktusok sajátosságairól és azok kezelésének lehetséges módszereiről.

A legtöbb konfliktus, amellyel a munkahelyünkön találkozunk, a fenti epigráfban leírthoz hasonló forgatókönyv szerint alakul ki. A résztvevők közül többen eleinte meglehetősen kedvezően viszonyulnak egymáshoz, próbálnak megoldani egy-egy kérdést, de végül a probléma megoldatlan marad, és valamiért a beszélgetés résztvevői közötti kapcsolatok megromlottak.

Az élet változatos, és a fent leírt forgatókönyvben is előfordulnak változatok. Előfordul, hogy kezdetben nem túl jó a kapcsolat a résztvevők között, néha nincs is olyan kérdés, ami közvetlen megoldást igényel (mint pl. az epigráfban), néha a megbeszélés után a kapcsolat ugyanaz marad, mint a kezdete előtt, de a probléma végül nem oldódik meg.

Mi a közös minden munkahelyi konfliktushelyzetként definiálható helyzetben?



Először is, két vagy több oldala van. Ezek a felek különböző helyeket foglalhatnak el a szervezetben, lehetnek egyenrangú viszonyban (kollégák egy csapatban), vagy a hierarchia különböző szintjein (főnök - beosztott), lehetnek egyéniek (alkalmazotti) vagy csoportosak (konfliktusok esetén alkalmazott és egy vagy két csapat), és így tovább. A konfliktus valószínűségét és a megoldás könnyűségét nagyban befolyásolja a résztvevők közötti bizalom szintje. Minél jobban ismerik egymást a felek, minél magasabb a bizalom szintje, annál nagyobb az esély arra, hogy megegyezésre jutnak. Például egy elosztott csapat tagjai, akik soha nem léptek kapcsolatba személyesen, nagyobb valószínűséggel élnek át konfliktust egy egyszerű munkahelyi probléma miatt, mint azok, akiknek volt már legalább néhány személyes interakciója. Ezért az elosztott csapatokban végzett munka során nagyon fontos gondoskodni arról, hogy minden csapattag rendszeresen találkozzon személyesen egymással.

Másodszor, a munkahelyi konfliktushelyzetben a felek valamilyen, az egyik fél, mindkettő vagy a szervezet egésze számára fontos kérdés megoldásának helyzetében vannak. Ugyanakkor a helyzet sajátosságaiból adódóan a feleknek általában elegendő idejük és változatos módjuk van a megoldásra (formális, informális, értekezletek, levelek, vezetői döntések, a csapat céljainak, terveinek megléte, a hierarchia ténye stb.). Ez különbözik attól a helyzettől, amikor egy munkahelyi (vagy nem munkahelyi) problémát egy szervezetben például egy fontos kérdés megoldásával oldanak meg: "Eh, kölyök, melyik területről származol?!" az utcán, vagy a konfliktus az epigráfból. Munkaprobléma megoldása esetén számít a munkafolyamat minősége, a problémamegoldás kultúrája a csapatban.

Harmadszor, a konfliktus meghatározó tényezője (beszélgetésünk szempontjából) az, hogy a folyamatban részt vevő felek nem tudnak önállóan olyan megoldást találni a kérdésben, amely minden fél számára megfelelő. A helyzet egy harmadik fél, külső döntőbíró beavatkozását igényli. Ez a pont ellentmondásosnak tűnhet, de lényegében, ha a konfliktushelyzetet külső döntőbíró beavatkozása nélkül sikerült megoldani, a kérdést sikeresen megoldották és a felek viszonya nem romlott meg, akkor erre a helyzetre kell törekedni. . Valószínűleg nem is fogunk tudni egy ilyen konfliktusról, vagy véletlenül megtudjuk, miután megoldódott. Minél több problémát tud egy csapat önállóan megoldani, annál hatékonyabb lesz.

A konfliktus másik jellemző jellemzője, amelyet érdemes érinteni, az érzelmi intenzitás mértéke a döntés során. A konfliktus nem feltétlenül kapcsolódik magas érzelmi szinthez. A résztvevőknek nem kell kiabálniuk és karjukat hadonászniuk ahhoz, hogy a helyzet lényegében konfliktus legyen. A kérdés nem oldódik meg, van egy bizonyos érzelmi feszültség (talán nem fejeződik ki egyértelműen), ami azt jelenti, hogy konfliktushelyzettel állunk szemben.

Egyáltalán kell-e beavatkozni a konfliktushelyzetekbe, vagy jobb, ha hagyjuk a megoldásukat a maga útján, és várjuk meg, míg a probléma magától megoldódik? Kell. Nem mindig az Ön hatalmában vagy hatáskörében a konfliktus teljes megoldása, de bármilyen helyzetben, bármilyen léptékű konfliktusban felnõtt álláspontra helyezkedhet, ezzel több embert is bevonva maga köré, mérsékelheti a konfliktus negatív következményeit. konfliktust, és hozzájárulnak annak megoldásához.

Mielőtt megnéznénk néhány példát a konfliktushelyzetekre, nézzünk meg néhány fontos pontot, amelyek minden konfliktusra jellemzőek.

A konfliktus feloldásakor fontos, hogy a harc felett álljunk, és ne azon belül (ezt „metapozíció felvételének” is nevezik), vagyis ne legyünk részesei a megoldási folyamat egyik felének. Ellenkező esetben, ha külső döntőbíró segíti a döntést, az csak az egyik fél pozícióját erősíti a másik fél rovására. A döntés meghozatalakor fontos, hogy azt erkölcsileg minden fél elfogadja, ahogy mondani szokták: „megvásárolták”. Így, ha a felek nem is örültek a döntésnek, legalább őszintén beleegyeztek annak végrehajtásába. Ahogy mondani szokták, hogy tudjunk egyet nem érteni és elköteleződni. Ellenkező esetben a konfliktus egyszerűen megváltoztatja a megjelenését, a parázsló tűz a tőzegláp alatt marad, és egy ponton elkerülhetetlenül újra fellángol.

A második, részben az elsőhöz kapcsolódó pont az, hogy ha már úgy döntött, hogy részt vesz a konfliktus megoldásában, vegye azt a kommunikáció és a kontextus tanulmányozása szempontjából a lehető legkomolyabban. Beszéljen személyesen mindegyik féllel. Kezdésnek mindegyikkel külön. Ne elégedj meg a postával. Elosztott csapat esetén legalább videolinken keresztül beszélgessünk. Ne elégedjen meg a hallomásokkal és a szemtanúk jelentéseivel. Értsék a történetet, mit akarnak mindkét fél, miért akarják, mit várnak el, próbálták-e korábban megoldani ezt a problémát, mi lesz, ha nem oldódik meg, milyen megoldásokat látnak, hogyan képzelik el a másik oldal, mit gondolnak, jó vagy rossz, stb. Nyitott elmével töltse be az összes lehetséges összefüggést a fejébe, feltételezve, hogy mindenkinek igaza van. Nem a konfliktuson belül vagy, hanem azon kívül, metapozícióban. Ha a szövegkörnyezet csak egy bejegyzésszálban érhető el, legalább olvassa el teljes egészében és a hozzá kapcsolódó szálakat és dokumentumokat. Miután elolvasta, továbbra is beszéljen a hangjával. Szinte garantáltan hallasz valami fontosat, ami nincs a levélben.

A harmadik fontos pont a kommunikáció általános megközelítése. Ezek hétköznapi dolgok, semmi kozmikus, de nagyon fontosak. Nem próbálunk időt spórolni, beszélgetünk minden résztvevővel, nem kritizáljuk az illetőt, hanem mérlegeljük tettei következményeit (nem „durva vagy”, hanem „talán megsértődhetnek a srácok ez a dolog”), lehetőséget adunk az arcmentésre, személyesen folytatjuk a megbeszéléseket, nem a sor előtt.

A konfliktusokat általában két ok egyike okozza. Az első azzal kapcsolatos, hogy egy személy a konfliktus idején felnőtt vagy gyermek helyzetében van-e (erről bővebben lentebb). Ez érzelmi érettségének, érzelmei kezelésére való képességének köszönhető (ami egyébként nem mindig függ össze az életkorával). A második gyakori ok a munkafolyamat tökéletlensége, amely szürke zónák helyzetét teremti meg, amelyben 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, a folyamatban betöltött szerepek összemosódnak.

Ennek megfelelően a konfliktus (és minden más kérdés) megoldása során a vezetőnek három szempontot kell szem előtt tartania: rövid távú - a probléma/konfliktus megoldása itt és most, középtáv -, hogy minimalizálja egy újabb konfliktus kialakulásának valószínűségét. ugyanezen okból, és hosszú távú - a felnőtt kultúra ápolása a csapatszemélyben.

Mindannyiunknak van egy belső gyermeke, körülbelül három-négy éves. A legtöbb időt a munkahelyén alszik, de néha felébred és átveszi az irányítást. A gyereknek saját prioritásai vannak. Fontos, hogy ragaszkodjon hozzá, hogy ez az ő homokozója, az anyja jobban szereti, a gépe a legjobb (a tervezés a legjobb, ő programoz a legjobban, ...). Konfliktushelyzetben a gyermek megnyomhatja a játékokat, tapossa a lábát és repesztheti a spatulát, de nem tudja megoldani a felnőttkori kérdéseket (megoldás architektúrája, automatizált tesztelés megközelítései, megjelenési dátumok stb.), nem gondolkodik előnyökben a csapatért. A konfliktusban lévő gyermeket úgy lehet bátorítani, vigasztalni és lefeküdni, ha megkérjük, hogy hívja fel a felnőttét. Mielőtt konfliktushelyzetben megbeszélést kezdenél, győződj meg arról, hogy felnőtthez beszélsz, nem gyerekhez, és te magad is felnőtt pozícióban vagy. Ha az őszinte célod pillanatnyilag egy komoly probléma megoldása, akkor felnőtt helyzetben vagy. Ha az a cél, hogy megtaposd a lábad és megreped a lapockád, ez gyerekes pozíció. Küldje le a belső gyermekét, és hívjon fel egy felnőttet, vagy ütemezze át a beszélgetést. Az ember érzelmi döntést hoz, majd racionális indoklást keres rá. A gyermek által a gyermek prioritásai alapján hozott döntés nem lesz optimális.

A gyermek vagy felnőtt helyzetét a konfliktuskori viselkedésen kívül az is jellemzi, hogy az ember milyen felelősséget vállal magára. Extrém megnyilvánulásaiban a programozó gyerekes álláspontja, amellyel nem egyszer találkoztam, így néz ki: megírtam a kódot, elküldtem felülvizsgálatra - a munkám kész. A bírálók nézzék át és hagyják jóvá, a QA ellenőrizze, ha probléma van, jelezni fognak. Furcsa módon néha még a meglehetősen érett és tapasztalt emberek is így viselkednek. A skála másik vége, hogy egy személy felelősnek tekinti magát azért, hogy kódja működjön, teszteljék, személyesen ellenőrizték-e, sikeresen átment a felülvizsgálaton (szükség esetén nincs probléma a lektorok pingelése, a kérdések megbeszélése). hanggal stb.) és le van tiltva, a minőségbiztosítási hatóság szükség esetén segítséget nyújt, a tesztforgatókönyvek leírása stb. Normális esetben a programozó vagy közelebb indul a skála felnőtt végéhez, vagy a tapasztalatszerzés során odaköltözik (feltéve, hogy a csapaton belül a megfelelő kultúrát művelik). Szélsőséges esetekben továbbra is dolgozik, általában gyerekes pozíciót foglal el, ekkor időnként problémái, konfliktusai vannak vele és a csapattal.

A megfelelő, érett kultúra ápolása egy csapatban minden menedzser számára fontos feladat. Hosszú időt és napi erőfeszítést igényel, de az eredmény megéri. A csapatkultúra befolyásolásának két módja van: példamutatás (amit biztosan követni fog; a csapat mindig a vezetőre néz), illetve a helyes viselkedés megvitatása és jutalmazása. Itt sincs semmi elgondolatlan vagy nagyon formális, csak a problémák megbeszélésekor vegyük észre, hogy itt lehetett volna valamit tenni, hangsúlyozzuk, hogy észrevetted, mikor döntöttek helyesen, dicsérd meg, jegyezd meg a kiadás felülvizsgálata során, stb.

Nézzünk meg néhány tipikus konfliktushelyzetet, az egyszerűtől a bonyolultig:

Nem munkahelyi problémákkal kapcsolatos konfliktusok

Gyakran előfordulnak olyan konfliktusok a munkahelyen, amelyek nem a munkahelyi kérdésekhez kapcsolódnak. Előfordulásuk és feloldásuk könnyűsége általában közvetlenül összefügg a résztvevők érzelmi intelligenciájával, érettségi szintjével, és nincs összefüggésben a munkafolyamat tökéletességével vagy tökéletlenségével.

Tipikus példák: valaki nem használja elég gyakran a mosógépet vagy zuhanyozót, amit mások nem szeretnek, valaki fülledt, míg másoknak szél támad, ha kinyitják az ablakot, valaki túl zajos, másoknak csendre van szükségük a munkához, ill. hamar. Jobb, ha nem halogatod az ilyen jellegű konfliktusok megoldását, és nem hagyod, hogy a maguk útján haladjanak. Nem oldódnak meg maguktól, és minden nap elvonják a figyelmét a munkáról, és megmérgezik a csapat légkörét. Szerencsére ezek megoldása általában nem jelent nagy problémát – csak beszélgessen nyugodtan (természetesen személyesen) a higiéniát figyelmen kívül hagyó kollégával, biztosítson kényelmes ülőhelyet a csendet/hűvösséget kedvelőknek, vásároljon hangelnyelő fejhallgatót vagy szereljen fel válaszfalakat. stb.

Egy másik példa, amellyel munkám során többször találkoztam, a csapattagok pszichológiai összeférhetetlensége. Valamiért az emberek egyszerűen nem tudnak együtt dolgozni, minden interakció botránnyal végződik. Ez néha annak a ténynek köszönhető, hogy az emberek sarkos nézeteket vallanak valamilyen sürgető (általában politikai) kérdésben, és nem tudják, hogyan hagyják el őket a munkán kívül. Meglehetősen hiábavaló feladat meggyőzni őket, hogy tűrjék egymást, vagy változtassák meg viselkedésüket. Az egyetlen kivétel, akivel találkoztam, a nyitott felfogású fiatal kollégák, akiknek viselkedése még mindig fokozatosan változtatható időszakos beszélgetésekkel. Általában a problémát úgy oldják meg sikeresen, hogy külön-külön csoportokba osztják őket, vagy legalábbis lehetőséget biztosítanak a munkahelyi átfedésekre nagyon ritkán.

A fenti szituációk mindegyikében érdemes személyesen beszélni minden résztvevővel, megbeszélni a helyzetet, megkérdezni, hogy lát-e egyáltalán problémát ebben az esetben, megkérdezni, hogy szerintük mik a megoldások, és biztosítani a részvételt ebben az esetben. döntés.

A munkafolyamat optimalizálása (az általam említett középtávú perspektíva) szempontjából itt nem sokat lehet tenni, az optimalizálás egyetlen lényege, hogy a csapatalakításnál vegyük figyelembe a kompatibilitási tényezőt, és ne az embereket helyezzük el. előre össze, ki fog konfliktusba kerülni.

Csapatkultúra szempontjából ilyen helyzetek sokkal ritkábban fordulnak elő érett kultúrájú csapatokban, ahol az emberek tisztelik a csapatot és a kollégákat, és tudják, hogyan kell önállóan megoldani a problémákat. Ráadásul az ilyen konfliktusok sokkal könnyebben (gyakran automatikusan) megoldódnak olyan csapatokban, ahol nagy a bizalom, az emberek régóta dolgoznak együtt és/vagy gyakran kommunikálnak a munkán kívül.

Munkaügyi problémákkal kapcsolatos konfliktusok:

Az ilyen konfliktusokat általában mindkét ok egyszerre okozza, mind érzelmi (az, hogy az egyik résztvevő nincs felnőtt pozícióban), mind pedig magának a munkafolyamatnak a tökéletlensége. Talán a leggyakoribb konfliktustípus, amellyel találkoztam, a kódellenőrzés vagy a fejlesztők közötti architektúra-megbeszélések során fellépő konfliktusok.

Két tipikus esetet emelnék ki itt:

1) Az első esetben a fejlesztő nem kérhet kódellenőrzést egy kollégájától. A javítást elküldik felülvizsgálatra, és semmi sem történik. Első pillantásra nincs nyilvánvaló konfliktus a két fél között, de ha jobban belegondolunk, ez eléggé konfliktus. A munkahelyi probléma nem oldódik meg, az egyik fél (ellenőrzésre várva) nyilvánvaló kényelmetlenséget tapasztal. Ennek az esetnek egy szélsőséges altípusa a közösségben vagy különböző csapatokban történő fejlesztés, miközben előfordulhat, hogy a lektort nem érdekli ez a kód, betöltés vagy egyéb körülmények miatt, egyáltalán nem figyel a felülvizsgálati kérelemre, illetve a külső döntőbíró (mindkét oldalon közös menedzser) ) előfordulhat, hogy egyáltalán nem létezik.

Az ilyen helyzetben segítő megoldási szemlélet pontosan a hosszú távú perspektívához, a felnőtt kultúrájához kapcsolódik. Először is, az okos tevékenység működik. Nem számíthat arra, hogy az ismertetőn lógó kód magára az értékelő figyelmét felkelti. Segítenünk kell a bírálóknak, hogy észrevegyék őt. Pingani pár ember, tegyen fel kérdést a syncape-ról, vegyen részt a megbeszéléseken. Nyilvánvaló, hogy az udvariatlanság inkább árt, mint segít, használd a józan észt. Másodszor, az előzetes előkészítés jól működik. Ha a csapat érti, hogy mi és miért történik, miért van egyáltalán szükség erre a kódra, a dizájnt mindenkivel előre megbeszélték és egyeztették, akkor az emberek nagyobb valószínűséggel odafigyelnek egy ilyen kódra és elfogadják a munkára. Harmadszor, a tekintély működik. Ha azt szeretné, hogy értékeljék, készítsen sok értékelést saját maga. Készítsen jó minőségű értékeléseket valódi ellenőrzésekkel, valódi tesztekkel és hasznos megjegyzésekkel. Ha a beceneved jól ismert a csapatban, nagyobb az esély arra, hogy a kódodat észreveszik.

Munkafolyamat szempontjából a lehetséges fejlesztések itt a helyes prioritások, amelyek célja, hogy segítsék a fejlesztőt saját és a csapat céljainak elérésében (másokat áttekinteni, levelet írni a közösségnek, a kódot architektúra leírással, dokumentációval, tesztekkel kísérni, beszélgetésekben részt venni közösség stb.), megakadályozza, hogy a javítások túl sokáig lógjanak a sorban, és így tovább.

2) A kód- vagy tervezési felülvizsgálatok során fellépő ütközések második gyakori esete a technikai kérdésekről, a kódolási stílusról és az eszközök megválasztásáról szóló eltérő nézet. Ebben az esetben nagyon fontos a résztvevők közötti bizalom szintje, az egy csapathoz való tartozás és a közös munka tapasztalata. Zsákutca akkor következik be, amikor az egyik résztvevő gyerekes pozíciót foglal el, és nem próbálja meghallani, mit akar a beszélgetőpartner közölni vele. Gyakran előfordul, hogy mind a másik fél által javasolt megközelítés, mind az eredetileg javasolt megközelítés sikeresen működik, és elvileg mindegy, hogy melyiket válasszam.

Egy nap a csapatom egyik programozója (nevezzük pasának) elkészített egy javítást a csomagtelepítési rendszer módosításával, amelyet a szomszédos részleg munkatársai fejlesztettek ki és támogattak. Egyiküknek (Igornak) volt határozott véleménye arról, hogy pontosan hogyan kell a Linux-szolgáltatásokat konfigurálni a csomagok telepítésekor. Ez a vélemény eltért a javításban javasolt megközelítéstől, és nem tudtak egyetérteni. Szokás szerint fogytak a határidők, kellett valamiféle döntést hozni, kellett, hogy valamelyikük felnőtt állást foglaljon el. Pasa felismerte, hogy mindkét megközelítésnek joga van az élethez, de azt akarta, hogy a választási lehetősége elmúljon, mert Sem az egyik, sem a második lehetőségnek nem volt nyilvánvaló technikai előnye.

A beszélgetésünk valahogy így nézett ki (persze nagyon sematikusan fél óráig tartott a beszélgetés):

- Pasha, néhány napon belül lefagyunk. Fontos, hogy mindent összerakjunk, és a lehető leghamarabb elkezdjük a tesztelést. Hogyan jutunk át Igoron?
— Másként akarja beállítani a szolgáltatásokat, nekem odaragasztotta a kommenteket...
- És mi van ott, nagy átalakítások, nagy felhajtás?
- Nem, van pár óra munka, de végülis nincs különbség, úgy is menni fog, miért van erre szükség? Csináltam valamit, ami működik, fogadjuk el.
- Figyelj, mióta tárgyalod mindezt?
- Igen, már másfél hete jelöljük az időt.
- Hm... pár óra alatt megoldhatunk egy kérdést, ami már másfél hétbe telt, és nem tesszük meg?
- Nos, igen, de nem akarom, hogy Igor azt higgye, hogy belebuktam...
- Figyelj, mi a fontosabb számodra, hogy szabadlábra helyezd a belső döntéseddel együtt, vagy megöld Igort? Letilthatjuk, akkor viszont jó eséllyel átrepülünk a kiadással.
- Hát... persze jó lenne megtörölni Igor orrát, de oké, az elengedés fontosabb, egyetértek.
- Tényleg ennyire fontos neked, hogy Igor mit gondol? Hogy őszinte legyek, egyáltalán nem törődik vele, csak egységes megközelítést szeretne a dolog különböző helyein, amiért felelős.
- Nos, oké, hadd tegyem, amit a megjegyzésekben kér, és kezdjük a tesztelést.
- Köszönöm, pasa! Biztos voltam benne, hogy kettőtök közül te leszel az érettebb, bár Igorek idősebb nálad :)

A probléma megoldódott, a kiadás időben megjelent, Pasha nem érzett nagy elégedetlenséget, mert ő maga javasolta a megoldást és végrehajtotta azt. Igor általában elégedett volt, mert... A véleményét figyelembe vették, és úgy tettek, ahogy javasolta.

A lényegében ugyanennek a konfliktusnak egy másik típusa a műszaki megoldások/könyvtárak/megközelítések közötti választás egy projektben, különösen egy elosztott csapatban. Az egyik, C/C++-t használó projektben kiderült, hogy a projekt technikai irányítása kategorikusan ellenzi az STL (Standard Template Library) használatát. Ez egy szabványos nyelvi könyvtár, amely leegyszerűsíti a fejlesztést, és csapatunk nagyon megszokta. Kiderült, hogy a projekt sokkal közelebb áll a C-hez, mint a C++-hoz, ami nem nagyon inspirálta a csapatot, mert a vezetőség mindent megtett, és nagyon klassz plusz játékosokat toborzott. Ugyanakkor a csapat amerikai része, mérnökök és menedzserek egyaránt régóta dolgoztak a cégnél, hozzászoktak a jelenlegi állapotokhoz, és mindennel elégedettek voltak. Nemrég, néhány héten belül összeállt a csapat orosz része (én is). A csapat orosz része kategorikusan nem akarta feladni a fejlesztés szokásos megközelítését.

Végtelen írásos viták kezdődtek a két kontinens között, három-négy képernyőn oda-vissza repültek a levelek, csoportos és személyes küldeményekben, a programozóktól a programozókig és menedzserekig. Mint általában, az ilyen hosszúságú leveleket a szerzőkön és lelkes támogatóikon kívül senki sem olvasta. Feszülten csikorogtak a csevegések, a többképernyős gondolatok különböző irányba terelve az STL technikai előnyeit, mennyire jól tesztelték, mennyire biztonságos, és általában, milyen csodálatos az élet vele, és milyen szörnyű nélküle. .

Ez az egész elég sokáig tartott, míg végül rájöttem, hogy a probléma technikai vonatkozásait tárgyaljuk, de a probléma valójában nem technikai volt. A probléma nem az STL előnyei vagy hátrányai, vagy a nélküle való munka nehézsége. A probléma inkább szervezési. Csak meg kellett értenünk, hogyan működik a cég, ahol dolgoztunk. Korábban egyikünknek sem volt tapasztalata ilyen cégnél. A helyzet az volt, hogy a kód kifejlesztése és gyártásba kerülése után a támogatást teljesen más emberek kezelték más csapatokból, más országokból. Ez a hatalmas, több tízezer mérnökből álló mérnökcsapat (összesen) csak egy teljesen alapvető technikai eszközöket engedhetett meg magának, úgymond minimális minimumot. Bármi, ami fizikailag meghaladja a vállalatnál megállapított mérnöki szabványt, a jövőben nem támogatható. Egy csapat szintjét a leggyengébb tagjainak szintje határozza meg. Miután megértettük igazi motiváció a csapat amerikai részének intézkedései miatt ez a kérdés lekerült a napirendről, és közösen sikeresen fejlesztettük és adtuk ki a terméket a cég által elfogadott szabványok alapján. A levelek és a chat ebben az esetben nem működtek jól, több utazásra és sok személyes kommunikációra volt szükség, hogy közös nevezőre jussunk.

A munkafolyamat szempontjából ebben a konkrét esetben segítséget jelentene a használt eszközök leírása, a velük szemben támasztott követelmények, az újak hozzáadásával kapcsolatos korlátozások és az ilyen korlátozások indoklása. Az ilyen dokumentumok nagyjából megfelelnek a „Szoftverfejlesztési menedzser kézikönyve” Újrahasználati stratégia és Fejlesztési környezet című bekezdéseiben leírtaknak. NASA. Kora ellenére tökéletesen leírja az ilyen jellegű szoftverfejlesztés összes fő tevékenységét és tervezési szakaszát. Az ehhez hasonló dokumentumok birtokában nagyon könnyű megvitatni, hogy milyen összetevők és megközelítések használhatók egy termékben, és miért.

Kulturális szempontból nyilván érettebb pozícióval, amelyben a felek igyekeznek meghallani és megérteni kollégáik cselekvésének valódi motivációját, és a projekt és a csapat prioritásai, nem pedig a személyes ego alapján cselekszenek. , a konfliktus könnyebben és gyorsabban megoldódna.

Egy másik, a műszaki megoldás megválasztása körüli konfliktusban is érezhetően sok időbe telt, mire megértettem az egyik fél motivációját (nagyon szokatlan eset volt), de miután a motiváció egyértelmű volt, a megoldás kézenfekvő volt.

A helyzet a következő: egy körülbelül 20 fős csapatban megjelenik egy új fejlesztő, nevezzük Stasnak. Akkoriban a csapatos kommunikáció standard eszköze a Skype volt. Mint később kiderült, Stas nagy rajongója volt a nyílt szabványoknak és a nyílt forráskódú szoftvereknek, és csak olyan eszközöket és operációs rendszereket használt, amelyek forrásai nyilvánosak voltak, és amelyek nyilvánosan leírt protokollokat használtak. A Skype nem tartozik ezen eszközök közé. Sok időt töltöttünk azzal, hogy megvitassuk ennek a megközelítésnek az előnyeit és hátrányait, a Skype analógjainak elindítására tett kísérleteket különböző operációs rendszereken, Stas megpróbálta meggyőzni a csapatot, hogy váltsanak át más szabványokra, írjunk neki személyesen e-mailben, hívjuk személyesen a telefon, vegyél neki egy második számítógépet kifejezetten Skype-hoz stb. Végül rájöttem, hogy ez a probléma lényegében nem technikai vagy szervezeti, inkább ideológiai, sőt, mondhatni vallási (Stas esetében). Még akkor is, ha végül összekapcsolnánk a Stast és a Skype-ot (ami több hónapig tartott), a probléma újra felmerülne bármely későbbi hangszeren. Nem állt rendelkezésemre valódi eszköz Stas világnézetének megváltoztatására, és semmi okom nem volt arra, hogy megpróbáljam megváltoztatni egy olyan csapat világképét, amely ebben a környezetben tökéletesen működött. A személy és a társaság egyszerűen ortogonális volt a világnézetében. Ilyen helyzetekben a jó megoldás a szervezés. Stast áthelyeztük egy másik csapathoz, ahol sokkal organikusabb volt.

Ennek a konfliktusnak az oka véleményem szerint az adott személy személyes kultúrája (akinek erős véleménye van, amely nem engedi meg a kompromisszumot) és a vállalati kultúra közötti eltérés. Ebben az esetben természetesen a menedzser hibája. Kezdetben helytelen volt egy ilyen projektben részt venni. Stas végül egy nyílt forráskódú szoftverfejlesztési projekthez költözött, és ott remekelt.

A fejlesztő gyerekes hozzáállása és a munkafolyamat hiányosságai miatt kialakuló konfliktusra jó példa az a helyzet, amikor a kész definíció hiányában a fejlesztő és a minőségbiztosítási csapat eltérő elvárásokat támaszt a fejlesztők felkészültségét illetően. a szolgáltatás átkerült a minőségbiztosításba. A fejlesztő úgy vélte, elég megírni a kódot, és átdobni a funkciót a kerítésen a QA-hoz – ott majd megoldják. Meglehetősen érett és tapasztalt programozó egyébként, de ez volt a belső minőségi küszöbe. A QA ezzel nem értett egyet, és azt követelte, mutassa meg és írja le nekik, amit ő maga ellenőrzött, és tesztelési forgatókönyvet kért számukra. Korábban problémáik voltak a fejlesztő működésével, és nem akarták újra pazarolni az idejüket. Mellesleg igazuk volt - a funkció valóban nem működött, nem ellenőrizte a kódot, mielőtt elküldte volna a QA-nak.

A helyzet megoldása érdekében megkértem, mutassa meg, hogy minden tényleg működik (nem működött, és meg kellett javítania), beszélgettünk a csapattal és a minőségbiztosítási definícióval, hogy kész (nem sikerült írás, mert nem akartuk túl bürokratikussá tenni a folyamatot ), nos, ettől a szakembertől hamar elváltak útjaink (általános megkönnyebbülésre).

A munkafolyamat szempontjából a lehetséges fejlesztések ebben az esetben a kész definíció megléte, az egyes egységfunkciók támogatására vonatkozó követelmények és az integrációs tesztek, valamint a fejlesztő által végzett tesztelés leírása. Az egyik projektben a CI során tesztekkel mértük a kódlefedettség szintjét, és ha a lefedettség szintje leesett patch hozzáadása után, akkor a teszteket sikertelennek jelöltük, pl. bármilyen új kódot csak akkor lehetett hozzáadni, ha új tesztek lennének hozzá.

Egy másik tipikus példa a munkafolyamat megszervezéséhez szorosan kapcsolódó konfliktusra. Van egy termékünk, egy termékfejlesztő csapatunk, egy támogató csapatunk és egy ügyfelünk. Az ügyfélnek problémái vannak a termékkel, és kapcsolatba lép a támogatással. A támogatás elemzi a problémát, és megérti, hogy a probléma a termékben van, és átadja a problémát a termékcsapatnak. A termékcsapat zsúfolt időszakban van, megjelenés közeledik, ezért egy ügyféltől származó, problémás jegy, amely elveszett a hozzárendelt fejlesztő jegyei között, több hétig lóg, figyelmetlenül. A támogatás úgy gondolja, hogy a fejlesztő az ügyfél problémáján dolgozik. Az ügyfél vár, és reméli, hogy a problémáján dolgoznak. A valóságban még nem történik semmi. Néhány hét elteltével az ügyfél végül úgy dönt, hogy érdeklődik a fejlemények iránt, és támogatást kér, hogyan állnak a dolgok. A támogatás fejlesztést kér. A fejlesztő megborzong, átnézi a jegyek listáját, és ott talál jegyet az ügyféltől. Egy ügyfél jegyét olvasva megérti, hogy nincs elég információ a probléma megoldásához, és több rönkre és szemétlerakóra van szüksége. A támogatás további információkat kér az ügyféltől. És akkor az ügyfél rájön, hogy senki sem dolgozott a problémáján egész idő alatt. És mennydörgés fog ütni...

Ebben a helyzetben maga a konfliktus megoldása meglehetősen nyilvánvaló és lineáris (a termék javítása, a dokumentáció és a tesztek frissítése, az ügyfél megnyugtatása, gyorsjavítás kiadása stb.). Fontos elemezni a munkafolyamatot, és megérteni, hogy ki a felelős a két csapat közötti interakció megszervezéséért, és miért vált lehetségessé ez a helyzet. Egyértelmű, hogy mit kell javítani a folyamat során - valakinek figyelnie kell az összképet az ügyfelek figyelmeztetése nélkül, proaktívan. Az ügyféltől származó jegyeknek kiemelkedniük kell a fejlesztők jegyei közül. A támogatásnak látnia kell, hogy a fejlesztőcsapat jelenleg dolgozik-e a jegyeken, és ha nem, mikor kezdheti el a munkát, és mikor várható eredmények. A támogatásnak, fejlesztésnek időszakonként kommunikálnia és megbeszélnie kell a jegyek állapotát, a hibakereséshez szükséges információgyűjtést lehetőleg automatizálni kell stb.

Ahogy a háborúban az ellenség két egység találkozási pontját próbálja eltalálni, úgy a munkában is általában a csapatok közötti interakció a legkényesebb és legsebezhetőbb pont. Ha a támogatási és fejlesztési menedzserek elég idősek, akkor saját maguk is meg tudják oldani a folyamatot, ha nem, akkor a folyamat továbbra is konfliktusokat és problémákat generál, amíg nem lép közbe egy menedzser, aki meg tudja oldani a helyzetet.

Egy másik tipikus példa, amelyet többször is láttam különböző cégeknél, az a helyzet, amikor egy terméket egy csapat ír, az automatikus integrációs teszteket egy második csapat írja, és az infrastruktúrát, amelyen mindez működik, egy harmadik kíséri. csapat. A tesztek futtatásakor folyamatosan felmerülnek problémák, amelyekben a problémák oka lehet a termék és a tesztek és az infrastruktúra egyaránt. Általában problémás megegyezni abban, hogy ki végezze el a problémák kezdeti elemzését, a fájlhibákat, a termék naplóit, a teszteket és az infrastruktúrát stb. A konfliktusok itt nagyon gyakoriak, ugyanakkor egységesek. Magas érzelmi intenzitás esetén a résztvevők gyakran gyerekes helyzetbe kerülnek, és a sorozatban elkezdődnek a viták: „miért bütyköljem ezt”, „gyakrabban törnek össze” stb.

A munkafolyamat szempontjából a probléma megoldásának konkrét lépései a csapatok összetételétől, a tesztek és a termék típusától stb. függenek. Az egyik projektben bevezettük az időszakos ügyeletet, amelyben a csapatok egyenként, hétről hétre figyelték a teszteket. A másikban a kezdeti elemzést mindig a tesztfejlesztők végezték, de az elemzés nagyon alap volt, a termék pedig elég stabil volt, így jól működött. A legfontosabb annak biztosítása, hogy a folyamat átlátható legyen, az elvárások minden fél számára világosak legyenek, és a helyzet mindenki számára igazságos legyen.

Egy szervezetben még probléma is a konfliktus?Rossz jel, hogy gyakran (vagy csak időszakosan) előfordulnak konfliktusok a csapatodban? Általában nem, mert ha van növekedés, fejlődés, van valamiféle dinamika, akkor olyan kérdések merülnek fel, amelyek korábban soha nem oldódtak meg, és ezek megoldása során konfliktusok adódhatnak. Ez azt jelzi, hogy bizonyos területekre oda kell figyelni, vannak fejlesztendő területek. Rossz, ha a konfliktusok nagyon gyakran merülnek fel, nehezen oldhatók meg vagy sokáig tartanak. Ez valószínűleg a nem kellően egyszerűsített munkafolyamatok és a csapat elégtelen érettségének a jele.

Forrás: will.com