Konfliktmanagement im Team – Balanceakt oder notwendige Pflicht?

Epigraf:
Eines Tages trafen sich im Wald Igel und Bärchen.
— Hallo, Igel!
— Hallo, Bärchen!
So, Wort für Wort, Witz für Witz, bekam der Igel schließlich von Bärchen eine auf die Nase ...

Im Folgenden Überlegungen unseres Teamleiters sowie des Leiters der Produktentwicklung RAS — Igor Marnat über die Eigenheiten von Arbeitskonflikten und mögliche Methoden zu deren Management.

Die meisten Konflikte, mit denen wir bei der Arbeit konfrontiert sind, entwickeln sich nach einem ähnlichen Schema wie das oben im Epigraph Beschriebene. Es gibt mehrere Teilnehmer, die anfangs gut aufeinander eingestellt sind, sie versuchen, ein bestimmtes Anliegen zu klären, aber letztendlich bleibt das Problem ungelöst und die Beziehungen zwischen den Diskussionsteilnehmern scheinen aus irgendeinem Grund gestört zu sein.

Das Leben ist vielfältig, in dem oben beschriebenen Schema gibt es Variationen. Manchmal sind die Beziehungen zwischen den Teilnehmern anfänglich nicht allzu gut, manchmal gibt es nicht einmal eine Frage, die sofortige Klärung erfordert (wie zum Beispiel im Epigraph), manchmal bleiben die Beziehungen nach der Diskussion dieselben wie vor deren Beginn, aber das Anliegen bleibt letztendlich ungelöst.

Was haben all diese Situationen, die man als Arbeitskonfliktsituation definieren kann, gemeinsam?



Erstens gibt es zwei oder mehr Parteien. Diese Parteien können unterschiedliche Positionen innerhalb der Organisation einnehmen, sich in Gleichheitsverhältnissen befinden (Kollegen im Team) oder auf verschiedenen Hierarchieebenen stehen (Vorgesetzter — Untergebener), individuell (Mitarbeiter) oder gruppenbezogen sein (im Falle eines Konflikts zwischen einem Mitarbeiter und einem Team oder zwei Teams) und so weiter. Das Vertrauen zwischen den Beteiligten beeinflusst die Wahrscheinlichkeit eines Konflikts und die Einfachheit seiner Lösung erheblich. Je besser die Seiten sich kennen, je höher das Vertrauen, desto größer ist die Chance, dass sie sich einigen. Zum Beispiel werden Mitarbeiter eines verteilten Teams, die sich nie persönlich getroffen haben, mit größerer Wahrscheinlichkeit in einen Konflikt geraten, wenn sie ein einfaches Arbeitsproblem zu lösen versuchen, als Menschen, die sich zumindest ein paar Mal persönlich getroffen haben. Daher ist es bei der Arbeit in verteilten Teams sehr wichtig, regelmäßige persönliche Treffen aller Teammitglieder sicherzustellen.

Zweitens befinden sich die Parteien in einem Konflikt am Arbeitsplatz in einer Situation, in der es darum geht, eine wichtige Frage zu klären, die für eine der Parteien, für beide oder für die Organisation als Ganzes von Bedeutung ist. Aufgrund der Spezifität der Situation haben die Parteien in der Regel genügend Zeit und verschiedene Möglichkeiten zur Lösung (formelle, informelle, Meetings, Schreiben, Entscheidungen der Geschäftsführung, das Vorhandensein von Zielen und Plänen des Teams, die Tatsache, dass es Hierarchien gibt usw.). Das unterscheidet sich von der Situation, in der ein arbeitsbezogenes (oder nicht arbeitsbezogenes) Problem in der Organisation gelöst werden muss, zum Beispiel der wichtigen Frage: "Hey, Kumpel, aus welchem Viertel kommst du?!" auf der Straße oder dem Konflikt aus dem Epigraph. Bei der Lösung eines arbeitsbezogenen Problems sind die Qualität des Arbeitsprozesses und die Kultur der Problemlösung im Team entscheidend.

Drittens ist der entscheidende Faktor eines Konflikts (im Sinne unserer Diskussion) die Tatsache, dass die Parteien des Prozesses nicht in der Lage sind, selbst zu einer für alle Seiten akzeptablen Lösung zu gelangen. Die Situation erfordert das Eingreifen einer dritten Partei, eines externen Schiedsrichters. Dieser Punkt mag umstritten erscheinen, aber im Grunde genommen, wenn eine Konfliktsituation erfolgreich ohne das Eingreifen eines externen Schiedsrichters gelöst wurde, ist das Problem erfolgreich gelöst und die Beziehungen der Parteien haben sich nicht verschlechtert. Dies ist die Situation, nach der man streben sollte. Wir werden von einem solchen Konflikt wahrscheinlich nicht einmal erfahren oder nur zufällig nach seiner Lösung. Je mehr Fragen das Team selbst lösen kann, desto effizienter wird es arbeiten.

