Teamkonflikte managen – Balanceakt oder Notwendigkeit?

Epigraph:
Eines Tages trafen sich im Wald der Igel und der Bär.
— Hallo, Igel!
— Hallo, Bärchen!
So kam es, dass der Igel von Bärchen einen Schlag ins Gesicht bekam …

Hier finden Sie die Überlegungen unseres Teamleiters sowie des Produktentwicklungsleiters RAS – Igor Marnat über die Besonderheiten von Arbeitskonflikten und mögliche Methoden zu deren Management.

Die meisten Konflikte, denen wir bei der Arbeit begegnen, entwickeln sich nach einem ähnlichen Schema wie das oben im Epigraph Beschriebene. Es gibt mehrere Beteiligte, die ursprünglich recht wohlwollend zueinander eingestellt sind, doch sie versuchen, ein Problem zu lösen, das letztendlich ungelöst bleibt und die Beziehungen zwischen den Beteiligten aus unerklärlichen Gründen belastet.

Das Leben ist vielfältig und in dem oben beschriebenen Szenario gibt es Variationen. Manchmal sind die Beziehungen zwischen den Beteiligten von Anfang an nicht gut, manchmal gibt es nicht einmal eine Frage, die sofortige Klärung erfordert (wie zum Beispiel im Epigraphen). Manchmal bleiben die Beziehungen nach der Diskussion unverändert, obwohl das Thema letztendlich nicht gelöst wurde.

Was haben all diese Situationen, die als Konfliktsituation am Arbeitsplatz definiert werden können, gemeinsam?



Zunächst einmal ist die Anwesenheit von zwei oder mehr Parteien entscheidend. Diese Parteien können unterschiedliche Positionen innerhalb der Organisation einnehmen, in gleichwertigen Beziehungen zueinander stehen (wie Teamkollegen) oder sich auf verschiedenen Hierarchieebenen befinden (z. B. Vorgesetzter – Untergeordneter). Sie können individuell (Mitarbeiter) oder kollektiv (bei Konflikten zwischen einem Mitarbeiter und einem Team oder zwischen zwei Teams) sein, und so weiter. Der Konfliktrisiko und die Leichtigkeit seiner Lösung werden stark durch das Vertrauen zwischen den Beteiligten beeinflusst. Je besser die Parteien sich kennen und je höher das Vertrauen ist, desto wahrscheinlicher ist es, dass sie sich einigen können. Zum Beispiel haben Mitglieder eines verteilten Teams, die nie persönlich miteinander kommuniziert haben, ein höheres Risiko, in einen Konflikt über eine einfache Arbeitsfrage zu geraten, als die, die zumindest einige Male persönlich miteinander gesprochen haben. Daher ist es besonders wichtig, regelmäßige persönliche Treffen aller Teammitglieder in verteilten Teams zu gewährleisten.

Zweitens befinden sich die Parteien in einer Konfliktsituation am Arbeitsplatz in einer Lage, in der es darum geht, eine Angelegenheit zu klären, die für eine der Parteien, für beide oder für die Organisation als Ganzes von Bedeutung ist. Aufgrund der speziellen Gegebenheiten der Situation haben die Parteien in der Regel ausreichend Zeit und verschiedene Möglichkeiten, die Angelegenheit zu lösen (formelle und informelle Mittel, Treffen, Schreiben, Entscheidungen des Managements, die bestehenden Ziele und Pläne des Teams, sowie die Tatsache, dass es eine Hierarchie gibt usw.). Dies unterscheidet sich von der Lösung von Arbeitsfragen (oder nicht arbeitsbezogenen Fragen) innerhalb einer Organisation, verglichen mit der Klärung einer wichtigen Frage wie: „Hey, Kumpel, aus welchem Viertel kommst du?!“ auf der Straße oder dem Konflikt im Epigraph. Bei der Lösung einer Arbeitsfrage sind die Qualität der Arbeitsprozesse und die Kultur der Problemlösung im Team von Bedeutung.

Drittens ist ein entscheidender Faktor für den Konflikt (in Bezug auf unsere Diskussion) die Tatsache, dass die Parteien des Prozesses nicht in der Lage sind, selbstständig zu einer Lösung zu kommen, die für alle Beteiligten akzeptabel ist. Die Situation erfordert das Eingreifen eines Dritten, eines externen Schiedsrichters. Dieser Punkt mag umstritten erscheinen, aber im Wesentlichen ist es so, dass wenn eine Konfliktsituation erfolgreich ohne das Eingreifen eines externen Schiedsrichters gelöst wird und die Beziehungen der Parteien nicht verschlechtert werden, dies die Situation ist, nach der man streben sollte. Wahrscheinlich werden wir von einem solchen Konflikt nicht einmal erfahren oder nur zufällig nach dessen Lösung. Je mehr Fragen das Team selbstständig klären kann, desto effektiver wird es arbeiten.

