Epigraaf:
Eens op 'n tyd het die krimpvarkie en die klein beertjie mekaar in die bos ontmoet.
- Hallo, Egel!
- Hallo, Klein Beertjie!
So, woord vir woord, grappie vir grappie, is die reier in die gesig geslaan deur die Klein Beertjie...
Hieronder is 'n bespreking van ons spanleier, sowel as RAS-produkontwikkelingsdirekteur Igor Marnat, oor die besonderhede van werkskonflikte en moontlike metodes om dit te bestuur.
Die meeste van die konflikte wat ons by die werk teëkom, ontwikkel volgens 'n scenario soortgelyk aan dié wat in die epigraaf hierbo beskryf word. Daar is verskeie deelnemers wat aanvanklik redelik gunstig teenoor mekaar is; hulle probeer een of ander kwessie oplos, maar op die ou end bly die probleem onopgelos, en om een of ander rede blyk die verhoudings tussen die deelnemers aan die bespreking bederf te wees.
Die lewe is divers, en variasies kom voor in die scenario wat hierbo beskryf is. Soms is die verhouding tussen die deelnemers aanvanklik nie baie goed nie, soms is daar nie eers 'n kwessie wat 'n direkte oplossing vereis nie (soos byvoorbeeld in die epigraaf), soms na die bespreking bly die verhouding dieselfde as voor dit begin het, maar die kwessie is uiteindelik nie opgelos nie.
Wat is algemeen in alle situasies wat as 'n situasie van werkskonflik gedefinieer kan word?
Eerstens is daar twee of meer kante. Hierdie partye kan verskillende plekke in die organisasie beklee, in 'n verhouding van gelykheid wees (kollegas in 'n span), of op verskillende vlakke van die hiërargie (baas - ondergeskikte), individueel (werknemer) of groep wees (in gevalle van konflik tussen 'n werknemer en 'n span of twee spanne), ensovoorts. Die waarskynlikheid van konflik en die gemak van die oplossing daarvan word grootliks beïnvloed deur die vlak van vertroue tussen die deelnemers. Hoe beter die partye mekaar ken, hoe hoër die vlak van vertroue, hoe groter is die kans dat hulle tot 'n vergelyk sal kom. Byvoorbeeld, lede van 'n verspreide span wat nog nooit van aangesig tot aangesig interaksie gehad het nie, is meer geneig om konflik te ervaar oor 'n eenvoudige werkkwessie as mense wat ten minste 'n paar van aangesig tot aangesig interaksies gehad het. Wanneer daar dus in verspreide spanne gewerk word, is dit baie belangrik om te verseker dat alle spanlede periodiek persoonlik met mekaar vergader.
Tweedens, in 'n situasie van konflik by die werk, is die partye in 'n situasie om een of ander kwessie op te los wat belangrik is vir een van die partye, vir albei van hulle, of vir die organisasie as geheel. Terselfdertyd, as gevolg van die besonderhede van die situasie, het die partye gewoonlik genoeg tyd en 'n verskeidenheid maniere om dit op te los (formeel, informeel, vergaderings, briewe, bestuursbesluite, die teenwoordigheid van doelwitte en planne van die span, die feit van 'n hiërargie, ens.). Dit is anders as die situasie van die oplossing van 'n werk (of nie-werk) kwessie in 'n organisasie van, byvoorbeeld, die oplossing van 'n belangrike vraag: "Eh, kind, van watter area kom jy?!" op straat, of die konflik van die epigraaf. In die geval van die oplossing van 'n werkkwessie, is die kwaliteit van die werkproses en die kultuur van die oplossing van probleme in die span van belang.
Derdens is die bepalende faktor van die konflik (uit die oogpunt van ons bespreking) die feit dat die partye tot die proses nie onafhanklik tot 'n oplossing vir die kwessie kan kom wat alle partye pas nie. Die situasie vereis die ingryping van 'n derde party, 'n eksterne arbiter. Hierdie punt mag dalk kontroversieel lyk, maar in wese, as die konfliksituasie suksesvol opgelos is sonder die tussenkoms van 'n eksterne arbiter, die kwessie suksesvol opgelos is en die verhoudinge van die partye nie versleg het nie, is dit die situasie waarna ons moet streef . Ons sal heel waarskynlik nie eers weet van so 'n konflik nie, of ons sal toevallig uitvind nadat dit opgelos is. Hoe meer kwessies 'n span op sy eie kan oplos, hoe doeltreffender sal dit wees.
Nog 'n kenmerkende kenmerk van die konflik wat die moeite werd is om aan te raak, is die mate van emosionele intensiteit tydens die besluit. Konflik word nie noodwendig met 'n hoë emosionele vlak geassosieer nie. Deelnemers hoef nie te skree en hul arms te swaai vir die situasie om in wese 'n konflik te wees nie. Die kwessie is nie opgelos nie, 'n sekere emosionele spanning is aanwesig (dalk word dit nie duidelik uiterlik uitgedruk nie), wat beteken dat ons voor 'n situasie van konflik te staan kom.
Is dit enigsins nodig om in konfliksituasies in te gryp, of is dit beter om hul oplossing sy gang te laat neem en te wag dat die probleem vanself oplos? Moet. Dit is nie altyd in jou vermoë of bevoegdheid om die konflik heeltemal op te los nie, maar in enige situasie, in 'n konflik van enige skaal, kan jy 'n volwasse posisie inneem, en daardeur verskeie meer mense rondom jou daarheen bring, die negatiewe gevolge van die konflik en dra by tot die oplossing daarvan.
Voordat ons na 'n paar voorbeelde van konfliksituasies kyk, kom ons kyk na 'n paar belangrike punte wat gemeen is aan alle konflikte.
Wanneer 'n konflik opgelos word, is dit belangrik om bo die stryd te wees, en nie daarbinne nie (dit word ook genoem "om 'n meta-posisie in te neem"), dit wil sê om nie deel te wees van een van die partye in die oplossingsproses nie. Andersins sal die posisie van een van die partye net tot nadeel van die ander party versterk word as 'n eksterne arbiter die besluit bystaan. Wanneer 'n besluit geneem word, is dit belangrik dat dit moreel deur alle partye aanvaar word, soos hulle sê, "gekoop." Sodat, selfs al was die partye nie verheug oor die besluit wat geneem is nie, hulle ten minste opreg ingestem het om dit te implementeer. Soos hulle sê, om te kan verskil en commit. Anders sal die konflik bloot sy voorkoms verander, die smeulende vuur sal onder die veenmoes bly en op 'n stadium onvermydelik weer opvlam.
Die tweede punt, wat deels verband hou met die eerste, is dat as jy reeds besluit het om deel te neem aan die oplossing van die konflik, neem dit so ernstig as moontlik vanuit die oogpunt van kommunikasie en bestudering van die konteks. Praat persoonlik met elkeen van die partye. Afsonderlik met elkeen, om mee te begin. Moenie tevrede wees met pos nie. In die geval van 'n verspreide span, praat ten minste via videoskakel. Moenie tevrede wees met hoorsê en ooggetuieverslae nie. Verstaan die storie, wat elke kant wil hê, hoekom hulle dit wil hê, wat hulle verwag, het hulle al probeer om hierdie probleem op te los, wat sal gebeur as dit nie opgelos word nie, watter oplossings sien hulle, hoe stel hulle die posisie van die ander kant, wat dink hulle, reg of verkeerd, ens. Laai al die moontlike konteks in jou kop, met 'n oop gemoed, met die veronderstelling dat almal reg is. Jy is nie binne die konflik nie, jy is daarbuite, in 'n metaposisie. As die konteks slegs in 'n posdraad beskikbaar is, lees dit ten minste in sy geheel en die drade en dokumente wat daarmee verband hou. Nadat jy dit gelees het, praat steeds met jou stem. Jy is amper gewaarborg om iets belangrik te hoor wat nie in die pos is nie.
Die derde belangrike punt is die algemene benadering tot kommunikasie. Dit is gewone dinge, niks kosmies nie, maar dit is baie belangrik. Ons probeer nie tyd bespaar nie, ons praat met al die deelnemers, ons kritiseer nie die persoon nie, maar ons neem die gevolge van sy optrede in ag (nie "jy is onbeskof", maar "miskien kan die ouens aanstoot neem deur hierdie ding"), gee ons die geleentheid om gesig te red, ons voer besprekings persoonlik, nie voor die ry nie.
Konflikte word gewoonlik deur een van twee redes veroorsaak. Die eerste hou verband met of 'n persoon ten tye van konflik in die posisie van 'n volwassene of in die posisie van 'n kind is (meer hieroor hieronder). Dit is te danke aan sy emosionele volwassenheid, die vermoë om sy emosies te bestuur (wat, terloops, nie altyd met sy ouderdom verband hou nie). Die tweede algemene rede is die onvolmaaktheid van die werksproses, wat situasies van grys areas skep waarin verantwoordelikheid tussen deelnemers versprei is, die verwagtinge van die partye nie deursigtig vir mekaar is nie, en rolle in die proses vervaag is.
Gevolglik, in die oplossing van 'n konflik (sowel as enige ander kwessie), moet 'n bestuurder drie perspektiewe in gedagte hou: korttermyn - om die kwessie/konflik hier en nou op te los, mediumtermyn - om die waarskynlikheid van 'n ander konflik te minimaliseer vir dieselfde rede, en langtermyn - om 'n volwasse kultuur in die span persoon te kweek.
Elkeen van ons het 'n innerlike kind, so drie of vier jaar oud. Hy slaap die meeste van die tyd by die werk, maar word soms wakker en neem beheer oor. Die kind het sy eie prioriteite. Dit is vir hom belangrik om aan te dring dat dit sy sandbox is, sy ma is meer lief vir hom, sy masjien is die beste (die ontwerp is die beste, hy programmeer die beste, ...). In 'n situasie van konflik kan 'n kind speelgoed druk, sy voete stamp en sy spatel kraak, maar hy kan nie volwasse kwessies oplos nie (oplossingsargitektuur, benaderings tot geoutomatiseerde toetsing, vrystellingdatums, ens.), hy dink nie in terme van voordele nie. vir die span. ’n Kind in konflik kan aangemoedig, getroos en bed toe gestuur word deur hom te vra om sy volwassene te bel. Voordat jy 'n gesprek in 'n konfliksituasie begin, maak seker dat jy met 'n volwassene praat, nie 'n kind nie, en dat jy self in die posisie van 'n volwassene is. As jou eerlike doelwit op die oomblik is om 'n ernstige kwessie op te los, is jy in die posisie van 'n volwassene. As jou doel is om jou voete te stamp en jou skouerblad te kraak, is dit 'n kinderagtige posisie. Stuur jou innerlike kind bed toe en bel 'n volwassene, of herskeduleer die bespreking. 'n Persoon neem 'n emosionele besluit, en soek dan 'n rasionele regverdiging daarvoor. ’n Besluit wat deur ’n kind geneem word op grond van kinders se prioriteite sal nie optimaal wees nie.
Benewens gedrag ten tye van konflik, word 'n kind of volwassene se posisie ook gekenmerk deur die vlak van verantwoordelikheid wat 'n persoon gereed is om op homself te neem. In sy uiterste manifestasies lyk die kinderagtige posisie van 'n programmeerder, wat ek meer as een keer ontmoet het, so: Ek het die kode geskryf, dit vir hersiening gestuur - my werk is klaar. Beoordelaars moet dit hersien en goedkeur, QA moet dit nagaan, as daar probleme is, sal hulle my laat weet. Vreemd genoeg tree selfs redelik volwasse en ervare mense soms so op. Die ander kant van die skaal is dat 'n persoon homself verantwoordelik ag om te verseker dat sy kode werk, deur toetse gedek word, persoonlik deur hom gekontroleer is, die hersiening suksesvol geslaag het (indien nodig is daar geen probleem om beoordelaars te ping, kwessies te bespreek nie deur stem, ens.) en is onderdruk , QA sal hulp verleen indien nodig, toetsscenario's sal beskryf word, ens. In normale gevalle begin die programmeerder óf nader aan die volwasse punt van die skaal, óf beweeg daarheen soos hy ondervinding opdoen (mits die regte kultuur binne die span gekweek word). In uiterste gevalle gaan hy voort om te werk, gewoonlik in 'n kinderagtige posisie, dan het hy en die span van tyd tot tyd probleme en konflikte.
Die bevordering van die regte, volwasse kultuur in 'n span is 'n belangrike taak vir enige bestuurder. Dit neem 'n lang tyd en daaglikse moeite, maar die resultaat is die moeite werd. Daar is twee maniere om spankultuur te beïnvloed – om deur voorbeeld te lei (wat beslis gevolg sal word; die span kyk altyd na die leier) en om die regte gedrag te bespreek en te beloon. Hier is ook niks abstrus of baie formeel nie, net wanneer probleme bespreek word, let op dat iets hier gedoen kon word, beklemtoon dat jy opgemerk het wanneer dit reg besluit is, lof, let op tydens die vrystellingoorsig, ens.
Kom ons kyk na verskeie tipiese konfliksituasies, van eenvoudig tot kompleks:
Konflikte wat nie verband hou met werkkwessies nie
Dikwels is daar konflikte by die werk wat nie met werkkwessies verband hou nie. Hul voorkoms en gemak van resolusie hou gewoonlik direk verband met die vlak van emosionele intelligensie van die deelnemers, hul vlak van volwassenheid, en hou nie verband met die perfeksie of onvolmaaktheid van die werksproses nie.
Tipiese voorbeelde: iemand gebruik nie die wasmasjien of stort gereeld genoeg nie, waarvan ander nie hou nie, iemand is bedompig, terwyl ander wind kry as hulle die venster oopmaak, iemand te raserig, en ander het stilte nodig om te werk, en so aan. Dit is beter om nie die oplossing van konflikte van hierdie soort te vertraag nie en nie toe te laat dat hulle hul gang gaan nie. Hulle sal nie op hul eie oplos nie en sal jou aandag elke dag van die werk aftrek en die atmosfeer in die span vergiftig. Gelukkig is dit gewoonlik nie 'n groot probleem om dit op te los nie - gesels net rustig (natuurlik een-tot-een) met 'n kollega wat higiëne verwaarloos, verskaf gemaklike sitplek vir mense wat stilte/koelte verkies, koop klankabsorberende oorfone of installeer afskortings , ens.
Nog 'n voorbeeld wat ek verskeie kere tydens my werk teëgekom het, is die sielkundige onverenigbaarheid van spanlede. Om een of ander rede kan mense eenvoudig nie saamwerk nie; elke interaksie eindig in 'n skandaal. Soms is dit te wyte aan die feit dat mense polêre sienings oor een of ander dringende kwessie (gewoonlik polities) huldig en nie weet hoe om hulle buite werk te laat nie. Om hulle te oortuig om mekaar te verdra of hul gedrag te verander, is 'n taamlik futiele taak. Die enigste uitsondering wat ek teëgekom het, is jong kollegas met oop persepsies; hul gedrag kan steeds geleidelik verander word deur periodieke gesprekke. Gewoonlik word die probleem suksesvol opgelos deur hulle in verskillende spanne te verdeel, of ten minste die geleentheid te bied om by die werk baie selde te oorvleuel.
In al die bogenoemde situasies is dit die moeite werd om persoonlik met alle deelnemers te praat, die situasie te bespreek, te vra of hulle hoegenaamd 'n probleem in hierdie geval sien, te vra wat, na hul mening, die oplossings is, en om hul deelname aan die maak daarvan te verseker. besluit.
Vanuit die oogpunt van die optimalisering van die werkproses (die mediumtermyn-perspektief wat ek genoem het), kan nie veel hier gedoen word nie; die enigste punt vir optimalisering is om die verenigbaarheidsfaktor in ag te neem wanneer 'n span gevorm word en nie om mense te sit nie. vooraf saam wie sal konflik.
Vanuit 'n spankultuurperspektief kom sulke situasies baie minder voor in spanne met 'n volwasse kultuur, waar mense die span en kollegas respekteer en weet hoe om kwessies onafhanklik op te los. Boonop word sulke konflikte baie makliker (dikwels outomaties) opgelos in spanne waar daar 'n hoë vlak van vertroue is, mense lank saamgewerk het en/of gereeld buite die werk kommunikeer.
Konflikte wat verband hou met werkkwessies:
Sulke konflikte word gewoonlik deur albei redes gelyktydig veroorsaak, beide emosioneel (die feit dat een van die deelnemers nie in die posisie van 'n volwassene is nie) en die onvolmaaktheid van die werksproses self. Miskien is die mees algemene tipe konflikte wat ek teëgekom het, konflikte tydens kode-oorsig of argitektuurbesprekings tussen ontwikkelaars.
Ek sal twee tipiese gevalle hier uitlig:
1) In die eerste geval kan die ontwikkelaar nie 'n kode-oorsig van 'n kollega kry nie. Die pleister word vir hersiening gestuur, en niks gebeur nie. Met die eerste oogopslag is daar geen ooglopende konflik tussen die twee kante nie, maar as jy daaroor dink, is dit nogal 'n konflik. Die werkkwessie is nie opgelos nie, een van die partye (wag vir 'n resensie) ervaar ooglopende ongemak. 'n Uiterste subtipe van hierdie saak is ontwikkeling in 'n gemeenskap of in verskillende spanne, terwyl die beoordelaar dalk nie in hierdie spesifieke kode belangstel nie, weens laai of ander omstandighede, dalk glad nie aandag gee aan die hersieningsversoek nie, en die eksterne arbiter ('n bestuurder gemeen aan beide kante) ) mag glad nie bestaan nie.
Die oplossingsbenadering wat in so 'n situasie help, hou juis verband met die langtermynperspektief, die kultuur van 'n volwassene. Eerstens werk slim aktiwiteit. Jy moet nie verwag dat die kode wat aan die resensie hang, die aandag van die resensent self sal trek nie. Ons moet beoordelaars help om hom raak te sien. Pingani 'n paar mense, vra 'n vraag oor syncape, neem deel aan besprekings. Dit is duidelik dat belangigheid meer geneig is om skade te berokken as om te help, jy moet gesonde verstand gebruik. Tweedens werk vooraf voorbereiding goed. As die span verstaan wat gebeur en hoekom, hoekom hierdie kode enigsins nodig is, die ontwerp is vooraf met almal bespreek en ooreengekom, is mense meer geneig om aandag aan sulke kode te gee en dit vir werk te aanvaar. Derdens werk gesag. As jy geresenseer wil word, doen baie resensies self. Doen resensies van hoë gehalte, met regte kontrole, regte toetse en nuttige opmerkings. As jou bynaam welbekend is in die span, is daar 'n groter kans dat jou kode raakgesien sal word.
Vanuit 'n werkvloei-oogpunt is moontlike verbeterings hier korrekte prioritisering wat daarop gemik is om die ontwikkelaar te help om sy en die span se doelwitte te bereik (hersien ander, skryf briewe aan die gemeenskap, vergesel die kode met 'n argitektuurbeskrywing, dokumentasie, toetse, neem deel aan gesprekke met gemeenskap, ens.), verhoed dat kolle te lank in die tou hang, ensovoorts.
2) Die tweede algemene geval van konflikte tydens kode- of ontwerpresensies is verskillende sienings oor tegniese kwessies, koderingstyl en keuse van gereedskap. Van groot belang in hierdie geval is die vlak van vertroue tussen die deelnemers, wat aan dieselfde span behoort, en ervaring van saamwerk. ’n Doodloopstraat vind plaas wanneer een van die deelnemers ’n kinderlike posisie inneem en nie probeer hoor wat die gespreksgenoot aan hom wil oordra nie. Dikwels kan beide die benadering wat deur die ander party voorgestel is en die benadering wat aanvanklik voorgestel is, suksesvol werk en dit maak in beginsel nie saak watter een om te kies nie.
Eendag het 'n programmeerder van my span (kom ons noem hom Pasha) 'n pleister voorberei met veranderinge aan die pakketontplooiingstelsel, wat ontwikkel en ondersteun is deur kollegas van 'n naburige departement. Een van hulle (Igor) het sy eie sterk mening gehad oor presies hoe Linux-dienste gekonfigureer moet word wanneer pakkette ontplooi word. Hierdie mening het verskil van die benadering wat in die pleister voorgestel is, en hulle kon nie saamstem nie. Soos gewoonlik was spertye besig om uit te loop, en dit was nodig om tot een of ander besluit te kom; dit was nodig dat een van hulle 'n volwasse posisie inneem. Pasha het erken dat beide benaderings 'n reg op lewe het, maar hy wou hê dat sy opsie moet slaag, want Nie een of die tweede opsie het enige ooglopende tegniese voordele gehad nie.
Ons bespreking het iets soos volg gelyk (baie skematies het die gesprek natuurlik 'n halfuur geduur):
- Pasha, ons het 'n funksie vries oor 'n paar dae. Dit is belangrik dat ons alles bymekaar kry en so gou moontlik begin toets. Hoe kan ons deur Igor kom?
— Hy wil dienste anders instel, hy het vir my opmerkings daar geplak...
- En wat is daar, groot veranderinge, baie ophef?
- Nee, daar is werk vir 'n paar uur, maar op die ou end is daar geen verskil nie, dit sal enige kant toe werk, hoekom is dit nodig? Ek het iets gemaak wat werk, kom ons aanvaar dit.
- Luister, hoe lank bespreek julle dit al?
- Ja, ons het nou 'n week en 'n half tyd gemerk.
- Um... kan ons 'n probleem binne 'n paar uur oplos wat reeds 'n week en 'n half geneem het, en dit nie doen nie?
- Wel, ja, maar ek wil nie hê Igor moet dink dat ek ingeval het nie ...
- Luister, wat is vir jou belangriker, om 'n vrylating uit te reik, saam met jou besluit binne, of om Igor dood te maak? Ons kan dit blokkeer, dan is daar egter 'n goeie kans om deur te vlieg met die vrystelling.
- Wel ... dit sal natuurlik cool wees om Igor se neus af te vee, maar goed, die vrylating is belangriker, ek stem saam.
- Is dit regtig vir jou so belangrik wat Igor dink? Om eerlik te wees, gee hy glad nie om nie, hy wil net 'n verenigde benadering hê op verskillende plekke van die ding waarvoor hy verantwoordelik is.
- Wel, ok, laat ek maak soos hy in die kommentaar vra en kom ons begin toets.
- Dankie, Pasha! Ek was seker dat van julle twee jy die meer volwasse sou wees, alhoewel Igorek ouer as jy is :)
Die probleem is opgelos, die vrystelling is betyds vrygestel, Pasha het nie veel ontevredenheid gevoel nie, want hy het self 'n oplossing voorgestel en dit geïmplementeer. Igor was oor die algemeen tevrede, want... Sy mening is in ag geneem en hulle het gedoen soos hy voorgestel het.
Nog 'n tipe van in wese dieselfde konflik is die keuse tussen tegniese oplossings/biblioteke/benaderings in 'n projek, veral in 'n verspreide span. In een van die projekte, wat geposisioneer is as die gebruik van C/C++, het dit geblyk dat die tegniese bestuur van die projek kategories teen die gebruik van STL (Standard Template Library) was. Dit is 'n standaardtaalbiblioteek wat ontwikkeling vergemaklik, en ons span is baie gewoond daaraan. Dit het geblyk dat die projek baie nader aan C is as aan C++, wat die span nie baie geïnspireer het nie, want bestuur het hul bes probeer en baie cool plus-spelers gewerf. Terselfdertyd het die Amerikaanse deel van die span, beide ingenieurs en bestuurders, lank in die maatskappy gewerk, gewoond aan die bestaande toedrag van sake en tevrede met alles. Die Russiese deel van die span is redelik onlangs bymekaar gebring, binne 'n paar weke (ek ingesluit). Die Russiese deel van die span wou kategories nie die gewone benadering tot ontwikkeling laat vaar nie.
Eindelose geskrewe besprekings het tussen die twee kontinente begin, briewe op drie of vier skerms het heen en weer gevlieg, in groepposse en persoonlikes, van programmeerders tot programmeerders en bestuurders. Soos gewoonlik die geval is, is briewe van hierdie lengte deur niemand gelees nie, behalwe die skrywers en hul vurige ondersteuners. Geselsies het gekraak van spanning, en het multiskerm-gedagtes in verskillende rigtings oorgedra oor die tegniese voordele van die STL, hoe goed dit getoets is, hoe veilig dit is, en in die algemeen, hoe wonderlik die lewe daarmee is, en hoe verskriklik dit is daarsonder .
Dit het alles nogal lank gehou, totdat ek uiteindelik besef het dat ons die tegniese aspekte van die kwessie bespreek, maar die probleem was in werklikheid nie tegnies nie. Die probleem is nie die voor- of nadele van STL of die moeilikheid om daarsonder te werk nie. Die probleem is eerder organisatories. Ons moes net verstaan hoe die maatskappy vir wie ons gewerk het gewerk het. Nie een van ons het voorheen ondervinding gehad om in so 'n maatskappy te werk nie. Die ding was dat nadat die kode ontwikkel en in produksie vrygestel is, ondersteuning deur heeltemal ander mense van ander spanne, van ander lande hanteer is. Hierdie groot ingenieurspan van etlike tienduisende ingenieurs (in totaal) kon net 'n heeltemal basiese minimum van tegniese middele bekostig, so te sê 'n minimum minimum. Enigiets wat verder gaan as die ingenieursstandaard wat fisies in die maatskappy vasgestel is, kon nie in die toekoms ondersteun word nie. Die vlak van 'n span word bepaal deur die vlak van sy swakste lede. Nadat ons verstaan het ware motivering optrede van die Amerikaanse deel van die span, is hierdie kwessie van die agenda verwyder, en saam het ons die produk suksesvol ontwikkel en vrygestel deur gebruik te maak van die standaarde wat deur die maatskappy aanvaar is. Briewe en geselsies in hierdie geval het nie goed gewerk nie; dit het verskeie reise en baie persoonlike kommunikasie gekos om tot 'n gemene deler te kom.
Uit die oogpunt van die werkvloei, in hierdie spesifieke geval, sal dit help om 'n beskrywing te hê van die gereedskap wat gebruik word, vereistes daarvoor, beperkings op die byvoeging van nuwes, en regverdiging vir sulke beperkings. Sulke dokumente stem rofweg ooreen met dié wat beskryf word in paragrawe Hergebruikstrategie en Ontwikkelingsomgewing van die “Manager's Handbook for Software Development”, ontwikkel in . Ten spyte van sy ouderdom, beskryf dit perfek al die hoofaktiwiteite en beplanningstadia van sagteware-ontwikkeling van hierdie soort. Om dokumente soos hierdie te hê, maak dit baie maklik om te bespreek watter komponente en benaderings in 'n produk gebruik kan word, en hoekom.
Uit 'n kulturele oogpunt, natuurlik, met 'n meer volwasse posisie, waarin die partye probeer om die werklike motivering van hul kollegas se optrede te hoor en te verstaan en op te tree gebaseer op die prioriteite van die projek en die span, en nie die persoonlike ego nie. , sou die konflik makliker en vinniger opgelos word.
In 'n ander konflik oor die keuse van 'n tegniese oplossing het dit my ook 'n merkbare tyd geneem om die motivering van een van die partye te verstaan (dit was 'n baie ongewone geval), maar nadat die motivering duidelik was, was die oplossing voor die hand liggend.
Die situasie is so: 'n nuwe ontwikkelaar verskyn in 'n span van ongeveer 20 mense, kom ons noem hom Stas. Op daardie tydstip was ons standaard hulpmiddel vir kommunikasie as 'n span Skype. Soos dit later geblyk het, was Stas 'n groot aanhanger van oop standaarde en oopbronsagteware, en het slegs gereedskap en bedryfstelsels gebruik waarvan die bronne publiek beskikbaar was en wat publiek beskryfde protokolle gebruik het. Skype is nie een van hierdie instrumente nie. Ons het baie tyd spandeer om die voor- en nadele van hierdie benadering te bespreek, pogings om analoë van Skype op verskillende bedryfstelsels bekend te stel, Stas se pogings om die span te oortuig om na ander standaarde oor te skakel, persoonlik aan hom te skryf per pos, hom persoonlik te bel op die foon, koop vir hom 'n tweede rekenaar spesifiek vir Skype, ens. Ten slotte het ek besef dat hierdie probleem in wese nie tegnies of organisatories is nie, dit is eerder ideologies, selfs, kan mens sê, godsdienstig (vir Stas). Selfs as ons uiteindelik Stas en Skype verbind het (wat etlike maande geneem het), sou die probleem weer op enige daaropvolgende instrument ontstaan. Ek het geen werklike middele tot my beskikking gehad om Stas se wêreldbeskouing te verander nie, en daar was geen rede om die wêreldbeskouing van 'n span wat perfek in hierdie omgewing gewerk het, te probeer verander nie. Die persoon en die maatskappy was eenvoudig ortogonaal in hul wêreldbeskouing. In sulke situasies is 'n goeie oplossing organisatories. Ons het Stas na 'n ander span oorgeplaas, waar hy meer organies was.
Die rede vir hierdie konflik is myns insiens die verskil tussen die persoonlike kultuur van 'n bepaalde persoon (wat 'n sterk mening het wat hom nie toelaat om kompromieë aan te gaan nie) en die kultuur van die maatskappy. In hierdie geval is dit natuurlik die bestuurder se fout. Dit was aanvanklik verkeerd om hom op 'n projek van hierdie soort te neem. Stas het uiteindelik na 'n oopbronsagteware-ontwikkelingsprojek oorgeskuif en daar uitgeblink.
'n Goeie voorbeeld van 'n konflik wat veroorsaak word deur beide die kinderagtige houding van die ontwikkelaar en die tekortkominge van die werksproses is 'n situasie waarin, in die afwesigheid van 'n definisie van gedoen, die ontwikkelaar en die QA-span verskillende verwagtinge het ten opsigte van die gereedheid van die kenmerk oorgedra na QA. Die ontwikkelaar het geglo dat dit genoeg was om die kode te skryf en die kenmerk oor die heining na QA te gooi – hulle sal dit daar uitsorteer. Terloops 'n taamlik volwasse en ervare programmeerder, maar dit was sy interne drempel vir kwaliteit. QA het nie hiermee saamgestem nie en geëis om aan hulle te wys en te beskryf wat hy self nagegaan het, en 'n toetsskrif vir hulle geëis. Hulle het in die verlede probleme met funksionaliteit van hierdie ontwikkelaar gehad en wou nie weer hul tyd mors nie. Terloops, hulle was reg - die kenmerk het regtig nie gewerk nie, hy het nie die kode nagegaan voordat hy dit na QA gestuur het nie.
Om die situasie op te los, het ek hom gevra om my te wys dat alles regtig werk (dit het nie gewerk nie, en hy moes dit regmaak), ons het met die span gepraat en met die QA-definisie van klaar (hulle het dit nie gemaak nie) skryf, want ons wou nie die proses te burokraties maak nie ), wel, ons het gou met hierdie spesialis geskei (tot algemene verligting).
Uit die oogpunt van die werkvloei is moontlike verbeterings in hierdie geval die teenwoordigheid van 'n definisie van gedoen, vereistes vir ondersteuning van elke eenheidkenmerk en integrasietoetse, en 'n beskrywing van toetsing wat deur die ontwikkelaar uitgevoer is. In een van die projekte het ons die vlak van kodedekking deur toetse tydens CI gemeet en as die dekkingsvlak gedaal het nadat 'n pleister bygevoeg is, is die toetse as misluk gemerk, m.a.w. enige nuwe kode kon slegs bygevoeg word as daar nuwe toetse daarvoor was.
Nog 'n tipiese voorbeeld van 'n konflik wat nou verband hou met die organisasie van die werkproses. Ons het 'n produk, 'n produkontwikkelingspan, 'n ondersteuningspan en 'n kliënt. Die kliënt het probleme met die produk en kontak ondersteuning. Ondersteuning ontleed die probleem en verstaan dat die probleem in die produk is en dra die probleem oor na die produkspan. Die produkspan is in 'n besige tyd, 'n vrystelling kom nader, so 'n kaartjie met 'n probleem van 'n kliënt, verlore tussen die ander kaartjies van die ontwikkelaar aan wie dit toegewys is, hang vir 'n paar weke sonder aandag. Ondersteuning dink dat die ontwikkelaar aan die kliënt se probleem werk. Die kliënt wag en hoop dat daar aan hul probleem gewerk word. In werklikheid gebeur nog niks nie. Na 'n paar weke besluit die kliënt uiteindelik om in die vordering belang te stel en vra ondersteuning hoe dit gaan. Ondersteuning vra vir ontwikkeling. Die ontwikkelaar sidder, kyk deur die lys kaartjies en kry 'n kaartjie van die kliënt daar. As hy 'n kaartjie van 'n kliënt lees, verstaan hy dat daar nie genoeg inligting is om die probleem op te los nie, en hy benodig meer logs en stortings. Ondersteuning versoek bykomende inligting van die kliënt. En dan besef die kliënt dat niemand al die tyd aan sy probleem gewerk het nie. En donderweer sal slaan...
In hierdie situasie is die oplossing vir die konflik self redelik voor die hand liggend en lineêr (maak die produk reg, werk dokumentasie en toetse op, stel die kliënt gerus, stel 'n hotfix vry, ens.). Dit is belangrik om die werkproses te ontleed en te verstaan wie verantwoordelik is vir die organisering van die interaksie tussen die twee spanne, en hoekom hierdie situasie in die eerste plek moontlik geword het. Dit is duidelik wat in die proses reggemaak moet word – iemand moet die geheelbeeld sonder aanmanings van kliënte proaktief monitor. Kaartjies van die kliënt moet uitstaan tussen ander kaartjies van ontwikkelaars. Ondersteuning moet kyk of die ontwikkelingspan tans aan sy kaartjies werk, en indien nie, wanneer dit kan begin werk, en wanneer resultate verwag kan word. Ondersteuning en ontwikkeling moet periodiek die status van kaartjies kommunikeer en bespreek, die versameling van inligting wat nodig is vir ontfouting moet so veel as moontlik geoutomatiseer word, ens.
Net soos in oorlog die vyand probeer om die aansluiting tussen twee eenhede te tref, so in werk is die mees delikate en kwesbare punt gewoonlik die interaksie tussen spanne. As die ondersteunings- en ontwikkelingsbestuurders oud genoeg is, sal hulle die proses self kan regmaak, indien nie, sal die proses voortgaan om konflikte en probleme te genereer totdat 'n bestuurder ingryp wat die situasie kan regmaak.
Nog 'n tipiese voorbeeld wat ek herhaaldelik in verskillende maatskappye gesien het, is 'n situasie waarin 'n produk deur een span geskryf word, outomatiese integrasietoetse daarvoor word deur 'n tweede span geskryf, en die infrastruktuur waarop dit alles bedryf word, word vergesel deur 'n derde span. Probleme met die uitvoer van toetse kom heeltyd voor, en die oorsaak van probleme daarin kan beide die produk en die toetse en infrastruktuur wees. Dit is gewoonlik problematies om ooreen te kom oor wie die aanvanklike ontleding van probleme, lêerfoute, ontleedlogboeke van die produk, toetse en infrastruktuur, ens. Konflikte hier is baie gereeld, en terselfdertyd eenvormig. In die geval van hoë emosionele intensiteit verval deelnemers dikwels in 'n kinderlike posisie en besprekings begin in die reeks: "hoekom moet ek hieraan peuter," "hulle breek meer gereeld af," ens.
Vanuit 'n werkvloeiperspektief hang die spesifieke stappe om 'n probleem op te los af van die samestelling van die spanne, die tipe toetse en produk, ens. In een van die projekte het ons periodieke diens ingestel, waarin spanne toetse een op 'n slag, week vir week gemonitor het. In die ander een is die aanvanklike ontleding altyd deur die toetsontwikkelaars gedoen, maar die ontleding was baie basies en die produk was redelik stabiel, so dit het goed gewerk. Die sleutel is om te verseker dat die proses deursigtig is, dat verwagtinge duidelik vir alle partye is en dat die situasie vir almal regverdig voel.
Is konflik selfs 'n probleem in 'n organisasie?Is dit 'n slegte teken dat konflikte dikwels (of net periodiek) in jou span voorkom? Oor die algemeen nee, want as daar groei, ontwikkeling is, is daar 'n soort dinamika, dan ontstaan kwessies wat nog nooit voorheen opgelos is nie, en wanneer dit opgelos word, kan konflikte ontstaan. Dit is 'n aanduiding dat sommige areas aandag nodig het, dat daar areas is vir verbetering. Dit is sleg as konflikte baie dikwels ontstaan, moeilik is om op te los of lank neem. Dit is heel waarskynlik 'n teken van onvoldoende vaartbelynde werkprosesse en onvoldoende volwassenheid van die span.
Bron: will.com