<\/a><\/noindex>Zweitens befinden sich die Parteien in einer Konfliktsituation am Arbeitsplatz in einer Lage, in der es darum geht, eine Angelegenheit zu kl\u00e4ren, die f\u00fcr eine der Parteien, f\u00fcr beide oder f\u00fcr die Organisation als Ganzes von Bedeutung ist. Aufgrund der speziellen Gegebenheiten der Situation haben die Parteien in der Regel ausreichend Zeit und verschiedene M\u00f6glichkeiten, die Angelegenheit zu l\u00f6sen (formelle und informelle Mittel, Treffen, Schreiben, Entscheidungen des Managements, die bestehenden Ziele und Pl\u00e4ne des Teams, sowie die Tatsache, dass es eine Hierarchie gibt usw.). Dies unterscheidet sich von der L\u00f6sung von Arbeitsfragen (oder nicht arbeitsbezogenen Fragen) innerhalb einer Organisation, verglichen mit der Kl\u00e4rung einer wichtigen Frage wie: \u201eHey, Kumpel, aus welchem Viertel kommst du?!\u201c auf der Stra\u00dfe oder dem Konflikt im Epigraph. Bei der L\u00f6sung einer Arbeitsfrage sind die Qualit\u00e4t der Arbeitsprozesse und die Kultur der Probleml\u00f6sung im Team von Bedeutung.<\/p>\n
Drittens ist ein entscheidender Faktor f\u00fcr den Konflikt (in Bezug auf unsere Diskussion) die Tatsache, dass die Parteien des Prozesses nicht in der Lage sind, selbstst\u00e4ndig zu einer L\u00f6sung zu kommen, die f\u00fcr 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\u00f6st 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\u00e4llig nach dessen L\u00f6sung. Je mehr Fragen das Team selbstst\u00e4ndig kl\u00e4ren kann, desto effektiver wird es arbeiten.<\/p>\n
Ein weiteres charakteristisches Merkmal von Konflikten, das es wert ist, angesprochen zu werden, ist der Grad der emotionalen Intensit\u00e4t bei der L\u00f6sung. Ein Konflikt muss nicht unbedingt mit einem hohen emotionalen Grad verbunden sein. Die Beteiligten m\u00fcssen nicht schreien oder mit den H\u00e4nden gestikulieren, damit die Situation im Grunde als konfliktbehaftet gilt. Wenn ein Problem nicht gel\u00f6st wird und ein gewisses emotionales Spannungsfeld vorhanden ist (vielleicht nicht offensichtlich nach au\u00dfen), dann haben wir es mit einem Konflikt zu tun.<\/p>\n
Sollte man sich \u00fcberhaupt in Konfliktsituationen einmischen oder besser abwarten und hoffen, dass sich das Problem von selbst l\u00f6st? Ja, es ist notwendig. Es liegt nicht immer in Ihrer Macht oder Kompetenz, einen Konflikt vollst\u00e4ndig zu l\u00f6sen, aber in jeder Situation, gleich welcher Gr\u00f6\u00dfenordnung, k\u00f6nnen Sie eine verantwortungsvolle Rolle \u00fcbernehmen und damit auch andere um sich herum dazu ermutigen, die negativen Folgen des Konflikts zu mildern und zur L\u00f6sung beizutragen.<\/p>\n
Bevor wir uns einigen Beispielen f\u00fcr Konfliktsituationen zuwenden, wollen wir auf einige wichtige Punkte eingehen, die f\u00fcr alle Konflikte allgemein sind.<\/p>\n
Bei der L\u00f6sung von Konflikten ist es wichtig, sich au\u00dferhalb 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\u00e4rken. 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\u00e4ren, sie umzusetzen. Man k\u00f6nnte sagen, man sollte in der Lage sein, nicht einverstanden zu sein, aber sich dennoch zu verpflichten. Andernfalls wird der Konflikt lediglich seine Form \u00e4ndern, und das schwelende Feuer wird unter der Oberfl\u00e4che bleiben, um irgendwann unvermeidlich erneut zu entflammen.<\/p>\n
Ein weiterer Punkt, der teilweise mit dem ersten verbunden ist \u2013 wenn Sie sich bereits entschieden haben, am Konfliktl\u00f6sungsprozess teilzunehmen, nehmen Sie dies bitte ernst, insbesondere was Kommunikation und Kontextstudium betrifft. Sprechen Sie zun\u00e4chst pers\u00f6nlich mit jeder Partei. Separat, und zwar mit jedem Einzelnen. Begn\u00fcgen Sie sich nicht mit E-Mails. Bei verteilten Teams \u2013 sprechen Sie mindestens per Videoanruf. Vertrauen Sie nicht auf Ger\u00fcchte oder die Erz\u00e4hlungen 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\u00f6sen, was passiert, wenn es nicht gel\u00f6st wird, welche L\u00f6sungsm\u00f6glichkeiten sehen sie, wie sehen sie die Position der anderen Partei, was halten sie f\u00fcr richtig oder falsch usw. Laden Sie alle m\u00f6glichen Kontexte in Ihren Kopf, unvoreingenommen, in der Annahme, dass alle im Recht sind. Sie sind nicht im Konflikt, Sie stehen au\u00dferhalb davon, in einer Meta-Position. Wenn der Kontext nur im E-Mail-Thread verf\u00fcgbar ist \u2013 lesen Sie zumindest den gesamten Thread sowie die zugeh\u00f6rigen Diskussionen und Dokumente. Nachdem Sie das gelesen haben \u2013 sprechen Sie trotzdem pers\u00f6nlich. Sie werden fast garantiert etwas Wichtiges h\u00f6ren, das in den E-Mails nicht enthalten ist.<\/p>\n
Ein dritter wichtiger Punkt ist der allgemeine Ansatz zur Kommunikation. Das sind allt\u00e4gliche Dinge, nichts \u00dcberm\u00e4\u00dfiges, 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\u00f6flich\", sondern \"vielleicht sind die Leute von dieser Sache verletzt\"), und lassen Raum f\u00fcr Gesichtswahrung. Diskussionen f\u00fchren wir pers\u00f6nlich, nicht im Plenum.<\/p>\n
Konflikte entstehen normalerweise aus einem von zwei Gr\u00fcnden. Der erste hat damit zu tun, ob sich die Person im Moment des Konflikts in der Erwachsenen- oder der Kinderrolle befindet (dar\u00fcber sp\u00e4ter mehr). Dies h\u00e4ngt mit ihrer emotionalen Reife und der F\u00e4higkeit zusammen, ihre Emotionen zu steuern (was \u00fcbrigens nicht immer mit ihrem Alter zu tun hat). Der zweite h\u00e4ufige Grund ist die Unvollkommenheit der Arbeitsabl\u00e4ufe, die Situationen schafft, in denen Verantwortung zwischen den Beteiligten verw\u00e4ssert ist, die Erwartungen der Parteien nicht transparent sind und die Rollen im Prozess nicht klar definiert sind. <\/p>\n
In einem Konflikt (wie bei jedem anderen Thema) sollte der Manager drei Perspektiven im Blick haben: die kurzfristige \u2014 das Problem oder den Konflikt hier und jetzt zu l\u00f6sen, die mittelfristige \u2014 die Wahrscheinlichkeit eines \u00e4hnlichen Konflikts zu minimieren, und die langfristige \u2014 eine Kultur der Reife innerhalb des Teams zu f\u00f6rdern. <\/p>\n
In jedem von uns gibt es ein inneres Kind, etwa drei oder vier Jahre alt. Die meiste Zeit schl\u00e4ft es bei der Arbeit, aber manchmal wacht es auf und \u00fcbernimmt die Kontrolle. Das Kind hat seine eigenen Priorit\u00e4ten. 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\u00fc\u00dfen stampfen und mit der Schaufel schlagen, aber es kann keine erwachsenen Fragen l\u00f6sen (Architektur des L\u00f6sungsansatzes, Ans\u00e4tze f\u00fcr automatisierte Tests, Fristen f\u00fcr Releases usw.), es denkt nicht in Bezug auf den Nutzen f\u00fcr das Team. Ein Kind im Konflikt kann ermutigt, getr\u00f6stet 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\u00f6sen, befinden Sie sich in der Position eines Erwachsenen. Wenn Ihr Ziel darin besteht, mit den F\u00fc\u00dfen zu stampfen und mit der Schaufel zu schlagen \u2013 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\u00fcndung daf\u00fcr. Eine Entscheidung, die vom Kind getroffen wird, basierend auf kindlichen Priorit\u00e4ten, wird nicht optimal sein.<\/p>\n
Neben dem Verhalten im Konfliktmoment zeichnet sich die kindliche oder erwachsene Position auch durch das Ma\u00df an Verantwortung aus, das eine Person bereit ist zu \u00fcbernehmen. In extremen F\u00e4llen zeigt sich die kindliche Position eines Entwicklers, die ich h\u00e4ufig erlebt habe, so: Ich habe den Code geschrieben, ihn zur \u00dcberpr\u00fcfung eingereicht \u2013 meine Arbeit ist damit erledigt. Die Reviewer m\u00fcssen ihn ansehen und mergen, das QA-Team muss ihn testen; wenn Probleme auftreten, werden sie mich informieren. Merkw\u00fcrdigerweise verhalten sich selbst recht erwachsene und erfahrene Personen manchmal auf diese Weise. Am anderen Ende der Skala steht die Person, die sich verantwortlich daf\u00fcr h\u00e4lt, dass ihr Code funktioniert, von Tests abgedeckt ist, pers\u00f6nlich \u00fcberpr\u00fcft wurde, erfolgreich das Review durchlaufen hat (wenn n\u00f6tig, kein Problem, die Reviewer zu kontaktieren, Fragen pers\u00f6nlich zu kl\u00e4ren usw.) und gemergt wurde. Das QA-Team wird nach Bedarf unterst\u00fctzt, Test-Szenarien werden beschrieben usw. In der Regel ist ein Entwickler entweder von Anfang an n\u00e4her am erwachsenen Ende der Skala oder verschiebt sich dorthin mit zunehmender Erfahrung (sofern im Team eine passende Kultur gef\u00f6rdert wird). In extremen F\u00e4llen bleibt er jedoch in der Regel in der kindlichen Position, was bei ihm und dem Team gelegentlich zu Problemen und Konflikten f\u00fchrt.<\/p>\n
Eine der wichtigsten Aufgaben eines Managers ist es, im Team eine positive, erwachsene Kultur zu f\u00f6rdern. Dies erfordert Zeit und t\u00e4gliche Anstrengungen, aber es lohnt sich. Es gibt zwei Wege, die Teamkultur zu beeinflussen: durch pers\u00f6nliches Vorbild (dem die Teammitglieder definitiv folgen werden, da sie stets zum Leader aufblicken) und durch Diskussion und F\u00f6rderung des richtigen Verhaltens. Hierbei gibt es nichts \u00dcbertriebenes oder zu F\u00f6rmliches. Achten Sie beim Besprechen von Problemen darauf, was man anders h\u00e4tte tun k\u00f6nnen, betonen Sie, wenn etwas richtig gel\u00f6st wurde, und loben Sie die Erfolge, beispielsweise bei der Durchsprache eines Releases.<\/p>\n
Lassen Sie uns einige typische Konfliktsituationen betrachten, von einfachen bis hin zu komplexen:<\/p>\n
Konflikte, die nicht mit der Arbeit zu tun haben<\/b><\/p>\n
H\u00e4ufig entstehen am Arbeitsplatz Konflikte, die nicht mit Arbeitsfragen zu tun haben. Ihr Auftreten und die Leichtigkeit ihrer L\u00f6sung stehen oft in direktem Zusammenhang mit dem emotionalen Intelligenzniveau der Beteiligten und deren Reife, und sie sind nicht vom Perfektionsgrad oder den Unzul\u00e4nglichkeiten des Arbeitsprozesses abh\u00e4ngig.<\/p>\n
Typische Beispiele sind: Jemand nutzt die Waschmaschine oder die Dusche nicht oft genug, was anderen missf\u00e4llt. Manchmal ist es jemandem zu stickig, w\u00e4hrend ein anderer zugige Fenster bevorzugt. Jemand ist zu laut, w\u00e4hrend andere Ruhe zum Arbeiten brauchen, und so weiter. Bei Konflikten dieser Art sollte man nicht z\u00f6gern und sie nicht sich selbst \u00fcberlassen. Sie l\u00f6sen sich nicht von selbst und st\u00f6ren t\u00e4glich die Arbeit sowie das Teamklima. Gl\u00fccklicherweise sind L\u00f6sungen oft nicht schwer zu finden \u2013 ein ruhiges Gespr\u00e4ch (nat\u00fcrlich 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\u00fchleren Raum bevorzugen, komfortabel platziert werden. Dar\u00fcber hinaus k\u00f6nnten schalld\u00e4mpfende Kopfh\u00f6rer oder Trennw\u00e4nde erworben werden, usw. <\/p>\n
Ein weiteres Beispiel, das mir w\u00e4hrend meiner Arbeit mehrfach begegnet ist, ist die psychologische Inkompatibilit\u00e4t der Teammitglieder. Aus bestimmten Gr\u00fcnden k\u00f6nnen Menschen einfach nicht zusammenarbeiten, jede Kommunikation endet in einem Streit. Manchmal h\u00e4ngt das damit zusammen, dass die Menschen polar gegens\u00e4tzliche Ansichten zu einem brisanten Thema (in der Regel politisch) vertreten und nicht in der Lage sind, diese au\u00dferhalb der Arbeit beiseite zu lassen. Sie zu \u00fcberzeugen, einander zu tolerieren oder ihr Verhalten zu \u00e4ndern, ist eine recht aussichtslose Aufgabe. Die einzige Ausnahme, die ich erlebt habe, sind junge Kollegen mit einer offenen Einstellung, deren Verhalten man durch regelm\u00e4\u00dfige Gespr\u00e4che allm\u00e4hlich positiv beeinflussen kann. \u00dcblicherweise wird das Problem erfolgreich gel\u00f6st, indem man sie in verschiedene Teams strukturiert oder zumindest sicherstellt, dass sie sich nur sehr selten \u00fcber die Arbeit begegnen.<\/p>\n
In all diesen Situationen sollte man mit allen beteiligten Personen pers\u00f6nlich sprechen, die Situation er\u00f6rtern, herausfinden, ob sie das Problem \u00fcberhaupt sehen, und fragen, welche L\u00f6sungen sie f\u00fcr m\u00f6glich halten. Es ist wichtig, sie aktiv in den Entscheidungsprozess einzubeziehen.<\/p>\n
In Bezug auf die Optimierung der Arbeitsabl\u00e4ufe (mittel- bis langfristige Perspektive, die ich erw\u00e4hnt habe) gibt es hier nicht viel zu tun. Der einzige Punkt f\u00fcr die Optimierung besteht darin, den Kompatibilit\u00e4tsfaktor bei der Teamzusammensetzung zu ber\u00fccksichtigen und es zu vermeiden, Personen zusammenzustellen, die Konflikte verursachen werden. <\/p>\n
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\u00e4ndig zu l\u00f6sen. Dar\u00fcber hinaus werden solche Konflikte oft viel einfacher (h\u00e4ufig automatisch) in Teams gel\u00f6st, in denen ein hohes Ma\u00df an Vertrauen besteht, die Menschen schon lange zusammenarbeiten und\/oder h\u00e4ufig au\u00dferhalb der Arbeit kommunizieren.<\/p>\n
Konflikte im Zusammenhang mit Arbeitsfragen:<\/b><\/p>\n
Solche Konflikte werden normalerweise durch beide Ursachen hervorgerufen: sowohl emotional (wenn einer der Beteiligten nicht aus einer erwachsenen Perspektive agiert) als auch durch Unzul\u00e4nglichkeiten im Arbeitsprozess selbst. Die h\u00e4ufigste Art von Konflikten, die ich beobachtet habe, sind Konflikte im Rahmen von Code-Reviews oder Architekturdiskussionen zwischen Entwicklern. <\/p>\n
Ich w\u00fcrde hier zwei typische F\u00e4lle hervorheben:<\/p>\n
1) Im ersten Fall kann der Entwickler kein Code-Review von einem Kollegen erhalten. Der Patch wurde zur \u00dcberpr\u00fcfung eingereicht, und es passiert nichts. Auf den ersten Blick scheint es keinen offensichtlichen Konflikt zwischen den beiden Parteien zu geben, aber bei n\u00e4herer Betrachtung handelt es sich durchaus um einen Konflikt. Das Arbeitsproblem bleibt ungel\u00f6st, 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\u00f6glicherweise kein Interesse an diesem spezifischen Code hat. Aufgrund von Arbeitsbelastung oder anderen Umst\u00e4nden k\u00f6nnte er die Anfrage zur \u00dcberpr\u00fcfung vollst\u00e4ndig ignorieren, und einen externen Schlichter (einen Manager, der f\u00fcr beide Parteien zust\u00e4ndig ist) k\u00f6nnte es gar nicht geben. <\/p>\n
Der L\u00f6sungsansatz f\u00fcr solche Situationen basiert auf einer langfristigen Perspektive und der Kultur von Erwachsenen. Zun\u00e4chst einmal kommt es auf sinnvolles Engagement an. Erwarten Sie nicht, dass der Code, der zur \u00dcberpr\u00fcfung 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 \u00fcberm\u00e4\u00dfige Hartn\u00e4ckigkeit eher schaden als n\u00fctzen; hier ist gesundes Urteilsverm\u00f6gen gefragt. Zweitens funktioniert eine gute Vorbereitung effektiv. Wenn das Team versteht, was und warum passiert, warum dieser Code \u00fcberhaupt ben\u00f6tigt 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\u00e4t eine Rolle. Wenn Sie m\u00f6chten, dass Ihr Code \u00fcberpr\u00fcft wird, f\u00fchren Sie selbst viele Reviews durch. Machen Sie qualitativ hochwertige Reviews mit echten Pr\u00fcfungen, tats\u00e4chlichen Tests und hilfreichen Kommentaren. Wenn Ihr Name im Team positiv bekannt ist, erh\u00f6ht sich die Wahrscheinlichkeit, dass Ihr Code Beachtung findet.<\/p>\n
Im Hinblick auf den Arbeitsprozess liegen die m\u00f6glichen Verbesserungen darin, die Priorit\u00e4ten richtig zu setzen, um dem Entwickler zu helfen, seine Ziele und die Ziele des Teams zu erreichen (andere Code-Reviews durchf\u00fchren, 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\u00fcr Patches in der Warteschlange zu vermeiden und so weiter. <\/p>\n
2) Ein zweiter h\u00e4ufiger Konfliktfall bei Code- oder Design-Reviews sind unterschiedliche Ansichten zu technischen Fragen, Codierstil und Auswahl von Werkzeugen. Das Vertrauensniveau zwischen den Beteiligten, die Zugeh\u00f6rigkeit 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\u00e4chspartner ihm vermitteln m\u00f6chte. Oft k\u00f6nnen sowohl der von der anderen Seite vorgeschlagene Ansatz als auch der urspr\u00fcnglich vorgeschlagene Ansatz erfolgreich funktionieren, und es ist nicht entscheidend, welchen man w\u00e4hlt. <\/p>\n
Eines Tages hat ein Programmierer aus meinem Team (wir nennen ihn Pasha) einen Patch mit \u00c4nderungen 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\u00f6glich. Wie so oft dr\u00e4ngten die Termine, und es war notwendig, zu einer L\u00f6sung zu kommen; jemand musste die Verantwortung \u00fcbernehmen. Pasha erkannte an, dass beide Ans\u00e4tze legitim waren, wollte aber, dass seine Variante zum Tragen kommt, da es keine klaren technischen Vorteile f\u00fcr einen der beiden Ans\u00e4tze gab. <\/p>\n
Unsere Diskussion verlief ungef\u00e4hr so (sehr schematisch, nat\u00fcrlich dauerte das Gespr\u00e4ch eine halbe Stunde): <\/p>\n
\u2014 Pasha, in ein paar Tagen ist Feature-Freeze. Es ist wichtig, dass wir alles zusammenstellen und so schnell wie m\u00f6glich mit dem Testen beginnen. Wie kommen wir an Igor vorbei?
Das Problem wurde gel\u00f6st, das Release wurde fristgerecht ver\u00f6ffentlicht. Pasha hatte kein besonderes Unbehagen, da er selbst die L\u00f6sung vorgeschlagen und umgesetzt hat. Igor war insgesamt zufrieden, da seine Meinung ber\u00fccksichtigt und nach seinen Vorschl\u00e4gen umgesetzt wurde.<\/p>\n
Ein weiterer typischer Konflikt ist die Wahl zwischen technischen L\u00f6sungen\/Bibliotheken\/Ans\u00e4tzen 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\u00f6hnt. Es stellte sich heraus, dass das Projekt deutlich n\u00e4her an C als an C++ war, was die Motivation des Teams nicht gerade f\u00f6rderte, da das Management tats\u00e4chlich einige hochqualifizierte C++-Entwickler gewonnen hatte. Die amerikanische Teamh\u00e4lfte, sowohl Ingenieure als auch Manager, arbeitete schon lange im Unternehmen und war an die bestehende Situation gew\u00f6hnt, was f\u00fcr sie in Ordnung war. Die russische Teamh\u00e4lfte hingegen wurde erst vor wenigen Wochen, einschlie\u00dflich mir, zusammengebracht. Diese Gruppe war absolut nicht bereit, von ihrem gewohnten Entwicklungsansatz Abstand zu nehmen.<\/p>\n
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\u00f6nlich, von Programmierern an Programmierer und Manager. Wie es oft der Fall ist, las niemand au\u00dfer den Autoren und ihren leidenschaftlichen Unterst\u00fctzern E-Mails dieser L\u00e4nge. Die Chats quietschten vor Anspannung und \u00fcbermittelten in alle Richtungen vielschichtige \u00dcberlegungen 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. <\/p>\n
Das dauerte eine ganze Weile, bis ich schlie\u00dflich verstand, dass wir die technischen Aspekte des Problems diskutieren, w\u00e4hrend die wirkliche Schwierigkeit gar nicht technischer Natur war. Es geht nicht um die Vorz\u00fcge 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\u00f6ffentlichung in der Produktion, die Wartung von v\u00f6llig anderen Personen aus anderen Teams und L\u00e4ndern \u00fcbernommen wurde. Dieses riesige Ingenieurteam mit mehreren zehntausend Ingenieuren (insgesamt) konnte sich nur die absolut grundlegenden technischen Mittel leisten, sozusagen das Minimum minimorum. Alles, was \u00fcber den Ingenieurstandard in der Firma hinausging, konnte physisch nicht weiter unterst\u00fctzt werden. Das Niveau des Teams wird durch das Niveau seiner schw\u00e4chsten Mitglieder bestimmt. Nachdem wir das verstanden hatten, die tats\u00e4chliche Motivation<\/i> Aufgrund der Handlungen des amerikanischen Teils des Teams wurde diese Frage vom Tisch genommen, und wir haben gemeinsam erfolgreich ein Produkt entwickelt und ver\u00f6ffentlicht, 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\u00f6nlicher Kommunikation.<\/p>\n
Im Hinblick auf den Arbeitsablauf w\u00fcrde es in diesem besonderen Fall helfen, eine Beschreibung der verwendeten Mittel, deren Anforderungen, Einschr\u00e4nkungen beim Hinzuf\u00fcgen neuer Mittel und eine Begr\u00fcndung f\u00fcr solche Einschr\u00e4nkungen zu haben. Solche Dokumente entsprechen etwa dem, was in den Punkten zur Wiederverwendungsstrategie und zur Entwicklungsumgebung im \u201eManager's Handbook for Software Development\u201c beschrieben ist, das in NASA<\/a><\/noindex>, beschrieben wird. Trotz seines Alters beschreibt es hervorragend alle wesentlichen Aktivit\u00e4ten 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\u00e4tze im Produkt verwendet werden k\u00f6nnen und warum.<\/p>\nKulturell betrachtet ist es offensichtlich, dass bei einer reiferen Haltung, bei der die Parteien versuchen, die tats\u00e4chlichen Beweggr\u00fcnde f\u00fcr die Handlungen ihrer Kollegen zu verstehen und entsprechend den Priorit\u00e4ten des Projekts und des Teams zu handeln, anstatt aus pers\u00f6nlichem Ego, Konflikte einfacher und schneller gel\u00f6st werden k\u00f6nnten.<\/p>\n
In einem anderen Konflikt, der durch die Wahl einer technischen L\u00f6sung entstand, ben\u00f6tigte ich ebenfalls eine erhebliche Zeit, um die Beweggr\u00fcnde einer der Parteien zu verstehen (es war ein sehr ungew\u00f6hnlicher Fall). Doch nachdem die Beweggr\u00fcnde klar waren, war die L\u00f6sung offensichtlich. <\/p>\n
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\u00e4ter herausstellte, war Stas ein gro\u00dfer Fan offener Standards und Open-Source-Software und benutzte nur Werkzeuge und Betriebssysteme, deren Quellcodes \u00f6ffentlich zug\u00e4nglich sind und die \u00f6ffentlich beschriebene Protokolle verwenden. Skype geh\u00f6rt 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 \u00fcberzeugen, das Team auf andere Standards umzustellen, ihn pers\u00f6nlich per E-Mail zu kontaktieren, ihn direkt anzurufen, ihm einen zweiten Computer speziell f\u00fcr Skype zu kaufen usw. Schlie\u00dflich 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\u00f6se (f\u00fcr Stas). Selbst wenn wir Stas am Ende mit Skype verbunden h\u00e4tten (was bereits mehrere Monate in Anspruch genommen hatte), w\u00fcrde dasselbe Problem bei jedem anderen Werkzeug wieder auftreten. Ich hatte keine realen Mittel zur Verf\u00fcgung, um Stas' Weltanschauung zu \u00e4ndern, und es gab keinen Grund, zu versuchen, die Weltanschauung des Teams zu \u00e4ndern, das in dieser Umgebung hervorragend arbeitete. Mensch und Unternehmen waren in ihrer Weltanschauung schlicht orthogonal. In solchen Situationen ist eine organisatorische L\u00f6sung oft sinnvoll. Wir haben Stas in ein anderes Team versetzt, wo er besser integriert war.<\/p>\n
Nach meiner Meinung liegt der Grund f\u00fcr diesen Konflikt in der Diskrepanz zwischen der pers\u00f6nlichen Kultur eines bestimmten Mitarbeiters (der eine starke Meinung hat, die ihm Kompromisse unm\u00f6glich macht) und der Unternehmenskultur. In diesem Fall ist das eindeutig ein Fehler des Managers. Es war von Anfang an falsch, ihn f\u00fcr ein Projekt dieser Art zu engagieren. Stattdessen wechselte Stas schlie\u00dflich zu einem Projekt zur Entwicklung von Open-Source-Software und hat dort gro\u00dfartige Erfolge erzielt.<\/p>\n
Ein gutes Beispiel f\u00fcr einen Konflikt, der gleichzeitig durch die kindliche Haltung des Entwicklers und M\u00e4ngel im Arbeitsprozess verursacht wird \u2013 eine Situation, in der der Entwickler und das QA-Team unterschiedliche Erwartungen an die Fertigstellung einer Funktion hatten, die dem QA \u00fcbergeben 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 \u2013 dort w\u00fcrden sie schon alles kl\u00e4ren. \u00dcbrigens war er ein recht erfahrener Programmierer, doch hatte er einen gewissen internen Qualit\u00e4tsstandard. Das QA-Team war damit nicht einverstanden und verlangte, dass er ihnen zeigt und beschreibt, was er selbst \u00fcberpr\u00fcft hat, und sie forderten ein Test-Szenario von ihm. In der Vergangenheit hatten sie bereits Probleme mit der Funktionalit\u00e4t dieses Entwicklers und wollten nicht noch einmal ihre Zeit vergeuden. \u00dcbrigens hatten sie recht \u2013 die Funktion funktionierte tats\u00e4chlich nicht, da er den Code vor der \u00dcbergabe an das QA nicht \u00fcberpr\u00fcft hatte. <\/p>\n
Um die Situation zu kl\u00e4ren, bat ich ihn, mir zu zeigen, dass alles tats\u00e4chlich funktioniert (es funktionierte nicht und er musste es reparieren). Wir sprachen mit dem Team \u00fcber die Definition of Done, die wir nicht schriftlich festhielten, um den Prozess nicht zu sehr zu b\u00fcrokratisieren. Mit diesem Spezialisten trennten wir uns bald darauf (zum allgemeinen Erleichterung).<\/p>\n
In Bezug auf den Workflow k\u00f6nnten 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\u00fchrten Tests erzielt werden. In einem unserer Projekte ma\u00dfen wir den Testabdeckungsgrad w\u00e4hrend des CI. Wenn der Abdeckungsgrad nach dem Hinzuf\u00fcgen eines Patches fiel, wurden die Tests als nicht bestanden markiert, was bedeutete, dass jeder neue Code nur dann hinzugef\u00fcgt werden konnte, wenn neue Tests daf\u00fcr vorhanden waren. <\/p>\n
Ein typisches Beispiel f\u00fcr einen Konflikt, der eng mit der Organisation von Arbeitsabl\u00e4ufen verbunden ist. Wir haben ein Produkt, ein Entwicklungsteam f\u00fcr 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 \u201eversteckt\u201c 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\u00dflich 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\u00fcgend Informationen zur L\u00f6sung des Problems vorliegen und dass er mehr Protokolle und Dumps ben\u00f6tigt. Der Support fordert zus\u00e4tzliche Informationen vom Kunden an. Und hier realisiert der Kunde, dass all die Zeit niemand an seinem Problem gearbeitet hat. Und der Sturm wird losbrechen ...<\/p>\n
In dieser Situation ist die L\u00f6sung des Konflikts ziemlich offensichtlich und geradlinig (Produkt reparieren, Dokumentation und Tests aktualisieren, den Kunden beschwichtigen, einen Hotfix ver\u00f6ffentlichen usw.). Wichtig ist es, den Arbeitsprozess zu analysieren und zu verstehen, wer f\u00fcr die Organisation der Zusammenarbeit zwischen den beiden Teams verantwortlich ist und warum eine solche Situation \u00fcberhaupt m\u00f6glich war. Es ist klar, dass w\u00e4hrend des Prozesses etwas behoben werden muss \u2013 jemand sollte das Gesamtbild proaktiv im Auge behalten, ohne dass Kunden anrufen m\u00fcssen. 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\u00e4\u00dfig kommunizieren und den Status der Tickets besprechen; die Sammlung der f\u00fcr die Fehlersuche ben\u00f6tigten Informationen sollte so weit wie m\u00f6glich automatisiert sein usw.<\/p>\n
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\u00e4lligste Bereich. Wenn die Support- und Entwicklungsteams ausreichend reif sind, k\u00f6nnen sie den Prozess selbstst\u00e4ndig reparieren; andernfalls wird der Prozess weiterhin Konflikte und Probleme verursachen, bis ein Manager eingreift, der die Situation beheben kann.<\/p>\n
Ein weiteres pr\u00e4gnantes 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\u00e4uft, von einem dritten Team betreut wird. Probleme bei den Testdurchl\u00e4ufen treten st\u00e4ndig auf, wobei sowohl das Produkt als auch die Tests und die Infrastruktur die Ursache sein k\u00f6nnen. Die Abstimmung dar\u00fcber, wer die erste Analyse der Probleme durchf\u00fchren, Bugs dokumentieren und die Protokolle des Produkts, der Tests und der Infrastruktur auswerten soll, gestaltet sich oft schwierig. Konflikte sind hier h\u00e4ufig und gleichzeitig einheitlich. Bei hohem emotionalen Druck fallen die Beteiligten h\u00e4ufig in eine kindliche Haltung zur\u00fcck, und es beginnen Diskussionen in der Art von: 'Warum sollte ich mich damit besch\u00e4ftigen?', 'Die haben \u00f6fter Probleme', usw. <\/p>\n
In Bezug auf den Arbeitsablauf h\u00e4ngen die konkreten Schritte zur Probleml\u00f6sung von der Zusammensetzung der Teams, der Art der Tests und dem Produkt ab, usw. In einem unserer Projekte haben wir regelm\u00e4\u00dfige Schichten eingef\u00fchrt, bei denen die Teams w\u00f6chentlich abwechselnd die Tests \u00fcberwacht haben. In einem anderen Projekt f\u00fchrten 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\u00e4hrleisten, die Erwartungen f\u00fcr alle Beteiligten klar zu definieren und ein Gef\u00fchl von Fairness in der Situation f\u00fcr alle Beteiligten zu schaffen.<\/p>\n
Ist ein Konflikt in einer Organisation tats\u00e4chlich ein Problem? Ist es ein schlechtes Zeichen, dass in Ihrem Team h\u00e4ufig (oder zumindest gelegentlich) Konflikte auftreten? Im Allgemeinen nein, denn wenn es Wachstum, Entwicklung und Dynamik gibt, entstehen Fragen, die zuvor nie gel\u00f6st wurden, und bei deren L\u00f6sung k\u00f6nnen Konflikte auftreten. Dies ist ein Indikator daf\u00fcr, dass bestimmte Bereiche Aufmerksamkeit ben\u00f6tigen und dass es Raum f\u00fcr Verbesserungen gibt. Es ist jedoch schlecht, wenn Konflikte sehr h\u00e4ufig auftreten und schwer oder lange gel\u00f6st werden. Das deutet wahrscheinlich auf unzureichend optimierte Arbeitsprozesse und eine mangelnde Reife des Teams hin.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u042d\u043f\u0438\u0433\u0440\u0430\u0444: \u0412\u0441\u0442\u0440\u0435\u0442\u0438\u043b\u0438\u0441\u044c \u043a\u0430\u043a-\u0442\u043e \u0432 \u043b\u0435\u0441\u0443 \u0401\u0436\u0438\u043a \u0438 \u041c\u0435\u0434\u0432\u0435\u0436\u043e\u043d\u043e\u043a. \u2014 \u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439, \u0401\u0436\u0438\u043a! \u2014 \u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439, \u041c\u0435\u0434\u0432\u0435\u0436\u043e\u043d\u043e\u043a! \u0422\u0430\u043a, \u0441\u043b\u043e\u0432\u043e \u0437\u0430 \u0441\u043b\u043e\u0432\u043e, \u0448\u0443\u0442\u043a\u0430 \u0437\u0430 \u0448\u0443\u0442\u043a\u043e\u0439, \u0438 \u043f\u043e\u043b\u0443\u0447\u0438\u043b \u0401\u0436\u0438\u043a \u043e\u0442 \u041c\u0435\u0434\u0432\u0435\u0436\u043e\u043d\u043a\u0430 \u043f\u043e \u043c\u043e\u0440\u0434\u0435 \u2026 \u041f\u043e\u0434 \u043a\u0430\u0442\u043e\u043c \u0440\u0430\u0441\u0441\u0443\u0436\u0434\u0435\u043d\u0438\u044f \u043d\u0430\u0448\u0435\u0433\u043e \u0442\u0438\u043c\u043b\u0438\u0434\u0430, \u0430 \u0442\u0430\u043a\u0436\u0435 \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440\u0430 \u043f\u043e \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044e \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430 RAS \u2014 \u0418\u0433\u043e\u0440\u044f \u041c\u0430\u0440\u043d\u0430\u0442\u0430 \u043e \u0441\u043f\u0435\u0446\u0438\u0444\u0438\u043a\u0435 \u0440\u0430\u0431\u043e\u0447\u0438\u0445 \u043a\u043e\u043d\u0444\u043b\u0438\u043a\u0442\u043e\u0432 \u0438 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u044b\u0445 \u043c\u0435\u0442\u043e\u0434\u0430\u0445 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u0438\u043c\u0438. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043a\u043e\u043d\u0444\u043b\u0438\u043a\u0442\u043e\u0432, […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27283,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[702],"tags":[],"class_list":["post-36457","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-novosti-interneta"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Teamkonflikte](\"\/wp-content\/uploads\/2019\/07\/de379c9eedec8cecda6651b5339a0277.jpg\")