Ein weiteres charakteristisches Merkmal von Konflikten, das es wert ist, angesprochen zu werden, ist der Grad der emotionalen Intensität bei der Lösung. Ein Konflikt muss nicht unbedingt mit einem hohen emotionalen Grad verbunden sein. Die Beteiligten müssen nicht schreien oder mit den Händen gestikulieren, damit die Situation im Grunde als konfliktbehaftet gilt. Wenn ein Problem nicht gelöst wird und ein gewisses emotionales Spannungsfeld vorhanden ist (vielleicht nicht offensichtlich nach außen), dann haben wir es mit einem Konflikt zu tun.

Sollte man sich überhaupt in Konfliktsituationen einmischen oder besser abwarten und hoffen, dass sich das Problem von selbst löst? Ja, es ist notwendig. Es liegt nicht immer in Ihrer Macht oder Kompetenz, einen Konflikt vollständig zu lösen, aber in jeder Situation, gleich welcher Größenordnung, können Sie eine verantwortungsvolle Rolle übernehmen und damit auch andere um sich herum dazu ermutigen, die negativen Folgen des Konflikts zu mildern und zur Lösung beizutragen.

Bevor wir uns einigen Beispielen für Konfliktsituationen zuwenden, wollen wir auf einige wichtige Punkte eingehen, die für alle Konflikte allgemein sind.

Bei der Lösung von Konflikten ist es wichtig, sich außerhalb des Geschehens zu positionieren, anstatt mitten im Geschehen zu sein (dies wird auch als "Meta-Position" bezeichnet). Das bedeutet, dass man nicht auf der Seite einer der Parteien stehen sollte. Andernfalls wird man anstelle eines neutralen Schlichters nur die Position einer Seite auf Kosten der anderen stärken. Bei der Entscheidung ist es entscheidend, dass alle Parteien das Ergebnis moralisch akzeptieren, sprich, 'es gekauft' haben. Auch wenn die Parteien nicht begeistert von der getroffenen Entscheidung sind, sollten sie sich zumindest aufrichtig bereit erklären, sie umzusetzen. Man könnte sagen, man sollte in der Lage sein, nicht einverstanden zu sein, aber sich dennoch zu verpflichten. Andernfalls wird der Konflikt lediglich seine Form ändern, und das schwelende Feuer wird unter der Oberfläche bleiben, um irgendwann unvermeidlich erneut zu entflammen.

Ein weiterer Punkt, der teilweise mit dem ersten verbunden ist – wenn Sie sich bereits entschieden haben, am Konfliktlösungsprozess teilzunehmen, nehmen Sie dies bitte ernst, insbesondere was Kommunikation und Kontextstudium betrifft. Sprechen Sie zunächst persönlich mit jeder Partei. Separat, und zwar mit jedem Einzelnen. Begnügen Sie sich nicht mit E-Mails. Bei verteilten Teams – sprechen Sie mindestens per Videoanruf. Vertrauen Sie nicht auf Gerüchte oder die Erzählungen von Zeugen. Verstehen Sie die Geschichte: Was will jede Partei, warum will sie das, welche Erwartungen hat sie, haben sie versucht, dieses Problem zuvor zu lösen, was passiert, wenn es nicht gelöst wird, welche Lösungsmöglichkeiten sehen sie, wie sehen sie die Position der anderen Partei, was halten sie für richtig oder falsch usw. Laden Sie alle möglichen Kontexte in Ihren Kopf, unvoreingenommen, in der Annahme, dass alle im Recht sind. Sie sind nicht im Konflikt, Sie stehen außerhalb davon, in einer Meta-Position. Wenn der Kontext nur im E-Mail-Thread verfügbar ist – lesen Sie zumindest den gesamten Thread sowie die zugehörigen Diskussionen und Dokumente. Nachdem Sie das gelesen haben – sprechen Sie trotzdem persönlich. Sie werden fast garantiert etwas Wichtiges hören, das in den E-Mails nicht enthalten ist.

Ein dritter wichtiger Punkt ist der allgemeine Ansatz zur Kommunikation. Das sind alltägliche Dinge, nichts Übermäßiges, aber sie haben eine enorme Bedeutung. Wir versuchen nicht, Zeit zu sparen, sondern kommunizieren mit allen Beteiligten, kritisieren nicht die Person, sondern betrachten die Konsequenzen ihres Handelns (nicht "du bist unhöflich", sondern "vielleicht sind die Leute von dieser Sache verletzt"), und lassen Raum für Gesichtswahrung. Diskussionen führen wir persönlich, nicht im Plenum.

Konflikte entstehen normalerweise aus einem von zwei Gründen. Der erste hat damit zu tun, ob sich die Person im Moment des Konflikts in der Erwachsenen- oder der Kinderrolle befindet (darüber später mehr). Dies hängt mit ihrer emotionalen Reife und der Fähigkeit zusammen, ihre Emotionen zu steuern (was übrigens nicht immer mit ihrem Alter zu tun hat). Der zweite häufige Grund ist die Unvollkommenheit der Arbeitsabläufe, die Situationen schafft, in denen Verantwortung zwischen den Beteiligten verwässert ist, die Erwartungen der Parteien nicht transparent sind und die Rollen im Prozess nicht klar definiert sind.

