Epigraaf:
Eartiids kamen de Egel en de Lytse Bear elkoar yn 'e bosk.
- Hallo, Hedgehog!
- Hallo, Lytse Bear!
Dus wurd foar wurd, grapke foar grap, krige de Egel yn it gesicht troch de Lytse Bear...
Hjirûnder is in diskusje fan ús teamlieder, lykas RAS-produktûntwikkelingsdirekteur Igor Marnat, oer de spesifiken fan wurkkonflikten en mooglike metoaden foar it behearen dêrfan.
De measte konflikten dy't wy op it wurk tsjinkomme, ûntwikkelje neffens in senario fergelykber mei dat beskreaun yn 'e epigraaf hjirboppe. D'r binne ferskate dielnimmers dy't yn 't earstoan aardich goed foar elkoar binne, se besykje wat probleem op te lossen, mar úteinlik bliuwt it probleem net oplost, en om ien of oare reden binne de relaasjes tusken de dielnimmers oan 'e diskusje bedoarn.
It libben is ferskaat, en fariaasjes komme foar yn it hjirboppe beskreaune senario. Soms is de relaasje tusken de dielnimmers yn 't earstoan net sa goed, soms is der net iens in kwestje dat in direkte oplossing freget (lykas bygelyks yn 'e epigraaf), soms bliuwt de relaasje nei de diskusje itselde as foardat it begûn, mar it probleem is úteinlik net oplost.
Wat is mienskiplik yn alle situaasjes dy't kinne wurde definiearre as in situaasje fan wurk konflikt?
As earste binne d'r twa of mear kanten. Dizze partijen kinne ferskate plakken yn 'e organisaasje ynnimme, yn in relaasje fan gelikensens wêze (kollega's yn in team), of op ferskate nivo's fan 'e hiërargy (baas - ûndergeskikt), yndividueel (meiwurker) of groep wêze (yn gefallen fan konflikt tusken in meiwurker en in team as twa teams), ensfh. De kâns op konflikt en it gemak fan har oplossing wurde sterk beynfloede troch it nivo fan fertrouwen tusken de dielnimmers. Hoe better de partijen inoar kennen, hoe heger it fertrouwen, hoe grutter de kâns dat se ta in oerienkomst komme. Bygelyks, leden fan in ferspraat team dy't noait face-to-face ynteraksje hawwe, hawwe mear kâns om konflikt te belibjen oer in ienfâldige wurkkwestje dan minsken dy't op syn minst in pear face-to-face ynteraksjes hawwe hân. Dêrom, by it wurkjen yn ferdielde teams, is it heul wichtich om te soargjen dat alle teamleden periodyk persoanlik mei elkoar moetsje.
Twad, yn in situaasje fan konflikt op it wurk, de partijen binne yn in situaasje fan it oplossen fan in probleem dat wichtich is foar ien fan 'e partijen, foar beide, of foar de organisaasje as gehiel. Tagelyk, fanwege de spesifike situaasje, de partijen hawwe meastal genôch tiid en in ferskaat oan manieren om it op te lossen (formele, ynformele, gearkomsten, brieven, behear besluten, de oanwêzigens fan doelen en plannen fan it team, de feit fan in hiërargy, ensfh.). Dit is oars as de situaasje fan it oplossen fan in wurk (of net-wurk) probleem yn in organisaasje fan bygelyks it oplossen fan in wichtige fraach: "Eh, bern, út hokker gebiet komsto?!" op strjitte, of it konflikt út de epigraph. Yn it gefal fan it oplossen fan in wurkprobleem is de kwaliteit fan it wurkproses en de kultuer fan it oplossen fan problemen yn it team saak.
Tredde, de bepalende faktor fan it konflikt (út it eachpunt fan ús diskusje) is it feit dat de partijen yn it proses net selsstannich komme kinne ta in oplossing foar it probleem dat past by alle partijen. De situaasje fereasket de yntervinsje fan in tredde partij, in eksterne arbiter. Dit punt kin kontroversjeel lykje, mar, yn essinsje, as de konfliktsituaasje mei súkses waard oplost sûnder de yntervinsje fan in eksterne arbiter, de kwestje waard mei súkses oplost en de relaasjes fan 'e partijen net minder wurde, dit is de situaasje dêr't wy moatte stribje . Wy sille nei alle gedachten net iens witte oer sa'n konflikt, of wy sille útfine by tafal neidat it is oplost. Hoe mear problemen in team sels oplosse kin, hoe effektiver it sil wêze.
In oar karakteristyk skaaimerk fan it konflikt dat it wurdich is oan te pakken is de mjitte fan emosjonele yntensiteit by it beslút. Konflikt is net needsaaklik ferbûn mei in heech emosjoneel nivo. Dielnimmers hoege net te roppen en mei de earms te swaaien om de situaasje yn wêzen in konflikt te wêzen. It probleem is net oplost, in bepaalde emosjonele spanning is oanwêzich (miskien wurdt it nei bûten net dúdlik útdrukt), wat betsjut dat wy te krijen hawwe mei in konfliktsituaasje.
Is it überhaupt nedich om yn konfliktsituaasjes yn te gripen, of is it better om har resolúsje syn gong gean te litten en te wachtsjen oant it probleem himsels oplost? Moatte. It is net altyd yn jo macht of kompetinsje om it konflikt folslein op te lossen, mar yn elke situaasje, yn in konflikt fan elke skaal, kinne jo in folwoeksen posysje ynnimme, en dêrmei ferskate mear minsken om jo hinne bringe, de negative gefolgen fan 'e konflikt en bydrage oan syn oplossing.
Foardat wy nei in pear foarbylden fan konfliktsituaasjes sjogge, litte wy nei in pear wichtige punten sjen dy't mienskiplik binne foar alle konflikten.
By it oplossen fan in konflikt is it wichtich om boppe de striid te wêzen, en net binnen it (dit wurdt ek wol "in meta-posysje nimme"), dat is, net diel te wêzen fan ien fan 'e partijen yn it resolúsjeproses. Oars, sil it hawwen fan in eksterne skiedsrjochter it beslút helpe allinich de posysje fan ien fan 'e partijen te fersterkjen yn it neidiel fan 'e oare partij. By it meitsjen fan in beslút is it wichtich dat it moreel wurdt akseptearre troch alle partijen, lykas se sizze, "kocht." Dat, sels as de partijen net bliid wiene mei it nommen beslút, se yn elts gefal oprjocht ynstimd hawwe om it út te fieren. Sa't se sizze, om it net iens te wêzen en te begean. Oars feroaret it konflikt gewoan syn oansjen, bliuwt it smeulende fjoer ûnder it fean en op in stuit ûnûntkomber wer op.
It twadde punt, foar in part ferbûn mei it earste, is dat as jo al besletten hawwe om mei te dwaan oan it oplossen fan it konflikt, nim it dan sa serieus mooglik út it eachpunt fan kommunikaasje en it bestudearjen fan 'e kontekst. Praat persoanlik mei elk fan 'e partijen. Apart mei elk, foar starters. Stel net foar post. Yn it gefal fan in ferspraat team, op syn minst prate fia fideo link. Wês net tefreden mei hearsay en eachtsjûge rapporten. Begryp it ferhaal, wat elke kant wol, wêrom se it wolle, wat se ferwachtsje, hawwe se earder besocht dit probleem op te lossen, wat sil der barre as it net oplost wurdt, hokker oplossingen sjogge se, hoe stellen se har de posysje fan 'e oare kant, wat tinke se, goed of ferkeard, ensfh. Laad alle mooglike kontekst yn jo holle, mei in iepen geast, oannommen dat elkenien gelyk hat. Jo binne net binnen it konflikt, jo binne der bûten, yn in metaposysje. As de kontekst allinich beskikber is yn in post-thread, lês it dan yn syn gehiel en de diskusjes en dokuminten dy't dêrmei relatearre binne. Neidat jo it lêzen hawwe, praat noch mei jo stim. Jo binne hast garandearre om wat wichtich te hearren dat net yn 'e post stiet.
It tredde wichtige punt is de algemiene oanpak fan kommunikaasje. Dit binne gewoane dingen, neat kosmysk, mar se binne tige wichtich. Wy besykje net tiid te besparjen, wy prate mei alle dielnimmers, wy bekritisearje de persoan net, mar wy beskôgje de gefolgen fan syn dieden (net "do bist rude", mar "miskien kinne de jonges misledigje troch dit ding"), jouwe wy de kâns om gesicht te bewarjen, wy fiere diskusjes persoanlik, net foar de line.
Konflikten wurde meastentiids feroarsake troch ien fan twa redenen. De earste is relatearre oan oft in persoan yn 'e tiid fan konflikt is yn' e posysje fan in folwoeksene of yn 'e posysje fan in bern (mear oer dit hjirûnder). Dit komt troch syn emosjonele folwoeksenheid, it fermogen om syn emoasjes te behearjen (dy't trouwens net altyd ferbûn is mei syn leeftyd). De twadde mienskiplike reden is de ûnfolsleinens fan it wurkproses, wêrtroch't situaasjes fan grize gebieten ûntstiet wêryn ferantwurdlikens wurdt ferspraat tusken dielnimmers, de ferwachtings fan 'e partijen binne net transparant foar elkoar, en rollen yn it proses binne wazig.
Sadwaande moat in manager by it oplossen fan in konflikt (lykas alle oare problemen) trije perspektiven yn gedachten hâlde: koarte termyn - om it probleem/konflikt hjir en no op te lossen, middellange termyn - om de kâns te minimalisearjen dat der in oar konflikt ûntstiet foar deselde reden, en op lange termyn - te kultivearjen in folwoeksen kultuer yn it team persoan.
Elk fan ús hat in ynderlik bern, sawat trije of fjouwer jier âld. Hy sliept meast op it wurk, mar wurdt soms wekker en nimt de kontrôle oer. It bern hat syn eigen prioriteiten. It is wichtich foar him om derop te stean dat dit syn sânbak is, syn mem hâldt mear fan him, syn masine is de bêste (it ûntwerp is it bêste, hy programmearret it bêste, ...). Yn in situaasje fan konflikt kin in bern boartersguod drukke, syn fuotten stompe en syn spatel kreakje, mar hy kin problemen foar folwoeksenen net oplosse (oplossingsarsjitektuer, oanpak foar automatisearre testen, releasedatums, ensfh.), Hy tinkt net yn termen fan foardielen foar it team. In bern yn konflikt kin stimulearre, treast en op bêd stjoerd wurde troch him te freegjen om syn folwoeksene te skiljen. Foardat jo in diskusje begjinne yn in konfliktsituaasje, soargje derfoar dat jo prate mei in folwoeksene, net in bern, en dat jo sels yn 'e posysje fan in folwoeksene binne. As jo earlike doel op it stuit is om in serieus probleem op te lossen, binne jo yn 'e posysje fan in folwoeksene. As jo doel is om jo fuotten te stompjen en jo skouderblêd te kraken, is dit in bernelike posysje. Stjoer jo ynderlike bern op bêd en belje in folwoeksene, of regelje de diskusje opnij. In persoan makket in emosjonele beslút, en dan siket nei in rasjonele rjochtfeardiging foar it. In beslút fan in bern op basis fan de prioriteiten fan bern sil net optimaal wêze.
Neist gedrach yn 'e tiid fan konflikt is de posysje fan in bern of folwoeksene ek karakterisearre troch it nivo fan ferantwurdlikens dat in persoan ree is om op himsels te nimmen. Yn syn ekstreme manifestaasjes sjocht de bernlike posysje fan in programmeur, dy't ik mear as ien kear haw moete, sa út: ik skreau de koade, stjoerde it foar resinsje - myn wurk is klear. Resinsinten moatte it besjen en goedkarre, QA moat it kontrolearje, as d'r problemen binne, litte se my witte. Frjemd genôch gedrage sels frij folwoeksen en betûfte minsken har soms sa. It oare ein fan 'e skaal is dat in persoan himsels ferantwurdlik achtet om te soargjen dat syn koade wurket, wurdt dekt troch tests, is persoanlik kontrolearre troch him, hat de resinsje mei súkses trochjûn (as nedich is d'r gjin probleem om resinsinten te pingjen, problemen te besprekken mei stim, ensfh.) en is ûnderdrukt, QA sil assistinsje leverje as it nedich is, testsenario's wurde beskreaun, ensfh. Yn normale gefallen begjint de programmeur of tichter by it folwoeksen ein fan 'e skaal, of ferpleatst dêr as hy ûnderfining opdien (mits de juste kultuer binnen it team wurdt kultivearre). Yn ekstreme gefallen, hy bliuwt te wurkjen, meastal nimme in bernlike posysje, dan hy en it team periodyk hawwe problemen en konflikten.
It befoarderjen fan de juste, folwoeksen kultuer yn in team is in wichtige taak foar elke manager. It duorret in lange tiid en deistige ynspanning, mar it resultaat is it wurdich. D'r binne twa manieren om de teamkultuer te beynfloedzjen - liede troch foarbyld (dat sil perfoarst folge wurde; it team sjocht altyd nei de lieder) en it besprekken en beleanjen fan it goede gedrach. D'r is hjir ek neat abstrus of heul formeel, gewoan by it besprekken fan problemen, merk op dat hjir wat dien wurde koe, beklamje dat jo opfallen hawwe wannear't it goed besletten is, lof, notysje by de release review, ensfh.
Litte wy ferskate typyske konfliktsituaasjes beskôgje, fan ienfâldich oant kompleks:
Konflikten dy't net relatearre binne oan wurkproblemen
Hiel faak binne der konflikten op it wurk dy't net te krijen hawwe mei wurkproblemen. Harren foarkommen en it gemak fan resolúsje binne meastentiids direkt relatearre oan it nivo fan emosjonele yntelliginsje fan 'e dielnimmers, har nivo fan folwoeksenens, en binne net relatearre oan de folsleinens of ûnfolsleinens fan it wurkproses.
Typyske foarbylden: immen brûkt de waskmasine of dûs net faak genôch, wat oaren net leuk fine, immen is bedompt, wylst oaren wyn krije as se it rút iependraaie, immen hat te lûd, en oaren hawwe stilte nedich om te wurkjen, en sa fierder. It is better om de oplossing fan dit soarte konflikten net te fertrage en se har kursus net te litten gean. Se sille net op harsels oplosse en sille jo elke dei ôfliede fan it wurk en de sfear yn it team fergiftigje. Gelokkich is it oplossen fan se meastentiids gjin grut probleem - praat gewoan rêstich (ien-op-ien, fansels) mei in kollega dy't hygiëne ferwaarloazget, noflike sitten foar minsken dy't leaver stilte/koelte leverje, lûdabsorberende koptelefoan keapje of partysjes ynstallearje , ensfh.
In oar foarbyld dat ik ferskate kearen tsjinkaam tidens myn wurk is de psychologyske ynkompatibiliteit fan teamleden. Om ien of oare reden kinne minsken gewoan net gearwurkje; elke ynteraksje einiget yn in skandaal. Soms komt dit troch it feit dat minsken polêre opfettings hawwe oer guon driuwende kwestje (meast polityk) en net witte hoe't se se bûten it wurk litte moatte. Harren oertsjûgje om inoar te tolerearjen of har gedrach te feroarjen is in nochal futile taak. De ienige útsûndering dy't ik tsjinkaam binne jonge kollega's mei iepen opfettings; har gedrach kin noch stadichoan feroare wurde troch periodike petearen. Meastentiids wurdt it probleem mei súkses oplost troch se te skieden yn ferskate teams, of op syn minst de kâns te jaan om op it wurk heul selden te oerlaapjen.
Yn alle boppesteande situaasjes is it de muoite wurdich om mei alle dielnimmers persoanlik te praten, de situaasje te besprekken, te freegjen oft se yn dit gefal überhaupt in probleem sjogge, te freegjen wat neffens har de oplossingen binne en har dielnimme oan it meitsjen fan dit te garandearjen beslút.
Fanút it eachpunt fan it optimalisearjen fan it wurkproses (it perspektyf op middellange termyn dat ik neamde), kin hjir net folle dien wurde; it iennichste punt foar optimalisaasje is om de kompatibiliteitsfaktor yn 'e rekken te nimmen by it foarmjen fan in team en net minsken te setten tegearre foarôf wa sil konflikt.
Fanút it perspektyf fan teamkultuer komme sokke sitewaasjes folle minder foar yn teams mei in folwoeksen kultuer, dêr't minsken it team en kollega's respektearje en witte hoe't se selsstannich problemen oplosse kinne. Boppedat wurde sokke konflikten folle makliker (faak automatysk) oplost yn teams dêr't in heech nivo fan fertrouwen is, minsken lang gearwurke hawwe en/of bûten it wurk faak kommunisearje.
Konflikten yn ferbân mei wurkproblemen:
Sokke konflikten wurde meastal feroarsake troch beide redenen tagelyk, sawol emosjonele (it feit dat ien fan 'e dielnimmers net yn' e posysje fan in folwoeksene is) en de ûnfolsleinens fan it wurkproses sels. Miskien is it meast foarkommende type konflikten dy't ik tsjinkaam binne konflikten tidens koadebeoardielingen as arsjitektuerdiskusjes tusken ûntwikkelders.
Ik soe hjir twa typyske gefallen markearje:
1) Yn it earste gefal kin de ûntwikkelder gjin koadebeoardieling krije fan in kollega. De patch wurdt stjoerd foar resinsje, en neat bart. Op it earste each is d'r gjin dúdlik konflikt tusken beide kanten, mar as jo der oer neitinke, is dit nochal in konflikt. De wurkkwestje is net oplost, ien fan de partijen (wachtsjen op in resinsje) ûnderfynt dúdlik ûngemak. In ekstreem subtype fan dit gefal is ûntwikkeling yn in mienskip of yn ferskate teams, wylst de resinsint miskien net ynteressearre is yn dizze bepaalde koade, fanwege laden of oare omstannichheden, miskien hielendal net omtinken jaan oan it beoardielingsfersyk, en de eksterne arbiter (in behearder mienskiplik oan beide kanten) ) kin hielendal net bestean.
De oplossingsbenadering dy't helpt yn sa'n sitewaasje, hat krekt te krijen mei it lange-termyn perspektyf, de kultuer fan in folwoeksene. Earst wurket tûke aktiviteit. Jo moatte net ferwachtsje dat de koade dy't op 'e resinsje hinget, de oandacht sil lûke fan' e resinsint sels. Wy moatte resinsinten helpe om him op te merken. Pingani in pear minsken, freegje in fraach oer syncape, meidwaan oan diskusjes. Fansels is ymportaasje mear kâns om skea te meitsjen as help, jo moatte sûn ferstân brûke. Twads, pre-tarieding wurket goed. As it team begrypt wat der bart en wêrom, wêrom dizze koade überhaupt nedich is, it ûntwerp is foarôf besprutsen en ôfpraat mei elkenien, minsken binne mear kâns om omtinken te jaan oan sokke koade en akseptearje it foar wurk. Tredde, autoriteit wurket. As jo wolle wurde beoardiele, doch in protte resinsjes sels. Doch beoardielingen fan hege kwaliteit, mei echte kontrôles, echte tests en nuttige opmerkings. As jo bynamme goed bekend is yn it team, is de kâns grutter dat jo koade opmurken wurdt.
Fanút it eachpunt fan workflow binne mooglike ferbetteringen hjir korrekte prioritearring rjochte op it helpen fan de ûntwikkelder om syn doelen en it team te berikken (besjoch oaren, skriuw brieven oan 'e mienskip, begeliede de koade mei in arsjitektuerbeskriuwing, dokumintaasje, tests, meidwaan oan diskusjes mei mienskip, ensfh.), foarkomme dat patches te lang yn 'e wachtrige hingje, ensfh.
2) It twadde mienskiplike gefal fan konflikten tidens koade as ûntwerpbeoardielingen is ferskillende werjeften oer technyske problemen, kodearringstyl en kar fan ark. Fan grut belang yn dit gefal is it nivo fan fertrouwen tusken de dielnimmers, hearrend ta itselde team, en ûnderfining fan gearwurkjen. In deade ein komt foar as ien fan de dielnimmers in bernich stânpunt ynnimt en net besiket te hearren wat de petearpartner him oerbringe wol. Faak kin sawol de troch de oare partij foarstelde oanpak as de yn it earstoan foarstelde oanpak wol mei súkses wurkje en makket it yn prinsipe net út hokker te kiezen.
Op in dei hat in programmeur fan myn team (lit ús him Pasha neame) in patch makke mei feroaringen oan it pakket-ynsetsysteem, dat waard ûntwikkele en stipe troch kollega's fan in oanbuorjende ôfdieling. Ien fan harren (Igor) hie syn eigen sterke miening oer krekt hoe't Linux-tsjinsten moatte wurde konfigureare by it ynsetten fan pakketten. Dizze miening ferskilde fan 'e oanpak foarsteld yn' e patch, en se koene it net iens wêze. Lykas gewoanlik rûnen de deadlines út, en it wie nedich om ta in soarte fan beslút te kommen; it wie nedich foar ien fan har om in folwoeksen posysje te nimmen. Pasha erkende dat beide oanpakken rjocht hawwe op it libben, mar hy woe dat syn opsje passe, om't Noch ien noch de twadde opsje hie gjin dúdlike technyske foardielen.
Us diskusje seach der sa út (hiel skematysk, fansels, it petear duorre in healoere):
- Pasha, wy hawwe in funksje freeze oer in pear dagen. It is wichtich dat wy alles byinoar krije en sa gau mooglik begjinne te testen. Hoe kinne wy troch Igor komme?
- Hy wol tsjinsten oars ynstelle, hy plakte dêr opmerkings foar my...
- En wat is der, grutte feroarings, in protte drokte?
- Nee, der wurdt in pear oeren wurke, mar op it lêst is der gjin ferskil, it sil fan beide kanten wurkje, wêrom is dat nedich? Ik makke wat dat wurket, lit ús it akseptearje.
- Harkje, hoe lang hawwe jo dit alles besprutsen?
- Ja, wy hawwe no oardel wike tiid ôfstimd.
- Um... kinne wy yn in pear oeren in probleem oplosse dat al oardel wike duorre hat, en it net dwaan?
- No, ja, mar ik wol net dat Igor tinkt dat ik yn 'e gaten haw...
- Harkje, wat is wichtiger foar jo, om in frijlitting út te jaan, tegearre mei jo beslút binnen, of Igor te deadzjen? Wy kinne it blokkearje, dan is der lykwols in goede kâns om troch te fleanen mei de frijlitting.
- No... it soe fansels cool wêze om Igor syn noas ôf te wipe, mar goed, de frijlitting is wichtiger, ik mei iens.
- Is it echt sa wichtich foar jo wat Igor tinkt? Om earlik te wêzen, jout er hielendal neat, hy wol gewoan in ienriedige oanpak op ferskate plakken fan it ding dêr't er ferantwurdlik foar is.
- No, ok, lit my dwaan lykas hy freget yn 'e opmerkingen en lit ús begjinne te testen.
- Tankewol, Pasha! Ik wie der wis fan dat jo fan jo twa de folwoeksener soene wêze, hoewol Igorek âlder is as jo :)
It probleem waard oplost, de frijlitting waard op 'e tiid frijlitten, Pasha fielde net folle ûntefredenheid, om't hy hat sels in oplossing foarsteld en útfierd. Igor wie oer it algemien bliid, om't ... Syn miening waard rekken holden en se diene lykas hy suggerearre.
In oar type fan yn wêzen itselde konflikt is de kar tusken technyske oplossingen/biblioteken/benaderingen yn in projekt, benammen yn in ferspraat team. Yn ien fan de projekten, dat waard gepositioneerd as mei help fan C / C ++, It die bliken dat de technyske behear fan it projekt wie kategoarysk tsjin it brûken fan STL (Standard Template Library). Dit is in standerttaalbibleteek dy't ûntwikkeling ferienfâldiget, en ús team is der tige wend oan. It die bliken dat it projekt folle tichter by C leit as by C++, wat it team net folle ynspireare, om't management besocht har bêst en rekrutearre echt cool plus spilers. Tagelyk hie it Amerikaanske part fan it team, sawol yngenieurs as managers, in lange tiid yn it bedriuw wurke, wiene wend oan de besteande stân fan saken en wiene bliid mei alles. It Russyske diel fan it team waard koartlyn byinoar brocht, binnen in pear wiken (ynklusyf my). It Russyske diel fan it team woe kategoarysk de gewoane oanpak fan ûntwikkeling net ferlitte.
Einleaze skriftlike diskusjes begûnen tusken de twa kontininten, brieven op trije of fjouwer skermen fleagen hinne en wer, yn groepsmailings en persoanlike, fan programmeurs oant programmeurs en managers. Lykas gewoanlik it gefal is, waarden brieven fan dizze lingte troch nimmen lêzen, útsein de skriuwers en har fûleindige oanhingers. Chats kreake fan spanning, trochjaan fan multi-skerm tinzen yn ferskate rjochtingen oangeande de technyske foardielen fan 'e STL, hoe goed hifke it is, hoe feilich it is, en yn it algemien, hoe prachtich it libben is mei it, en hoe ferskriklik it is sûnder it .
Dit alles duorre nochal in lange tiid, oant ik úteinlik realisearre dat wy bepraten de technyske aspekten fan it probleem, mar it probleem wie yn werklikheid net technysk. It probleem is net de foardielen of neidielen fan STL of de muoite om sûnder it te wurkjen. It probleem is earder organisatoarysk. Wy moasten gewoan begripe hoe't it bedriuw wêrfoar wy wurken wurke. Net ien fan ús hie earder ûnderfining yn sa'n bedriuw. It ding wie dat nei de koade ûntwikkele en frijlitten yn produksje, stipe waard behannele troch folslein oare minsken út oare teams, út oare lannen. Dit enoarme yngenieurteam fan ferskate tsientûzenen yngenieurs (yn totaal) koe allinich in folslein basis minimum fan technyske middels leverje, sa te sizzen, in minimum minimorum. Alles dat boppe de yn it bedriuw fêststelde technyske standert gie, koe yn 'e takomst net wurde stipe. It nivo fan in team wurdt bepaald troch it nivo fan syn swakste leden. Neidat wy begrepen echte motivaasje aksjes fan it Amerikaanske diel fan it team, dit probleem waard fuortsmiten fan de aginda, en tegearre wy mei súkses ûntwikkele en útbrocht it produkt mei help fan de noarmen oannommen troch it bedriuw. Brieven en petearen yn dit gefal wurken net goed; it duorre ferskate reizen en in protte persoanlike kommunikaasje om ta in mienskiplike neamer te kommen.
Ut it eachpunt fan 'e workflow, yn dit bysûndere gefal, soe it helpe om in beskriuwing te hawwen fan' e brûkte ark, easken foar har, beheiningen foar it tafoegjen fan nije, en rjochtfeardiging foar sokke beheiningen. Sokke dokuminten oerienkomme rûchwei mei dy beskreaun yn paragrafen Herbrûksstrategy en ûntwikkelingsomjouwing fan it "Manager's Handbook for Software Development", ûntwikkele yn . Nettsjinsteande syn leeftyd, it beskriuwt perfekt alle wichtichste aktiviteiten en planning stadia fan software ûntwikkeling fan dit soarte. It hawwen fan dokuminten lykas dit makket it heul maklik om te besprekken hokker komponinten en oanpak kinne wurde brûkt yn in produkt, en wêrom.
Ut in kultureel eachpunt, fansels, mei in mear folwoeksen posysje, dêr't de partijen besykje te hearren en begripe de echte motivaasje fan harren kollega 'aksjes en hannelje op basis fan de prioriteiten fan it projekt en it team, en net it persoanlike ego , soe it konflikt makliker en flugger wurde oplost.
Yn in oar konflikt oer de kar foar in technyske oplossing hat it my ek in merkbere tiid nedich om de motivaasje fan ien fan 'e partijen te begripen (it wie in heul ûngewoan gefal), mar nei't de motivaasje dúdlik wie, wie de oplossing dúdlik.
De situaasje is dit: in nije ûntwikkelder ferskynt yn in team fan sawat 20 minsken, lit ús him Stas neame. Op dat stuit wie ús standert ark foar kommunikaasje as team Skype. As letter bliken die, wie Stas in grutte fan fan iepen noarmen en iepen boarne software, en brûkte hy allinich ark en bestjoeringssystemen wêrfan de boarnen iepenbier beskikber wiene en dy't iepenbier beskreaune protokollen brûkten. Skype is net ien fan dizze ark. Wy hawwe in protte tiid bestege oan it besprekken fan 'e foardielen en neidielen fan dizze oanpak, besykjen om analogen fan Skype op ferskate bestjoeringssystemen te lansearjen, Stas's besykjen om it team te oertsjûgjen om oer te skeakeljen nei oare noarmen, skriuw him persoanlik per post, skilje him persoanlik op 'e telefoan, keapje him in twadde kompjûter spesifyk foar Skype, ensfh. Uteinlik realisearre ik dat dit probleem yn wêzen net technysk of organisatoarysk is, it is earder ideologysk, sels, soe men sizze, religieus (foar Stas). Sels as wy úteinlik Stas en Skype ferbûn hawwe (wat ferskate moannen duorre), soe it probleem opnij ûntstean op elk folgjende ynstrumint. Ik hie gjin echte middels ta myn beskikking om Stas syn wrâldbyld te feroarjen, en d'r wie gjin reden om te besykjen it wrâldbyld te feroarjen fan in team dat perfekt wurke yn dizze omjouwing. De persoan en it bedriuw wiene gewoan orthogonaal yn har wrâldbyld. Yn sokke situaasjes is in goede oplossing organisatoarysk. Wy hawwe Stas oerbrocht nei in oar team, dêr't hy mear organysk wie.
De reden foar dit konflikt is neffens my de diskrepânsje tusken de persoanlike kultuer fan in bepaalde persoan (dy't in sterke miening hat dy't him net tastiet om kompromissen te meitsjen) en de kultuer fan it bedriuw. Yn dit gefal is it fansels de flater fan de manager. It wie ynearsten ferkeard om him mei te nimmen op sa'n projekt. Stas úteinlik ferhuze nei in iepen boarne software ûntwikkeling projekt en útblonk dêr.
In goed foarbyld fan in konflikt feroarsake troch sawol de bernlike hâlding fan de ûntwikkelder as de tekoartkommingen fan it wurkproses is in situaasje wêryn, by it ûntbrekken fan in definysje fan dien, de ûntwikkelder en it QA-team ferskillende ferwachtings hawwe oangeande de reewilligens fan de funksje oerdroegen oan QA. De ûntwikkelder leaude dat it genôch wie om de koade te skriuwen en de funksje oer it hek nei QA te goaien - se soene it dêr sortearje. In frij folwoeksen en betûfte programmeur, trouwens, mar dat wie syn ynterne drompel foar kwaliteit. QA wie it dêr net mei iens en easke harren sjen te litten en te beskriuwen wat er sels kontrolearre hie, en easke in testskript foar harren. Se hiene yn it ferline problemen mei funksjonaliteit fan dizze ûntwikkelder en woene har tiid net wer fergrieme. Trouwens, se hiene gelyk - de funksje wurke echt net, hy kontrolearre de koade net foardat hy it nei QA stjoerde.
Om de situaasje op te lossen, frege ik him om my sjen te litten dat alles echt wurke (it wurke net, en hy moast it reparearje), wy prate mei it team en mei de QA-definysje fan dien (se makken it net yn skriuwen, om't wy it proses net te burokratysk meitsje woenen ), no, wy hawwe al gau ôfskied fan dizze spesjalist (ta algemiene opluchting).
Ut it eachpunt fan 'e workflow binne mooglike ferbetteringen yn dit gefal de oanwêzigens fan in definysje fan dien, easken foar stipe fan elke ienheidfunksje en yntegraasjetests, en in beskriuwing fan testen útfierd troch de ûntwikkelder. Yn ien fan 'e projekten mjitten wy it nivo fan koadedekking troch testen tidens CI en as it dekkingsnivo sakke nei it tafoegjen fan in patch, waarden de tests markearre as mislearre, d.w.s. eltse nije koade koe allinnich wurde tafoege as der wiene nije tests foar it.
In oar typysk foarbyld fan in konflikt nau ferbûn mei de organisaasje fan it wurk proses. Wy hawwe in produkt, in produktûntwikkelingsteam, in stipeteam en in klant. De klant hat problemen mei it produkt en kontakten stipe. Stipe analysearret it probleem en begrypt dat it probleem yn it produkt is en draacht it probleem oer nei it produktteam. It produktteam is yn in drokke tiid, in frijlitting komt oan, dus in kaartsje mei in probleem fan in klant, ferlern ûnder de oare kaartsjes fan 'e ûntwikkelder oan wa't it is tawiisd, hinget foar ferskate wiken sûnder oandacht. Support tinkt dat de ûntwikkelder wurket oan it probleem fan de klant. De klant wachtet en hopet dat oan har probleem wurke wurdt. Yn werklikheid bart der noch neat. Nei in pear wiken beslút de klant úteinlik om belangstelling te hawwen foar de foarútgong en freget stipe hoe't it giet. Stipe freget om ûntwikkeling. De ûntwikkelder huveret, sjocht de list mei kaartsjes troch en fynt dêr in kaartsje fan de klant. It lêzen fan in kaartsje fan in klant, hy begrypt dat d'r net genôch ynformaasje is om it probleem op te lossen, en hy hat mear logs en dumps nedich. Support freget ekstra ynformaasje fan de klant. En dan beseft de klant dat nimmen al dy tiid oan syn probleem wurke hat. En de tonger sil slaan ...
Yn dizze situaasje is de oplossing foar it konflikt sels frij fanselssprekkend en lineêr (it produkt reparearje, dokumintaasje en tests bywurkje, de klant befredigje, in hotfix frijlitte, ensfh.). It is wichtich om it wurkproses te analysearjen en te begripen wa't ferantwurdlik is foar it organisearjen fan de ynteraksje tusken de twa teams, en wêrom dizze situaasje yn it earste plak mooglik waard. It is dúdlik wat yn it proses moat wurde reparearre - immen moat it totale byld kontrolearje sûnder herinneringen fan klanten, proaktyf. Kaarten fan de klant moatte opfalle ûnder oare kaartsjes fan ûntwikkelders. Stipe moat sjen oft it ûntwikkelingsteam op it stuit wurket oan har kaartsjes, en sa net, wannear't it kin begjinne te wurkjen, en wannear't resultaten kinne wurde ferwachte. Stipe en ûntwikkeling moatte periodyk kommunisearje en besprekke oer de status fan kaartsjes, de kolleksje fan ynformaasje dy't nedich is foar debuggen moat safolle mooglik automatisearre wurde, ensfh.
Krekt sa't yn 'e oarloch de fijân besiket it krúspunt tusken twa ienheden te reitsjen, sa is yn it wurk meastentiids it delikatste en kwetsbere punt de ynteraksje tusken teams. As de stipe- en ûntwikkelingsmanagers âld genôch binne, kinne se it proses sels reparearje, as net, sil it proses trochgean mei it generearjen fan konflikten en problemen oant in manager yngrypt dy't de situaasje reparearje kin.
In oar typysk foarbyld dat ik meardere kearen sjoen haw yn ferskate bedriuwen is in situaasje wêryn in produkt wurdt skreaun troch ien team, automatyske yntegraasjetests dêrfoar wurde skreaun troch in twadde team, en de ynfrastruktuer wêrop it allegear wurdt eksploitearre wurdt begelaat troch in tredde ploech. Problemen by it útfieren fan tests ûntsteane de hiele tiid, en de oarsaak fan problemen dêryn kin sawol it produkt as de tests en ynfrastruktuer wêze. It is meastentiids problematysk om iens te wurden oer wa't de earste analyse fan problemen, triembugs, parselogs fan it produkt, tests en ynfrastruktuer, ensfh. Konflikten binne hjir tige faak, en tagelyk unifoarm. By hege emosjonele yntensiteit falle de dielnimmers faak yn in bernlike posysje en begjinne de diskusjes yn 'e searje: "wêrom moat ik hjir oan tink", "se brekke faker ôf," ensfh.
Fanút in workflowperspektyf binne de spesifike stappen om in probleem op te lossen ôfhinklik fan 'e gearstalling fan' e teams, it type tests en produkt, ensfh. Yn ien fan 'e projekten hawwe wy periodike plicht ynfierd, wêrby't teams ien foar ien, wike nei wike, toetsen kontroleare. Yn 'e oare waard de earste analyse altyd dien troch de testûntwikkelders, mar de analyse wie heul basis en it produkt wie frij stabyl, dus it wurke goed. De kaai is om te soargjen dat it proses transparant is, dat de ferwachtingen dúdlik binne foar alle partijen en dat de situaasje foar elkenien earlik fielt.
Is konflikt sels in probleem yn in organisaasje Is it in min teken dat konflikten faak (of gewoan periodyk) foarkomme yn jo team? Yn 't algemien nee, want as d'r groei, ûntwikkeling is, is d'r in soarte fan dynamyk, dan ûntsteane problemen dy't noch noait earder binne oplost, en by it oplossen kinne konflikten ûntstean. Dit is in yndikator dat guon gebieten omtinken nedich binne, dat d'r gebieten binne foar ferbettering. It is slim as konflikten hiel faak ûntsteane, dreech op te lossen binne of lang duorje. Dit is nei alle gedachten in teken fan net genôch streamlined wurk prosessen en net genôch folwoeksenheid fan it team.
Boarne: www.habr.com