opschrift:
Er was eens een egel en een kleine beer die elkaar ontmoetten in het bos.
- Hallo, Egel!
- Hallo, kleine beer!
Dus, woord voor woord, grap voor grap, werd de Egel in zijn gezicht geslagen door de Kleine Beer...
Hieronder vindt u een gesprek van onze teamleider en Igor Marnat, directeur productontwikkeling van RAS, over de specifieke kenmerken van werkconflicten en mogelijke methoden om deze te beheren.
De meeste conflicten die we op het werk tegenkomen, ontwikkelen zich volgens een scenario dat vergelijkbaar is met het scenario hierboven. Er zijn verschillende deelnemers die aanvankelijk heel gunstig tegenover elkaar staan; ze proberen een probleem op te lossen, maar uiteindelijk blijft het probleem onopgelost en om de een of andere reden blijken de relaties tussen de deelnemers aan de discussie verstoord te zijn.
Het leven is divers en er doen zich variaties voor in het hierboven beschreven scenario. Soms is de relatie tussen de deelnemers aanvankelijk niet zo goed, soms is er niet eens een probleem dat een directe oplossing vereist (zoals bijvoorbeeld in het motto), soms blijft de relatie na de discussie hetzelfde als voordat deze begon, maar het probleem is uiteindelijk niet opgelost.
Wat is gebruikelijk in alle situaties die kunnen worden gedefinieerd als een situatie van werkconflict?
Ten eerste zijn er twee of meer kanten. Deze partijen kunnen verschillende plaatsen in de organisatie innemen, zich in een gelijkwaardige relatie bevinden (collega's in een team), of op verschillende niveaus van de hiërarchie (baas - ondergeschikt), individueel (werknemer) of groep zijn (in geval van conflict tussen een werknemer en een team of twee teams), enzovoort. De waarschijnlijkheid van conflicten en het gemak van de oplossing ervan worden sterk beïnvloed door de mate van vertrouwen tussen de deelnemers. Hoe beter de partijen elkaar kennen, hoe hoger het vertrouwen, hoe groter de kans dat zij tot overeenstemming komen. Leden van een gedistribueerd team die nog nooit face-to-face interactie hebben gehad, hebben bijvoorbeeld een grotere kans om conflicten te ervaren over een eenvoudig werkprobleem dan mensen die op zijn minst een paar face-to-face interacties hebben gehad. Daarom is het bij het werken in gedistribueerde teams erg belangrijk om ervoor te zorgen dat alle teamleden elkaar periodiek persoonlijk ontmoeten.
Ten tweede bevinden de partijen zich in een conflictsituatie op het werk in een situatie waarin ze een kwestie moeten oplossen die belangrijk is voor een van de partijen, voor hen beiden, of voor de organisatie als geheel. Tegelijkertijd hebben de partijen, vanwege de specifieke kenmerken van de situatie, meestal voldoende tijd en verschillende manieren om deze op te lossen (formeel, informeel, vergaderingen, brieven, managementbeslissingen, de aanwezigheid van doelen en plannen van het team, de feit van een hiërarchie, enz.). Dit verschilt van de situatie waarbij een werk- (of niet-werk) kwestie in een organisatie wordt opgelost of bijvoorbeeld een belangrijke vraag wordt opgelost: "Eh, jongen, uit welke regio kom jij?!" op straat, of het conflict uit het motto. Bij het oplossen van een werkprobleem zijn de kwaliteit van het werkproces en de cultuur van het oplossen van problemen in het team van belang.
Ten derde is de bepalende factor van het conflict (vanuit het perspectief van onze discussie) het feit dat de partijen in het proces niet zelfstandig tot een oplossing voor het vraagstuk kunnen komen die voor alle partijen geschikt is. De situatie vereist de tussenkomst van een derde partij, een externe scheidsrechter. Dit punt lijkt misschien controversieel, maar als de conflictsituatie met succes is opgelost zonder tussenkomst van een externe scheidsrechter, de kwestie met succes is opgelost en de betrekkingen tussen de partijen niet zijn verslechterd, is dit de situatie waarnaar we moeten streven. . Hoogstwaarschijnlijk zullen we niet eens op de hoogte zijn van een dergelijk conflict, of we zullen er bij toeval achter komen nadat het is opgelost. Hoe meer problemen een team zelf kan oplossen, hoe effectiever het zal zijn.
Een ander kenmerkend kenmerk van het conflict dat de moeite waard is om te bespreken, is de mate van emotionele intensiteit tijdens de beslissing. Conflicten gaan niet noodzakelijkerwijs gepaard met een hoog emotioneel niveau. Deelnemers hoeven niet te schreeuwen en met hun armen te zwaaien om de situatie in wezen een conflict te laten zijn. Het probleem is niet opgelost, er is een zekere emotionele spanning aanwezig (misschien wordt deze niet duidelijk naar buiten uitgedrukt), wat betekent dat we met een conflictsituatie worden geconfronteerd.
Is het überhaupt nodig om in conflictsituaties in te grijpen, of is het beter om de oplossing ervan op zijn beloop te laten en te wachten tot het probleem zichzelf oplost? Nodig hebben. Het ligt niet altijd in uw macht of competentie om het conflict volledig op te lossen, maar in elke situatie, in een conflict van welke omvang dan ook, kunt u een volwassen standpunt innemen, waardoor u nog meer mensen om u heen erbij kunt betrekken, en de negatieve gevolgen van de gevolgen kunt verzachten. conflicten en bijdragen aan de oplossing ervan.
Voordat we naar enkele voorbeelden van conflictsituaties kijken, kijken we eerst naar een paar belangrijke punten die alle conflicten gemeen hebben.
Bij het oplossen van een conflict is het belangrijk om boven de strijd te staan, en niet erbinnen (dit wordt ook wel ‘een metapositie innemen’ genoemd), dat wil zeggen dat je geen deel uitmaakt van een van de partijen in het oplossingsproces. Anders zal het inschakelen van een externe scheidsrechter bij de beslissing de positie van een van de partijen alleen maar versterken, ten nadele van de andere partij. Bij het nemen van een beslissing is het belangrijk dat deze door alle partijen moreel wordt geaccepteerd, zoals ze zeggen: ‘gekocht’. Zodat, ook al waren de partijen niet blij met de genomen beslissing, ze in ieder geval oprecht overeenkwamen om deze uit te voeren. Zoals ze zeggen, om het oneens te kunnen zijn en je te kunnen engageren. Anders zal het conflict eenvoudigweg van uiterlijk veranderen, zal het smeulende vuur onder het veen blijven en op een gegeven moment onvermijdelijk weer oplaaien.
Het tweede punt, gedeeltelijk gerelateerd aan het eerste, is dat als je al hebt besloten deel te nemen aan het oplossen van het conflict, dit zo serieus mogelijk moet nemen vanuit het oogpunt van communicatie en het bestuderen van de context. Praat persoonlijk met elk van de partijen. Om te beginnen bij elk afzonderlijk. Neem geen genoegen met post. In het geval van een gedistribueerd team, praat in ieder geval via een videoverbinding. Wees niet tevreden met geruchten en ooggetuigenverslagen. Begrijp het verhaal, wat elke partij wil, waarom ze het willen, wat ze verwachten, hebben ze eerder geprobeerd dit probleem op te lossen, wat zal er gebeuren als het niet wordt opgelost, welke oplossingen zien ze, hoe stellen ze zich de positie van de andere kant, wat vinden zij, goed of fout, etc. Laad alle mogelijke contexten in je hoofd, met een open geest, ervan uitgaande dat iedereen gelijk heeft. Je bevindt je niet binnen het conflict, je bevindt je erbuiten, in een metapositie. Als de context alleen beschikbaar is in een berichtthread, lees deze dan in zijn geheel en de daaraan gerelateerde threads en documenten. Nadat u het hebt gelezen, spreekt u nog steeds met uw stem. Je hoort bijna gegarandeerd iets belangrijks dat niet in de post zit.
Het derde belangrijke punt is de algemene benadering van communicatie. Dit zijn gewone dingen, niets kosmisch, maar ze zijn erg belangrijk. We proberen geen tijd te besparen, we praten met alle deelnemers, we bekritiseren de persoon niet, maar we houden rekening met de gevolgen van zijn daden (niet 'je bent onbeleefd', maar 'misschien zijn de jongens misschien beledigd door this thing”), geven we de mogelijkheid om ons gezicht te redden, we voeren persoonlijke discussies, niet voor de rij.
Conflicten worden meestal veroorzaakt door een van twee redenen. De eerste heeft te maken met de vraag of een persoon zich ten tijde van een conflict in de positie van een volwassene of in de positie van een kind bevindt (meer hierover hieronder). Dit komt door zijn emotionele volwassenheid, het vermogen om zijn emoties te beheersen (wat overigens niet altijd verband houdt met zijn leeftijd). De tweede veel voorkomende reden is de imperfectie van het werkproces, waardoor situaties van grijze gebieden ontstaan waarin de verantwoordelijkheid over de deelnemers wordt verspreid, de verwachtingen van de partijen niet transparant voor elkaar zijn en de rollen in het proces vaag zijn.
Dienovereenkomstig moet een manager bij het oplossen van een conflict (en elk ander probleem) drie perspectieven in gedachten houden: korte termijn – om het probleem/conflict hier en nu op te lossen, middellange termijn – om de kans op een nieuw conflict te minimaliseren. om dezelfde reden, en op de lange termijn, om een volwassen cultuur in de teampersoon te cultiveren.
Ieder van ons heeft een innerlijk kind, ongeveer drie of vier jaar oud. Hij slaapt het grootste deel van de tijd op het werk, maar wordt soms wakker en neemt de controle over. Het kind heeft zijn eigen prioriteiten. Het is belangrijk voor hem om vol te houden dat dit zijn zandbak is, dat zijn moeder meer van hem houdt, dat zijn machine de beste is (het ontwerp is het beste, hij programmeert het beste, ...). In een conflictsituatie kan een kind op speelgoed drukken, met zijn voeten stampen en zijn spatel kraken, maar hij kan problemen voor volwassenen niet oplossen (architectuur van oplossingen, benaderingen van geautomatiseerd testen, releasedatums, enz.). Hij denkt niet in termen van voordelen voor het team. Een kind in conflict kan worden aangemoedigd, getroost en naar bed gestuurd door hem te vragen zijn volwassene te bellen. Voordat u in een conflictsituatie een gesprek begint, moet u ervoor zorgen dat u met een volwassene praat, en niet met een kind, en dat u zich in de positie van een volwassene bevindt. Als het op dit moment uw eerlijke doel is om een ernstig probleem op te lossen, bevindt u zich in de positie van een volwassene. Als het je doel is om met je voeten te stampen en je schouderblad te kraken, is dit een kinderlijke houding. Stuur je innerlijke kind naar bed en bel een volwassene, of verplaats het gesprek. Iemand neemt een emotionele beslissing en zoekt daar vervolgens een rationele rechtvaardiging voor. Een beslissing die een kind neemt op basis van de prioriteiten van het kind zal niet optimaal zijn.
Naast het gedrag ten tijde van een conflict wordt de positie van een kind of volwassene ook gekenmerkt door de mate van verantwoordelijkheid die iemand bereid is op zich te nemen. In zijn extreme vormen ziet de kinderlijke positie van een programmeur, die ik meer dan eens heb ontmoet, er als volgt uit: ik heb de code geschreven, ter beoordeling opgestuurd - mijn werk is voltooid. Reviewers moeten het beoordelen en goedkeuren, QA moet het controleren en als er problemen zijn, laten ze het mij weten. Vreemd genoeg gedragen zelfs redelijk volwassen en ervaren mensen zich soms zo. Het andere uiteinde van de schaal is dat iemand zichzelf verantwoordelijk acht om ervoor te zorgen dat zijn code werkt, wordt getest, persoonlijk door hem is gecontroleerd, de beoordeling met succes heeft doorstaan (indien nodig is het geen probleem om reviewers te pingen, kwesties te bespreken via stem, etc.) en is onderdrukt, QA zal indien nodig assistentie verlenen, er zullen testscenario's worden beschreven, etc. In normale gevallen begint de programmeur dichter bij de volwassen kant van de schaal, of gaat hij daarheen naarmate hij meer ervaring opdoet (mits de juiste cultuur binnen het team wordt gecultiveerd). In extreme gevallen blijft hij werken, meestal neemt hij een kinderlijke houding aan, waarna hij en het team periodiek problemen en conflicten hebben.
Het bevorderen van de juiste, volwassen cultuur in een team is een belangrijke taak voor elke manager. Het kost veel tijd en dagelijkse inspanning, maar het resultaat is het waard. Er zijn twee manieren om de teamcultuur te beïnvloeden: het goede voorbeeld geven (wat zeker zal worden gevolgd; het team kijkt altijd naar de leider) en het bespreken en belonen van het juiste gedrag. Er is hier ook niets diepzinnigs of erg formeels, let alleen bij het bespreken van problemen op dat hier iets gedaan had kunnen worden, benadruk dat je het gemerkt hebt toen het correct werd besloten, complimenteer, noteer tijdens de releaserecensie, enz.
Laten we een aantal typische conflictsituaties bekijken, van eenvoudig tot complex:
Conflicten die geen verband houden met werkkwesties
Vaak zijn er conflicten op het werk die niets met werkkwesties te maken hebben. Het voorkomen ervan en het gemak waarmee ze kunnen worden opgelost, houden doorgaans rechtstreeks verband met het niveau van emotionele intelligentie van de deelnemers en hun mate van volwassenheid, en houden geen verband met de perfectie of imperfectie van het werkproces.
Typische voorbeelden: iemand gebruikt de wasmachine of douche niet vaak genoeg, wat anderen niet prettig vinden, iemand heeft het benauwd, terwijl anderen wind krijgen als ze het raam opendoen, iemand is te luidruchtig, weer anderen hebben stilte nodig om te kunnen werken, en spoedig. Het is beter om de oplossing van dit soort conflicten niet uit te stellen en ze niet op hun beloop te laten. Ze komen niet vanzelf tot een oplossing en leiden je elke dag af van je werk en vergiftigen de sfeer in het team. Gelukkig is het oplossen ervan meestal geen groot probleem - praat gewoon rustig (één-op-één natuurlijk) met een collega die de hygiëne verwaarloost, zorg voor comfortabele zitplaatsen voor mensen die de voorkeur geven aan stilte/koelte, koop een geluidsabsorberende koptelefoon of plaats scheidingswanden , enz.
Een ander voorbeeld dat ik tijdens mijn werk meerdere keren tegenkwam, is de psychologische onverenigbaarheid van teamleden. Om de een of andere reden kunnen mensen eenvoudigweg niet samenwerken; elke interactie eindigt in een schandaal. Soms is dit te wijten aan het feit dat mensen verschillende opvattingen hebben over een dringende kwestie (meestal politiek) en niet weten hoe ze deze buiten het werk moeten laten. Hen ervan overtuigen elkaar te tolereren of hun gedrag te veranderen is een nogal nutteloze taak. De enige uitzondering die ik ben tegengekomen zijn jonge collega’s met een open perceptie; hun gedrag kan nog steeds geleidelijk worden veranderd door middel van periodieke gesprekken. Meestal wordt het probleem met succes opgelost door ze in verschillende teams te verdelen, of door ze op zijn minst zeer zelden de mogelijkheid te bieden om elkaar op het werk te overlappen.
In alle bovenstaande situaties is het de moeite waard om persoonlijk met alle deelnemers te praten, de situatie te bespreken, te vragen of zij in dit geval überhaupt een probleem zien, te vragen wat naar hun mening de oplossingen zijn, en ervoor te zorgen dat hun deelname aan het maken van dit probleem wordt gewaarborgd. beslissing.
Vanuit het oogpunt van het optimaliseren van het werkproces (het middellangetermijnperspectief dat ik noemde) kan hier niet veel gedaan worden; het enige punt voor optimalisatie is om bij het vormen van een team rekening te houden met de compatibiliteitsfactor en niet om mensen vooraf samen wie er in conflict zal komen.
Vanuit teamcultuurperspectief komen dergelijke situaties veel minder vaak voor in teams met een volwassen cultuur, waar mensen het team en de collega’s respecteren en weten hoe ze zelfstandig problemen moeten oplossen. Bovendien worden dergelijke conflicten veel gemakkelijker (vaak automatisch) opgelost in teams waar het vertrouwen groot is, mensen al lang samenwerken en/of veel communiceren buiten het werk.
Conflicten gerelateerd aan werkproblemen:
Dergelijke conflicten worden meestal veroorzaakt door beide redenen tegelijk, zowel emotioneel (het feit dat een van de deelnemers niet in de positie van een volwassene verkeert) als de imperfectie van het werkproces zelf. Misschien wel het meest voorkomende type conflicten dat ik ben tegengekomen, zijn conflicten tijdens codebeoordelingen of architectuurdiscussies tussen ontwikkelaars.
Ik wil hier twee typische gevallen benadrukken:
1) In het eerste geval kan de ontwikkelaar geen codereview krijgen van een collega. De patch wordt ter beoordeling verzonden en er gebeurt niets. Op het eerste gezicht is er geen duidelijk conflict tussen de twee partijen, maar als je erover nadenkt is dit nogal een conflict. Het werkprobleem is niet opgelost, een van de partijen (wachtend op een beoordeling) ervaart duidelijk ongemak. Een extreem subtype van deze casus is ontwikkeling in een gemeenschap of in verschillende teams, terwijl de recensent mogelijk niet geïnteresseerd is in deze specifieke code vanwege belasting of andere omstandigheden, mogelijk helemaal geen aandacht schenkt aan het beoordelingsverzoek, en de externe arbiter (een manager die beide partijen gemeen hebben)) bestaat misschien helemaal niet.
De oplossingsrichting die in zo’n situatie helpt, heeft juist te maken met het langetermijnperspectief, de cultuur van een volwassene. Ten eerste werkt slimme activiteit. Je moet niet verwachten dat de code die aan de review hangt de aandacht van de reviewer zelf zal trekken. We moeten ervoor zorgen dat recensenten hem opmerken. Pingani een paar mensen, stel een vraag over syncape, neem deel aan discussies. Het is duidelijk dat importunity eerder schadelijk is dan helpt, je moet je gezond verstand gebruiken. Ten tweede werkt de voorbereiding goed. Als het team begrijpt wat er gebeurt en waarom, waarom deze code überhaupt nodig is, en het ontwerp vooraf met iedereen is besproken en overeengekomen, is de kans groter dat mensen aandacht aan dergelijke code besteden en deze voor hun werk accepteren. Ten derde werkt autoriteit. Als je beoordeeld wilt worden, doe dan zelf veel beoordelingen. Voer beoordelingen van hoge kwaliteit uit, met echte controles, echte tests en nuttige opmerkingen. Als uw bijnaam bekend is binnen het team, is de kans groter dat uw code wordt opgemerkt.
Vanuit het oogpunt van de workflow zijn mogelijke verbeteringen hier de juiste prioriteitstelling, gericht op het helpen van de ontwikkelaar om zijn doelen en die van het team te bereiken (anderen beoordelen, brieven schrijven aan de gemeenschap, de code begeleiden met een architectuurbeschrijving, documentatie, testen, deelnemen aan discussies met community, enz.), voorkomen dat patches te lang in de wachtrij blijven staan, enzovoort.
2) Het tweede veel voorkomende geval van conflicten tijdens code- of ontwerpbeoordelingen zijn verschillende opvattingen over technische kwesties, codeerstijl en keuze van tools. Van groot belang in dit geval is het niveau van vertrouwen tussen de deelnemers, die tot hetzelfde team behoren, en de ervaring met samenwerken. Er ontstaat een doodlopende weg wanneer een van de deelnemers een kinderlijke houding aanneemt en niet probeert te horen wat de gesprekspartner hem wil overbrengen. Vaak kunnen zowel de door de andere partij voorgestelde aanpak als de aanvankelijk voorgestelde aanpak succesvol werken en maakt het in principe niet uit welke te kiezen.
Op een dag bereidde een programmeur van mijn team (laten we hem Pasha noemen) een patch voor met wijzigingen in het pakketimplementatiesysteem, die werd ontwikkeld en ondersteund door collega's van een naburige afdeling. Eén van hen (Igor) had zijn eigen sterke mening over hoe Linux-services precies moeten worden geconfigureerd bij het implementeren van pakketten. Deze mening verschilde van de aanpak die in de patch werd voorgesteld, en ze waren het er niet mee eens. Zoals gewoonlijk liepen de deadlines op en was het nodig om tot een besluit te komen; het was noodzakelijk dat een van hen een volwassen positie zou innemen. Pasha erkende dat beide benaderingen recht op leven hebben, maar hij wilde dat zijn optie voorbijging, omdat Noch de ene, noch de tweede optie had duidelijke technische voordelen.
Ons gesprek zag er ongeveer zo uit (heel schematisch duurde het gesprek uiteraard een half uur):
- Pasha, over een paar dagen hebben we een functiebevriezing. Het is belangrijk dat we alles bij elkaar brengen en zo snel mogelijk beginnen met testen. Hoe komen we door Igor heen?
— Hij wil de diensten anders opzetten, hij heeft daar opmerkingen voor mij opgeplakt...
- En wat is er, grote veranderingen, veel gedoe?
- Nee, er is werk voor een paar uur, maar uiteindelijk is er geen verschil, het werkt hoe dan ook, waarom is dit nodig? Ik heb iets gemaakt dat werkt, laten we het accepteren.
- Luister, hoe lang heb je dit allemaal besproken?
- Ja, we zijn al anderhalve week aan het nadenken.
- Eh... kunnen we een probleem in een paar uur oplossen dat al anderhalve week heeft geduurd, en het niet doen?
- Nou ja, maar ik wil niet dat Igor denkt dat ik heb toegegeven...
- Luister, wat is belangrijker voor jou, vrijlating, samen met je interne beslissing, of Igor vermoorden? We kunnen het blokkeren, maar dan is er een goede kans om door te vliegen met de release.
- Nou... het zou natuurlijk cool zijn om Igors neus af te vegen, maar oké, de vrijlating is belangrijker, daar ben ik het mee eens.
- Vind je het echt zo belangrijk wat Igor denkt? Eerlijk gezegd kan het hem helemaal niets schelen, hij wil gewoon een uniforme aanpak op verschillende plaatsen van de zaak waarvoor hij verantwoordelijk is.
- Nou, oké, laat me doen wat hij vraagt in de reacties en laten we beginnen met testen.
- Bedankt, Pasha! Ik was er zeker van dat jullie twee de volwassener zouden zijn, ook al is Igorek ouder dan jij :)
Het probleem was opgelost, de release werd op tijd uitgebracht, Pasha voelde niet veel ontevredenheid, omdat hij stelde zelf een oplossing voor en voerde deze uit. Igor was over het algemeen tevreden, omdat... Er werd rekening gehouden met zijn mening en ze deden wat hij voorstelde.
Een ander type van in wezen hetzelfde conflict is de keuze tussen technische oplossingen/bibliotheken/benaderingen in een project, vooral in een gedistribueerd team. In een van de projecten, die gepositioneerd was als C/C++, bleek dat het technisch beheer van het project categorisch tegen het gebruik van STL (Standard Template Library) was. Dit is een standaardtaalbibliotheek die de ontwikkeling vereenvoudigt, en ons team is er erg aan gewend. Het bleek dat het project veel dichter bij C lag dan bij C++, wat het team niet erg inspireerde, omdat Het management deed zijn best en rekruteerde hele coole plusspelers. Tegelijkertijd werkte het Amerikaanse deel van het team, zowel ingenieurs als managers, al lange tijd in het bedrijf, was gewend aan de bestaande stand van zaken en was met alles tevreden. Het Russische deel van het team is vrij recent, binnen een paar weken, bij elkaar gebracht (ikzelf inbegrepen). Het Russische deel van het team wilde categorisch de gebruikelijke benadering van ontwikkeling niet opgeven.
Er ontstonden eindeloze schriftelijke discussies tussen de twee continenten, brieven op drie of vier schermen vlogen heen en weer, in groepsmailings en persoonlijke mailings, van programmeurs tot programmeurs en managers. Zoals meestal het geval is, werden brieven van deze lengte door niemand gelezen behalve door de auteurs en hun fervente aanhangers. Chats kraakten van spanning, waardoor gedachten op meerdere schermen in verschillende richtingen gingen over de technische voordelen van de STL, hoe goed getest het is, hoe veilig het is, en in het algemeen, hoe geweldig het leven ermee is, en hoe verschrikkelijk het is zonder .
Dit duurde allemaal behoorlijk lang, totdat ik uiteindelijk besefte dat we de technische aspecten van de kwestie bespraken, maar dat het probleem in werkelijkheid niet technisch was. Het probleem zijn niet de voor- of nadelen van STL, of de moeilijkheid om zonder te werken. Het probleem is nogal organisatorisch. We moesten gewoon begrijpen hoe het bedrijf waarvoor we werkten werkte. Niemand van ons had eerder ervaring met het werken bij zo’n bedrijf. Het punt was dat nadat de code was ontwikkeld en in productie was genomen, de ondersteuning werd afgehandeld door totaal andere mensen van andere teams, uit andere landen. Dit enorme technische team van enkele tienduizenden ingenieurs (in totaal) kon zich slechts een absoluut basisminimum aan technische middelen veroorloven, om zo te zeggen, een minimum minimum. Alles wat verder ging dan de technische standaard die fysiek in het bedrijf was vastgelegd, kon in de toekomst niet meer worden ondersteund. Het niveau van een team wordt bepaald door het niveau van de zwakste leden. Nadat we het begrepen hadden echte motivatie Door de acties van het Amerikaanse deel van het team werd deze kwestie van de agenda gehaald en samen hebben we het product met succes ontwikkeld en uitgebracht volgens de normen die door het bedrijf zijn aangenomen. Brieven en chats werkten in dit geval niet goed; het kostte verschillende reizen en veel persoonlijke communicatie om tot een gemeenschappelijke noemer te komen.
Vanuit het oogpunt van de workflow zou het in dit specifieke geval helpen om een beschrijving te hebben van de gebruikte tools, de vereisten daarvoor, de beperkingen op het toevoegen van nieuwe en de rechtvaardiging voor dergelijke beperkingen. Dergelijke documenten komen grofweg overeen met de documenten beschreven in de paragrafen Hergebruikstrategie en ontwikkelomgeving van het “Manager's Handbook for Software Development”, ontwikkeld in . Ondanks zijn leeftijd beschrijft het perfect alle hoofdactiviteiten en planningsfasen van dit soort softwareontwikkeling. Het hebben van dit soort documenten maakt het heel gemakkelijk om te bespreken welke componenten en benaderingen in een product kunnen worden gebruikt, en waarom.
Vanuit cultureel oogpunt uiteraard met een meer volwassen positie, waarin de partijen proberen de echte motivatie van de acties van hun collega's te horen en te begrijpen en te handelen op basis van de prioriteiten van het project en het team, en niet op basis van het persoonlijke ego , zou het conflict gemakkelijker en sneller worden opgelost.
Bij een ander conflict over de keuze voor een technische oplossing kostte het mij ook merkbaar veel tijd om de motivatie van een van de partijen te begrijpen (het was een zeer ongebruikelijk geval), maar nadat de motivatie duidelijk was, lag de oplossing voor de hand.
De situatie is als volgt: er verschijnt een nieuwe ontwikkelaar in een team van ongeveer 20 mensen, laten we hem Stas noemen. Ons standaardmiddel voor teamcommunicatie was destijds Skype. Zoals later bleek, was Stas een groot fan van open standaarden en open source-software, en gebruikte hij alleen tools en besturingssystemen waarvan de bronnen openbaar beschikbaar waren en die gebruik maakten van publiekelijk beschreven protocollen. Skype is niet een van deze tools. We hebben veel tijd besteed aan het bespreken van de voor- en nadelen van deze aanpak, pogingen om analogen van Skype op verschillende besturingssystemen te lanceren, de pogingen van Stas om het team te overtuigen om naar andere standaarden over te schakelen, hem persoonlijk per post te schrijven, hem persoonlijk te bellen op de telefoon, koop een tweede computer voor hem speciaal voor Skype, enz. Ten slotte besefte ik dat dit probleem in wezen niet technisch of organisatorisch van aard is, maar eerder ideologisch en zelfs religieus (voor Stas). Zelfs als we Stas en Skype uiteindelijk met elkaar zouden verbinden (wat enkele maanden duurde), zou het probleem zich op elk volgend instrument opnieuw voordoen. Ik had geen echte middelen tot mijn beschikking om het wereldbeeld van Stas te veranderen, en er was geen reden om te proberen het wereldbeeld te veranderen van een team dat perfect werkte in deze omgeving. De persoon en het bedrijf waren eenvoudigweg orthogonaal in hun wereldbeeld. In dergelijke situaties is een goede oplossing organisatorisch. We hebben Stas overgeplaatst naar een ander team, waar hij organischer was.
De reden voor dit conflict is naar mijn mening de discrepantie tussen de persoonlijke cultuur van een bepaalde persoon (die een sterke mening heeft die hem niet toestaat compromissen te sluiten) en de cultuur van het bedrijf. In dit geval is het uiteraard de fout van de manager. Het was aanvankelijk verkeerd om hem voor een dergelijk project mee te nemen. Stas stapte uiteindelijk over naar een open source softwareontwikkelingsproject en blonk daar uit.
Een goed voorbeeld van een conflict veroorzaakt door zowel de kinderlijke houding van de ontwikkelaar als de tekortkomingen van het werkproces is een situatie waarin, bij gebrek aan een definition of done, de ontwikkelaar en het QA-team verschillende verwachtingen hebben over de bereidheid om de functie is overgedragen naar QA. De ontwikkelaar was van mening dat het voldoende was om de code te schrijven en de functie over het hek naar QA te gooien - zij zouden het daar uitzoeken. Een redelijk volwassen en ervaren programmeur overigens, maar dat was zijn interne drempel voor kwaliteit. QA was het hier niet mee eens en eiste hen te laten zien en beschrijven wat hij zelf had gecontroleerd, en eiste een testscript voor hen. Ze hadden in het verleden problemen gehad met de functionaliteit van deze ontwikkelaar en wilden hun tijd niet opnieuw verspillen. Ze hadden trouwens gelijk: de functie werkte echt niet, hij controleerde de code niet voordat hij deze naar QA stuurde.
Om de situatie op te lossen, vroeg ik hem om me te laten zien dat alles echt werkte (het werkte niet, en hij moest het repareren), we spraken met het team en met de QA-definitie van gedaan (ze hebben het niet gehaald in schrijven, omdat we het proces niet te bureaucratisch wilden maken), nou ja, we namen al snel afscheid van deze specialist (tot algemene opluchting).
Vanuit het oogpunt van de workflow zijn mogelijke verbeteringen in dit geval de aanwezigheid van een definition of done, vereisten voor ondersteuning van elke unit-functie en integratietests, en een beschrijving van de tests die door de ontwikkelaar zijn uitgevoerd. In een van de projecten hebben we het niveau van codedekking gemeten door middel van tests tijdens CI en als het dekkingsniveau daalde na het toevoegen van een patch, werden de tests gemarkeerd als mislukt, dat wil zeggen: elke nieuwe code kon alleen worden toegevoegd als er nieuwe tests voor waren.
Nog een typisch voorbeeld van een conflict dat nauw samenhangt met de organisatie van het werkproces. We hebben een product, een productontwikkelingsteam, een ondersteuningsteam en een klant. De klant heeft problemen met het product en neemt contact op met de ondersteuning. Support analyseert het probleem en begrijpt dat het probleem in het product zit en draagt het probleem over aan het productteam. Het productteam zit in een drukke tijd, er komt een release aan, dus een ticket met een probleem van een klant, kwijtgeraakt tussen de andere tickets van de ontwikkelaar aan wie het is toegewezen, blijft enkele weken hangen zonder aandacht. Support denkt dat de ontwikkelaar aan het probleem van de klant werkt. De klant wacht en hoopt dat er aan zijn probleem wordt gewerkt. In werkelijkheid gebeurt er nog niets. Na een paar weken besluit de klant eindelijk interesse te tonen in de voortgang en vraagt ondersteuning hoe het gaat. Ondersteuning vraagt om ontwikkeling. De ontwikkelaar huivert, bladert door de lijst met tickets en vindt daar een ticket van de klant. Als hij een ticket van een klant leest, begrijpt hij dat er niet genoeg informatie is om het probleem op te lossen, en dat hij meer logs en dumps nodig heeft. Support vraagt om aanvullende informatie van de klant. En dan beseft de klant dat niemand al die tijd aan zijn probleem heeft gewerkt. En de donder zal toeslaan...
In deze situatie is de oplossing voor het conflict zelf vrij voor de hand liggend en lineair (het product repareren, de documentatie en tests bijwerken, de klant tevreden stellen, 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 werd. Het is duidelijk wat er in het proces moet worden opgelost: iemand moet het totaalbeeld proactief bewaken zonder herinneringen van klanten. Tickets van de klant moeten opvallen tussen andere tickets van ontwikkelaars. Ondersteuning moet zien of het ontwikkelteam momenteel aan de tickets werkt, en zo niet, wanneer het kan beginnen met werken en wanneer resultaten kunnen worden verwacht. Ondersteuning en ontwikkeling moeten periodiek de status van tickets communiceren en bespreken, het verzamelen van informatie die nodig is voor het debuggen moet zoveel mogelijk worden geautomatiseerd, enz.
Net zoals in een oorlog de vijand het kruispunt tussen twee eenheden probeert te bereiken, is op het werk meestal de interactie tussen teams het meest delicate en kwetsbare punt. Als de ondersteunings- en ontwikkelingsmanagers oud genoeg zijn, kunnen ze het proces zelf oplossen. Als dat niet het geval is, zal het proces conflicten en problemen blijven genereren totdat een manager tussenbeide komt die de situatie kan oplossen.
Een ander typisch voorbeeld dat ik herhaaldelijk bij verschillende bedrijven heb gezien, is een situatie waarin een product door één team wordt geschreven, automatische integratietests ervoor worden geschreven door een tweede team, en de infrastructuur waarop het allemaal wordt beheerd, wordt begeleid door een derde team. team. Er doen zich voortdurend problemen voor bij het uitvoeren van tests, en de oorzaak van problemen daarbij kan zowel het product als de tests en infrastructuur zijn. Het is meestal problematisch om het eens te worden over wie de initiële analyse van problemen moet uitvoeren, bugs moet archiveren, logs van het product, tests en infrastructuur moet ontleden, enz. Conflicten komen hier zeer vaak voor en zijn tegelijkertijd uniform. Bij een hoge emotionele intensiteit vervallen deelnemers vaak in een kinderlijke positie en beginnen discussies in de serie: ‘waarom zou ik hieraan sleutelen’, ‘ze gaan vaker kapot’, etc.
Vanuit een workflowperspectief zijn de specifieke stappen om een probleem op te lossen afhankelijk van de samenstelling van de teams, het type tests en product, enz. In een van de projecten hebben we periodieke taken geïntroduceerd, waarbij teams de tests één voor één, week na week, controleerden. In het andere geval werd de initiële analyse altijd gedaan door de testontwikkelaars, maar de analyse was erg basaal en het product was redelijk stabiel, dus het werkte goed. De sleutel is om ervoor te zorgen dat het proces transparant is, dat de verwachtingen voor alle partijen duidelijk zijn en dat de situatie voor iedereen eerlijk aanvoelt.
Is conflict wel een probleem in een organisatie of is het een slecht teken dat er vaak (of slechts af en toe) conflicten voorkomen in uw team? Over het algemeen niet, want als er groei en ontwikkeling is, is er een soort dynamiek, dan ontstaan er problemen die nog nooit eerder zijn opgelost, en bij het oplossen ervan kunnen er conflicten ontstaan. Dit is een indicator dat sommige gebieden aandacht behoeven, dat er gebieden zijn die voor verbetering vatbaar zijn. Het is erg als conflicten heel vaak voorkomen, moeilijk op te lossen zijn of lang duren. Dit is hoogstwaarschijnlijk een teken van onvoldoende gestroomlijnde werkprocessen en onvoldoende volwassenheid van het team.
Bron: www.habr.com