In einem Konflikt (wie bei jedem anderen Thema) sollte der Manager drei Perspektiven im Blick haben: die kurzfristige — das Problem oder den Konflikt hier und jetzt zu lösen, die mittelfristige — die Wahrscheinlichkeit eines ähnlichen Konflikts zu minimieren, und die langfristige — eine Kultur der Reife innerhalb des Teams zu fördern.

In jedem von uns gibt es ein inneres Kind, etwa drei oder vier Jahre alt. Die meiste Zeit schläft es bei der Arbeit, aber manchmal wacht es auf und übernimmt die Kontrolle. Das Kind hat seine eigenen Prioritäten. Es ist ihm wichtig, dass es seine Sandkiste ist, dass Mama es mehr liebt, und dass sein Auto das beste ist (das Design ist das beste, es programmiert am besten usw.). In Konfliktsituationen kann das Kind seine Spielzeuge umklammern, mit den Füßen stampfen und mit der Schaufel schlagen, aber es kann keine erwachsenen Fragen lösen (Architektur des Lösungsansatzes, Ansätze für automatisierte Tests, Fristen für Releases usw.), es denkt nicht in Bezug auf den Nutzen für das Team. Ein Kind im Konflikt kann ermutigt, getröstet und zum Schlafen geschickt werden, indem man es bittet, seinen Erwachsenen zu rufen. Vor Beginn einer Diskussion in einem Konflikt sollten Sie sicherstellen, dass Sie gerade mit dem Erwachsenen sprechen und nicht mit dem Kind, und selbst in der Position des Erwachsenen stehen. Wenn Ihr ehrliches Ziel in diesem Moment darin besteht, ein ernstes Problem zu lösen, befinden Sie sich in der Position eines Erwachsenen. Wenn Ihr Ziel darin besteht, mit den Füßen zu stampfen und mit der Schaufel zu schlagen – dann ist das die Position eines Kindes. Schicken Sie Ihr inneres Kind schlafen und rufen Sie den Erwachsenen, oder verschieben Sie die Diskussion. Der Mensch trifft emotionale Entscheidungen und sucht dann nach einer rationalen Begründung dafür. Eine Entscheidung, die vom Kind getroffen wird, basierend auf kindlichen Prioritäten, wird nicht optimal sein.

Neben dem Verhalten im Konfliktmoment zeichnet sich die kindliche oder erwachsene Position auch durch das Maß an Verantwortung aus, das eine Person bereit ist zu übernehmen. In extremen Fällen zeigt sich die kindliche Position eines Entwicklers, die ich häufig erlebt habe, so: Ich habe den Code geschrieben, ihn zur Überprüfung eingereicht – meine Arbeit ist damit erledigt. Die Reviewer müssen ihn ansehen und mergen, das QA-Team muss ihn testen; wenn Probleme auftreten, werden sie mich informieren. Merkwürdigerweise verhalten sich selbst recht erwachsene und erfahrene Personen manchmal auf diese Weise. Am anderen Ende der Skala steht die Person, die sich verantwortlich dafür hält, dass ihr Code funktioniert, von Tests abgedeckt ist, persönlich überprüft wurde, erfolgreich das Review durchlaufen hat (wenn nötig, kein Problem, die Reviewer zu kontaktieren, Fragen persönlich zu klären usw.) und gemergt wurde. Das QA-Team wird nach Bedarf unterstützt, Test-Szenarien werden beschrieben usw. In der Regel ist ein Entwickler entweder von Anfang an näher am erwachsenen Ende der Skala oder verschiebt sich dorthin mit zunehmender Erfahrung (sofern im Team eine passende Kultur gefördert wird). In extremen Fällen bleibt er jedoch in der Regel in der kindlichen Position, was bei ihm und dem Team gelegentlich zu Problemen und Konflikten führt.

Eine der wichtigsten Aufgaben eines Managers ist es, im Team eine positive, erwachsene Kultur zu fördern. Dies erfordert Zeit und tägliche Anstrengungen, aber es lohnt sich. Es gibt zwei Wege, die Teamkultur zu beeinflussen: durch persönliches Vorbild (dem die Teammitglieder definitiv folgen werden, da sie stets zum Leader aufblicken) und durch Diskussion und Förderung des richtigen Verhaltens. Hierbei gibt es nichts Übertriebenes oder zu Förmliches. Achten Sie beim Besprechen von Problemen darauf, was man anders hätte tun können, betonen Sie, wenn etwas richtig gelöst wurde, und loben Sie die Erfolge, beispielsweise bei der Durchsprache eines Releases.

Lassen Sie uns einige typische Konfliktsituationen betrachten, von einfachen bis hin zu komplexen:

Konflikte, die nicht mit der Arbeit zu tun haben

Häufig entstehen am Arbeitsplatz Konflikte, die nicht mit Arbeitsfragen zu tun haben. Ihr Auftreten und die Leichtigkeit ihrer Lösung stehen oft in direktem Zusammenhang mit dem emotionalen Intelligenzniveau der Beteiligten und deren Reife, und sie sind nicht vom Perfektionsgrad oder den Unzulänglichkeiten des Arbeitsprozesses abhängig.

