Epigraf:
Egel en Beer ontmoetten elkaar eens in het bos.
— Hallo, Egel!
— Hallo, Beer!
Zo, woord voor woord, grapje voor grapje, kreeg Egel een tik van Beer...
Onder de kat zijn de overpeinzingen van onze teamleider en de directeur productontwikkeling RAS — Igor Marnat over de specifieke aard van werkconflicten en mogelijke beheermethoden.
De meeste conflicten waarmee we op het werk te maken krijgen, volgen een scenario dat lijkt op het hierboven beschreven in de epigraaf. Er zijn verschillende deelnemers, die aanvankelijk positief tegenover elkaar zijn ingesteld; ze proberen een probleem op te lossen, maar uiteindelijk blijft het probleem onopgelost en blijken de relaties tussen de deelnemers om de een of andere reden verstoord.
Het leven is divers, in het hierboven beschreven scenario zijn er variaties. Soms zijn de verhoudingen tussen de deelnemers vanaf het begin niet zo goed, soms is er zelfs geen vraag die onmiddellijke oplossing vereist (zoals in de epigraaf), en soms blijven de verhoudingen na de bespreking hetzelfde als ervoor, maar is de kwestie uiteindelijk niet opgelost.
Wat hebben alle situaties die we kunnen definiëren als een werkconflict gemeen?
Ten eerste is er de aanwezigheid van twee of meer partijen. Deze partijen kunnen verschillende posities in de organisatie innemen, zich in een gelijke relatie bevinden (collega's in een team), of op verschillende niveaus van de hiërarchie (leidinggevende — ondergeschikte), individueel (werknemer) of groepsgewijs (in het geval van een conflict tussen een werknemer en een team of tussen twee teams), enzovoorts. Het niveau van vertrouwen tussen de deelnemers heeft een grote invloed op de waarschijnlijkheid van een conflict en de eenvoud ervan om op te lossen. Hoe beter de partijen elkaar kennen en hoe hoger het niveau van vertrouwen, des te groter de kans dat ze tot een overeenkomst komen. Bijvoorbeeld, medewerkers van een verspreid team die nooit persoonlijk hebben gesproken, zullen eerder in een conflictsituatie geraken bij het oplossen van een eenvoudige werkkwestie dan mensen die tenminste een paar keer persoonlijk hebben gesproken. Daarom is het erg belangrijk om periodes van persoonlijke ontmoetingen tussen alle teamleden te waarborgen wanneer men in verspreide teams werkt.
Ten eerste bevinden de partijen in een conflictsituatie zich in een situatie waarin ze een kwestie moeten oplossen die belangrijk is voor een van de partijen, voor beide partijen of voor de organisatie als geheel. Door de specifieke aard van de situatie hebben de partijen meestal voldoende tijd en verschillende manieren om het op te lossen (formeel, informeel, vergaderingen, brieven, besluiten van het management, de aanwezigheid van doelen en plannen van het team, de aanwezigheid van een hiërarchie, enzovoort). Dit is het verschil met het oplossen van een werkgerelateerde (of niet-werkgerelateerde) kwestie binnen de organisatie, bijvoorbeeld het oplossen van een belangrijke vraag: “Hé, jongen, uit welke wijk kom je?!” op straat, of het conflict uit de inleiding. Bij het oplossen van een werkgerelateerde kwestie zijn de kwaliteit van het werkproces en de cultuur van het oplossen van kwesties binnen het team van belang.
Ten derde is een bepalende factor voor het conflict (vanuit ons gespreksperspectief) het feit dat de partijen in het proces niet zelfstandig tot een voor alle partijen acceptabele oplossing kunnen komen. De situatie vereist de tussenkomst van een derde partij, een externe arbiter. Dit punt kan omstreden lijken, maar in wezen, als een conflictsituatie met succes werd opgelost zonder tussenkomst van een externe arbiter, dan is de kwestie succesvol opgelost en zijn de relaties tussen de partijen niet verslechterd. Dit is de situatie waarnaar we moeten streven. We zullen hoogstwaarschijnlijk niet eens weten van zo'n conflict, of we ontdekken er toevallig iets van na de oplossing. Hoe meer vragen het team zelfstandig kan oplossen, hoe effectiever het zal werken.
Een andere kenmerkende eigenschap van een conflict die het waard is om te bespreken, is de mate van emotionele intensiteit tijdens het oplossen. Een conflict gaat niet per se gepaard met een hoge emotionele temperatuur. De deelnemers hoeven niet te schreeuwen en met hun handen te zwaaien om de situatie als conflictueus te bestempelen. Een vraag wordt niet opgelost, er is een bepaalde emotionele spanning aanwezig (misschien is deze niet duidelijk extern geuit), wat betekent dat we hier te maken hebben met een conflictsituatie.
Is it necessary to intervene in conflict situations, or is it better to let them resolve themselves and wait for the problem to dissipate on its own? Yes, it is necessary. While it may not always be within your power or expertise to fully resolve a conflict, in any situation, no matter the scale of the conflict, you can adopt an adult perspective, thereby encouraging others around you to do the same, mitigating the negative consequences of the conflict, and promoting its resolution.
Before we delve into several examples of conflict situations, let’s focus on a few important points that are common to all conflicts.
In resolving a conflict, it is important to remain above the fray rather than being caught up in it (this is also called 'taking a meta position'); that is, not to find oneself on one side of the solution process. Otherwise, instead of being an external arbitrator assisting in the resolution, you will only strengthen the position of one party to the detriment of the other. When making a decision, it is crucial that all parties morally accept it, as they say, 'buy-in' is essential. Even if the parties are not thrilled about the decision made, they should at least sincerely agree to carry it out. It’s about being able to disagree and commit. Otherwise, the conflict may simply change form, with the smoldering fire remaining under the surface, and at some point, it will inevitably flare up again.
Een tweede punt, dat gedeeltelijk verband houdt met de eerste, is dat als je besluit deel te nemen aan het oplossen van een conflict, je dit zo serieus mogelijk moet nemen in termen van communicatie en het begrijpen van de context. Spreek persoonlijk met elke partij. Begin afzonderlijk met elke partij. Tevreden zijn met e-mail is niet voldoende. In het geval van een gedistribueerd team — spreek in ieder geval via videoverbinding. Tevreden zijn met geruchten en samenvattingen van getuigen is niet genoeg. Begrijp het verhaal, wat elke partij wil, waarom ze dat willen, wat ze verwachten, of ze geprobeerd hebben het probleem eerder op te lossen, wat er zal gebeuren als het niet wordt opgelost, welke oplossingsmogelijkheden ze zien, hoe ze de positie van de andere partij voorstellen, wat zij denken dat goed of verkeerd is, enzovoort. Laad zoveel mogelijk context in je hoofd, onbevooroordeeld, veronderstellende dat iedereen gelijk heeft. Je zit niet in het conflict, je staat er buiten, in een meta-positie. Als de context alleen beschikbaar is in een e-mailthread — lees in ieder geval de hele thread en relevante discussies en documenten. Nadat je hebt gelezen — praat dan alsnog persoonlijk. Bijna gegarandeerd hoor je iets belangrijks dat niet in de e-mail staat.
Een derde belangrijk punt is de algemene aanpak van communicatie. Dit zijn gewone dingen, niets buitenaards, maar ze zijn van groot belang. Probeer geen tijd te besparen, praat met alle betrokkenen, bekritiseer niet de persoon, maar beschouw de gevolgen van zijn daden (niet “jij bent grof”, maar “misschien kunnen de jongens zich beledigd voelen door deze zaak”), geef de mogelijkheid om gezichtsverlies te voorkomen, voer discussies persoonlijk en niet voor een groep.
Conflicten ontstaan meestal door een van de twee redenen. De eerste heeft betrekking op de vraag of iemand zich op dat moment in de positie van een volwassene of een kind bevindt (hierover later meer). Dit heeft te maken met zijn emotionele rijpheid, het vermogen om zijn emoties te beheersen (wat overigens niet altijd gerelateerd is aan zijn leeftijd). De tweede veelvoorkomende reden is de onvolkomenheid van het werkproces, die situaties van grijze gebieden creëert, waarin de verantwoordelijkheid verdeeld is tussen de deelnemers, en de verwachtingen van de partijen niet transparant voor elkaar zijn, waarbij de rollen in het proces vervaagd zijn.
In de oplossing van conflicten (en andere vraagstukken) moet de manager rekening houden met drie perspectieven: het kortetermijnperspectief — het probleem/conflict hier en nu oplossen, het middellangetermijnperspectief — de kans op een soortgelijk conflict in de toekomst minimaliseren, en het langetermijnperspectief — het cultiveren van een volwassen cultuur binnen het team.
In ieder van ons leeft een innerlijk kind van ongeveer drie of vier jaar oud. Het grootste deel van de tijd slaapt dit kind op het werk, maar soms wordt het wakker en neemt het de controle over. Het kind heeft zijn eigen prioriteiten. Het is belangrijk voor hem om aan te dringen op het feit dat dit zijn zandbak is, dat mama hem meer houdt dan anderen, dat zijn autootje het mooiste is (het ontwerp is het beste, hij programmeert het beste, …). In een conflictsituatie kan het kind zijn speelgoed klemmen, met zijn voeten stampen en met een schepje slaan, maar het kan geen volwassen kwesties oplossen (de architectuur van de oplossing, benaderingen voor geautomatiseerd testen, deadlines, enz.), en denkt niet in termen van nut voor het team. Het kind in een conflict kan aangemoedigd, getroost en weer naar bed gestuurd worden, als je het vraagt om zijn volwassen ik te roepen. Voordat je begint met bespreken in een conflictsituatie, zorg ervoor dat je op dat moment met de volwassene praat en niet met het kind, en dat je zelf de volwassen rol aanneemt. Als jouw eerlijke doel op dit moment is om een serieus probleem op te lossen, ben je in de rol van een volwassene. Als jouw doel is om met je voeten te stampen en met een schepje te slaan, is dat de kinderlijke positie. Stuur je innerlijke kind naar bed en laat de volwassene komen, of stel het gesprek uit. Een persoon neemt een emotionele beslissing en zoekt daarna een rationele rechtvaardiging. Een beslissing die door het kind is genomen, op basis van kinderlijke prioriteiten, zal niet optimaal zijn.
Naast het gedrag tijdens een conflict, wordt de positie van een kind of volwassene ook gekarakteriseerd door het niveau van verantwoordelijkheid dat iemand bereid is te nemen. In extreme gevallen ziet de kinderlijke positie van een programmeur, die ik herhaaldelijk ben tegengekomen, er als volgt uit: ik heb code geschreven en deze ter review aangeboden — mijn werk is klaar. De reviewers moeten deze bekijken en samenvoegen, QA moet deze controleren, als er problemen zijn — zullen ze me dit laten weten. Vreemd genoeg gedragen zelfs behoorlijk volwassen en ervaren mensen zich soms op deze manier. Aan de andere kant van het spectrum beschouwt een persoon zich verantwoordelijk voor het functioneren van zijn code, ervoor zorgen dat deze gedekt is door tests, persoonlijk gecontroleerd is, met succes de review heeft doorstaan (indien nodig, geen probleem om de reviewers te pingelen, vragen mondeling te bespreken, enz.) en is samengevoegd, met assistentie van QA indien nodig, testscenario's beschreven, enz. In normale gevallen bevindt een programmeur zich in eerste instantie dichter bij de volwassen kant van het spectrum, of verschuift daar naarmate hij meer ervaring opdoet (mits de juiste cultuur in het team wordt gecultiveerd). In extreme gevallen blijft hij echter doorgaand werken vanuit de kinderpositie en ontstaan er regelmatig problemen en conflicten voor hem en het team.
Het ontwikkelen van een juiste, volwassen cultuur binnen het team is een belangrijke taak voor elke manager. Het vereist langdurige inspanning en dagelijkse toewijding, maar het resultaat is het waard. Er zijn twee manieren om de cultuur van het team te beïnvloeden — door persoonlijk voorbeeld (waarom het team altijd naar de leider kijkt) en door het bespreken en aanmoedigen van juist gedrag. Ook hier is niets ingewikkelds of heel formeels aan, gewoon tijdens het bespreken van problemen opmerken wat anders had kunnen worden gedaan, benadrukken dat je hebt gezien wanneer het goed is opgelost, lof geven, dit markeren tijdens de release-analyse, enz.
Laten we enkele typische conflict situaties bekijken, van eenvoudig naar complex:
Conflicten die niet verband houden met werkgerelateerde kwesties
Vaker wel dan niet ontstaan er op het werk conflicten die niet verband houden met werkgerelateerde kwesties. Hun ontstaan en de gemakkelijkheid van oplossing zijn meestal rechtstreeks gerelateerd aan het niveau van emotionele intelligentie van de deelnemers, hun volwassenheid en zijn niet gerelateerd aan de perfectie of imperfectie van het werkproces.
Typische voorbeelden zijn dat iemand de wasmachine of de douche niet vaak genoeg gebruikt, wat anderen stoort, iemand het te warm heeft terwijl een ander het liefst de ramen opent, iemand te veel lawaai maakt en anderen stilte nodig hebben om te werken, enzovoort. Voor het oplossen van dergelijke conflicten is het beter om niet te lang te wachten en de zaken niet vanzelf te laten lopen. Ze lossen zich niet vanzelf op en zullen dagelijks afleiden van het werk en de sfeer in het team vergiftigen. Gelukkig zijn ze meestal niet zeer problematisch op te lossen — het is voldoende om rustig te praten (uiteraard één op één) met een collega die de hygiëne negeert, ervoor te zorgen dat mensen die stilte of koelte prefereren comfortabel kunnen zitten, geluidsabsorberende koptelefoons aan te schaffen of wanden te plaatsen, enzovoort.
Een ander voorbeeld dat ik tijdens mijn werk verschillende keren ben tegengekomen, is de psychologische incompatibiliteit van teamleden. Om de een of andere reden kunnen mensen gewoon niet samen werken, elke communicatie eindigt in een ruzie. Soms komt dit doordat mensen extreem verschillende opvattingen hebben over een prangend probleem (meestal politiek) en niet in staat zijn om deze buiten het werk te laten. Proberen hen te overtuigen elkaar te tolereren of hun gedrag te veranderen is vrij nutteloos. De enige uitzondering die ik heb gezien, zijn jonge collega's met een open houding, wiens gedrag nog kan worden aangepast door middel van periodieke gesprekken. Gewoonlijk wordt het probleem succesvol opgelost door hen in verschillende teams te plaatsen, of op zijn minst ervoor te zorgen dat ze uiterst zelden met elkaar hoeven samen te werken.
In alle genoemde situaties moet er persoonlijk met alle betrokkenen gesproken worden, de situatie besproken worden, gevraagd worden of zij überhaupt een probleem zien in dit geval, en gevraagd worden welke oplossingen zij denken te hebben, en ervoor gezorgd worden dat ze deelnemen aan het besluitvormingsproces.
Vanuit het oogpunt van procesoptimalisatie (de middellange termijn die ik noemde), is er hier niet veel te doen. Het enige aspect dat geoptimaliseerd kan worden, is rekening houden met het compatibiliteitsfactor bij het samenstellen van teams en van tevoren geen mensen bij elkaar plaatsen die zullen conflicteren.
Vanuit het perspectief van teamcultuur komen dergelijke situaties veel minder voor in teams met een volwassen cultuur, waar mensen respect hebben voor elkaar en in staat zijn om problemen zelfstandig op te lossen. Bovendien worden dergelijke conflicten veel makkelijker opgelost (vaak automatisch) in teams waar het niveau van vertrouwen hoog is, mensen lange tijd samen werken en/of vaak buiten werktijd communiceren.
Conflicten gerelateerd aan werkkwesties:
Dergelijke conflicten worden meestal door beide oorzaken tegelijkertijd veroorzaakt, zowel emotioneel (wanneer een van de deelnemers niet in een volwassen positie is) als door onvolkomenheden in het werkproces zelf. De misschien wel meest voorkomende soort conflicten die ik tegenkom, zijn conflicten tijdens code reviews of architectuurdiscussies tussen ontwikkelaars.
Ik zou hier twee typische gevallen willen onderscheiden:
1) In het eerste geval kan een ontwikkelaar geen code review van een collega krijgen. De patch is ter review verzonden, maar er gebeurt niets. Op het eerste gezicht is er geen duidelijk conflict tussen de twee partijen, maar als je er goed over nadenkt, is het een conflict. Het werkprobleem wordt niet opgelost, en een van de partijen (die de review verwacht) ervaart duidelijk ongemak. Een extreme variant van dit caso is ontwikkelen binnen een community of in verschillende teams, waarbij de reviewer misschien geen belangstelling heeft voor deze specifieke code. Vanwege drukte of andere omstandigheden kan hij of zij helemaal niet op de reviewverzoek letten, en er is misschien helemaal geen externe arbiter (een gemeenschappelijke manager voor beide partijen).
De aanpak van een oplossing die helpt in deze situatie, heeft betrekking op een langetermijnperspectief en de cultuur van een volwassene. Ten eerste is er een verstandige activiteit. Verwacht niet dat de code die in review staat vanzelf de aandacht van de reviewer trekt. Je moet de reviewers helpen om het op te merken. Ping een paar mensen, stel een vraag op Slack, neem deel aan discussies. Het is duidelijk dat opdringerigheid eerder schaadt dan helpt, dus gebruik gezond verstand. Ten tweede, goede voorbereiding werkt goed. Als het team begrijpt wat er gebeurt en waarom, waarom deze code überhaupt nodig is, en als het ontwerp van tevoren met iedereen is besproken en goedgekeurd, zullen mensen eerder op zulke code letten en deze in behandeling nemen. Ten derde, autoriteit werkt. Als je wilt dat je code wordt gereviewd, review dan zelf veel code. Doe kwalitatieve reviews met echte controles, echte tests, en nuttige opmerkingen. Als je naam binnen het team positief bekend is, is de kans groter dat je code aandacht krijgt.
Wat betreft het werkproces, mogelijke verbeteringen hier zijn de juiste prioriteiten stellen, gericht op het helpen van de ontwikkelaar om zijn doelen en die van het team te bereiken (andere reviews doen, berichten schrijven in de community, code begeleiden met architectuurbeschrijvingen, documentatie, tests, deelnemen aan discussies met de community, enz.), ervoor zorgen dat patches niet te lang in de wachtrij blijven hangen, enzovoort.
2) Een tweede veelvoorkomende situatie van conflicten tijdens de code- of ontwerpreview zijn verschillende opvattingen over technische kwesties, codeerstijlen en de keuze van hulpmiddelen. Het niveau van vertrouwen tussen de deelnemers, de verbondenheid met hetzelfde team, en de ervaring van samenwerking zijn hierbij van groot belang. Het probleem ontstaat wanneer een van de deelnemers een kinderachtige houding aanneemt en niet probeert te begrijpen wat de gesprekspartner probeert over te brengen. Vaak kunnen zowel de benadering die door de andere kant is voorgesteld als de oorspronkelijk voorgestelde benadering doeltreffend zijn en maakt het principieel geen verschil welke wordt gekozen.
Op een dag had een programmeur uit mijn team (laten we hem Pasha noemen) een patch voorbereid met veranderingen in het systeem voor het uitrollen van pakketten, dat was ontwikkeld en onderhouden door collega’s uit een andere afdeling. Een van hen (Igor) had een sterke mening over hoe de Linux-services ingesteld moesten worden bij het uitrollen van pakketten. Dit verschilde van de aanpak die in de patch werd voorgesteld, en ze konden niet tot een overeenstemming komen. Zoals gebruikelijk was de deadline dichtbij, en we moesten tot een oplossing komen; iemand moest volwassen overkomen. Pasha erkende dat beide benaderingen hun recht op bestaan hadden, maar hij wilde dat zijn optie werd gekozen, omdat er eigenlijk geen duidelijke technische voordelen waren voor beide opties.
Ons gesprek zag er ongeveer zo uit (uiterst schematisch overigens, het gesprek duurde een half uur):
— Pasha, we hebben over een paar dagen feature freeze. Het is belangrijk dat we alles samenvoegen en zo snel mogelijk met testen beginnen. Hoe kunnen we Igor omzeilen?
— Hij wil de services op een andere manier instellen, heeft me een heleboel opmerkingen gegeven...
— En wat is er aan de hand? Moeten er grote veranderingen worden aangebracht, veel gedoe?
— Nee, er is maar een paar uur werk, maar uiteindelijk maakt het geen verschil; het werkt op beide manieren, waarom is het nodig? Ik heb iets werkends gemaakt, laten we dat gewoon accepteren.
— Zeg, hoe lang bespreken jullie dit al?
— Al ongeveer anderhalve week.
— Hmm... kunnen we een probleem dat al anderhalve week duurt in een paar uur oplossen, en doen we dat niet?
— Nou ja, dat klopt, maar ik wil niet dat Igor denkt dat ik toegeef...
— Zeg, wat is voor jou belangrijker: de release uitbrengen, samen met jouw oplossing erin, of Igor overwinnen? We kunnen hem overwinnen, maar dan is er wel een goede kans dat we de release mislopen.
— Nou... het zou natuurlijk leuk zijn om Igor een les te leren, maar goed, de release is belangrijker, ik ga akkoord.
— Is het echt zo belangrijk voor je wat Igor denkt? Eerlijk gezegd, het maakt hem weinig uit; hij wil gewoon een uniforme aanpak op verschillende plekken van dat ding waarvoor hij verantwoordelijk is.
— Oké, laten we het zo doen als hij vraagt in de opmerkingen, en beginnen met testen.
— Dank je, Pasha! Ik was er zeker van dat jij degene van jullie twee zou zijn die volwassener zou zijn, hoewel Igor ouder is dan jij :)
Het probleem is opgelost, de release is op tijd uitgebracht, Pasha had geen bijzondere onvrede, omdat hij zelf de oplossing heeft voorgesteld en deze heeft geïmplementeerd. Igor was over het algemeen tevreden, omdat zijn mening is gehoord en het zo is gedaan als hij had voorgesteld.
Een andere vorm van hetzelfde type conflict is de keuze tussen technische oplossingen/bibliotheken/benaderingen in een project, vooral in een gedistribueerd team. In een van de projecten, dat werd gepositioneerd als zijnde gebruikmakend van C/C++, bleek uiteindelijk dat het technische management van het project categorisch tegen het gebruik van STL (Standard Template Library) was. Dit is de standaardbibliotheek van de taal, die de ontwikkeling vereenvoudigt; ons team was er erg aan gewend. Het bleek dat het project veel dichter bij C was dan bij C++, wat het team niet echt inspireerde, aangezien het management geprobeerd had en echt geweldige C++-ontwikkelaars had aangetrokken. Tegelijkertijd werkte het Amerikaanse deel van het team, zowel ingenieurs als managers, al lange tijd bij het bedrijf en was gewend aan de bestaande situatie; zij waren er tevreden mee. Het Russische deel van het team was daarentegen pas zeer recent, binnen enkele weken, (inclusief ikzelf) bijeengebracht. Het Russische deel van het team was absoluut niet bereid om afstand te doen van de gebruikelijke ontwikkelingsaanpak.
Onbeperkte schriftelijke discussies begonnen tussen twee continenten, brieven van drie tot vier schermen vlogen heen en weer, zowel in groepsberichten als persoonlijk van programmeurs – naar programmeurs en managers. Zoals meestal het geval is, las niemand behalve de auteurs en hun vurige supporters brieven van deze omvang. De chats kraakten van de spanning, terwijl er veelschermige overpeinzingen over de technische voordelen van STL werden uitgewisseld, hoe goed deze is getest, veilig is, en hoe geweldig het leven met haar is, en hoe vreselijk zonder.
Dit heeft vrij lang geduurd, totdat ik eindelijk besefte dat we de technische aspecten van de kwestie bespraken, terwijl het probleem in werkelijkheid niet technisch was. Het probleem ligt niet in de voor- of nadelen van STL of de complexiteit van het werken zonder. Het is eerder organisatorisch van aard. We moesten gewoon begrijpen hoe het bedrijf waar we werkten was georganiseerd. Tot dat moment had niemand van ons ervaring in zo'n bedrijf. Het punt was dat na het ontwikkelen van de code en het uitbrengen ervan in productie, de ondersteuning volledig door andere mensen uit andere teams en andere landen werd gedaan. Dit enorme engineeringteam van enkele tienduizenden ingenieurs kon zich slechts de meest basale technische middelen veroorloven, zeg maar het minimum minimorum. Alles wat buiten de engineeringnorm viel die in het bedrijf was vastgesteld, kon fysiek niet verder worden ondersteund. Het niveau van het team wordt bepaald door het niveau van de zwakste leden. Nadat we dat begrepen hadden, de echte motivatie van de acties van het Amerikaanse deel van het team, werd deze kwestie van de agenda gehaald en hebben we gezamenlijk met succes een product ontwikkeld en uitgebracht, gebruikmakend van de standaarden die in het bedrijf zijn aangenomen. E-mails en chats werkten in dit geval slecht; om tot een gemeenschappelijke afstemming te komen, waren er verschillende reizen en veel persoonlijke interactie nodig.
Vanuit het perspectief van het werkproces zou in dit specifieke geval een beschrijving van de gebruikte middelen, de vereisten eraan, de beperkingen voor het toevoegen van nieuwe middelen en de rechtvaardiging voor dergelijke beperkingen nuttig zijn geweest. Zulke documenten komen in grote lijnen overeen met die beschreven in de secties Reuse Strategy en Development Environment van de handleiding 'Manager's Handbook for Software Development', ontwikkeld in . Ondanks zijn leeftijd beschrijft het prachtig alle belangrijke activiteiten en fasen van de planning van softwareontwikkeling van dit soort. Het hebben van dergelijke documenten vereenvoudigt het proces van het bespreken van welke componenten en benaderingen in het product kunnen worden gebruikt en waarom.
Vanuit cultureel perspectief zou het, met een volwassener houding waarbij partijen proberen te luisteren en de echte motivatie van de acties van collega's te begrijpen en handelen op basis van de prioriteiten van het project en het team, en niet op persoonlijke ego's, het conflict makkelijker en sneller zijn opgelost.
In een ander conflict over de keuze van de technische oplossing had ik ook aanzienlijk veel tijd nodig om de motivatie van een van de partijen te begrijpen (het was een zeer ongebruikelijke situatie), maar nadat de motivatie duidelijk was, was de oplossing voor de hand liggend.
De situatie is als volgt: in een team van ongeveer 20 mensen komt er een nieuwe ontwikkelaar, laten we hem Stas noemen. Ons standaard communicatiemiddel in het team was in dat moment Skype. Later bleek dat Stas een grote fan was van open standaarden en open source software, en alleen werkte met tools en besturingssystemen waarvan de source code publiek beschikbaar was, en die gebruik maakten van publiek beschreven protocollen. Skype valt niet onder zulke tools. We hebben enorm veel tijd besteed aan discussies over de voors en tegens van deze aanpak, pogingen om alternatieven voor Skype op verschillende besturingssystemen te draaien, Stas' pogingen om het team te overtuigen over te stappen op andere standaarden, hem persoonlijk per e-mail te benaderen, hem persoonlijk te bellen, hem een tweede computer speciaal voor Skype te kopen, enzovoorts. Uiteindelijk begreep ik dat dit probleem in wezen niet technisch of organisatorisch was, het was eerder wereldbeschouwelijk, zelfs, kan je zeggen, religieus (voor Stas). Zelfs als we Stas uiteindelijk met Skype hadden verbonden (waarvoor al enkele maanden waren besteed), zou het probleem zich bij elk volgend hulpmiddel opnieuw voordoen. Ik had geen reële middelen om de wereldbeschouwing van Stas te veranderen, en er was geen reden om te proberen de wereldbeschouwing van het team te veranderen, dat uitstekend functioneerde in deze omgeving. De persoon en het bedrijf waren simpelweg orthogonaal qua wereldbeschouwing. In dergelijke situaties is een organisatorische oplossing vaak een goede optie. We hebben Stas naar een ander team overgeplaatst, waar hij beter paste.
De reden voor dit conflict ligt, in mijn ogen, in de discrepantie tussen de persoonlijke cultuur van een specifiek individu (die een sterke mening heeft die hem niet in staat stelt compromissen te sluiten) en de cultuur van het bedrijf. In dit geval is het natuurlijk de fout van de manager. Het was aanvankelijk verkeerd om hem aan een project van deze aard toe te wijzen. Stas is uiteindelijk overgestapt naar een project voor de ontwikkeling van open source software en heeft het daar uitstekend gedaan.
Een goed voorbeeld van een conflict dat is ontstaan door de combinatie van de kinderachtige houding van de ontwikkelaar en tekortkomingen in het werkproces - een situatie waarin de ontwikkelaar en het QA-team verschillende verwachtingen hebben over de gereedheid van een feature die aan QA is overgedragen, zonder een definition of done. De ontwikkelaar dacht dat het voldoende was om de code te schrijven en de feature over de schutting naar QA te gooien - daar zouden ze het wel uitzoeken. Het was trouwens een vrij volwassen en ervaren programmeur, maar dat was zijn interne kwaliteitsdrempel. QA was het hier niet mee eens en eiste dat hij hen liet zien en beschrijven wat hij zelf had gecontroleerd en vroeg om een testscenario voor hen. Ze hadden in het verleden al problemen ondervonden met de functionaliteit van deze ontwikkelaar en wilden hun tijd niet nogmaals verdoen. Overigens hadden ze gelijk - de feature werkte inderdaad niet, hij had de code niet gecontroleerd voordat hij deze aan QA overdroeg.
Om de situatie op te lossen vroeg ik hem me te laten zien dat alles daadwerkelijk werkte (het werkte niet, en hij moest het repareren), we bespraken de definitie van done met het team en met QA (we maakten het niet schriftelijk omdat we het proces niet te bureaucratisch wilden maken), en met deze specialist namen we al snel afscheid (tot ieders opluchting).
Wat betreft het werkproces zijn mogelijke verbeteringen in dit geval - het hebben van een definitie van done, de eis om elke feature te ondersteunen met unit- en integratietests, en het documenteren van de tests die door de ontwikkelaar zijn uitgevoerd. In een van de projecten maten we de code dekking bij tests tijdens CI, en als het dekkingspercentage na het toevoegen van een patch daalde, werden de tests gemarkeerd als niet geslaagd, dat wil zeggen dat nieuwe code alleen kon worden toegevoegd als er nieuwe tests voor waren.
Weer een typisch voorbeeld van een conflict dat nauw samenhangt met de organisatie van het werkproces. We hebben een product, een ontwikkelingsteam voor dit product, een supportteam en de klant. De klant ondervindt problemen met het product en wendt zich tot de support. De support analyseert het probleem en begrijpt dat het probleem bij het product ligt, waarna het probleem wordt doorgegeven aan het productteam. Het productteam heeft het druk, de release komt eraan, dus het ticket met het probleem van de klant, dat verloren is geraakt tussen de andere tickets bij de ontwikkelaar, blijft enkele weken onbeantwoord. De support denkt dat de ontwikkelaar bezig is met het probleem van de klant. De klant wacht en hoopt dat er aan zijn probleem wordt gewerkt. In werkelijkheid gebeurt er nog niets. Na enkele weken besluit de klant eindelijk om naar de voortgang te vragen en vraagt hij de support hoe het ervoor staat. De support vraagt de ontwikkeling. De ontwikkelaar schrikt, bekijkt de lijst met tickets en ontdekt daar het ticket van de klant. Terwijl hij het ticket leest, realiseert hij zich dat er onvoldoende informatie is om het probleem op te lossen en dat hij meer logs en dumps nodig heeft. De support vraagt de klant om aanvullende informatie. En dan realiseert de klant zich dat er al die tijd niemand aan zijn probleem heeft gewerkt. En de donder zal slaan...
In deze situatie is de oplossing van het conflict vrij duidelijk en rechtlijnig (het product repareren, de documentatie en tests bijwerken, de klant geruststellen, een hotfix uitbrengen, enz.). Het is belangrijk om het werkproces te analyseren en te begrijpen wie verantwoordelijk is voor het organiseren van de interactie tussen de twee teams, en waarom deze situatie überhaupt mogelijk was. Het is duidelijk dat er iets moet worden verbeterd in het proces - iemand moet het geheel proactief monitoren zonder herinneringen van klanten. Tickets van klanten moeten opvallen tussen de andere tickets bij de ontwikkelaars. De support moet kunnen zien of de ontwikkeling momenteel aan hun tickets werkt, en zo niet - wanneer ze kunnen beginnen, en wanneer resultaten verwacht kunnen worden. Support en ontwikkeling moeten regelmatig communiceren en de status van tickets bespreken, de verzameling van benodigde informatie voor probleemoplossing moet maximaal geautomatiseerd zijn, enz.
Net als in oorlogen, waar de tegenstander probeert toe te slaan tussen twee eenheden, is de meest kwetsbare plek in de samenwerking vaak de interactie tussen teams. Als de managers van ondersteuning en ontwikkeling voldoende volwassen zijn, kunnen ze het proces zelf verhelpen; als dat niet het geval is, blijft het proces conflicten en problemen genereren, totdat een manager ingrijpt die de situatie kan herstellen.
Een ander kenmerkend voorbeeld dat ik herhaaldelijk in verschillende bedrijven ben tegengekomen, is de situatie waarin een product door het ene team wordt geschreven, automatische integratietests door een tweede team worden uitgevoerd, en de infrastructuur waarop dit alles draait wordt beheerd door een derde team. Problemen bij het uitvoeren van de tests komen voortdurend voor, en de oorzaak kan zowel het product, de tests als de infrastructuur zijn. Het is meestal problematisch om overeenstemming te bereiken over wie de eerste analyse van de problemen moet uitvoeren, bugs moet indienen, de logs van het product, de tests en de infrastructuur moet parseren, enzovoorts. Conflicten zijn hier heel gebruikelijk, en tegelijkertijd ook voorspelbaar. In het geval van hoge emotionele spanning vallen de deelnemers vaak terug in een kinderlijke positie en beginnen discussies zoals: 'waarom moet ik hiermee bezig zijn', 'zij hebben vaker problemen', enzovoorts.
Vanuit het perspectief van het werkproces hangen de specifieke stappen voor het oplossen van het probleem af van de samenstelling van de teams, het type tests en het product, enzovoort. In een van de projecten hebben we periodieke diensten ingevoerd, waarbij de teams om de beurt, wekelijks, zorgden voor de tests. In een ander project voerden de ontwikkelaars van de tests altijd de eerste analyse uit, maar die analyse was vrij basaal en het product was voldoende stabiel, dus dat werkte redelijk goed. Het belangrijkste is om transparantie in het proces te waarborgen, duidelijkheid in de verwachtingen voor alle partijen en een gevoel van rechtvaardigheid in de situatie voor iedereen.
Is conflict within an organization really a problem, or is it a bad sign that your team frequently (or just occasionally) faces conflicts? Generally, no, as conflicts can arise alongside growth, development, and dynamics when new questions emerge that have never been addressed before. This can indicate areas that need attention and opportunities for improvement. However, it is concerning if conflicts arise very frequently and are difficult or prolonged to resolve. This is likely a sign of inadequately established work processes and a lack of team maturity.
Bron: habr.com