Eine weitere charakteristische Eigenschaft eines Konflikts, die erwähnenswert ist, ist der Grad der emotionalen Erregung während der Lösung. Ein Konflikt ist nicht unbedingt mit einem hohen emotionalen Grad verbunden. Es ist nicht notwendig, dass die Teilnehmer schreien und mit den Händen fuchteln, damit die Situation im Wesentlichen konfliktbehaftet ist. Ein Problem wird nicht gelöst, ein gewisses emotionales Spannungsfeld ist dabei vorhanden (möglicherweise wird es nach außen hin nicht offensichtlich ausgedrückt), was bedeutet, dass wir es mit einer Konfliktsituation zu tun haben.

Sollte man überhaupt in Konfliktsituationen eingreifen, oder ist es besser, sie sich selbst zu überlassen und zu warten, bis das Problem von selbst verschwindet? Ja, sollte man. Es liegt nicht immer in Ihrer Macht oder Kompetenz, einen Konflikt vollständig zu lösen, aber in jeder Situation und bei Konflikten jeder Größenordnung können Sie eine erwachsene Position einnehmen und damit auch andere um sich herum dazu bringen, das Gleiche zu tun. So können Sie die negativen Folgen des Konflikts mildern und zur Lösung beitragen.

Bevor wir einige Beispiele für Konfliktsituationen betrachten, lassen Sie uns auf einige wichtige Punkte eingehen, die für alle Konflikte gelten.

Bei der Lösung eines Konflikts ist es wichtig, über dem Geschehen zu stehen und nicht mittendrin zu sein (dies wird auch als "Meta-Position einnehmen" bezeichnet). Das bedeutet, dass Sie nicht Teil einer der Konfliktparteien werden sollten. Ansonsten werden Sie, statt als externer Schiedsrichter zu helfen, nur die Position einer der Parteien auf Kosten der anderen stärken. Bei der Entscheidungsfindung ist es wichtig, dass diese von allen Parteien moralisch akzeptiert wird, wie man sagt, "abgekauft". Wenn die Parteien also nicht begeistert von der getroffenen Entscheidung sind, sollten sie zumindest aufrichtig bereit sein, sie umzusetzen. Man sollte in der Lage sein, unterschiedlicher Meinung zu sein und dennoch zuzustimmen. Andernfalls wird der Konflikt einfach eine andere Form annehmen, und das glühende Feuer wird unter der Asche bleiben und irgendwann unvermeidlich wieder aufflammen.

Ein weiterer Punkt, der teilweise mit dem ersten verbunden ist – wenn Sie sich bereits an der Lösung eines Konflikts beteiligen, gehen Sie damit so ernsthaft wie möglich mit Blick auf die Kommunikation und das Verständnis des Kontexts um. Sprechen Sie persönlich mit jeder der Parteien. Zuerst getrennt mit jeder. Begnügen Sie sich nicht mit E-Mails. Bei einem verteilten Team – sprechen Sie zumindest per Videokonferenz. Begnügen Sie sich nicht mit Gerüchten und Erzählungen von Zeugen. Verstehen Sie die Geschichte, was jede der Parteien möchte, warum sie das möchte, was sie erwartet, ob sie versucht haben, dieses Thema zuvor zu lösen, was passieren wird, wenn es nicht gelöst wird, welche Lösungsmöglichkeiten sie sehen, wie sie die Position der anderen Seite wahrnehmen, was ihrer Meinung nach richtig oder falsch ist usw. Laden Sie sich den gesamten möglichen Kontext unverfälscht in Ihren Kopf, in dem Sie annehmen, dass alle im Recht sind. Sie sind nicht im Konflikt, sondern außerhalb desselben, in einer Meta-Position. Wenn der Kontext nur in einem E-Mail-Thread verfügbar ist, lesen Sie zumindest diesen und die damit verbundenen Diskussionsthreads und Dokumente vollständig durch. Nachdem Sie gelesen haben – reden Sie trotzdem persönlich. So gut wie garantiert werden Sie etwas Wichtiges hören, das nicht in den E-Mails steht.

Ein dritter wichtiger Punkt – der allgemeine Ansatz zur Kommunikation. Das sind alltägliche Dinge, nichts Abgehobenes, aber sie haben eine sehr große Bedeutung. Versuchen Sie nicht, Zeit zu sparen, sondern sprechen Sie mit allen Beteiligten, kritisieren Sie nicht die Person, sondern betrachten Sie die Folgen ihres Handelns (nicht 'du bist unhöflich', sondern 'vielleicht könnten die Leute sich über diese Sache ärgern'), geben Sie ihnen die Möglichkeit, ihr Gesicht zu wahren, führen Sie persönliche Diskussionen und nicht im Team.

Konflikte entstehen normalerweise aus einem von zwei Gründen. Der erste hängt damit zusammen, ob sich eine Person im Moment des Konflikts in der Position eines Erwachsenen oder eines Kindes befindet (darüber später mehr). Dies hat mit ihrer emotionalen Reife zu tun, mit der Fähigkeit, ihre Emotionen zu steuern (was übrigens nicht immer mit ihrem Alter zusammenhängt). Der zweite häufige Grund ist die Unzulänglichkeit des Arbeitsprozesses, die Situationen schafft, in denen die Verantwortung zwischen den Teilnehmern verschwommen ist, die Erwartungen der Parteien nicht transparent sind und die Rollen im Prozess unklar sind.