Typische Beispiele sind: Jemand nutzt die Waschmaschine oder die Dusche nicht oft genug, was anderen missfällt. Manchmal ist es jemandem zu stickig, während ein anderer zugige Fenster bevorzugt. Jemand ist zu laut, während andere Ruhe zum Arbeiten brauchen, und so weiter. Bei Konflikten dieser Art sollte man nicht zögern und sie nicht sich selbst überlassen. Sie lösen sich nicht von selbst und stören täglich die Arbeit sowie das Teamklima. Glücklicherweise sind Lösungen oft nicht schwer zu finden – ein ruhiges Gespräch (natürlich unter vier Augen) mit einem Kollegen, der auf Hygiene verzichtet, kann helfen. Man kann auch die Sitzordnung so gestalten, dass diejenigen, die Ruhe oder einen kühleren Raum bevorzugen, komfortabel platziert werden. Darüber hinaus könnten schalldämpfende Kopfhörer oder Trennwände erworben werden, usw.

Ein weiteres Beispiel, das mir während meiner Arbeit mehrfach begegnet ist, ist die psychologische Inkompatibilität der Teammitglieder. Aus bestimmten Gründen können Menschen einfach nicht zusammenarbeiten, jede Kommunikation endet in einem Streit. Manchmal hängt das damit zusammen, dass die Menschen polar gegensätzliche Ansichten zu einem brisanten Thema (in der Regel politisch) vertreten und nicht in der Lage sind, diese außerhalb der Arbeit beiseite zu lassen. Sie zu überzeugen, einander zu tolerieren oder ihr Verhalten zu ändern, ist eine recht aussichtslose Aufgabe. Die einzige Ausnahme, die ich erlebt habe, sind junge Kollegen mit einer offenen Einstellung, deren Verhalten man durch regelmäßige Gespräche allmählich positiv beeinflussen kann. Üblicherweise wird das Problem erfolgreich gelöst, indem man sie in verschiedene Teams strukturiert oder zumindest sicherstellt, dass sie sich nur sehr selten über die Arbeit begegnen.

In all diesen Situationen sollte man mit allen beteiligten Personen persönlich sprechen, die Situation erörtern, herausfinden, ob sie das Problem überhaupt sehen, und fragen, welche Lösungen sie für möglich halten. Es ist wichtig, sie aktiv in den Entscheidungsprozess einzubeziehen.

In Bezug auf die Optimierung der Arbeitsabläufe (mittel- bis langfristige Perspektive, die ich erwähnt habe) gibt es hier nicht viel zu tun. Der einzige Punkt für die Optimierung besteht darin, den Kompatibilitätsfaktor bei der Teamzusammensetzung zu berücksichtigen und es zu vermeiden, Personen zusammenzustellen, die Konflikte verursachen werden.

In Bezug auf die Teamkultur treten solche Situationen viel seltener in Teams mit einer reifen Kultur auf, in denen die Mitglieder einander respektieren und in der Lage sind, Konflikte eigenständig zu lösen. Darüber hinaus werden solche Konflikte oft viel einfacher (häufig automatisch) in Teams gelöst, in denen ein hohes Maß an Vertrauen besteht, die Menschen schon lange zusammenarbeiten und/oder häufig außerhalb der Arbeit kommunizieren.

Konflikte im Zusammenhang mit Arbeitsfragen:

Solche Konflikte werden normalerweise durch beide Ursachen hervorgerufen: sowohl emotional (wenn einer der Beteiligten nicht aus einer erwachsenen Perspektive agiert) als auch durch Unzulänglichkeiten im Arbeitsprozess selbst. Die häufigste Art von Konflikten, die ich beobachtet 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 kein Code-Review von einem Kollegen erhalten. Der Patch wurde zur Überprüfung eingereicht, und es passiert nichts. Auf den ersten Blick scheint es keinen offensichtlichen Konflikt zwischen den beiden Parteien zu geben, 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 deutliches Unbehagen. Eine extremere Variante dieses Falls sind Entwicklungen in Communitys oder in verschiedenen Teams, wobei der Reviewer möglicherweise kein Interesse an diesem spezifischen Code hat. Aufgrund von Arbeitsbelastung oder anderen Umständen könnte er die Anfrage zur Überprüfung vollständig ignorieren, und einen externen Schlichter (einen Manager, der für beide Parteien zuständig ist) könnte es gar nicht geben.

