motto:
Olipa kerran siili ja pikkukarhu tapasivat metsässä.
- Hei, Hedgehog!
- Hei, Pikku Karhu!
Joten sana sanalta, vitsi vitsiltä, siili sai lyönnin kasvoihin Pikku Karhulta...
Alla tiimimme johtajan sekä RAS:n tuotekehitysjohtaja Igor Marnatin keskustelu työkonfliktin erityispiirteistä ja mahdollisista hallintamenetelmistä.
Suurin osa työssä kohtaamistamme konflikteista kehittyy yllä olevassa epigrafissa kuvatun kaltaisen skenaarion mukaan. Useat osallistujat ovat aluksi melko suotuisasti suhtautuvia toisiinsa, he yrittävät ratkaista jonkin asian, mutta lopulta ongelma jää ratkaisematta ja keskustelun osallistujien väliset suhteet ovat jostain syystä pilalla.
Elämä on monimuotoista ja vaihtelua esiintyy yllä kuvatussa skenaariossa. Joskus osallistujien välinen suhde ei ole aluksi kovin hyvä, joskus ei edes ole suoraa ratkaisua vaativaa asiaa (kuten esimerkiksi epigrafiassa), joskus keskustelun jälkeen suhde pysyy samana kuin ennen sen alkua, mutta ongelmaa ei lopulta ratkaista.
Mikä on yhteistä kaikissa työriitatilanteeksi määriteltävissä tilanteissa?
Ensinnäkin puolta on kaksi tai useampia. Nämä osapuolet voivat sijaita organisaatiossa eri paikoissa, olla tasa-arvosuhteessa (kollegat tiimissä) tai hierarkian eri tasoilla (pomo - alainen), olla yksilöitä (työntekijä) tai ryhmää (riitatilanteissa työntekijä ja tiimi tai kaksi tiimiä) ja niin edelleen. Konfliktin todennäköisyyteen ja sen ratkaisemisen helppouteen vaikuttaa suuresti osallistujien välinen luottamus. Mitä paremmin osapuolet tuntevat toisensa, sitä korkeampi luottamus on, sitä suurempi on mahdollisuus päästä sopimukseen. Esimerkiksi hajautetun tiimin jäsenet, jotka eivät ole koskaan olleet vuorovaikutuksessa kasvokkain, joutuvat todennäköisemmin konfliktiin yksinkertaisesta työongelmasta kuin ihmiset, joilla on ollut ainakin muutaman kasvokkain vuorovaikutus. Siksi hajautetuissa tiimeissä työskennellessä on erittäin tärkeää varmistaa, että kaikki tiimin jäsenet tapaavat säännöllisesti henkilökohtaisesti toistensa kanssa.
Toiseksi, työelämän konfliktitilanteessa osapuolet ovat tilanteessa, jossa ratkaistaan jokin asia, joka on tärkeä jommallekummalle osapuolelle, molemmille tai koko organisaatiolle. Samaan aikaan tilanteen erityispiirteistä johtuen osapuolilla on yleensä riittävästi aikaa ja erilaisia tapoja ratkaista se (muodolliset, epäviralliset, tapaamiset, kirjeet, johdon päätökset, tiimin tavoitteiden ja suunnitelmien olemassaolo, hierarkian tosiasia jne.). Tämä eroaa tilanteesta, jossa organisaatiossa ratkaistaan työ- (tai ei-työ)kysymys esimerkiksi ratkaisemalla tärkeä kysymys: "Eh, poika, miltä alueelta olet?!" kadulla tai konflikti epigrafista. Työasian ratkaisemisessa on kysymys työprosessin laadusta ja asioiden ratkaisukulttuurista tiimissä.
Kolmanneksi konfliktin ratkaiseva tekijä (keskustelumme näkökulmasta) on se, että prosessin osapuolet eivät voi itsenäisesti löytää kaikille osapuolille sopivaa ratkaisua asiaan. Tilanne vaatii kolmannen osapuolen, ulkopuolisen välimiehen, väliintuloa. Tämä kohta saattaa tuntua kiistanalaiselta, mutta pohjimmiltaan, jos konfliktitilanne ratkesi onnistuneesti ilman ulkopuolisen välimiehen väliintuloa, asia ratkesi onnistuneesti ja osapuolten suhteet eivät huonontuneet, tähän tilanteeseen on pyrittävä. . Emme todennäköisesti edes tiedä tällaisesta konfliktista tai saamme sen sattumalta selville sen ratkettua. Mitä enemmän ongelmia tiimi pystyy ratkaisemaan itse, sitä tehokkaampi se on.
Toinen konfliktin ominainen piirre, johon kannattaa koskea, on emotionaalinen intensiteetti päätöksenteon aikana. Konflikti ei välttämättä liity korkeaan tunnetasoon. Osallistujien ei tarvitse huutaa ja heiluttaa käsiään, jotta tilanne olisi pohjimmiltaan konflikti. Asiaa ei ole ratkaistu, tietty tunnejännite on läsnä (ehkä se ei ilmene selvästi ulospäin), mikä tarkoittaa, että olemme ristiriitatilanteessa.
Onko konfliktitilanteisiin ylipäätään puututtava, vai onko parempi antaa niiden ratkaisun kulkea omaa tahtiaan ja odottaa, että ongelma ratkeaa itsestään? Tarvitsee. Ei ole aina sinun vallassasi tai päteväsi ratkaista konfliktia kokonaan, mutta missä tahansa tilanteessa, minkä mittakaavaisessa konfliktissa voit ottaa aikuisen kannan ja tuoda siihen useita muita ihmisiä ympärilläsi, lieventää konfliktin kielteisiä seurauksia. konflikti ja edistää sen ratkaisemista.
Ennen kuin tarkastelemme muutamia esimerkkejä konfliktitilanteista, katsotaanpa muutamia tärkeitä kohtia, jotka ovat yhteisiä kaikille konflikteille.
Konfliktia ratkaistaessa on tärkeää olla taistelun yläpuolella, ei sen sisällä (tätä kutsutaan myös "meta-asennon ottamiseksi"), eli olla osallisena ratkaisuprosessissa. Muussa tapauksessa ulkopuolisen välimiehen avustaminen päätöksenteossa vain vahvistaa toisen osapuolen asemaa toisen osapuolen kustannuksella. Päätöstä tehtäessä on tärkeää, että kaikki osapuolet hyväksyvät sen moraalisesti, kuten sanotaan "ostettu". Joten vaikka osapuolet eivät olleetkaan mielissään tehdystä päätöksestä, he ainakin vilpittömästi suostuivat panemaan sen täytäntöön. Kuten sanotaan, olla eri mieltä ja sitoutua. Muuten konflikti vain muuttaa ulkonäköään, kytevä tuli jää turvesuon alle ja syttyy jossain vaiheessa väistämättä uudelleen.
Toinen, osittain ensimmäiseen liittyvä seikka on, että jos olet jo päättänyt osallistua konfliktin ratkaisemiseen, ota se mahdollisimman vakavasti viestinnän ja kontekstin tutkimisen kannalta. Keskustele henkilökohtaisesti kunkin osapuolen kanssa. Aluksi jokaisen kanssa erikseen. Älä tyydy postiin. Hajautetun tiimin tapauksessa puhu ainakin videolinkin kautta. Älä tyydy kuulopuheisiin ja silminnäkijöiden kertomuksiin. Ymmärtää tarinan, mitä kumpikin osapuoli haluaa, miksi he haluavat sitä, mitä he odottavat, ovatko he yrittäneet ratkaista tämän ongelman aiemmin, mitä tapahtuu, jos sitä ei ratkaista, mitä ratkaisuja he näkevät, miten he kuvittelevat tilanteen toinen puoli, mitä he ajattelevat, oikein vai väärin jne. Lataa kaikki mahdollinen konteksti päähösi avoimin mielin olettaen, että kaikki ovat oikeassa. Et ole konfliktin sisällä, olet sen ulkopuolella, metaasennossa. Jos konteksti on saatavilla vain viestiketjussa, lue se ainakin kokonaisuudessaan ja siihen liittyvät säikeet ja asiakirjat. Kun olet lukenut sen, puhu silti äänelläsi. Kuulet melkein taatusti jotain tärkeää, mitä ei ole postissa.
Kolmas tärkeä seikka on yleinen lähestymistapa viestintään. Nämä ovat tavallisia asioita, ei mitään kosmista, mutta ne ovat erittäin tärkeitä. Emme yritä säästää aikaa, puhumme kaikkien osallistujien kanssa, emme kritisoi henkilöä, mutta otamme huomioon hänen tekojensa seuraukset (ei "olet töykeä", mutta "ehkä kaverit saattavat loukkaantua tämä asia”), annamme mahdollisuuden pelastaa kasvot, käymme keskusteluja henkilökohtaisesti, ei jonon edessä.
Konfliktit johtuvat yleensä kahdesta syystä. Ensimmäinen liittyy siihen, onko henkilö konfliktin hetkellä aikuisen vai lapsen asemassa (lisätietoja alla). Tämä johtuu hänen emotionaalisesta kypsyydestään, kyvystään hallita tunteitaan (joka muuten ei aina liity hänen ikänsä). Toinen yleinen syy on työprosessin epätäydellisyys, joka luo harmaita alueita, joissa vastuu jakautuu osallistujien kesken, osapuolten odotukset eivät ole läpinäkyviä toisilleen ja roolit prosessissa hämärtyvät.
Vastaavasti johtajan tulee konfliktia (sekä mitä tahansa muuta asiaa) ratkaistaessa pitää mielessä kolme näkökulmaa: lyhyt aika - ratkaista ongelma/konflikti tässä ja nyt, keskipitkän aikavälin - minimoida uuden konfliktin syntymisen todennäköisyys. samasta syystä ja pitkällä aikavälillä - viljellä aikuiskulttuuria tiimihenkilössä.
Jokaisella meistä on sisäinen lapsi, noin kolme-neljävuotias. Hän nukkuu suurimman osan ajasta töissä, mutta joskus herää ja hallitsee. Lapsella on omat prioriteettinsa. Hänelle on tärkeää vaatia, että tämä on hänen hiekkalaatikkonsa, hänen äitinsä rakastaa häntä enemmän, hänen koneensa on paras (suunnittelu on paras, hän ohjelmoi parhaiten, ...). Lapsi voi konfliktitilanteessa painaa leluja, tallata jalkojaan ja särkeä lastaan, mutta hän ei pysty ratkaisemaan aikuisten asioita (ratkaisuarkkitehtuuri, lähestymistavat automatisoituun testaukseen, julkaisupäivämäärät jne.), hän ei ajattele etuja. joukkueelle. Konfliktissa olevaa lasta voidaan rohkaista, lohduttaa ja laittaa nukkumaan pyytämällä häntä soittamaan aikuiselle. Ennen kuin aloitat keskustelun konfliktitilanteessa, varmista, että puhut aikuisen, et lapsen kanssa ja olet itse aikuisen asemassa. Jos rehellinen tavoitteesi tällä hetkellä on ratkaista vakava ongelma, olet aikuisen asemassa. Jos tavoitteenasi on polkea jalkojasi ja murtaa lapaluu, tämä on lapsellinen asento. Lähetä sisäinen lapsesi nukkumaan ja soita aikuiselle tai sovita keskustelu uudelleen. Ihminen tekee tunnepäätöksen ja etsii sitten sille rationaalista perustetta. Lapsen tekemä päätös lasten prioriteettien perusteella ei ole optimaalinen.
Lapsen tai aikuisen asemaa leimaa konfliktihetken käytöksen lisäksi myös se vastuun taso, jonka ihminen on valmis ottamaan itselleen. Äärimmäisissä ilmenemismuodoissaan ohjelmoijan lapsellinen asema, jonka olen tavannut useammin kuin kerran, näyttää tältä: kirjoitin koodin, lähetin sen tarkistettavaksi - työni on valmis. Arvostelijoiden tulee tarkistaa se ja hyväksyä se, laadunvarmistuksen tulee tarkistaa se. Jos ongelmia ilmenee, he ilmoittavat minulle. Kummallista kyllä, jopa melko kypsät ja kokeneet ihmiset käyttäytyvät joskus näin. Asteikon toinen pää on, että henkilö kokee olevansa vastuussa siitä, että hänen koodinsa toimii, on testattu, hän on henkilökohtaisesti tarkastanut, on läpäissyt tarkistuksen (tarvittaessa ei ole ongelmaa pingata arvostelijoita, keskustella asioista äänellä jne.) ja se on tukahdutettu, laadunvarmistus antaa tarvittaessa apua, testiskenaariot kuvataan jne. Normaalitapauksissa ohjelmoija joko lähtee lähemmäs asteikon aikuista päätä tai siirtyy sinne kokemuksen kerryttäessä (edellyttäen, että tiimissä viljellään oikeaa kulttuuria). Äärimmäisissä tapauksissa hän jatkaa työskentelyä ja ottaa yleensä lapsellisen asennon, jolloin hänellä ja tiimillä on ajoittain ongelmia ja konflikteja.
Oikean, kypsän kulttuurin edistäminen tiimissä on tärkeä tehtävä jokaiselle esimiehelle. Se vie paljon aikaa ja päivittäistä vaivaa, mutta tulos on sen arvoinen. Tiimikulttuuriin voi vaikuttaa kahdella tavalla - esimerkkinä johtaminen (jota ehdottomasti seurataan; tiimi katsoo aina johtajaan) ja keskustella ja palkita oikeasta käytöksestä. Tässäkään ei ole mitään hätiköityä tai kovin muodollista, vain ongelmista puhuttaessa huomaa, että täällä olisi voinut tehdä jotain, korosta, että huomasit, kun se päätettiin oikein, kehu, huomauta julkaisukatsauksen aikana jne.
Tarkastellaan useita tyypillisiä konfliktitilanteita yksinkertaisista monimutkaisiin:
Konfliktit eivät liity työasioihin
Työssä on melko usein konflikteja, jotka eivät liity työasioihin. Niiden esiintyminen ja ratkaisun helppous liittyvät yleensä suoraan osallistujien tunneälyn tasoon, heidän kypsyystasoonsa, eivätkä ne liity työprosessin täydellisyyteen tai epätäydellisyyteen.
Tyypillisiä esimerkkejä: joku ei käytä pesukonetta tai suihkua tarpeeksi usein, mistä muut eivät pidä, joku on tukkoinen, kun taas toisille tuulee ikkunan avaamisesta, joku on liian meluisa ja toiset tarvitsevat hiljaisuutta toimiakseen ja pian. On parempi olla viivyttämättä tällaisten konfliktien ratkaisemista ja olla antamatta niiden kulkea omaa kulkuaan. He eivät ratkea itsestään ja häiritsevät sinua työstä joka päivä ja myrkyttävät ilmapiirin tiimissä. Onneksi niiden ratkaiseminen ei yleensä ole suuri ongelma - keskustele vain rauhallisesti (tietysti kahden kesken) hygieniaa laiminlyövän kollegan kanssa, tarjoa mukavat istuimet hiljaisuutta/viileyttä suosiville, osta ääntä vaimentavat kuulokkeet tai asenna väliseinät , jne.
Toinen esimerkki, johon olen törmännyt useaan otteeseen työssäni, on tiimin jäsenten psyykkinen yhteensopimattomuus. Jostain syystä ihmiset eivät yksinkertaisesti voi työskennellä yhdessä, jokainen vuorovaikutus päättyy skandaaliin. Joskus tämä johtuu siitä, että ihmisillä on polaarisia näkemyksiä jostain kiireellisestä asiasta (yleensä poliittisesta), eivätkä he tiedä miten jättää niitä työn ulkopuolelle. Heidän vakuuttaminen sietämään toisiaan tai muuttamaan käyttäytymistään on melko turha tehtävä. Ainoa poikkeus, johon olen törmännyt, ovat nuoret kollegat, joilla on avoin käsitys, joiden käyttäytymistä voidaan vielä asteittain muuttaa säännöllisillä keskusteluilla. Yleensä ongelma ratkeaa onnistuneesti jakamalla heidät eri tiimeihin tai ainakin tarjoamalla harvoin mahdollisuuden päällekkäisyyteen.
Kaikissa yllä mainituissa tilanteissa kannattaa keskustella kaikkien osallistujien kanssa henkilökohtaisesti, keskustella tilanteesta, kysyä, näkevätkö he ongelmaa tässä tapauksessa, kysyä, mitkä ovat heidän mielestään ratkaisut ja varmistaa heidän osallistumisensa tämän tekemiseen. päätös.
Työprosessin optimoinnin näkökulmasta (mainitsemani keskipitkän aikavälin näkökulma) ei tässä paljoa voida tehdä, optimoinnin ainoa pointti on ottaa huomioon yhteensopivuustekijä tiimiä muodostettaessa, eikä laittaa ihmisiä. yhdessä etukäteen ketkä ovat ristiriidassa.
Tiimikulttuurin näkökulmasta tällaisia tilanteita syntyy paljon harvemmin tiimeissä, joissa on kypsä kulttuuri, jossa ihmiset kunnioittavat tiimiä ja työtovereita ja osaavat ratkaista ongelmat itsenäisesti. Lisäksi sellaiset ristiriidat ratkeavat paljon helpommin (usein automaattisesti) tiimeissä, joissa luottamus on korkea, ihmiset ovat työskennelleet yhdessä pitkään ja/tai kommunikoivat usein työn ulkopuolella.
Työasioihin liittyvät ristiriidat:
Tällaiset ristiriidat johtuvat yleensä molemmista syistä kerralla, sekä tunneperäisistä syistä (se, että toinen osallistujista ei ole aikuisen asemassa) että itse työprosessin epätäydellisyydestä. Ehkä yleisin ristiriita, jonka olen kohdannut, ovat ristiriidat koodin tarkistusten tai kehittäjien välisten arkkitehtuurikeskustelujen aikana.
Korostan tässä kaksi tyypillistä tapausta:
1) Ensimmäisessä tapauksessa kehittäjä ei voi saada koodiarviointia kollegalta. Laastari lähetetään tarkistettavaksi, eikä mitään tapahdu. Ensi silmäyksellä osapuolten välillä ei ole selvää ristiriitaa, mutta jos ajattelee sitä, tämä on melkoinen konflikti. Työkysymys ei ratkea, toinen osapuolista (odottaa arvostelua) kokee ilmeistä epämukavuutta. Tämän tapauksen äärimmäinen alatyyppi on kehitys yhteisössä tai eri tiimeissä, kun taas arvioija ei ehkä ole kiinnostunut tästä koodista latauksen tai muiden olosuhteiden vuoksi, hän ei välttämättä kiinnitä tarkistuspyyntöön ollenkaan huomiota ja ulkopuolinen tuomari (molemmille osapuolille yhteinen johtaja) ) ei välttämättä ole ollenkaan.
Tällaisessa tilanteessa auttava ratkaisu lähestymistapa liittyy nimenomaan pitkän tähtäimen perspektiiviin, aikuisen kulttuuriin. Ensinnäkin älykäs toiminta toimii. Sinun ei pitäisi odottaa, että arvostelussa oleva koodi kiinnittää itse arvioijan huomion. Meidän on autettava arvioijia huomaamaan hänet. Pingani pari ihmistä, kysy syncapesta, osallistu keskusteluihin. Ilmeisesti tyhmyydestä on enemmän haittaa kuin apua, sinun on käytettävä maalaisjärkeä. Toiseksi esivalmistelu toimii hyvin. Jos tiimi ymmärtää mitä tapahtuu ja miksi, miksi tätä koodia ylipäänsä tarvitaan, suunnittelusta on keskusteltu ja sovittu etukäteen kaikkien kanssa, ihmiset kiinnittävät todennäköisemmin huomiota sellaiseen koodiin ja hyväksyvät sen työhön. Kolmanneksi auktoriteetti toimii. Jos haluat tulla arvioitavaksi, tee itse paljon arvosteluja. Tee laadukkaita arvosteluja, joissa on todellisia tarkastuksia, todellisia testejä ja hyödyllisiä kommentteja. Jos lempinimesi tunnetaan hyvin tiimissä, on suurempi mahdollisuus, että koodisi huomataan.
Työnkulun näkökulmasta mahdollisia parannuksia tässä ovat oikea priorisointi, jonka tarkoituksena on auttaa kehittäjää saavuttamaan omat ja tiiminsä tavoitteet (tarkistaa muita, kirjoittaa kirjeitä yhteisölle, liittää koodiin arkkitehtuurin kuvaus, dokumentaatio, testit, osallistua keskusteluihin yhteisö jne.), estää korjaustiedostoja roikkumasta jonossa liian pitkään ja niin edelleen.
2) Toinen yleinen ristiriitatapaus koodin tai suunnittelun tarkastelun aikana on erilaiset näkemykset teknisistä ongelmista, koodaustyylistä ja työkalujen valinnasta. Tässä tapauksessa erittäin tärkeää on osallistujien välinen luottamus, samaan tiimiin kuuluminen ja kokemus yhteistyöstä. Umpikuja tapahtuu, kun yksi osallistujista ottaa lapsellisen asennon eikä yritä kuulla, mitä keskustelukumppani haluaa hänelle välittää. Usein sekä toisen osapuolen ehdottama lähestymistapa että alun perin ehdotettu lähestymistapa voivat hyvinkin toimia onnistuneesti, eikä sillä periaatteessa ole väliä, kumpi valita.
Eräänä päivänä tiimini ohjelmoija (kutsutaanko häntä Pashaksi) valmisteli paketin käyttöönottojärjestelmään muutoksia sisältävän korjaustiedoston, jonka kehittivät ja tukivat naapuriosaston kollegat. Yhdellä heistä (Igor) oli oma vahva mielipiteensä siitä, miten Linux-palvelut tulisi konfiguroida paketteja otettaessa. Tämä mielipide poikkesi korjaustiedostossa ehdotetusta lähestymistavasta, eivätkä he olleet samaa mieltä. Kuten tavallista, määräajat olivat loppumassa, ja oli pakko tehdä jonkinlainen päätös, jommankumman piti ottaa aikuisen asema. Pasha tunnusti, että molemmilla lähestymistavoilla on oikeus elämään, mutta hän halusi, että hänen vaihtoehtonsa menisi ohi, koska Yhdellä tai toisella vaihtoehdolla ei ollut ilmeisiä teknisiä etuja.
Keskustelumme näytti tältä (hyvin kaavamaisesti, tietysti keskustelu kesti puoli tuntia):
- Pasha, ominaisuus jäädytetään muutaman päivän kuluttua. On tärkeää saada kaikki yhteen ja aloittaa testaus mahdollisimman pian. Kuinka pääsemme Igorin läpi?
— Hän haluaa perustaa palvelut eri tavalla, hän laittoi minulle kommentteja...
- Ja mitä siellä on, suuria muutoksia, paljon meteliä?
- Ei, töitä on pari tuntia, mutta loppujen lopuksi ei ole mitään eroa, se toimii kummallakin tavalla, miksi tämä on välttämätöntä? Tein jotain, joka toimii, hyväksytään se.
- Kuuntele, kuinka kauan olet keskustellut tästä kaikesta?
- Kyllä, olemme merkinneet aikaa nyt puolitoista viikkoa.
- Hm... voimmeko ratkaista ongelman parissa tunnissa, joka on kestänyt jo puolitoista viikkoa, emmekä tee sitä?
- No, kyllä, mutta en halua, että Igor ajattelee, että minä antauduin...
- Kuuntele, mikä on sinulle tärkeämpää, vapauttaa päätöksesi sisällä vai tappaa Igor? Voimme estää sen, mutta silloin on kuitenkin hyvä mahdollisuus lentää läpi julkaisun kanssa.
- No... olisi tietysti siistiä pyyhkiä Igorin nenä, mutta okei, vapauttaminen on tärkeämpää, olen samaa mieltä.
- Onko sinulle todella niin tärkeää, mitä Igor ajattelee? Rehellisesti sanottuna hän ei välitä yhtään, hän haluaa vain yhtenäisen lähestymistavan eri paikoissa siihen asiaan, josta hän on vastuussa.
- No, ok, anna minun tehdä niin kuin hän pyytää kommenteissa ja aloitetaan testaus.
- Kiitos, Pasha! Olin varma, että teistä kahdesta olisitte kypsempi, vaikka Igorek onkin sinua vanhempi :)
Ongelma ratkesi, julkaisu julkaistiin ajoissa, Pasha ei tuntenut suurta tyytymättömyyttä, koska hän itse ehdotti ratkaisua ja toteutti sen. Igor oli yleisesti ottaen tyytyväinen, koska... Hänen mielipiteensä otettiin huomioon ja he tekivät niin kuin hän ehdotti.
Toinen olennaisesti samantyyppinen ristiriita on valinta teknisten ratkaisujen/kirjastojen/lähestymistapojen välillä projektissa, erityisesti hajautetussa tiimissä. Yhdessä C/C++:aa käyttäväksi asemoidussa projektissa kävi ilmi, että projektin tekninen johtaminen vastusti jyrkästi STL:n (Standard Template Library) käyttöä. Tämä on standardikielikirjasto, joka yksinkertaistaa kehitystä, ja tiimimme on hyvin tottunut siihen. Kävi ilmi, että projekti on paljon lähempänä C:tä kuin C++:aa, mikä ei inspiroinut tiimiä kovinkaan paljon, koska johto yritti parhaansa ja rekrytoi todella upeita plus-pelaajia. Samaan aikaan tiimin amerikkalainen osa, sekä insinöörit että johtajat, olivat työskennelleet yrityksessä pitkään, olivat tottuneet vallitsevaan tilanteeseen ja olivat kaikkeen tyytyväisiä. Joukkueen venäläinen osa koottiin äskettäin, muutaman viikon sisällä (minä mukaan lukien). Tiimin venäläinen osa ei kategorisesti halunnut hylätä tavanomaista kehitystä.
Loputtomat kirjalliset keskustelut alkoivat kahden mantereen välillä, kirjeitä kolmella tai neljällä näytöllä lensi edestakaisin, ryhmäpostituksissa ja henkilökohtaisissa kirjeissä ohjelmoijista ohjelmoijille ja johtajille. Kuten yleensä, tämän pituisia kirjeitä ei lukenut kukaan muu kuin kirjoittajat ja heidän innokkaat kannattajansa. Chatit narisevat jännityksestä, jakoivat usean näytön ajatuksia eri suuntiin koskivat STL:n teknisiä etuja, kuinka hyvin se on testattu, kuinka turvallista se on ja ylipäänsä kuinka ihanaa elämä sen kanssa on ja kuinka kauheaa se on ilman sitä .
Tämä kaikki kesti melko pitkään, kunnes lopulta tajusin, että keskustelimme asian teknisistä puolista, mutta ongelma ei todellisuudessa ollut tekninen. Ongelma ei ole STL:n edut tai haitat tai ilman sitä työskentelyn vaikeus. Ongelma on pikemminkin organisatorinen. Meidän piti vain ymmärtää, kuinka yritys, jossa työskentelimme, toimi. Kenelläkään meistä ei ollut aiemmin kokemusta tällaisessa yrityksessä. Asia oli siinä, että koodin kehittämisen ja tuotantoon julkaisun jälkeen tuesta vastasivat täysin eri ihmiset muista tiimeistä, muista maista. Tällä useiden kymmenien tuhansien insinöörien (yhteensä) valtavalla insinööritiimillä oli varaa vain täysin perustavanlaatuisiin teknisiin välineisiin, niin sanotusti minimiin. Mitään, mikä ylittää yrityksessä vahvistetun suunnittelustandardin fyysisesti, ei voida tukea tulevaisuudessa. Joukkueen tason määrää sen heikoimpien jäsenten taso. Sen jälkeen kun ymmärsimme todellista motivaatiota tiimin amerikkalaisen osan toimista tämä asia poistettiin esityslistalta, ja yhdessä kehitimme ja julkaisimme tuotteen onnistuneesti yhtiön hyväksymiä standardeja käyttäen. Kirjeet ja chatit eivät tässä tapauksessa toimineet hyvin, kesti useita matkoja ja paljon henkilökohtaista kommunikointia, jotta yhteiseen nimittäjään päästiin.
Työnkulun kannalta tässä nimenomaisessa tapauksessa auttaisi kuvaus käytetyistä työkaluista, niitä koskevista vaatimuksista, uusien lisäämisen rajoituksista ja rajoitusten perusteluista. Tällaiset asiakirjat vastaavat suunnilleen niitä, jotka on kuvattu kohdassa Uudelleenkäyttöstrategia ja Kehitysympäristö "Ohjelmiston ohjelmistokehityksen johtajan käsikirja", kehitetty . Iästään huolimatta se kuvaa täydellisesti kaikki tämän tyyppisen ohjelmistokehityksen päätoiminnot ja suunnitteluvaiheet. Tällaisten asiakirjojen avulla on erittäin helppoa keskustella siitä, mitä komponentteja ja lähestymistapoja tuotteessa voidaan käyttää ja miksi.
Kulttuurin näkökulmasta luonnollisesti kypsemmällä asemalla, jossa osapuolet yrittävät kuulla ja ymmärtää kollegoidensa toiminnan todellisen motivaation ja toimia projektin ja tiimin prioriteettien, ei henkilökohtaisen egon perusteella. , konflikti ratkeaisi helpommin ja nopeammin.
Toisessa teknisen ratkaisun valintaa koskevassa ristiriidassa kesti myös minulta huomattavan paljon aikaa ymmärtää toisen osapuolen motivaatio (erittäin epätavallinen tapaus), mutta kun motivaatio oli selvä, ratkaisu oli ilmeinen.
Tilanne on tämä: noin 20 hengen tiimiin ilmestyy uusi kehittäjä, kutsutaan häntä Stasiksi. Tuolloin tavallinen tiimiviestinnän työkalumme oli Skype. Kuten myöhemmin kävi ilmi, Stas oli suuri avointen standardien ja avoimen lähdekoodin ohjelmistojen fani ja käytti vain työkaluja ja käyttöjärjestelmiä, joiden lähteet olivat julkisesti saatavilla ja jotka käyttivät julkisesti kuvattuja protokollia. Skype ei ole yksi näistä työkaluista. Käytimme paljon aikaa keskusteluun tämän lähestymistavan eduista ja haitoista, yrityksistä käynnistää Skypen analogeja eri käyttöjärjestelmissä, Stasin yrityksissä saada tiimi siirtymään muihin standardeihin, kirjoittaa hänelle henkilökohtaisesti postitse, soittaa hänelle henkilökohtaisesti puhelinta, osta hänelle toinen tietokone erityisesti Skypeä varten jne. Lopulta ymmärsin, että tämä ongelma ei ole pohjimmiltaan tekninen tai organisatorinen, se on pikemminkin ideologinen, jopa, voisi sanoa, uskonnollinen (Stasille). Vaikka lopulta yhdistäisimme Stasin ja Skypen (mikä kesti useita kuukausia), ongelma ilmaantuisi uudelleen missä tahansa myöhemmässä instrumentissa. Minulla ei ollut käytössäni todellisia keinoja muuttaa Stasin maailmankuvaa, eikä ollut mitään syytä yrittää muuttaa tässä ympäristössä täydellisesti toimineen tiimin maailmankuvaa. Henkilö ja yritys olivat yksinkertaisesti ortogonaalisia maailmankuvassaan. Tällaisissa tilanteissa hyvä ratkaisu on organisatorinen. Siirsimme Stasin toiseen joukkueeseen, jossa hän oli orgaanisempi.
Syy tähän ristiriitaan on mielestäni tietyn henkilön henkilökohtaisen kulttuurin (jolla on vahva mielipide, joka ei salli hänen tehdä kompromisseja) ja yrityksen kulttuurin välinen ristiriita. Tässä tapauksessa se on tietysti johtajan virhe. Aluksi oli väärin ottaa hänet mukaan tällaiseen projektiin. Lopulta Stas siirtyi avoimen lähdekoodin ohjelmistokehitysprojektiin ja menestyi siellä.
Hyvä esimerkki konfliktista, joka johtuu sekä kehittäjän lapsellisesta asenteesta että työprosessin puutteista, on tilanne, jossa tehdyn määritelmän puuttuessa kehittäjällä ja laadunvarmistustiimillä on erilaiset odotukset valmiudesta. ominaisuus siirrettiin laadunvarmistukseen. Kehittäjä uskoi, että koodin kirjoittaminen ja ominaisuuden heittäminen aidan yli riitti QA:lle - he selvittäisivät sen siellä. Melko kypsä ja kokenut ohjelmoija muuten, mutta se oli hänen sisäinen laadun kynnys. QA oli eri mieltä tästä ja vaati näyttämään ja kuvailemaan heille, mitä hän oli itse tarkistanut, ja vaati heille testauskäsikirjoituksen. Heillä oli aiemmin ollut ongelmia tämän kehittäjän toiminnassa, eivätkä he halunneet tuhlata aikaansa uudelleen. Muuten, he olivat oikeassa - ominaisuus ei todellakaan toiminut, hän ei tarkistanut koodia ennen sen lähettämistä QA:lle.
Tilanteen ratkaisemiseksi pyysin häntä näyttämään minulle, että kaikki todella toimi (se ei toiminut, ja hänen täytyi korjata se), keskustelimme tiimin kanssa ja laadunvarmistuksen määritelmästä valmiiksi (he eivät päässeet sisään kirjoittaminen, koska emme halunneet tehdä prosessista liian byrokraattista ), no, erosimme pian tämän asiantuntijan kanssa (yleiseksi helpotukseksi).
Työnkulun kannalta mahdollisia parannuksia tässä tapauksessa ovat valmiin määritelmän olemassaolo, kunkin yksikön ominaisuuden tukivaatimukset ja integrointitestit sekä kehittäjän suorittaman testauksen kuvaus. Yhdessä projektista mittasimme koodipeittotason testeillä CI:n aikana ja jos peittotaso putosi korjaustiedoston lisäämisen jälkeen, testit merkittiin epäonnistuneiksi, ts. uusi koodi voidaan lisätä vain, jos sille olisi uusia testejä.
Toinen tyypillinen esimerkki konfliktista, joka liittyy läheisesti työprosessin organisointiin. Meillä on tuote, tuotekehitystiimi, tukitiimi ja asiakas. Asiakkaalla on ongelmia tuotteen kanssa ja hän ottaa yhteyttä tukeen. Tuki analysoi ongelman ja ymmärtää, että ongelma on tuotteessa ja siirtää ongelman tuotetiimille. Tuotetiimillä on kiire, julkaisu lähestyy, joten asiakkaan ongelmallinen lippu, joka on kadonnut sen kehittäjän muiden lippujen joukkoon, jolle se on osoitettu, roikkuu useita viikkoja ilman huomiota. Tuki uskoo, että kehittäjä työskentelee asiakkaan ongelman parissa. Asiakas odottaa ja toivoo, että hänen ongelmaansa korjataan. Todellisuudessa mitään ei tapahdu vielä. Muutaman viikon kuluttua asiakas päättää viimein olla kiinnostunut etenemisestä ja kysyy tuelta, miten asiat etenevät. Tuki vaatii kehitystä. Kehittäjä vapisee, selaa lippuluetteloa ja löytää sieltä lipun asiakkaalta. Lukeessaan lipun asiakkaalta hän ymmärtää, että ongelman ratkaisemiseksi ei ole tarpeeksi tietoa, ja hän tarvitsee lisää tukkeja ja kaatopaikkoja. Tuki pyytää asiakkaalta lisätietoja. Ja sitten asiakas tajuaa, ettei kukaan ole työskennellyt hänen ongelmansa parissa koko tämän ajan. Ja ukkonen iskee...
Tässä tilanteessa itse konfliktin ratkaisu on melko ilmeinen ja lineaarinen (korjaa tuote, päivitä dokumentaatio ja testit, rauhoittaa asiakasta, julkaise hotfix-korjaus jne.). On tärkeää analysoida työprosessia ja ymmärtää, kuka on vastuussa kahden tiimin välisen vuorovaikutuksen järjestämisestä ja miksi tämä tilanne ylipäätään tuli mahdolliseksi. On selvää, mitä prosessissa pitää korjata - jonkun on seurattava kokonaiskuvaa ilman asiakkaiden muistutuksia, ennakoivasti. Asiakkaan lippujen tulee erottua muiden kehittäjien lippujen joukosta. Tuen pitäisi nähdä, työskenteleekö kehitystiimi parhaillaan lippujaan, ja jos ei, milloin se voi aloittaa työn ja milloin tuloksia voidaan odottaa. Tuen ja kehityksen tulisi säännöllisin väliajoin viestiä ja keskustella lippujen tilasta, virheenkorjaukseen tarvittavan tiedon kerääminen tulisi automatisoida mahdollisimman pitkälle jne.
Aivan kuten sodassa vihollinen yrittää iskeä kahden yksikön väliseen risteykseen, niin työssäkin herkin ja haavoittuvin kohta on yleensä joukkueiden välinen vuorovaikutus. Jos tuki- ja kehityspäälliköt ovat tarpeeksi vanhoja, he pystyvät korjaamaan prosessin itse, jos ei, niin prosessi jatkaa konfliktien ja ongelmien synnyttämistä, kunnes johtaja puuttuu asiaan, joka voi korjata tilanteen.
Toinen tyypillinen esimerkki, jonka olen nähnyt toistuvasti eri yrityksissä, on tilanne, jossa tuotteen kirjoittaa yksi tiimi, automaattiset integraatiotestit sille kirjoittaa toinen tiimi ja infrastruktuuria, jossa sitä kaikkea käytetään, seuraa kolmas tiimi. tiimi. Ongelmia testien suorittamisessa syntyy jatkuvasti, ja niiden ongelmien syy voi olla sekä tuote että testit ja infrastruktuuri. Yleensä on ongelmallista sopia siitä, kenen tulee suorittaa ensimmäinen ongelmien, tiedostovirheiden, tuotteen jäsennyslokien, testien ja infrastruktuurin jne. analyysi. Konfliktit ovat täällä hyvin yleisiä ja samalla yhtenäisiä. Korkean tunneintensiteetin tapauksessa osallistujat joutuvat usein lapselliseen asemaan ja sarjassa alkaa keskustelu: "miksi minun pitäisi puuhailla tätä", "he hajoavat useammin" jne.
Työnkulun näkökulmasta tarkat vaiheet ongelman ratkaisemiseksi riippuvat ryhmien kokoonpanosta, testien ja tuotteen tyypistä jne. Yhdessä projektista otimme käyttöön määräaikaisen päivystyksen, jossa tiimit seurasivat testejä yksi kerrallaan, viikoittain. Toisessa alkuperäisen analyysin tekivät aina testikehittäjät, mutta analyysi oli hyvin yksinkertainen ja tuote oli melko vakaa, joten se toimi hyvin. Tärkeintä on varmistaa, että prosessi on läpinäkyvä, odotukset selkeät kaikille osapuolille ja tilanne tuntuu kaikille oikeudenmukaiselta.
Onko konflikti edes ongelma organisaatiossa?Onko se huono merkki, että konflikteja esiintyy usein (tai vain ajoittain) tiimissäsi? Yleisesti ottaen ei, koska jos on kasvua, kehitystä, on jonkinlaista dynamiikkaa, niin syntyy asioita, joita ei ole koskaan ratkaistu ennen, ja niitä ratkaistaessa voi syntyä konflikteja. Tämä on osoitus siitä, että jotkut alueet kaipaavat huomiota, että on alueita, joita on parannettava. On huonoa, jos konflikteja syntyy usein, niitä on vaikea ratkaista tai kestää kauan. Tämä on todennäköisesti merkki riittämättömästä virtaviivaistetusta työprosessista ja joukkueen riittämättömästä kypsyydestä.
Lähde: will.com