Dementsprechend muss der Manager bei der Konfliktlösung (wie auch bei jeder anderen Frage) drei Perspektiven im Blick haben: eine kurzfristige – um das Problem/den Konflikt hier und jetzt zu lösen, eine mittelfristige – um die Wahrscheinlichkeit eines erneuten Konflikts aus demselben Grund zu minimieren, und eine langfristige – um in der Mannschaft eine Kultur des Erwachsenseins zu fördern.

In jedem von uns gibt es ein inneres Kind, etwa drei bis vier Jahre alt. Die meiste Zeit schläft es bei der Arbeit, wach aber manchmal auf und übernimmt das Steuer. Das Kind hat seine eigenen Prioritäten. Es ist ihm wichtig, darauf zu bestehen, dass dies seine Sandkiste ist, Mama ihn mehr liebt, sein Auto das beste ist (das Design das beste, er programmiert am besten, …). In Konfliktsituationen kann das Kind mit Spielzeugen schubsen, stampfen und mit dem Schaufel zerschlagen, aber es kann keine erwachsenen Fragen lösen (Architektur der Lösung, Ansätze zum automatisierten Testen, Fristen für die Veröffentlichung usw.), es denkt nicht in Begriffen von Nutzen für das Team. Man kann das Kind in einem Konflikt ermutigen, trösten und zum Schlafen schicken, indem man es bittet, den Erwachsenen zu rufen. Vor Beginn einer Diskussion in Konfliktsituationen stellen Sie sicher, dass Sie gerade mit dem Erwachsenen sprechen und nicht mit dem Kind und dass Sie selbst auf der Erwachsenenseite stehen. Wenn Ihr ehrliches Ziel in diesem Moment ist, ein ernsthaftes Problem zu lösen, stehen Sie auf der Seite des Erwachsenen. Wenn Ihr Ziel darin besteht, zu stampfen und mit dem Schaufel zu schlagen – ist das eine Kinderposition. Schicken Sie Ihr inneres Kind ins Bett und rufen Sie den Erwachsenen, oder verschieben Sie die Diskussion. Der Mensch trifft eine emotionale Entscheidung und sucht dann eine rationale Begründung dafür. Eine Entscheidung, die das Kind basierend auf seinen kindlichen Prioritäten trifft, wird nicht optimal sein.

Neben dem Verhalten im Konflikt wird die kindliche oder erwachsene Position auch durch das Maß an Verantwortung charakterisiert, das eine Person bereit ist zu übernehmen. In extremen Ausprägungen sieht die kindliche Position eines Programmierers, die ich mehrfach erlebt habe, so aus: Ich habe den Code geschrieben, ihn zur Überprüfung geschickt – meine Arbeit ist getan. Die Reviewer müssen ihn überprüfen und mergen, das QA-Team sollte es testen, wenn es Probleme gibt – werden sie mir Bescheid geben. Seltsamerweise verhalten sich selbst ziemlich erwachsene und erfahrene Menschen manchmal so. Am anderen Ende der Skala sieht die Person sich selbst als verantwortlich dafür, dass ihr Code funktioniert, mit Tests abgedeckt ist, persönlich überprüft wurde, erfolgreich reviewed wurde (wenn nötig, kein Problem, die Reviewer anzupingen, Fragen per Voice zu besprechen usw.) und gemerged wird. Das QA-Team erhält bei Bedarf Unterstützung, Testfälle werden beschrieben usw. In normalen Fällen befindet sich der Programmierer entweder von Anfang an näher am erwachsenen Ende der Skala oder verschiebt sich dorthin mit zunehmender Erfahrung (vorausgesetzt, die richtige Kultur wird im Team gefördert). In extremen Fällen arbeitet er jedoch weiterhin meist aus einer kindlichen Position heraus, was gelegentlich zu Problemen und Konflikten für ihn und das Team führt.

Die Förderung einer richtigen, erwachsenen Kultur im Team ist eine wichtige Aufgabe jedes Managers. Sie erfordert viel Zeit und tägliche Anstrengungen, aber das Ergebnis ist es wert. Es gibt zwei Möglichkeiten, die Kultur des Teams zu beeinflussen – das persönliche Beispiel (dem stets gefolgt wird, das Team schaut immer auf den Leader) und die Diskussion und Förderung des richtigen Verhaltens. Auch hier gibt es nichts Kompliziertes oder Formalistisches, einfach beim Diskutieren von Problemen darauf hinweisen, was man hätte anders machen können, betonen, dass man anerkannt hat, wenn etwas richtig gelöst wurde, loben, bei der Analyse von Releases anmerken usw.

Betrachten wir einige typische Konfliktsituationen, von einfachen bis hin zu komplexen:

Konflikte, die nicht mit Arbeitsfragen verbunden sind

Relativ häufig treten am Arbeitsplatz Konflikte auf, die nicht mit Arbeitsfragen zusammenhängen. Ihr Auftreten und die Leichtigkeit ihrer Lösung stehen normalerweise in direktem Zusammenhang mit dem emotionalen Intelligenzgrad der Beteiligten, ihrem Erwachsenenalter und sind nicht mit der Vollkommenheit oder Unvollkommenheit des Arbeitsprozesses verbunden.