Der Lösungsansatz für solche Situationen basiert auf einer langfristigen Perspektive und der Kultur von Erwachsenen. Zunächst einmal kommt es auf sinnvolles Engagement an. Erwarten Sie nicht, dass der Code, der zur Überprüfung ansteht, die Aufmerksamkeit des Reviewers von selbst auf sich zieht. Es ist wichtig, den Reviewern dabei zu helfen, ihn wahrzunehmen. Kontaktieren Sie ein paar Personen, stellen Sie eine Frage im Stand-up, beteiligen Sie sich an Diskussionen. Offensichtlich wird übermäßige Hartnäckigkeit eher schaden als nützen; hier ist gesundes Urteilsvermögen gefragt. Zweitens funktioniert eine gute Vorbereitung effektiv. Wenn das Team versteht, was und warum passiert, warum dieser Code überhaupt benötigt wird und das Design zuvor mit allen besprochen und abgestimmt wurde, werden die Personen eher geneigt sein, solchen Code zu beachten und weiterzuverarbeiten. Drittens spielt Autorität eine Rolle. Wenn Sie möchten, dass Ihr Code überprüft wird, führen Sie selbst viele Reviews durch. Machen Sie qualitativ hochwertige Reviews mit echten Prüfungen, tatsächlichen Tests und hilfreichen Kommentaren. Wenn Ihr Name im Team positiv bekannt ist, erhöht sich die Wahrscheinlichkeit, dass Ihr Code Beachtung findet.

Im Hinblick auf den Arbeitsprozess liegen die möglichen Verbesserungen darin, die Prioritäten richtig zu setzen, um dem Entwickler zu helfen, seine Ziele und die Ziele des Teams zu erreichen (andere Code-Reviews durchführen, E-Mails an die Community schreiben, den Code mit Architektur-, Dokumentations- und Testbeschreibungen zu begleiten, an Diskussionen in der Community teilnehmen usw.), lange Wartezeiten für Patches in der Warteschlange zu vermeiden und so weiter.

2) Ein zweiter häufiger Konfliktfall bei Code- oder Design-Reviews sind unterschiedliche Ansichten zu technischen Fragen, Codierstil und Auswahl von Werkzeugen. Das Vertrauensniveau zwischen den Beteiligten, die Zugehörigkeit zu einem Team und die gemeinsame Erfahrung spielen dabei eine enorme Rolle. Ein Stillstand tritt ein, wenn einer der Teilnehmer eine unkooperative Haltung einnimmt und nicht versucht, zu verstehen, was der Gesprächspartner ihm vermitteln möchte. Oft können sowohl der von der anderen Seite vorgeschlagene Ansatz als auch der ursprünglich vorgeschlagene Ansatz erfolgreich funktionieren, und es ist nicht entscheidend, welchen man wählt.

Eines Tages hat ein Programmierer aus meinem Team (wir nennen ihn Pasha) einen Patch mit Änderungen an dem Paketbereitstellungssystem vorbereitet, das von Kollegen aus einer benachbarten Abteilung entwickelt und betreut wurde. Einer von ihnen (Igor) hatte eine klare Vorstellung davon, wie die Linux-Dienste bei der Bereitstellung von Paketen konfiguriert werden sollten. Diese Meinung unterschied sich von dem Ansatz, der im Patch vorgeschlagen wurde, und eine Einigung war nicht möglich. Wie so oft drängten die Termine, und es war notwendig, zu einer Lösung zu kommen; jemand musste die Verantwortung übernehmen. Pasha erkannte an, dass beide Ansätze legitim waren, wollte aber, dass seine Variante zum Tragen kommt, da es keine klaren technischen Vorteile für einen der beiden Ansätze gab.

Unsere Diskussion verlief ungefähr so (sehr schematisch, natürlich dauerte das Gespräch eine halbe Stunde):

— Pasha, in ein paar Tagen ist Feature-Freeze. Es ist wichtig, dass wir alles zusammenstellen und so schnell wie möglich mit dem Testen beginnen. Wie kommen wir an Igor vorbei?
— Er möchte die Dienste anders einrichten, hat mir dazu viele Kommentare hinterlassen …
— Und was ist da, große Umstellungen, viel Arbeit?
— Nein, da sind nur ein paar Stunden Arbeit, aber am Ende ist es egal, es wird so oder so funktionieren, wozu das Ganze? Ich habe etwas Funktionierendes gemacht, lass uns das akzeptieren.
— Sag mal, wie lange diskutiert ihr das schon?
— Wir stehen schon seit anderthalb Wochen auf der Stelle.
— Ähm … können wir das Problem, das schon anderthalb Wochen besteht, nicht in ein paar Stunden lösen?
— Na ja, ich möchte nicht, dass Igor denkt, ich gebe nach …
— Sag mal, was ist dir wichtiger: das Release mit deiner Lösung zu veröffentlichen oder Igor zu übertreffen? Wenn wir ihn übertreffen, gibt es allerdings eine gute Chance, dass das Release scheitert.
— Naja … es wäre zwar ganz nett, Igor einen herabzusetzen, aber gut, das Release ist wichtiger, ich stimme zu.
— Ist dir wirklich so wichtig, was Igor denkt? Um ehrlich zu sein, es ist ihm ziemlich egal, er möchte nur einen einheitlichen Ansatz in den verschiedenen Bereichen, für die er verantwortlich ist.
— Okay, ich mache es, wie er in den Kommentaren verlangt hat, und dann fangen wir mit dem Testen an.
— Danke, Pasha! Ich war mir sicher, dass du von euch beiden der Vernünftigere bist, auch wenn Igor älter ist :)

