Epigrafea:
Bazen behin, Trikua eta Hartz Txikia basoan elkartu ziren.
- Kaixo, Trikua!
- Kaixo, Hartz txikia!
Beraz, hitzez hitz, txantxaz txantxa, Hartz Txikiak aurpegian jo zuen Trikua...
Jarraian, gure taldeburuaren eta Igor Marnat RASeko Produktuen Garapeneko zuzendariaren eztabaida bat dago, lan-gatazkaren berezitasunei eta horiek kudeatzeko balizko metodoei buruz.
Lanean aurkitzen ditugun gatazka gehienak goiko epigrafean azaldutakoaren antzeko eszenatoki baten arabera garatzen dira. Hainbat parte-hartzaile daude hasieran elkarren artean nahiko jarrera onean daudenak; arazoren bat konpontzen saiatzen ari dira, baina azkenean arazoa konpondu gabe dago, eta arrazoiren batengatik eztabaidan parte hartzen dutenen arteko harremanak hondatu egiten dira.
Bizitza anitza da, eta gorago azaldutako eszenatokian aldaerak gertatzen dira. Batzuetan parte-hartzaileen arteko harremana ez da oso ona hasieran, beste batzuetan ez dago zuzeneko konponbiderik behar duen gairik ere (epigrafean adibidez), beste batzuetan eztabaidaren ondoren harremana hasi aurretik zegoen berdina izaten jarraitzen du, baina arazoa azkenean ez da konpondu.
Zer da ohikoa lan gatazka egoera gisa defini daitezkeen egoera guztietan?
Lehenik eta behin, bi alde edo gehiago daude. Alderdi hauek erakundean leku desberdinak okupatu ditzakete, berdintasun-harremanean egon (talde bateko lankideak), edo hierarkiaren maila ezberdinetan (nagusia - menpekoa), banakakoa (langilea) edo taldekoa (batez baten arteko gatazka kasuetan). langilea eta talde bat edo bi talde), eta abar. Gatazkaren probabilitateak eta bere konponbidearen erraztasunak eragin handia dute parte-hartzaileen arteko konfiantza mailak. Alderdiek zenbat eta hobeto ezagutu, orduan eta konfiantza maila handiagoa, orduan eta aukera handiagoa izango dute akordio batera iristeko. Esate baterako, aurrez aurre inoiz elkarreragin izan ez duten talde banatu bateko kideek litekeena da laneko arazo soil baten ondorioz gatazkak bizitzea, aurrez aurre elkarrekintza gutxi batzuk izan dituzten pertsonek baino. Horregatik, banatutako taldeetan lan egitean, oso garrantzitsua da taldekide guztiak aldian-aldian elkartzen direla bermatzea.
Bigarrenik, laneko gatazka-egoeran, alderdiak alderdietako batentzat, bientzat edo erakunde osoarentzat garrantzitsua den gairen bat konpontzeko egoeran daude. Aldi berean, egoeraren berezitasunak direla-eta, alderdiek normalean denbora nahikoa eta hainbat modu dituzte konpontzeko (formalak, informalak, bilerak, gutunak, kudeaketa erabakiak, taldearen helburu eta planen presentzia, hierarkia bat, etab.). Erakunde batean laneko (edo lanekoa ez den) arazo bat ebazteko egoeratik ezberdina da, adibidez, galdera garrantzitsu bat ebaztearekin: "Eh, mutil, zein arlokoa zara?!" kalean, edo epigrafetik gatazka. Lan-arazo bat ebazteko kasuan, lan-prozesuaren kalitatea eta gaiak taldean ebazteko kultura gai dira.
Hirugarrenik, gatazkaren erabakigarria (gure eztabaidaren ikuspuntutik) prozesuko alderdiek ezin dutela modu independentean alderdi guztiei dagokien gaiari irtenbidea eman. Egoerak hirugarren baten esku hartzea eskatzen du, kanpoko arbitro batena. Puntu honek eztabaidagarria dirudi, baina, funtsean, gatazka-egoera arrakastaz konpontzen bazen kanpoko arbitro baten esku-hartzerik gabe, arazoa arrakastaz konpondu zen eta alderdien harremanak ez ziren okerrera egin, hau da ahalegindu beharko genukeen egoera. . Seguruenik ez dugu halako gatazka baten berri ere ezagutuko, edo kasualitatez jakingo dugu hori konpondu ondoren. Talde batek bere kabuz konpondu ditzakeen arazo gehiago, orduan eta eraginkorragoa izango da.
Gatazkaren beste ezaugarri bat ukitzea merezi duena da erabakia hartzerakoan intentsitate emozionalaren maila. Gatazka ez dago zertan maila emozional altuarekin lotuta. Parte-hartzaileek ez dute zertan oihukatu eta besoak astintzen egoera, funtsean, gatazka izan dadin. Gaia ez da konpontzen, nolabaiteko tentsio emozional bat dago (agian ez da kanpotik argi adierazten), horrek esan nahi du gatazka egoera baten aurrean gaudela.
Beharrezkoa al da gatazka-egoeretan esku hartzea edo hobe da haien konponbideak bere bidea egiten uztea eta arazoa berari irtenbidea arte itxarotea? Behar. Ez dago beti zure esku edo eskumeneko gatazka guztiz konpontzea, baina edozein egoeratan, edozein mailatako gatazkan, helduen jarrera har dezakezu eta, horrela, zure inguruko hainbat pertsona gehiago hurbilduz, ondorio negatiboak arintzen ditu. gatazka eta konponbidean laguntzea.
Gatazka egoeren adibide batzuk aztertu aurretik, ikus ditzagun gatazka guztietan komunak diren puntu garrantzitsu batzuk.
Gatazka bat konpontzean, garrantzitsua da borrokaren gainetik egotea, eta ez horren barruan (horri βmeta-posizio bat hartzeaβ ere esaten zaio), hau da, konponbide prozesuan alderdietako baten parte ez izatea. Bestela, erabakian kanpoko arbitro baten laguntza izateak alderdietako baten jarrera indartu baino ez du egingo bestearen kaltetan. Erabaki bat hartzerakoan, garrantzitsua da alderdi guztiek moralki onartzea, esaten duten moduan, "erosi". Beraz, nahiz eta alderdiak pozik ez egon hartutako erabakiarekin, gutxienez zintzo adostu zuten hura gauzatzea. Esaten dutenez, ados egon eta konprometitu ahal izateko. Bestela, gatazkak itxura besterik ez du aldatuko, sua sutsua zohikaztegiaren azpian geratuko da eta noizbait berriro piztuko da.
Bigarren puntua, neurri batean lehenengoarekin lotuta, zera da: gatazkaren konponbidean parte hartzea erabaki baduzu, ahalik eta serioen hartu komunikazioen eta testuinguruaren azterketaren ikuspegitik. Pertsonalki hitz egin alderdietako bakoitzarekin. Bakoitzak bereizita, hasteko. Ez konformatu postarekin. Banatutako talde baten kasuan, gutxienez hitz egin bideo-esteken bidez. Ez zaitez konformatu entzumen eta lekukoen txostenekin. Istorioa ulertzea, alde bakoitzak zer nahi duen, zergatik nahi duten, zer espero duten, aurretik saiatu ote diren arazo hau konpontzen, zer gertatuko den konpontzen ez bada, zer irtenbide ikusten dituzten, nola imajinatzen duten posizioa. beste aldean, zer uste dute, ongi ala gaizki, etab. Kargatu zure buruan testuinguru posible guztia, gogo irekiarekin, denek arrazoia dutela suposatuz. Ez zaude gatazkaren barruan, kanpoan zaude, metaposizio batean. Testuingurua post-hari batean bakarrik badago, irakurri gutxienez osorik eta hari lotutako hariak eta dokumentuak. Irakurri ondoren, hitz egin oraindik zure ahotsarekin. Ia ziurtatuta duzu posta elektronikoan ez dagoen zerbait garrantzitsua entzutea.
Hirugarren puntu garrantzitsua komunikazioaren ikuspegi orokorra da. Gauza arruntak dira, ezer kosmikorik, baina oso garrantzitsuak dira. Ez gara denbora aurrezten saiatzen, parte hartzaile guztiekin hitz egiten dugu, ez dugu pertsona kritikatzen, baina bere ekintzen ondorioak kontuan hartzen ditugu (ez βzakarra zaraβ, baizik eta βagian mutilak minduta egon daitezkeβ. gauza hauβ), aurpegia salbatzeko aukera ematen dugu, eztabaidak pertsonalki egiten ditugu, ez lerro aurrean.
Gatazkak bi arrazoi hauetako batek sortzen ditu normalean. Lehenengoa gatazkaren unean pertsona bat helduen edo ume baten posizioan dagoen ala ez (hori gehiago behean). Heldutasun emozionalagatik gertatzen da hori, bere emozioak kudeatzeko gaitasunagatik (hori, bide batez, ez dago beti adinarekin erlazionatuta). Bigarren arrazoi arrunta lan-prozesuaren inperfekzioa da, eta horrek eremu grisen egoerak sortzen ditu, non parte-hartzaileen artean erantzukizuna zabaltzen den, alderdien itxaropenak elkarren artean gardenak ez diren eta prozesuan rolak lausotu egiten dira.
Horren arabera, gatazka bat ebazteko (baita beste edozein arazo ere), kudeatzaileak hiru ikuspuntu izan behar ditu kontuan: epe laburrean - arazoa/gatazka hemen eta orain konpontzeko, epe ertainean - beste gatazka bat sortzeko aukera gutxitzeko. arrazoi beragatik, eta epe luzerako - taldean helduen kultura lantzea.
Gutako bakoitzak barne ume bat du, hiruzpalau urte ingurukoa. Lanean lo egiten du gehienetan, baina batzuetan esnatu eta kontrola hartzen du. Haurrak bere lehentasunak ditu. Garrantzitsua da bere harea-kutxa hori dela azpimarratzea, amak gehiago maite duela, bere makina onena dela (diseinua onena da, onena programatzen du, ...). Gatazka egoeran, haurrak jostailuak sakatu, oinak zapaldu eta espatula apurtu ditzake, baina ezin ditu helduen arazoak konpondu (konponbide-arkitektura, proba automatikoen planteamenduak, kaleratze-datak, etab.), ez du onuren arabera pentsatzen. taldearentzat. Gatazkan dagoen haur bat animatu, kontsolatu eta ohera bidal daiteke bere helduari deitzeko eskatuz. Gatazka egoeran eztabaidan hasi aurretik, ziurtatu heldu batekin hitz egiten ari zarela, ez ume batekin, eta zu zeu heldu baten egoeran zaudela. Momentu honetan zure helburu zintzoa arazo larri bat konpontzea bada, heldu baten egoeran zaude. Zure helburua oinak zapaltzea eta omoplata haustea bada, hau haurren posizioa da. Bidali barruko haurra ohera eta deitu heldu bati, edo berriro antolatu eztabaida. Pertsona batek erabaki emozional bat hartzen du, eta gero horren justifikazio arrazional bat bilatzen du. Haur batek haurren lehentasunetan oinarrituta hartutako erabakia ez da egokiena izango.
Gatazka-unean jokabideaz gain, haurraren edo helduaren posizioak pertsona batek bere gain hartzeko prest dagoen erantzukizun-maila ere bereizten du. Bere muturreko agerpenetan, behin baino gehiagotan ezagutu dudan programatzaile baten haur posizioak itxura hau du: kodea idatzi nuen, berrikusteko bidali nuen - nire lana amaitu da. Ebaluatzaileek berrikusi eta onartu beharko lukete, QA egiaztatu beharko lukete, arazoak izanez gero, jakinaraziko didate. Bitxia bada ere, nahiko helduak eta esperientziadunak ere horrela jokatzen dute batzuetan. Eskalaren beste muturra da pertsona batek bere kodea funtzionatzen duela ziurtatzeko ardura duela, probek estalita dagoela, berak pertsonalki egiaztatu duela, berrikuspena behar bezala gainditu duela (beharrezkoa bada, ez dago arazorik berrikusleei ping egiteko, gaiak eztabaidatzeko. ahotsez, etab.) eta kendu egin da, QA-k laguntza emango du behar izanez gero, proba-egoerak deskribatuko dira, etab. Kasu normaletan, programatzailea helduen eskalaren muturretik hurbilago hasten da, edo hara mugitzen da esperientzia hartzen duen heinean (taldearen barruan kultura egokia lantzen bada). Muturreko kasuetan, lanean jarraitzen du, normalean umeen jarrera hartuz, orduan berak eta taldeak aldian-aldian arazoak eta gatazkak izaten dituzte.
Taldean kultura egokia eta heldua sustatzea zeregin garrantzitsua da edozein zuzendarirentzat. Denbora luzea eta eguneroko ahalegina eskatzen du, baina emaitzak merezi du. Taldearen kulturan eragiteko bi modu daude: adibidearen bidez gidatzea (behin betiko jarraituko duena; taldeak beti begiratzen dio liderrari) eta jokabide egokia eztabaidatzea eta saritzea. Hemen ere ez dago ezer abstrusorik edo oso formalik, arazoei buruz eztabaidatzerakoan, ohartu hemen zerbait egin zitekeela, azpimarratu behar bezala erabaki zenean ohartu zarela, goraipatu, ohartu oharra berrikuspenean, etab.
Ikus ditzagun gatazka-egoera tipiko batzuk, sinpleetatik konplexuetara:
Laneko gaiekin zerikusirik ez duten gatazkak
Askotan lan-gatazkak izaten dira lan-gaiekin zerikusirik ez dutenak. Haien agerraldia eta ebazteko erraztasuna parte-hartzaileen adimen emozionalarekin, heldutasun mailarekin zuzenean lotuta egon ohi dira, eta ez daude lan-prozesuaren perfekzioarekin edo inperfekzioarekin.
Adibide tipikoak: norbaitek ez du garbigailua edo dutxa behar bezain maiz erabiltzen, besteei gustatzen ez zaiena, norbait beteta dago, beste batzuek leihoa irekiz gero haizea hartzen dute, norbait zaratatsuegia da eta besteek isiltasuna behar dute lan egiteko, eta abar. Hobe da mota honetako gatazken konponbidea ez atzeratzea eta ez uztea beren bidea egiten. Ez dira euren kabuz konponduko eta egunero lanetik urrunduko zaituzte eta taldeko giroa pozoituko dute. Zorionez, horiek konpontzea normalean ez da arazo handi bat - lasai hitz egin (bat-batean, noski) higienea alde batera uzten duen lankide batekin, eserleku erosoak eskaini isiltasuna/freskotasuna nahiago duten pertsonei, soinu xurgatzaileak erosi edo partizioak instalatu. , etab.
Nire lanean hainbat aldiz topatu dudan beste adibide bat taldekideen bateraezintasun psikologikoa da. Zerbaitegatik, jendeak ezin du elkarrekin lan egin; elkarrekintza bakoitza iskanbila batean amaitzen da. Batzuetan, jendeak premiazko gai batzuei buruz (normalean politikoak) iritzi polarrak dituelako eta ez dakiela lanetik kanpo nola utzi. Elkar toleratzeko edo portaera aldatzeko konbentzitzea alferrikako zeregina da. Topatu dudan salbuespen bakarra pertzepzio irekia duten lankide gazteak dira; haien jokabidea oraindik pixkanaka alda daiteke aldizkako elkarrizketen bidez. Normalean arazoa ondo konpontzen da talde ezberdinetan banatuz, edo, gutxienez, lanean gainjartzeko aukera oso gutxitan emanez.
Aurreko egoera guztietan, merezi du parte-hartzaile guztiekin pertsonalki hitz egitea, egoeraz eztabaidatzea, kasu honetan arazoren bat ikusten duten galdetzea, zeintzuk diren, haien ustez, irtenbideak galdetzea eta hau egiteko parte hartzea ziurtatzea. erabakia.
Lan-prozesua optimizatzearen ikuspuntutik (aipatzen dudan epe ertainerako ikuspegia), hemen ezin da gauza handirik egin; optimizatzeko puntu bakarra taldea osatzerakoan bateragarritasun-faktorea kontuan hartzea da eta ez jendea jartzea. elkarrekin aldez aurretik nor izango da gatazka.
Taldearen kulturaren ikuspegitik, horrelako egoerak askoz gutxiagotan sortzen dira kultura heldua duten taldeetan, non jendeak taldea eta lankideak errespetatzen dituen eta gaiak modu independentean konpontzen dakienean. Gainera, horrelako gatazkak askoz errazago konpontzen dira (askotan automatikoki) konfiantza handia dagoen taldeetan, jendeak denbora luzez elkarrekin lan egin duen eta/edo lanetik kanpo maiz komunikatzen diren taldeetan.
Laneko gaiekin lotutako gatazkak:
Halako gatazkak bi arrazoik aldi berean sortu ohi dituzte, bai emozionalak (parte-hartzaileetako bat heldu baten egoeran ez egoteak) bai lan-prozesuaren beraren inperfekzioek. Beharbada, aurkitu ditudan gatazka mota ohikoenak kodeen berrikuspenetan edo garatzaileen arteko arkitekturako eztabaidetan izan daitezke.
Hemen bi kasu tipiko nabarmenduko nituzke:
1) Lehenengo kasuan, garatzaileak ezin du lankide baten kode berrikuspena jaso. Adabakia berrikusteko bidaltzen da, eta ez da ezer gertatzen. Lehen begiratuan, ez dago bi aldeen arteko gatazka nabaririk, baina pentsatuz gero, nahiko gatazka da. Lanaren arazoa ez da konpontzen, alderdietako batek (berrikuspenaren zain) ondoeza nabaria izaten du. Kasu honen muturreko azpimota bat komunitate batean edo talde ezberdinetan garatzea da, baliteke ebaluatzaileari kode jakin hau interesatzen ez izatea, kargagatik edo beste zirkunstantzia batzuengatik, baliteke berrikuspen-eskaerari batere erreparatu eta kanpoko arbitroak. (bi aldeetako kudeatzaile komuna) ) baliteke inola ere ez egotea.
Egoera horretan laguntzen duen irtenbide-ikuspegia, hain zuzen ere, epe luzeko ikuspegiari dagokio, helduaren kulturari. Lehenik eta behin, jarduera adimendunak funtzionatzen du. Ez duzu espero behar berrikuspenean zintzilik dagoen kodeak ebaluatzailearen beraren arreta erakarriko duenik. Berrikusleei berari erreparatzen lagundu behar diegu. Pingani pertsona pare bat, sincapeari buruzko galdera bat egin, eztabaidetan parte hartu. Jakina, inportunitateak kalte egiteko aukera gehiago du laguntzea baino, zentzua erabili behar duzu. Bigarrenik, aurre-prestaketak ondo funtzionatzen du. Taldeak ulertzen badu zer gertatzen den eta zergatik, zergatik behar den kode hori, diseinua aldez aurretik guztiekin eztabaidatu eta adostu bada, jendeak gehiago litekeena da kode horri kasu egitea eta lanerako onartzea. Hirugarrenik, autoritateak funtzionatzen du. Berrikuspena jaso nahi baduzu, egin berrikuspen asko zeuk. Egin kalitate handiko berrikuspenekin, egiaztapen errealekin, proba errealekin eta iruzkin erabilgarriekin. Zure goitizena taldean ezaguna bada, aukera handiagoa dago zure kodea ohartzeko.
Lan-fluxuaren ikuspuntutik, hemen hobekuntza posibleak lehenespen zuzena dira, garatzaileari bere eta taldearen helburuak lortzen laguntzera bideratua (besteak berrikusi, komunitateari gutunak idatzi, kodea arkitektura deskribapenarekin batera, dokumentazioa, probak, eztabaidetan parte hartzea. komunitatea, etab.), saihestu adabakiak ilaran denbora gehiegiz zintzilikatzea, eta abar.
2) Kodearen edo diseinuaren berrikuspenetan gertatzen den gatazkaren bigarren kasua arazo teknikoei, kodetze-estiloari eta tresnen aukeraketari buruzko ikuspegi desberdinak dira. Kasu honetan garrantzi handia dute parte-hartzaileen arteko konfiantza mailak, talde berekoak izateak eta elkarrekin lan egiteko esperientziak. Bide hil bat gertatzen da parte-hartzaileetako batek umeen jarrera hartzen duenean eta solaskideak helarazi nahi diona entzuten saiatzen ez denean. Askotan, bai beste alderdiak proposatutako planteamenduak bai hasieran proposatutakoak ondo funtziona dezakete eta printzipioz ez du axola zein aukeratu.
Egun batean, nire taldeko programatzaile batek (dei dezagun Pasha) adabaki bat prestatu zuen paketeak zabaltzeko sisteman aldaketekin, aldameneko sail bateko lankideek garatu eta lagundu zutena. Horietako batek (Igor) bere iritzi sendoa zuen paketeak zabaltzean Linux zerbitzuak nola konfiguratu behar ziren zehatz-mehatz. Iritzi hori adabakian proposatutako planteamendutik ezberdina zen, eta ezin zuten ados jarri. Ohi bezala, epeak amaitzen ari ziren, eta nolabaiteko erabakia hartu beharra zegoen;beharrezkoa zen haietako batek heldu postua hartzea. Paxak aitortu zuen bi ikuspegiek bizitzarako eskubidea dutela, baina bere aukera pasatzea nahi zuen, zeren Ez batek ez bigarren aukerak ez zuten abantaila tekniko agerikorik.
Gure eztabaidak honelako itxura zuen (oso eskematikoki, noski, elkarrizketak ordu erdi iraun zuen):
- Pasha, ezaugarri izoztu bat dugu egun gutxi barru. Garrantzitsua da dena bateratzea eta ahalik eta azkarren probak egiten hastea. Nola pasa gaitezke Igorren barrena?
β Zerbitzuak beste era batera ezarri nahi ditu, iruzkinak hor itsatsi zizkidan...
- Eta zer dago, aldaketa handiak, zalaparta asko?
- Ez, pare bat orduko lana dago, baina azkenean ez dago alderik, ala biak funtzionatuko du, zergatik da beharrezkoa? Funtzionatzen duen zerbait egin dut, onar dezagun.
- Entzun, zenbat denbora daramazu hau guztia eztabaidatzen?
- Bai, aste eta erdi daramagu denbora markatzen.
- Um... konpon al dezakegu pare bat ordutan jada aste eta erdi behar izan duen arazo bat, eta ez egin?
- Beno, bai, baina ez dut nahi Igorrek uste izan dezan erori naizenik...
- Entzun, zer da garrantzitsuagoa zuretzat, kaleratzea, barruan zure erabakiarekin batera, edo Igor hiltzea? Blokeatu dezakegu, orduan, ordea, aukera ona dago oharrarekin hegan egiteko.
- Tira... polita litzateke, noski, Igorren sudurra garbitzea, baina ados, askatzea garrantzitsuagoa da, ados nago.
- Hain garrantzitsua al da zuretzat Igorrek pentsatzen duena? Egiari zor, ez dio ezertxo ere ematen, bere ardura duen gauzaren leku ezberdinetan ikuspegi bateratua nahi du.
- Beno, ados, egin dezadan iruzkinetan eskatzen duen bezala eta has gaitezen probatzen.
- Eskerrik asko, Pasha! Ziur nengoen bietatik helduagoa izango zaretela, nahiz eta Igorek zu baino zaharragoa izan :)
Arazoa konpondu zen, kaleratzea garaiz kaleratu zen, Pasha ez zen atsekabe handirik sentitu, zeren berak irtenbide bat proposatu eta ezarri zuen. Igor, oro har, pozik zegoen, zeren... Bere iritzia kontuan hartu zen eta berak proposatutakoa egin zuten.
Funtsean, beste gatazka mota bat proiektu bateko irtenbide/liburutegi/ikuspegi teknikoen arteko aukeraketa da, bereziki banatutako talde batean. Proiektuetako batean, C/C++ erabiliz kokatu zena, proiektuaren kudeaketa teknikoa STL (Standard Template Library) erabiltzearen aurka zegoen kategorikoki. Garapena errazten duen hizkuntza-liburutegi estandarra da, eta gure taldea oso ohituta dago horretara. Konturatu zen proiektua C-tik C++tik baino askoz gertuago dagoela, eta horrek ez zuen taldea asko inspiratu, izan ere zuzendaritzak ahalik eta ondoen egin zuen eta oso jokalari politak kontratatu zituen. Aldi berean, talde amerikarrak, ingeniariak zein zuzendariak, denbora luzez lan egiten zuen enpresan, zegoen egoerara ohituta zeuden eta denarekin pozik zeuden. Talde errusiarra duela gutxi bildu zen, aste gutxiren buruan (ni barne). Talde errusiarrak kategorikoki ez zuen garapenaren ohiko ikuspegia alde batera utzi nahi izan.
Idatzizko eztabaida amaigabeak hasi ziren bi kontinenteen artean, hiru edo lau pantailetako eskutitzak hara eta hona hegan egiten zuten, talde-mailak eta pertsonalak, programatzaileetatik programatzaile eta kudeatzaileetaraino. Normalean gertatzen den bezala, luzera horretako gutunak inork ez zituen irakurtzen egileek eta haien aldeko sutsuek izan ezik. Txatek tentsioarekin kirrinka egiten zuten, pantaila anitzeko pentsamenduak norabide ezberdinetan pasatzen zituzten STLren abantaila teknikoei buruz, zein ondo probatua den, zein segurua den eta, oro har, zein zoragarria den berarekin eta zein izugarria den hura gabe. .
Horrek guztiak nahiko luze iraun zuen, azkenean konturatu nintzen arte gaiaren alderdi teknikoak eztabaidatzen ari ginela, baina arazoa errealitatean ez zen teknikoa. Arazoa ez dira STLren abantailak edo desabantailak edo hura gabe lan egiteko zailtasuna. Arazoa antolakuntzazkoa da. Lan egiten genuen enpresak nola funtzionatzen zuen ulertzea besterik ez genuen falta. Gutako inork ez zuen aurretik horrelako enpresa batean lan egiteko esperientziarik. Kontua zen kodea garatu eta produkziora kaleratu ondoren, laguntza beste taldeetako, beste herrialde batzuetako pertsona guztiz ezberdinek kudeatzen zutela. Zenbait hamarnaka ingeniariz osatutako ingeniaritza talde erraldoi honek (guztira) bitarteko teknikoen gutxieneko guztiz oinarrizkoa besterik ez zuen eskaini, nolabait esateko, minimorum minimo bat. Enpresan fisikoki ezarritako ingeniaritza estandartik haratago doan edozer ezin izan da etorkizunean onartu. Talde baten maila bere kide ahulenen mailak zehazten du. Ulertu ondoren benetako motibazioa Taldearen parte amerikarraren ekintzak, gai hau agendatik kendu zen, eta elkarrekin arrakastaz garatu eta kaleratu genuen produktua enpresak hartutako estandarrak erabiliz. Eskutitzak eta txatak kasu honetan ez zuten ondo funtzionatu; hainbat bidaia eta komunikazio pertsonal asko behar izan ziren izendatzaile komun batera iristeko.
Lan-fluxuaren ikuspuntutik, kasu zehatz honetan, erabilitako tresnen deskribapena, horien eskakizunak, berriak gehitzeko murrizketak eta murrizketa horien justifikazioa izatea lagunduko luke. Dokumentu horiek bat datoz, gutxi gorabehera, "Softwarearen Garapenerako Kudeatzailearen Eskuliburua"ren Berrerabilpen Estrategia eta Garapen Inguruneko paragrafoetan deskribatutakoekin. . Adina izan arren, ezin hobeto deskribatzen ditu mota honetako software-garapenaren jarduera eta plangintza-fase nagusiak. Horrelako dokumentuak izateak oso erraza da eztabaidatzea zer osagai eta ikuspegi erabil daitezkeen produktu batean, eta zergatik.
Kulturaren ikuspuntutik, bistan denez, jarrera helduago batekin, zeinean alderdiak lankideen ekintzen benetako motibazioa entzuten eta ulertzen saiatzen diren eta proiektuaren eta taldearen lehentasunen arabera jokatzen, eta ez ego pertsonalean. , gatazka errazago eta azkarrago konponduko litzateke.
Irtenbide teknikoa aukeratzearen inguruko beste gatazka batean, aldeetako baten motibazioa ulertzeko ere denbora nabarmena behar izan nuen (oso ezohiko kasua izan zen), baina motibazioa argia izan ondoren, konponbidea begi-bistakoa zen.
Egoera hau da: garatzaile berri bat agertzen da 20 bat laguneko talde batean, dei diezaiogun Stas. Garai hartan, talde gisa komunikaziorako gure tresna estandarra Skype zen. Geroago ikusi zenez, Stas estandar irekien eta kode irekiko softwarearen zale handia zen, eta iturriak publikoki eskuragarri zeuden eta publikoki deskribatutako protokoloak erabiltzen zituzten tresnak eta sistema eragileak soilik erabiltzen zituen. Skype ez da tresna horietako bat. Denbora asko eman genuen planteamendu honen abantailak eta desabantailak eztabaidatzen, Skype-ren analogoak sistema eragile desberdinetan abiarazteko saiakerak, Stasek taldea beste estandar batzuetara aldatzeko konbentzitzeko saiakerak, postaz pertsonalki idatzi, pertsonalki deitzeko. telefonoa, erosi zion bigarren ordenagailu bat Skyperako bereziki, etab. Azkenik, konturatu nintzen arazo hau, funtsean, ez dela teknikoa edo antolakuntzakoa, ideologikoa baizik, baita, esan liteke, erlijiosoa (Stasentzat). Nahiz eta azkenean Stas eta Skype konektatu (hainbat hilabete behar izan zituen), arazoa hurrengo edozein tresnatan sortuko litzateke berriro. Ez nuen benetako baliabiderik eskura Stasen mundu-ikuskera aldatzeko, eta ez zegoen arrazoirik ingurune horretan primeran lan egiten zuen talde baten mundu-ikuskera aldatzen saiatzeko. Pertsona eta enpresa ortogonalak ziren beren mundu-ikuskeran. Horrelako egoeretan, irtenbide ona antolakuntza da. Stas beste talde batera eraman genuen, non organikoagoa zen.
Gatazka honen arrazoia, nire ustez, pertsona jakin baten kultura pertsonalaren (konpromisorik egiten uzten ez duen iritzi sendoa duena) eta enpresaren kulturaren arteko desadostasuna da. Kasu honetan, noski, zuzendariaren akatsa da. Hasieran gaizki zegoen era honetako proiektu batera eramatea. Stas azkenean kode irekiko softwarea garatzeko proiektu batera joan zen eta bertan nabarmendu zen.
Garatzailearen jarrera umeek eta lan-prozesuaren gabeziek eragindako gatazkaren adibide ona da, non eginda dagoen definiziorik ezean, sustatzaileak eta QA taldeak itxaropen desberdinak dituztenak prest egoteari buruz. QAra transferitutako eginbidea. Garatzaileak uste zuen nahikoa zela kodea idaztea eta funtzioa hesiaren gainetik botatzea QAra; hor ordenatuko zuten. Nahiko heldua eta eskarmentu handiko programatzailea, bide batez, baina hori zen bere kalitatearen barneko atalasea. QA ez zegoen horrekin ados eta berak egiaztatutakoa erakusteko eta deskribatzeko eskatu zien, eta haientzako proba-gidoia eskatu zuen. Garatzaile honen funtzionalitatearekin arazoak izan zituzten iraganean eta ez zuten denbora berriro galdu nahi izan. Bide batez, arrazoi zuten - funtzioak benetan ez zuen funtzionatu, ez zuen kodea egiaztatu QAra bidali aurretik.
Egoera konpontzeko, dena benetan funtzionatu zuela erakusteko eskatu nion (ez zuen funtzionatu, eta konpondu behar izan zuen), taldearekin hitz egin genuen eta egindako QA definizioarekin (ez zuten lortu idatziz, ez genuelako prozesua burokratikoegi egin nahi ), ba, laster banandu ginen espezialista honekin (erliebe orokorrerako).
Lan-fluxuaren ikuspuntutik, kasu honetan hobekuntza posibleak honako hauek dira: egindako definizio baten presentzia, unitate-funtzio bakoitzaren laguntzarako baldintzak eta integrazio-probak eta garatzaileak egindako proben deskribapena. Proiektuetako batean, kode-estaldura-maila neurtu genuen CI zehar proben bidez eta adabaki bat gehitu ondoren estaldura-maila jaisten bazen, probak porrot bezala markatu ziren, hau da. edozein kode berri gehitu liteke horretarako proba berriak baleude.
Lan-prozesuaren antolakuntzarekin oso lotuta dagoen gatazka baten beste adibide tipiko bat. Produktu bat, produktua garatzeko talde bat, laguntza talde bat eta bezero bat ditugu. Bezeroak arazoak ditu produktuarekin eta kontaktuen laguntzarekin. Laguntzak arazoa aztertzen du eta arazoa produktuan dagoela ulertzen du eta arazoa produktu-taldeari transferitzen dio. Produktu taldea lanpetuta dago, kaleratze bat hurbiltzen ari da, beraz, bezero baten arazoa duen txartel bat, esleitu zaion garatzailearen beste txartelen artean galduta, hainbat astez zintzilikatzen da arretarik gabe. Laguntzak uste du garatzailea bezeroaren arazoan lanean ari dela. Bezeroak itxaron egiten du eta bere arazoa konpontzen ari dela espero du. Egia esan, oraindik ez da ezer gertatzen. Aste batzuk igaro ondoren, bezeroak azkenean aurrerapenarekiko interesa hartzea erabakitzen du eta laguntzari galdetzen dio gauzak nola doazen. Laguntzak garapena eskatzen du. Garatzailea dardar egiten du, txartelen zerrendan begiratu eta bertan bezeroaren txartel bat aurkitzen du. Bezero baten txartel bat irakurrita, arazoa konpontzeko informazio nahikorik ez dagoela ulertzen du, eta erregistro eta zabortegi gehiago behar dituela. Laguntzak bezeroari informazio gehigarria eskatzen dio. Eta orduan bezeroa konturatzen da denbora honetan inor ez dela bere arazoan lanean aritu. Eta trumoiak joko du...
Egoera horretan, gatazkaren konponbidea bera nahiko agerikoa eta lineala da (produktua konpondu, dokumentazioa eta probak eguneratu, bezeroa baretu, konponketa bat kaleratu, etab.). Garrantzitsua da lan-prozesua aztertzea eta ulertzea nor den bi taldeen arteko elkarrekintza antolatzeaz arduratzen den, eta egoera hori zergatik izan den posible lehenik. Argi dago prozesuan zer konpondu behar den: norbaitek argazki orokorra kontrolatu behar du bezeroen abisurik gabe, modu proaktiboan. Bezeroaren sarrerak garatzaileen beste sarrera batzuen artean nabarmendu behar dira. Laguntza-zerbitzuak ikusi beharko luke garapen-taldea bere txarteletan lanean ari ote den, eta hala ez bada, noiz has daitekeen lanean, eta emaitzak noiz espero daitezkeen. Laguntzak eta garapenak aldian-aldian txartelen egoera komunikatu eta eztabaidatu behar du, arazketarako beharrezkoa den informazioa biltzea ahal den neurrian automatizatu behar da, etab.
Gerran etsaia bi unitateren arteko bidegurutzea lortzen saiatzen den bezala, lanean ere punturik delikatu eta zaurgarriena taldeen arteko elkarrekintza izan ohi da. Laguntza- eta garapen-arduradunek adina badute, prozesua beraiek konpondu ahal izango dute, bestela, prozesuak gatazkak eta arazoak sortzen jarraituko du, egoera konpondu dezakeen kudeatzaile batek esku hartzen duen arte.
Enpresa ezberdinetan behin eta berriz ikusi dudan beste adibide tipiko bat produktu bat talde batek idazten duen egoera da, horren integrazio automatikoko probak bigarren talde batek idazten dituena eta dena funtzionatzen duen azpiegitura hirugarren batekin batera doana da. taldea. Probak exekutatzeko arazoak uneoro sortzen dira, eta horietan arazoen kausa produktua zein probak eta azpiegiturak izan daitezke. Arazoa izan ohi da arazoen hasierako analisia, akatsak artxibatzea, produktuaren erregistroak analizatzea, probak eta azpiegiturak eta abar nork egin behar dituen adostea. Hemen gatazkak oso maiz dira, eta, aldi berean, uniformeak. Intentsitate emozionalaren kasuan, parte hartzaileak sarritan haur-posizioan erortzen dira eta eztabaidak hasten dira seriean: "zergatik egin behar dut hau", "maizago apurtzen dira", etab.
Lan-fluxuaren ikuspegitik, arazo bat konpontzeko urrats zehatzak taldeen osaeraren, proba eta produktu motaren eta abarren araberakoak dira. Proiektuetako batean, aldizkako betebeharra sartu genuen, zeinetan taldeek probak banan-banan kontrolatzen zituzten, astez aste. Bestean, hasierako analisia probaren garatzaileek egiten zuten beti, baina analisia oso oinarrizkoa zen eta produktua nahiko egonkorra zen, beraz, ondo funtzionatu zuen. Prozesua gardena dela ziurtatzea da gakoa, alde guztientzat itxaropenak argiak izatea eta egoera denontzat bidezkoa dela.
Gatazkak ere arazo bat al dira erakunde batean? Seinale txarra al da zure taldean gatazkak sarritan (edo aldian behin) gertatzea? Orokorrean, ez, zeren hazkundea, garapena bada, bada dinamika bat, orduan sortzen dira inoiz konpondu gabeko gaiak, eta horiek konpontzerakoan, gatazkak sor daitezke. Arlo batzuek arreta behar duten adierazle da hori, hobetzeko arloak daudela. Gaizki da gatazkak sarritan sortzen badira, konpontzen zailak badira edo denbora luzez irauten badute. Hau da, ziurrenik, lan-prozesuak nahikoa erraztu ez direnaren eta taldearen heldutasun nahikorik ezaren seinale.
Iturria: www.habr.com