Typische Beispiele sind, dass jemand die Waschmaschine oder die Dusche nicht oft genug benutzt, was den anderen missfällt, jemandem ist es zu heiß, während ein anderer einen Zug bekommt, wenn das Fenster geöffnet wird, jemand ist zu laut, während die anderen Ruhe zum Arbeiten benötigen, und so weiter. Konflikte dieser Art sollten nicht hinausgezögert oder ignoriert werden. Sie lösen sich nicht von selbst auf und lenken täglich von der Arbeit ab und verderben die Atmosphäre im Team. Glücklicherweise ist es normalerweise nicht zu schwierig, sie zu lösen – es reicht, ruhig (natürlich unter vier Augen) mit dem Kollegen zu sprechen, der die Hygiene vernachlässigt, eine angenehme Sitzordnung für Leute zu gewährleisten, die Ruhe/Kühle bevorzugen, schalldämpfende Kopfhörer zu kaufen oder Trennwände aufzustellen, usw.

Ein weiteres Beispiel, das ich während meiner Arbeit mehrmals erlebt habe, ist die psychologische Unverträglichkeit der Teammitglieder. Aus irgendwelchen Gründen können die Menschen einfach nicht zusammenarbeiten, jede Kommunikation endet in einem Skandal. Manchmal liegt das daran, dass die Menschen diametral entgegengesetzte Ansichten zu einem brisanten Thema (gewöhnlich politisch) vertreten und nicht wissen, wie sie diese außerhalb der Arbeit außen vor lassen können. Sie davon zu überzeugen, einander zu ertragen oder ihr Verhalten zu ändern, ist eine Aussicht, die wenig Erfolg verspricht. Die einzige Ausnahme, die ich erlebt habe, sind junge Kollegen mit offenen Wahrnehmungen, deren Verhalten man allmählich durch regelmäßige Gespräche ändern kann. In der Regel lässt sich das Problem erfolgreich lösen, indem man sie in verschiedene Teams aufteilt oder zumindest sicherstellt, dass sie sehr selten beruflich aufeinandertreffen.

In all den genannten Situationen sollte jeder Teilnehmer persönlich angesprochen werden, um die Situation zu besprechen, zu erkundigen, ob sie das Problem in diesem Fall überhaupt sehen, und zu fragen, welche ihrer Meinung nach Lösungsmöglichkeiten bestehen und sie in die Entscheidungsfindung einzubeziehen.

In Bezug auf die Optimierung des Arbeitsprozesses (die mittelfristige Perspektive, die ich erwähnt habe) ist hier nicht viel zu tun, der einzige Punkt zur Optimierung besteht darin, den Kompatibilitätsfaktor bei der Teamzusammensetzung zu berücksichtigen und im Voraus keine Menschen zusammenzustellen, die in Konflikt geraten werden.

In Bezug auf die Teamkultur treten solche Situationen viel seltener in Teams mit einer reifen Kultur auf, in denen die Menschen das Team und ihre Kollegen respektieren und in der Lage sind, Probleme selbstständig zu lösen. Zudem werden solche Konflikte viel einfacher (oft automatisch) in Teams gelöst, in denen das Vertrauen hoch ist, die Menschen lange zusammenarbeiten und/oder oft außerhalb der Arbeit kommunizieren.

Konflikte im Zusammenhang mit Arbeitsfragen:

Solche Konflikte werden in der Regel durch beide Ursachen verursacht, sowohl die emotionale (dass sich einer der Beteiligten nicht auf der Erwachsenenposition befindet) als auch durch Unzulänglichkeiten des Arbeitsprozesses selbst. Die häufigste Art von Konflikten, die ich erlebt habe, sind Konflikte im Rahmen von Code-Reviews oder Architekturdiskussionen zwischen Entwicklern.

Ich würde hier zwei typische Fälle hervorheben:

1) Im ersten Fall kann der Entwickler keine Code-Überprüfung von einem Kollegen erhalten. Der Patch wurde zur Überprüfung gesendet, und es passiert nichts. Auf den ersten Blick gibt es keinen offensichtlichen Konflikt zwischen den beiden Parteien, aber bei näherer Betrachtung handelt es sich durchaus um einen Konflikt. Das Arbeitsproblem bleibt ungelöst, eine der Parteien (die auf das Review wartet) empfindet offensichtliches Unbehagen. Eine extreme Unterkategorie dieses Falls ist die Entwicklung in Communities oder in unterschiedlichen Teams, wobei der Reviewer möglicherweise an diesem speziellen Code nicht interessiert ist, aufgrund von Arbeitsbelastung oder anderen Umständen möglicherweise überhaupt nicht auf die Anfrage zur Überprüfung achtet, und ein externer Schiedsrichter (ein gemeinsamer Manager für beide Seiten) möglicherweise überhaupt nicht vorhanden ist.