Das Problem wurde gelöst, das Release wurde fristgerecht veröffentlicht. Pasha hatte kein besonderes Unbehagen, da er selbst die Lösung vorgeschlagen und umgesetzt hat. Igor war insgesamt zufrieden, da seine Meinung berücksichtigt und nach seinen Vorschlägen umgesetzt wurde.

Ein weiterer typischer Konflikt ist die Wahl zwischen technischen Lösungen/Bibliotheken/Ansätzen in einem 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 strikt gegen die Verwendung der STL (Standard Template Library) war. Diese Standardbibliothek vereinfacht die Entwicklung, und unser Team war daran sehr gewöhnt. Es stellte sich heraus, dass das Projekt deutlich näher an C als an C++ war, was die Motivation des Teams nicht gerade förderte, da das Management tatsächlich einige hochqualifizierte C++-Entwickler gewonnen hatte. Die amerikanische Teamhälfte, sowohl Ingenieure als auch Manager, arbeitete schon lange im Unternehmen und war an die bestehende Situation gewöhnt, was für sie in Ordnung war. Die russische Teamhälfte hingegen wurde erst vor wenigen Wochen, einschließlich mir, zusammengebracht. Diese Gruppe war absolut nicht bereit, von ihrem gewohnten Entwicklungsansatz Abstand zu nehmen.

Es begannen endlose schriftliche Diskussionen zwischen zwei Kontinenten, E-Mails, die drei bis vier Bildschirme lang waren, flogen hin und her, sowohl in Gruppenverteilern als auch persönlich, von Programmierern an Programmierer und Manager. Wie es oft der Fall ist, las niemand außer den Autoren und ihren leidenschaftlichen Unterstützern E-Mails dieser Länge. Die Chats quietschten vor Anspannung und übermittelten in alle Richtungen vielschichtige Überlegungen zu den technischen Vorteilen von STL, wie gut sie getestet und sicher ist, und wie wunderbar das Leben mit ihr ist und wie schrecklich ohne sie.

Das dauerte eine ganze Weile, bis ich schließlich verstand, dass wir die technischen Aspekte des Problems diskutieren, während die wirkliche Schwierigkeit gar nicht technischer Natur war. Es geht nicht um die Vorzüge oder Nachteile von STL oder die Herausforderungen, ohne es zu arbeiten. Die Problematik war eher organisatorischer Natur. Wir mussten einfach verstehen, wie die Firma strukturiert ist, in der wir arbeiteten. Keiner von uns hatte vorher Erfahrung in einem solchen Unternehmen. Das Problem war, dass nach der Entwicklung des Codes und der Veröffentlichung in der Produktion, die Wartung von völlig anderen Personen aus anderen Teams und Ländern übernommen wurde. Dieses riesige Ingenieurteam mit mehreren zehntausend Ingenieuren (insgesamt) konnte sich nur die absolut grundlegenden technischen Mittel leisten, sozusagen das Minimum minimorum. Alles, was über den Ingenieurstandard in der Firma hinausging, konnte physisch nicht weiter unterstützt werden. Das Niveau des Teams wird durch das Niveau seiner schwächsten Mitglieder bestimmt. Nachdem wir das verstanden hatten, die tatsächliche Motivation Aufgrund der Handlungen des amerikanischen Teils des Teams wurde diese Frage vom Tisch genommen, und wir haben gemeinsam erfolgreich ein Produkt entwickelt und veröffentlicht, das den in der Firma akzeptierten Standards entspricht. In diesem Fall funktionierten E-Mails und Chats nicht gut, um einen gemeinsamen Nenner zu finden; es bedurfte mehrerer Reisen und intensiver persönlicher Kommunikation.

Aus der Perspektive des Arbeitsablaufs hätte es in diesem speziellen Fall geholfen, eine Beschreibung der verwendeten Mittel, deren Anforderungen, Einschränkungen bei der Hinzufügung neuer Mittel und die Begründung solcher Einschränkungen zu haben. Solche Dokumente entsprechen in etwa dem, was in den Punkten zur Wiederverwendungsstrategie und zur Entwicklungsumgebung im Handbuch „Manager’s Handbook for Software Development“, das entwickelt wurde von NASA, beschrieben wird. Trotz seines Alters beschreibt es hervorragend alle wesentlichen Aktivitäten und Phasen der Planung der Entwicklung von Software dieser Art. Das Vorhandensein solcher Dokumente erleichtert den Diskussionsprozess erheblich, da es klar macht, welche Komponenten und Ansätze im Produkt verwendet werden können und warum.

Kulturell betrachtet ist es offensichtlich, dass bei einer reiferen Haltung, bei der die Parteien versuchen, die tatsächlichen Beweggründe für die Handlungen ihrer Kollegen zu verstehen und entsprechend den Prioritäten des Projekts und des Teams zu handeln, anstatt aus persönlichem Ego, Konflikte einfacher und schneller gelöst werden könnten.

In einem anderen Konflikt, der durch die Wahl einer technischen Lösung entstand, benötigte ich ebenfalls eine erhebliche Zeit, um die Beweggründe einer der Parteien zu verstehen (es war ein sehr ungewöhnlicher Fall). Doch nachdem die Beweggründe klar waren, war die Lösung offensichtlich.