Der Lösungsansatz, der in dieser Situation hilft, bezieht sich auf eine langfristige Perspektive und die Kultur eines erwachsenen Menschen. Erstens funktioniert rationale Aktivität. Man sollte nicht erwarten, dass der Code, der zur Überprüfung bereitgestellt wurde, von selbst die Aufmerksamkeit des Prüfers auf sich zieht. Man muss den Prüfern helfen, ihn zu bemerken. Kontaktiere ein paar Leute, stelle eine Frage im Meeting, nimm an Diskussionen teil. Es ist offensichtlich, dass Nervigkeit eher schädlich als hilfreich ist, daher sollte man gesunden Menschenverstand walten lassen. Zweitens funktioniert eine gute Vorbereitung. Wenn das Team versteht, was und warum passiert, wofür dieser Code überhaupt benötigt wird, und das Design im Voraus mit allen besprochen und genehmigt wurde, werden die Leute eher auf diesen Code achten und ihn in die Arbeit einbeziehen. Drittens spielt Autorität eine Rolle. Wenn du möchtest, dass dein Code überprüft wird, mache viele Reviews selbst. Führe qualitativ hochwertige Reviews durch, mit echten Prüfungen, echten Tests und nützlichen Kommentaren. Wenn dein Name im Team positiv bekannt ist, hast du bessere Chancen, dass dein Code Aufmerksamkeit erregt.

Aus der Sicht des Arbeitsprozesses gibt es mögliche Verbesserungen wie die richtige Priorisierung, um dem Entwickler zu helfen, seine Ziele und die Ziele des Teams zu erreichen (andere überprüfen, Kommunikations-E-Mails zu schreiben, den Code mit Architektur-, Dokumentations- und Testbeschreibungen zu begleiten, an Diskussionen mit der Community teilzunehmen usw.), um zu verhindern, dass Patches zu lange in der Warteschlange hängen bleiben, und so weiter.

2) Ein weiterer häufiger Konfliktfall bei der Überprüfung von Code oder Design sind unterschiedliche Sichtweisen auf technische Fragen, Kodierungsstil und Werkzeugauswahl. Dabei spielt das Vertrauen zwischen den Beteiligten, die Zugehörigkeit zu einem Team und die Erfahrung in der Zusammenarbeit eine große Rolle. Eine Sackgasse entsteht, wenn einer der Beteiligten eine kindische Haltung einnimmt und nicht versucht, die Botschaft des Gesprächspartners zu hören. Oft können sowohl der von der anderen Seite vorgeschlagene Ansatz als auch der ursprüngliche Ansatz erfolgreich sein und es ist grundsätzlich unerheblich, welchen man wählt.

Eines Tages bereitete ein Programmierer aus meinem Team (nennen wir ihn Pasha) einen Patch mit Änderungen am System für die Paketverteilung vor, das von Kolleginnen und Kollegen aus der benachbarten Abteilung entwickelt und gepflegt wurde. Einer von ihnen (Igor) hatte eine starke Meinung darüber, wie die Linux-Dienste bei der Paketverteilung konfiguriert werden sollten. Diese Meinung unterschied sich von dem Ansatz, der im Patch vorgeschlagen wurde, und es war nicht möglich, sich zu einigen. Wie immer drängten die Fristen, und es musste eine Lösung gefunden werden; jemand musste eine erwachsene Position einnehmen. Pasha räumte ein, dass beide Ansätze ihre Daseinsberechtigung hatten, wollte jedoch, dass seine Variante akzeptiert wurde, da es keine offensichtlichen technischen Vorteile für keinen der beiden Ansätze gab.

Unsere Diskussion sah etwa so aus (ziemlich schematisch, natürlich dauerte das Gespräch eine halbe Stunde):

— Pasha, wir haben in ein paar Tagen Feature Freeze. Es ist wichtig, dass wir alles sammeln und so schnell wie möglich mit dem Testen beginnen. Wie können wir an Igor vorbeikommen?
— Er möchte die Dienste anders konfigurieren und hat mir … viele Kommentare reingepflanzt.
— Und was ist damit? Große Umstellungen, viel Aufwand?
— Nein, es sind nur ein paar Stunden Arbeit, aber am Ende ist der Unterschied doch egal; so oder so wird es funktionieren. Warum ist das nötig? Ich habe etwas Funktionierendes gemacht, lass uns das akzeptieren.
— Sag mal, wie lange diskutiert ihr das schon?
— Schon seit anderthalb Wochen.
— Ähm … können wir nicht in ein paar Stunden eine Frage klären, die bereits anderthalb Wochen dauert, und tun es nicht?
— Naja, ja, aber ich möchte nicht, dass Igor denkt, ich hätte nachgegeben.
— Sag mal, was ist dir eigentlich wichtiger, die Veröffentlichung oder Igor zu besiegen? Wir können ihn besiegen, aber dann gibt es echt eine gute Chance, dass wir mit der Veröffentlichung durchfallen.
— Nun … es wäre natürlich cool, Igor mal einen Streich zu spielen, aber gut, die Veröffentlichung ist wichtiger, einverstanden.
— Ist dir wirklich so wichtig, was Igor denkt? Ehrlich gesagt, ihm ist das ziemlich egal. Er möchte einfach einen einheitlichen Ansatz in den verschiedenen Bereichen des Systems, für das er verantwortlich ist.
— Okay, dann mache ich es so, wie er in den Kommentaren verlangt, und wir beginnen mit den Tests.
— Danke, Pasha! Ich war mir sicher, dass du von euch beiden der Erwachsenere bist, auch wenn Igor älter ist als du :)

Das Problem wurde gelöst, das Release wurde pünktlich veröffentlicht, Pasha war nicht besonders unzufrieden, da er selbst die Lösung vorgeschlagen und umgesetzt hat. Igor war insgesamt zufrieden, da seine Meinung berücksichtigt wurde und es so umgesetzt wurde, wie er es vorgeschlagen hatte.

Eine andere Art eines ähnlichen Konflikts besteht in der Wahl zwischen technischen Lösungen/Bibliotheken/Ansätzen im Projekt, insbesondere in einem verteilten Team. In einem der Projekte, das als C/C++-basiert positioniert wurde, stellte sich heraus, dass das technische Management des Projekts kategorisch gegen die Verwendung von STL (Standard Template Library) war. Dies ist die Standardbibliothek der Sprache, die die Entwicklung erleichtert; unser Team hatte sich sehr daran gewöhnt. Es stellte sich heraus, dass das Projekt viel näher an C als an C++ war, was das Team nicht gerade inspirierte, da das Management wirklich talentierte C++-Entwickler akquiriert hatte. Dabei arbeiteten die amerikanischen Teammitglieder, sowohl Ingenieure als auch Manager, schon lange im Unternehmen, so dass sie mit dem aktuellen Status quo zufrieden waren. Die russische Teamhälfte wurde erst vor wenigen Wochen, einschließlich meiner Person, versammelt. Die russische Teilmannschaft war kategorisch dagegen, von ihrem gewohnten Entwicklungsansatz abzurücken.

Es begannen endlose schriftliche Diskussionen zwischen zwei Kontinenten, Briefe mit drei bis vier Bildschirmen flogen hin und her, in Gruppen-E-Mails und persönlichen, von Programmierern an Programmierer und Manager. Wie das oft der Fall ist, las außer den Autoren und ihren leidenschaftlichen Unterstützern niemand Briefe dieser Länge. Die Chats knisterten vor Anspannung und übermittelten in alle Richtungen umfangreiche Überlegungen zu den technischen Vorteilen von STL, wie gut sie getestet, sicher und überhaupt wie schön das Leben mit ihr ist, und wie schrecklich ohne sie.

Das Ganze zog sich ziemlich lange hin, bis ich schließlich begriff, dass wir die technischen Aspekte der Frage diskutierten, während das Problem in Wirklichkeit nicht technischer Natur war. Das Problem lag nicht in den Vorzügen oder Nachteilen von STL oder der Schwierigkeit, ohne sie zu arbeiten. Das Problem war eher organisatorischer Art. Wir mussten einfach verstehen, wie das Unternehmen strukturiert war, in dem wir arbeiteten. Zuvor hatte keiner von uns Erfahrung in einem solchen Unternehmen. Denn nach der Entwicklung des Codes und dessen Veröffentlichung in der Produktion übernahmen völlig andere Leute aus anderen Teams, aus anderen Ländern, den Support. Dieses riesige Ingenieurteam mit mehreren zehntausend Ingenieuren (insgesamt) konnte sich nur die grundlegendsten technischen Mittel leisten, sozusagen das Minimum minimorum. Alles, was über den Ingenieurstandard hinausging, der im Unternehmen etabliert war, konnte physisch nicht weiter unterstützt werden. Das Niveau des Teams wird durch das Niveau seiner schwächsten Mitglieder bestimmt. Nachdem wir verstanden hatten die tatsächliche Motivation der Handlungen des amerikanischen Teils des Teams, wurde diese Frage von der Agenda gestrichen, und wir entwickelten und veröffentlichten gemeinsam erfolgreich ein Produkt unter Verwendung der im Unternehmen geltenden Standards. In diesem Fall funktionierten E-Mails und Chats schlecht, um einen gemeinsamen Nenner zu finden, waren mehrere Reisen und viel persönlicher Kontakt erforderlich.

Aus Sicht des Arbeitsprozesses hätte in diesem speziellen Fall eine Beschreibung der verwendeten Mittel, der Anforderungen an diese, der Einschränkungen bei der Hinzufügung neuer Mittel und der Begründung solcher Einschränkungen hilfreich gewesen. Solche Dokumente entsprechen etwa den in den Punkten Reuse Strategy und Development Environment im Leitfaden „Manager’s Handbook for Software Development“ beschriebenen Aspekten, der entwickelt wurde in NASA. Trotz seines Alters beschreibt es hervorragend alle grundlegenden Aktivitäten und Phasen der Planung von Softwareentwicklungen dieser Art. Das Vorhandensein solcher Dokumente erleichtert den Diskussionsprozess darüber, welche Komponenten und Ansätze im Produkt verwendet werden können und warum.

Aus kultureller Sicht wäre es offensichtlich, dass bei einer reiferen Haltung, bei der die Parteien versuchen, die tatsächliche Motivation der Handlungen ihrer Kollegen zu hören und zu verstehen und aus den Prioritäten des Projekts und des Teams und nicht aus persönlichem Ego heraus handeln, Konflikte einfacher und schneller gelöst würden.

In einem anderen Konflikt über die Wahl einer technischen Lösung hat es ebenfalls einige Zeit gedauert, um die Motivation einer der Parteien zu verstehen (der Fall war wirklich ungewöhnlich), aber nachdem die Motivation klar war, war die Lösung offensichtlich.