Die Situation ist folgende: In einem Team von etwa 20 Personen kommt ein neuer Entwickler hinzu, nennen wir ihn Stas. Zu diesem Zeitpunkt war unser Standardkommunikationsmittel Skype. Wie sich später herausstellte, war Stas ein großer Fan offener Standards und Open-Source-Software und benutzte nur Werkzeuge und Betriebssysteme, deren Quellcodes öffentlich zugänglich sind und die öffentlich beschriebene Protokolle verwenden. Skype gehört nicht zu diesen Werkzeugen. Wir haben viel Zeit damit verbracht, die Vor- und Nachteile dieses Ansatzes zu diskutieren, verschiedene Alternativen zu Skype auf unterschiedlichen Betriebssystemen zu testen, Stas zu überzeugen, das Team auf andere Standards umzustellen, ihn persönlich per E-Mail zu kontaktieren, ihn direkt anzurufen, ihm einen zweiten Computer speziell für Skype zu kaufen usw. Schließlich habe ich verstanden, dass dies ein Problem ist, das im Wesentlichen weder technischer noch organisatorischer Natur ist; es ist eher eine weltanschauliche, ja, man kann sagen, eine religiöse (für Stas). Selbst wenn wir Stas am Ende mit Skype verbunden hätten (was bereits mehrere Monate in Anspruch genommen hatte), würde dasselbe Problem bei jedem anderen Werkzeug wieder auftreten. Ich hatte keine realen Mittel zur Verfügung, um Stas' Weltanschauung zu ändern, und es gab keinen Grund, zu versuchen, die Weltanschauung des Teams zu ändern, das in dieser Umgebung hervorragend arbeitete. Mensch und Unternehmen waren in ihrer Weltanschauung schlicht orthogonal. In solchen Situationen ist eine organisatorische Lösung oft sinnvoll. Wir haben Stas in ein anderes Team versetzt, wo er besser integriert war.

Nach meiner Meinung liegt der Grund für diesen Konflikt in der Diskrepanz zwischen der persönlichen Kultur eines bestimmten Mitarbeiters (der eine starke Meinung hat, die ihm Kompromisse unmöglich macht) und der Unternehmenskultur. In diesem Fall ist das eindeutig ein Fehler des Managers. Es war von Anfang an falsch, ihn für ein Projekt dieser Art zu engagieren. Stattdessen wechselte Stas schließlich zu einem Projekt zur Entwicklung von Open-Source-Software und hat dort großartige Erfolge erzielt.

Ein gutes Beispiel für einen Konflikt, der gleichzeitig durch die kindliche Haltung des Entwicklers und Mängel im Arbeitsprozess verursacht wird – eine Situation, in der der Entwickler und das QA-Team unterschiedliche Erwartungen an die Fertigstellung einer Funktion hatten, die dem QA übergeben wurde, da es keine Definition of Done gab. Der Entwickler war der Meinung, dass es ausreicht, den Code zu schreiben und die Funktion einfach zum QA zu werfen – dort würden sie schon alles klären. Übrigens war er ein recht erfahrener Programmierer, doch hatte er einen gewissen internen Qualitätsstandard. Das QA-Team war damit nicht einverstanden und verlangte, dass er ihnen zeigt und beschreibt, was er selbst überprüft hat, und sie forderten ein Test-Szenario von ihm. In der Vergangenheit hatten sie bereits Probleme mit der Funktionalität dieses Entwicklers und wollten nicht noch einmal ihre Zeit vergeuden. Übrigens hatten sie recht – die Funktion funktionierte tatsächlich nicht, da er den Code vor der Übergabe an das QA nicht überprüft hatte.

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 über die Definition of Done, die wir nicht schriftlich festhielten, um den Prozess nicht zu sehr zu bürokratisieren. Mit diesem Spezialisten trennten wir uns bald darauf (zum allgemeinen Erleichterung).

In Bezug auf den Workflow könnten in diesem Fall Verbesserungen durch eine Definition of Done, Anforderungen an die Begleitung jeder Funktion mit Unit- und Integrationstests sowie eine Beschreibung der vom Entwickler durchgeführten Tests erzielt werden. In einem unserer Projekte maßen wir den Testabdeckungsgrad während des CI. Wenn der Abdeckungsgrad nach dem Hinzufügen eines Patches fiel, wurden die Tests als nicht bestanden markiert, was bedeutete, dass jeder neue Code nur dann hinzugefügt werden konnte, wenn neue Tests dafür vorhanden waren.