Die Situation ist folgende: In einem Team von etwa 20 Personen kommt ein neuer Entwickler, nennen wir ihn Stas, dazu. Unser Standardkommunikationsmittel im Team war zu diesem Zeitpunkt Skype. Wie sich später herausstellte, war Stas ein großer Fan offener Standards und Open-Source-Software und nutzte nur Tools und Betriebssysteme, deren Quellcodes öffentlich verfügbar sind und die öffentlich dokumentierte Protokolle verwenden. Skype gehört nicht zu diesen Tools. Wir haben eine Menge Zeit mit Diskussionen über Vor- und Nachteile dieses Ansatzes, Versuche, Skype-Alternativen auf verschiedenen Betriebssystemen zu starten, und Stas' Versuchen, das Team zu überzeugen, auf andere Standards umzusteigen, damit er ihm persönlich per E-Mail schreiben, ihn persönlich anrufen oder ihm einen zweiten Computer speziell für Skype kaufen könnte, verbracht. Schließlich wurde mir klar, dass es sich dabei im Wesentlichen nicht um ein technisches oder organisatorisches Problem handelt, sondern um eine weltanschauliche Einstellung, sogar, man könnte sagen, um eine religiöse (für Stas). Selbst wenn wir Stas und Skype schließlich verbinden würden (worauf bereits mehrere Monate verwendet wurden), würde das Problem mit jedem nachfolgenden Tool erneut auftreten. Ich hatte keine realen Mittel, um die Weltanschauung von Stas zu ändern, und es gab keine Grundlage, um die Weltanschauung des Teams zu ändern, das in dieser Umgebung gut arbeitete. Der Mensch und das Unternehmen waren einfach orthogonal in ihren Weltanschauungen. In solchen Situationen ist eine organisatorische Lösung oft eine gute Option. Wir haben Stas in ein anderes Team versetzt, wo er besser integriert war.

Der Grund für diesen Konflikt liegt meiner Meinung nach im Missverhältnis zwischen der persönlichen Kultur einer bestimmten Person (die eine starke Meinung hat und nicht bereit ist, Kompromisse einzugehen) und der Kultur des Unternehmens. In diesem Fall ist das natürlich ein Fehler des Managers. Es war von Anfang an falsch, ihn für ein Projekt dieser Art einzuplanen. Stas wechselte letztendlich zu einem Projekt zur Entwicklung von Open-Source-Software und war dort sehr erfolgreich.

Ein gutes Beispiel für einen Konflikt, verursacht durch die gleichzeitig kindliche Haltung des Entwicklers und Mängel im Arbeitsprozess – eine Situation, in der der Entwickler und das QA-Team unterschiedliche Erwartungen bezüglich der Bereitschaft eines Features hatten, das an QA übergeben wurde, in Abwesenheit einer Definition von „done“. Der Entwickler war der Meinung, dass es ausreicht, den Code zu schreiben und das Feature über den Zaun zu QA zu werfen – dort werden sie sich schon darum kümmern. Übrigens war er ein recht erfahrener und reifer Programmierer, aber so war sein innerer Qualitätsgrad. QA war damit nicht einverstanden und verlangte, dass er ihnen zeigt und beschreibt, was er selbst überprüft hatte, und sie verlangten ein Test-Szenario von ihm. Sie hatten in der Vergangenheit bereits Probleme mit der Funktionalität von diesem Entwickler und wollten ihre Zeit nicht erneut verschwenden. Übrigens hatten sie recht – das Feature funktionierte tatsächlich nicht, der Code wurde vor der Übergabe an QA nicht geprüft.

Um die Situation zu klären, bat ich ihn, mir zu zeigen, dass alles tatsächlich funktioniert (es funktionierte nicht, und er musste es reparieren), wir sprachen mit dem Team und QA über die Definition von „done“ (wir machten sie nicht schriftlich, da wir den Prozess nicht zu bürokratisch gestalten wollten), und bald trennten wir uns von diesem Spezialisten (zu unser aller Erleichterung).

Aus Sicht des Arbeitsprozesses wären mögliche Verbesserungen in diesem Fall eine Definition von „done“, Anforderungen an die Begleitung jeder Funktion durch Unit- und Integrationstests sowie eine Beschreibung des vom Entwickler durchgeführten Tests. In einem unserer Projekte maßen wir den Testabdeckungsgrad während CI, und wenn der Abdeckungsgrad nach dem Hinzufügen eines Patches fiel, wurden die Tests als nicht bestanden markiert, d.h. neuer Code konnte nur bei Vorliegen neuer Tests hinzugefügt werden.

Ein weiteres typisches Beispiel für einen Konflikt, der eng mit der Organisation des Arbeitsprozesses verbunden ist. Wir haben ein Produkt, ein Entwicklungsteam für dieses Produkt, ein Support-Team und einen Kunden. Der Kunde hat Probleme mit dem Produkt und kontaktiert den Support. Der Support analysiert das Problem und erkennt, dass es im Produkt liegt, und leitet das Problem an das Produkt-Team weiter. Das Produkt-Team hat gerade viel zu tun, da ein Release bevorsteht, weshalb das Ticket mit dem Problem des Kunden, das unter den anderen Tickets bei dem Entwickler, dem es zugewiesen wurde, verloren gegangen ist, mehrere Wochen unbeaufsichtigt bleibt. Der Support denkt, dass der Entwickler an dem Problem des Kunden arbeitet. Der Kunde wartet und hofft, dass an seinem Problem gearbeitet wird. In Wirklichkeit passiert jedoch nichts. Nach einigen Wochen beschließt der Kunde schließlich, sich nach dem Fortschritt zu erkundigen und fragt den Support, wie es um die Sache steht. Der Support fragt die Entwicklung. Der Entwickler zuckt zusammen, schaut sich die Liste der Tickets an und entdeckt dort das Ticket des Kunden. Während er das Ticket liest, wird ihm klar, dass nicht genügend Informationen zur Lösung des Problems vorhanden sind, und dass er weitere Logs und Dumps benötigt. Der Support fragt den Kunden nach zusätzlichen Informationen. Und hier erkennt der Kunde, dass die ganze Zeit niemand an seinem Problem gearbeitet hat. Und es wird laut ...

In dieser Situation ist die Lösung des Konflikts ziemlich offensichtlich und geradlinig (das Produkt reparieren, die Dokumentation und Tests aktualisieren, den Kunden besänftigen, einen Hotfix herausbringen usw.). Es ist wichtig, den Arbeitsprozess zu analysieren und zu verstehen, wer für die Organisation der Interaktion zwischen den beiden Teams verantwortlich ist und warum diese Situation überhaupt möglich wurde. Es ist klar, dass im Prozess etwas repariert werden muss – jemand sollte die Gesamtübersicht proaktiv überwachen, ohne erinnert werden zu müssen. Tickets vom Kunden sollten sich unter den anderen Tickets der Entwickler abheben. Der Support sollte sehen, ob die Entwicklung derzeit an ihren Tickets arbeitet, und wenn nicht, wann sie beginnen kann und wann Ergebnisse zu erwarten sind. Support und Entwicklung sollten regelmäßig kommunizieren und den Status der Tickets besprechen, die Sammlung der für das Debugging notwendigen Informationen sollte so weit wie möglich automatisiert werden usw.

Wie im Krieg versucht der Gegner, an der Schnittstelle zwischen zwei Einheiten zuzuschlagen, so ist in der Arbeit der schwächste Punkt oft die Interaktion zwischen den Teams. Wenn die Manager für Support und Entwicklung ausreichend reif sind, können sie den Prozess selbst reparieren; wenn nicht, wird der Prozess weiterhin Konflikte und Probleme erzeugen, bis ein Manager eingreift, der die Situation beheben kann.

Ein weiteres typisches Beispiel, das ich immer wieder in verschiedenen Unternehmen erlebt habe, ist die Situation, in der ein Produkt von einem Team entwickelt wird, automatisierte Integrationstests von einem zweiten Team und die Infrastruktur, auf der alles betrieben wird, von einem dritten Team betreut wird. Probleme beim Durchführen der Tests treten ständig auf, und die Ursachen für diese Probleme können sowohl das Produkt als auch die Tests und die Infrastruktur sein. Es ist oft problematisch, sich darüber zu einigen, wer die erste Problemanalyse durchführen, Bugs melden und die Protokolle des Produkts, der Tests und der Infrastruktur auswerten sollte. Konflikte sind hier häufig und gleichzeitig einheitlich. In Fällen mit intensiven Emotionen fallen die Beteiligten oft in eine kindliche Position zurück und beginnen Diskussionen in der Art von: „Warum sollte ich mich damit befassen?“, „Bei ihnen geht es öfter kaputt“ usw.

Aus Sicht des Arbeitsprozesses hängen die konkreten Schritte zur Lösung des Problems von der Zusammensetzung der Teams, der Art der Tests und des Produkts usw. ab. In einem unserer Projekte haben wir regelmäßige Bereitschaftsdienste eingeführt, bei denen die Teams wöchentlich abwechselnd die Tests überwacht haben. In einem anderen wurden die ersten Analysen immer von den Testentwicklern durchgeführt, aber diese Analysen waren ziemlich grundlegend und das Produkt ziemlich stabil, sodass das ganz gut funktionierte. Das Wichtigste ist, Transparenz im Prozess zu gewährleisten, klare Erwartungen für alle Beteiligten zu schaffen und ein Gefühl von Fairness für alle zu vermitteln.

Ist ein Konflikt in einer Organisation überhaupt ein Problem? Ist es ein schlechtes Zeichen, dass in Ihrem Team oft (oder zumindest gelegentlich) Konflikte auftreten? Im Allgemeinen ist dies nicht der Fall, denn wenn es Wachstum und Entwicklung gibt, gibt es Fragen, die zuvor nie geklärt wurden, und beim Klären solcher Fragen können Konflikte entstehen. Dies ist ein Indikator dafür, dass es Bereiche gibt, auf die man achten sollte und dass es Raum für Verbesserungen gibt. Schlecht ist es, wenn Konflikte sehr häufig auftreten und schwierig oder langwierig gelöst werden. Dies ist wahrscheinlich ein Zeichen für nicht ausreichend optimierte Arbeitsprozesse und mangelnde Reife des Teams.

Quelle: habr.com