Ein typisches Beispiel für einen Konflikt, der eng mit der Organisation von Arbeitsabläufen 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 wendet sich an den Support. Der Support analysiert das Problem und stellt fest, dass das Problem im Produkt liegt, und leitet es an das Produktteam weiter. Das Produktteam hat viel zu tun, ein Release steht bevor, weshalb das Ticket mit dem Kundenproblem, das beim Entwickler unter den anderen Tickets „versteckt“ ist, mehrere Wochen unbeachtet bleibt. Der Support glaubt, dass der Entwickler am Problem des Kunden arbeitet. Der Kunde wartet und hofft, dass an seinem Problem gearbeitet wird. In Wirklichkeit passiert jedoch nichts. Nach einigen Wochen fragt der Kunde schließlich nach dem Fortschritt und erkundigt sich beim Support, wie es aussieht. Der Support fragt die Entwicklung. Der Entwickler zuckt zusammen, sieht sich die Ticketliste an und entdeckt das Ticket des Kunden. Beim Lesen des Kunden-Tickets wird ihm klar, dass nicht genügend Informationen zur Lösung des Problems vorliegen und dass er mehr Protokolle und Dumps benötigt. Der Support fordert zusätzliche Informationen vom Kunden an. Und hier realisiert der Kunde, dass all die Zeit niemand an seinem Problem gearbeitet hat. Und der Sturm wird losbrechen ...

In dieser Situation ist die Lösung des Konflikts ziemlich offensichtlich und geradlinig (Produkt reparieren, Dokumentation und Tests aktualisieren, den Kunden beschwichtigen, einen Hotfix veröffentlichen usw.). Wichtig ist es, den Arbeitsprozess zu analysieren und zu verstehen, wer für die Organisation der Zusammenarbeit zwischen den beiden Teams verantwortlich ist und warum eine solche Situation überhaupt möglich war. Es ist klar, dass während des Prozesses etwas behoben werden muss – jemand sollte das Gesamtbild proaktiv im Auge behalten, ohne dass Kunden anrufen müssen. Tickets vom Kunden sollten sich unter den anderen Tickets der Entwickler abheben. Der Support sollte sehen, ob die Entwicklung an seinen Tickets arbeitet; wenn nicht, wann sie damit beginnen kann und wann Ergebnisse zu erwarten sind. Der Support und die Entwicklung sollten regelmäßig kommunizieren und den Status der Tickets besprechen; die Sammlung der für die Fehlersuche benötigten Informationen sollte so weit wie möglich automatisiert sein usw.

Wie in einem Krieg versucht der Gegner, die Schwachstelle zwischen zwei Einheiten zu treffen, so ist in der Zusammenarbeit oft die Schnittstelle zwischen den Teams der sensibelste und anfälligste Bereich. Wenn die Support- und Entwicklungsteams ausreichend reif sind, können sie den Prozess selbstständig reparieren; andernfalls wird der Prozess weiterhin Konflikte und Probleme verursachen, bis ein Manager eingreift, der die Situation beheben kann.

Ein weiteres prägnantes Beispiel, das ich in verschiedenen Unternehmen immer wieder erlebt habe, ist die Situation, in der ein Produkt von einem Team entwickelt wird, automatisierte Integrationstests von einem anderen Team erstellt werden und die Infrastruktur, auf der alles läuft, von einem dritten Team betreut wird. Probleme bei den Testdurchläufen treten ständig auf, wobei sowohl das Produkt als auch die Tests und die Infrastruktur die Ursache sein können. Die Abstimmung darüber, wer die erste Analyse der Probleme durchführen, Bugs dokumentieren und die Protokolle des Produkts, der Tests und der Infrastruktur auswerten soll, gestaltet sich oft schwierig. Konflikte sind hier häufig und gleichzeitig einheitlich. Bei hohem emotionalen Druck fallen die Beteiligten häufig in eine kindliche Haltung zurück, und es beginnen Diskussionen in der Art von: 'Warum sollte ich mich damit beschäftigen?', 'Die haben öfter Probleme', usw.

In Bezug auf den Arbeitsablauf hängen die konkreten Schritte zur Problemlösung von der Zusammensetzung der Teams, der Art der Tests und dem Produkt ab, usw. In einem unserer Projekte haben wir regelmäßige Schichten eingeführt, bei denen die Teams wöchentlich abwechselnd die Tests überwacht haben. In einem anderen Projekt führten die Entwickler der Tests immer die erste Analyse durch, wobei diese jedoch recht grundlegend war und das Produkt ausreichend stabil, sodass dies gut funktionierte. Das Wichtigste ist, Transparenz im Prozess zu gewährleisten, die Erwartungen für alle Beteiligten klar zu definieren und ein Gefühl von Fairness in der Situation für alle Beteiligten zu schaffen.

Ist ein Konflikt in einer Organisation tatsächlich ein Problem? Ist es ein schlechtes Zeichen, dass in Ihrem Team häufig (oder zumindest gelegentlich) Konflikte auftreten? Im Allgemeinen nein, denn wenn es Wachstum, Entwicklung und Dynamik gibt, entstehen Fragen, die zuvor nie gelöst wurden, und bei deren Lösung können Konflikte auftreten. Dies ist ein Indikator dafür, dass bestimmte Bereiche Aufmerksamkeit benötigen und dass es Raum für Verbesserungen gibt. Es ist jedoch schlecht, wenn Konflikte sehr häufig auftreten und schwer oder lange gelöst werden. Das deutet wahrscheinlich auf unzureichend optimierte Arbeitsprozesse und eine mangelnde Reife des Teams hin.

Quelle: habr.com