<\/a><\/noindex>Zweitens befinden sich die Parteien in einem Konflikt am Arbeitsplatz in einer Situation, in der es darum geht, eine wichtige Frage zu kl\u00e4ren, die f\u00fcr eine der Parteien, f\u00fcr beide oder f\u00fcr die Organisation als Ganzes von Bedeutung ist. Aufgrund der Spezifit\u00e4t der Situation haben die Parteien in der Regel gen\u00fcgend Zeit und verschiedene M\u00f6glichkeiten zur L\u00f6sung (formelle, informelle, Meetings, Schreiben, Entscheidungen der Gesch\u00e4ftsf\u00fchrung, das Vorhandensein von Zielen und Pl\u00e4nen 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\u00f6st werden muss, zum Beispiel der wichtigen Frage: \"Hey, Kumpel, aus welchem Viertel kommst du?!\" auf der Stra\u00dfe oder dem Konflikt aus dem Epigraph. Bei der L\u00f6sung eines arbeitsbezogenen Problems sind die Qualit\u00e4t des Arbeitsprozesses und die Kultur der Probleml\u00f6sung im Team entscheidend.<\/p>\n
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\u00fcr alle Seiten akzeptablen L\u00f6sung 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\u00f6st wurde, ist das Problem erfolgreich gel\u00f6st 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\u00e4llig nach seiner L\u00f6sung. Je mehr Fragen das Team selbst l\u00f6sen kann, desto effizienter wird es arbeiten.<\/p>\n
Eine weitere charakteristische Eigenschaft eines Konflikts, die erw\u00e4hnenswert ist, ist der Grad der emotionalen Erregung w\u00e4hrend der L\u00f6sung. Ein Konflikt ist nicht unbedingt mit einem hohen emotionalen Grad verbunden. Es ist nicht notwendig, dass die Teilnehmer schreien und mit den H\u00e4nden fuchteln, damit die Situation im Wesentlichen konfliktbehaftet ist. Ein Problem wird nicht gel\u00f6st, ein gewisses emotionales Spannungsfeld ist dabei vorhanden (m\u00f6glicherweise wird es nach au\u00dfen hin nicht offensichtlich ausgedr\u00fcckt), was bedeutet, dass wir es mit einer Konfliktsituation zu tun haben.<\/p>\n
Sollte man \u00fcberhaupt in Konfliktsituationen eingreifen, oder ist es besser, sie sich selbst zu \u00fcberlassen und zu warten, bis das Problem von selbst verschwindet? Ja, sollte man. Es liegt nicht immer in Ihrer Macht oder Kompetenz, einen Konflikt vollst\u00e4ndig zu l\u00f6sen, aber in jeder Situation und bei Konflikten jeder Gr\u00f6\u00dfenordnung k\u00f6nnen Sie eine erwachsene Position einnehmen und damit auch andere um sich herum dazu bringen, das Gleiche zu tun. So k\u00f6nnen Sie die negativen Folgen des Konflikts mildern und zur L\u00f6sung beitragen.<\/p>\n
Bevor wir einige Beispiele f\u00fcr Konfliktsituationen betrachten, lassen Sie uns auf einige wichtige Punkte eingehen, die f\u00fcr alle Konflikte gelten.<\/p>\n
Bei der L\u00f6sung eines Konflikts ist es wichtig, \u00fcber 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\u00e4rken. 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\u00fchende Feuer wird unter der Asche bleiben und irgendwann unvermeidlich wieder aufflammen.<\/p>\n
Ein weiterer Punkt, der teilweise mit dem ersten verbunden ist \u2013 wenn Sie sich bereits an der L\u00f6sung eines Konflikts beteiligen, gehen Sie damit so ernsthaft wie m\u00f6glich mit Blick auf die Kommunikation und das Verst\u00e4ndnis des Kontexts um. Sprechen Sie pers\u00f6nlich mit jeder der Parteien. Zuerst getrennt mit jeder. Begn\u00fcgen Sie sich nicht mit E-Mails. Bei einem verteilten Team \u2013 sprechen Sie zumindest per Videokonferenz. Begn\u00fcgen Sie sich nicht mit Ger\u00fcchten und Erz\u00e4hlungen von Zeugen. Verstehen Sie die Geschichte, was jede der Parteien m\u00f6chte, warum sie das m\u00f6chte, was sie erwartet, ob sie versucht haben, dieses Thema zuvor zu l\u00f6sen, was passieren wird, wenn es nicht gel\u00f6st wird, welche L\u00f6sungsm\u00f6glichkeiten 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\u00f6glichen Kontext unverf\u00e4lscht in Ihren Kopf, in dem Sie annehmen, dass alle im Recht sind. Sie sind nicht im Konflikt, sondern au\u00dferhalb desselben, in einer Meta-Position. Wenn der Kontext nur in einem E-Mail-Thread verf\u00fcgbar ist, lesen Sie zumindest diesen und die damit verbundenen Diskussionsthreads und Dokumente vollst\u00e4ndig durch. Nachdem Sie gelesen haben \u2013 reden Sie trotzdem pers\u00f6nlich. So gut wie garantiert werden Sie etwas Wichtiges h\u00f6ren, das nicht in den E-Mails steht.<\/p>\n
Ein dritter wichtiger Punkt \u2013 der allgemeine Ansatz zur Kommunikation. Das sind allt\u00e4gliche Dinge, nichts Abgehobenes, aber sie haben eine sehr gro\u00dfe 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\u00f6flich', sondern 'vielleicht k\u00f6nnten die Leute sich \u00fcber diese Sache \u00e4rgern'), geben Sie ihnen die M\u00f6glichkeit, ihr Gesicht zu wahren, f\u00fchren Sie pers\u00f6nliche Diskussionen und nicht im Team.<\/p>\n
Konflikte entstehen normalerweise aus einem von zwei Gr\u00fcnden. Der erste h\u00e4ngt damit zusammen, ob sich eine Person im Moment des Konflikts in der Position eines Erwachsenen oder eines Kindes befindet (dar\u00fcber sp\u00e4ter mehr). Dies hat mit ihrer emotionalen Reife zu tun, mit der F\u00e4higkeit, ihre Emotionen zu steuern (was \u00fcbrigens nicht immer mit ihrem Alter zusammenh\u00e4ngt). Der zweite h\u00e4ufige Grund ist die Unzul\u00e4nglichkeit 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. <\/p>\n
Dementsprechend muss der Manager bei der Konfliktl\u00f6sung (wie auch bei jeder anderen Frage) drei Perspektiven im Blick haben: eine kurzfristige \u2013 um das Problem\/den Konflikt hier und jetzt zu l\u00f6sen, eine mittelfristige \u2013 um die Wahrscheinlichkeit eines erneuten Konflikts aus demselben Grund zu minimieren, und eine langfristige \u2013 um in der Mannschaft eine Kultur des Erwachsenseins zu f\u00f6rdern. <\/p>\n
In jedem von uns gibt es ein inneres Kind, etwa drei bis vier Jahre alt. Die meiste Zeit schl\u00e4ft es bei der Arbeit, wach aber manchmal auf und \u00fcbernimmt das Steuer. Das Kind hat seine eigenen Priorit\u00e4ten. 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, \u2026). In Konfliktsituationen kann das Kind mit Spielzeugen schubsen, stampfen und mit dem Schaufel zerschlagen, aber es kann keine erwachsenen Fragen l\u00f6sen (Architektur der L\u00f6sung, Ans\u00e4tze zum automatisierten Testen, Fristen f\u00fcr die Ver\u00f6ffentlichung usw.), es denkt nicht in Begriffen von Nutzen f\u00fcr das Team. Man kann das Kind in einem Konflikt ermutigen, tr\u00f6sten 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\u00f6sen, stehen Sie auf der Seite des Erwachsenen. Wenn Ihr Ziel darin besteht, zu stampfen und mit dem Schaufel zu schlagen \u2013 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\u00fcndung daf\u00fcr. Eine Entscheidung, die das Kind basierend auf seinen kindlichen Priorit\u00e4ten trifft, wird nicht optimal sein.<\/p>\n
Neben dem Verhalten im Konflikt wird die kindliche oder erwachsene Position auch durch das Ma\u00df an Verantwortung charakterisiert, das eine Person bereit ist zu \u00fcbernehmen. In extremen Auspr\u00e4gungen sieht die kindliche Position eines Programmierers, die ich mehrfach erlebt habe, so aus: Ich habe den Code geschrieben, ihn zur \u00dcberpr\u00fcfung geschickt \u2013 meine Arbeit ist getan. Die Reviewer m\u00fcssen ihn \u00fcberpr\u00fcfen und mergen, das QA-Team sollte es testen, wenn es Probleme gibt \u2013 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\u00fcr, dass ihr Code funktioniert, mit Tests abgedeckt ist, pers\u00f6nlich \u00fcberpr\u00fcft wurde, erfolgreich reviewed wurde (wenn n\u00f6tig, kein Problem, die Reviewer anzupingen, Fragen per Voice zu besprechen usw.) und gemerged wird. Das QA-Team erh\u00e4lt bei Bedarf Unterst\u00fctzung, Testf\u00e4lle werden beschrieben usw. In normalen F\u00e4llen befindet sich der Programmierer entweder von Anfang an n\u00e4her am erwachsenen Ende der Skala oder verschiebt sich dorthin mit zunehmender Erfahrung (vorausgesetzt, die richtige Kultur wird im Team gef\u00f6rdert). In extremen F\u00e4llen arbeitet er jedoch weiterhin meist aus einer kindlichen Position heraus, was gelegentlich zu Problemen und Konflikten f\u00fcr ihn und das Team f\u00fchrt.<\/p>\n
Die F\u00f6rderung einer richtigen, erwachsenen Kultur im Team ist eine wichtige Aufgabe jedes Managers. Sie erfordert viel Zeit und t\u00e4gliche Anstrengungen, aber das Ergebnis ist es wert. Es gibt zwei M\u00f6glichkeiten, die Kultur des Teams zu beeinflussen \u2013 das pers\u00f6nliche Beispiel (dem stets gefolgt wird, das Team schaut immer auf den Leader) und die Diskussion und F\u00f6rderung des richtigen Verhaltens. Auch hier gibt es nichts Kompliziertes oder Formalistisches, einfach beim Diskutieren von Problemen darauf hinweisen, was man h\u00e4tte anders machen k\u00f6nnen, betonen, dass man anerkannt hat, wenn etwas richtig gel\u00f6st wurde, loben, bei der Analyse von Releases anmerken usw.<\/p>\n
Betrachten wir einige typische Konfliktsituationen, von einfachen bis hin zu komplexen:<\/p>\n
Konflikte, die nicht mit Arbeitsfragen verbunden sind<\/b><\/p>\n
Relativ h\u00e4ufig treten am Arbeitsplatz Konflikte auf, die nicht mit Arbeitsfragen zusammenh\u00e4ngen. Ihr Auftreten und die Leichtigkeit ihrer L\u00f6sung stehen normalerweise in direktem Zusammenhang mit dem emotionalen Intelligenzgrad der Beteiligten, ihrem Erwachsenenalter und sind nicht mit der Vollkommenheit oder Unvollkommenheit des Arbeitsprozesses verbunden.<\/p>\n
Typische Beispiele sind, dass jemand die Waschmaschine oder die Dusche nicht oft genug benutzt, was den anderen missf\u00e4llt, jemandem ist es zu hei\u00df, w\u00e4hrend ein anderer einen Zug bekommt, wenn das Fenster ge\u00f6ffnet wird, jemand ist zu laut, w\u00e4hrend die anderen Ruhe zum Arbeiten ben\u00f6tigen, und so weiter. Konflikte dieser Art sollten nicht hinausgez\u00f6gert oder ignoriert werden. Sie l\u00f6sen sich nicht von selbst auf und lenken t\u00e4glich von der Arbeit ab und verderben die Atmosph\u00e4re im Team. Gl\u00fccklicherweise ist es normalerweise nicht zu schwierig, sie zu l\u00f6sen \u2013 es reicht, ruhig (nat\u00fcrlich unter vier Augen) mit dem Kollegen zu sprechen, der die Hygiene vernachl\u00e4ssigt, eine angenehme Sitzordnung f\u00fcr Leute zu gew\u00e4hrleisten, die Ruhe\/K\u00fchle bevorzugen, schalld\u00e4mpfende Kopfh\u00f6rer zu kaufen oder Trennw\u00e4nde aufzustellen, usw. <\/p>\n
Ein weiteres Beispiel, das ich w\u00e4hrend meiner Arbeit mehrmals erlebt habe, ist die psychologische Unvertr\u00e4glichkeit der Teammitglieder. Aus irgendwelchen Gr\u00fcnden k\u00f6nnen 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\u00f6hnlich politisch) vertreten und nicht wissen, wie sie diese au\u00dferhalb der Arbeit au\u00dfen vor lassen k\u00f6nnen. Sie davon zu \u00fcberzeugen, einander zu ertragen oder ihr Verhalten zu \u00e4ndern, ist eine Aussicht, die wenig Erfolg verspricht. Die einzige Ausnahme, die ich erlebt habe, sind junge Kollegen mit offenen Wahrnehmungen, deren Verhalten man allm\u00e4hlich durch regelm\u00e4\u00dfige Gespr\u00e4che \u00e4ndern kann. In der Regel l\u00e4sst sich das Problem erfolgreich l\u00f6sen, indem man sie in verschiedene Teams aufteilt oder zumindest sicherstellt, dass sie sehr selten beruflich aufeinandertreffen.<\/p>\n
In all den genannten Situationen sollte jeder Teilnehmer pers\u00f6nlich angesprochen werden, um die Situation zu besprechen, zu erkundigen, ob sie das Problem in diesem Fall \u00fcberhaupt sehen, und zu fragen, welche ihrer Meinung nach L\u00f6sungsm\u00f6glichkeiten bestehen und sie in die Entscheidungsfindung einzubeziehen.<\/p>\n
In Bezug auf die Optimierung des Arbeitsprozesses (die mittelfristige Perspektive, die ich erw\u00e4hnt habe) ist hier nicht viel zu tun, der einzige Punkt zur Optimierung besteht darin, den Kompatibilit\u00e4tsfaktor bei der Teamzusammensetzung zu ber\u00fccksichtigen und im Voraus keine Menschen zusammenzustellen, die in Konflikt geraten werden. <\/p>\n
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\u00e4ndig zu l\u00f6sen. Zudem werden solche Konflikte viel einfacher (oft automatisch) in Teams gel\u00f6st, in denen das Vertrauen hoch ist, die Menschen lange zusammenarbeiten und\/oder oft au\u00dferhalb der Arbeit kommunizieren.<\/p>\n
Konflikte im Zusammenhang mit Arbeitsfragen:<\/b><\/p>\n
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\u00e4nglichkeiten des Arbeitsprozesses selbst. Die h\u00e4ufigste Art von Konflikten, die ich erlebt 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 keine Code-\u00dcberpr\u00fcfung von einem Kollegen erhalten. Der Patch wurde zur \u00dcberpr\u00fcfung gesendet, und es passiert nichts. Auf den ersten Blick gibt es keinen offensichtlichen Konflikt zwischen den beiden Parteien, 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 offensichtliches Unbehagen. Eine extreme Unterkategorie dieses Falls ist die Entwicklung in Communities oder in unterschiedlichen Teams, wobei der Reviewer m\u00f6glicherweise an diesem speziellen Code nicht interessiert ist, aufgrund von Arbeitsbelastung oder anderen Umst\u00e4nden m\u00f6glicherweise \u00fcberhaupt nicht auf die Anfrage zur \u00dcberpr\u00fcfung achtet, und ein externer Schiedsrichter (ein gemeinsamer Manager f\u00fcr beide Seiten) m\u00f6glicherweise \u00fcberhaupt nicht vorhanden ist. <\/p>\n
Der L\u00f6sungsansatz, der in dieser Situation hilft, bezieht sich auf eine langfristige Perspektive und die Kultur eines erwachsenen Menschen. Erstens funktioniert rationale Aktivit\u00e4t. Man sollte nicht erwarten, dass der Code, der zur \u00dcberpr\u00fcfung bereitgestellt wurde, von selbst die Aufmerksamkeit des Pr\u00fcfers auf sich zieht. Man muss den Pr\u00fcfern helfen, ihn zu bemerken. Kontaktiere ein paar Leute, stelle eine Frage im Meeting, nimm an Diskussionen teil. Es ist offensichtlich, dass Nervigkeit eher sch\u00e4dlich als hilfreich ist, daher sollte man gesunden Menschenverstand walten lassen. Zweitens funktioniert eine gute Vorbereitung. Wenn das Team versteht, was und warum passiert, wof\u00fcr dieser Code \u00fcberhaupt ben\u00f6tigt 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\u00e4t eine Rolle. Wenn du m\u00f6chtest, dass dein Code \u00fcberpr\u00fcft wird, mache viele Reviews selbst. F\u00fchre qualitativ hochwertige Reviews durch, mit echten Pr\u00fcfungen, echten Tests und n\u00fctzlichen Kommentaren. Wenn dein Name im Team positiv bekannt ist, hast du bessere Chancen, dass dein Code Aufmerksamkeit erregt.<\/p>\n
Aus der Sicht des Arbeitsprozesses gibt es m\u00f6gliche Verbesserungen wie die richtige Priorisierung, um dem Entwickler zu helfen, seine Ziele und die Ziele des Teams zu erreichen (andere \u00fcberpr\u00fcfen, 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\u00e4ngen bleiben, und so weiter. <\/p>\n
2) Ein weiterer h\u00e4ufiger Konfliktfall bei der \u00dcberpr\u00fcfung von Code oder Design sind unterschiedliche Sichtweisen auf technische Fragen, Kodierungsstil und Werkzeugauswahl. Dabei spielt das Vertrauen zwischen den Beteiligten, die Zugeh\u00f6rigkeit zu einem Team und die Erfahrung in der Zusammenarbeit eine gro\u00dfe Rolle. Eine Sackgasse entsteht, wenn einer der Beteiligten eine kindische Haltung einnimmt und nicht versucht, die Botschaft des Gespr\u00e4chspartners zu h\u00f6ren. Oft k\u00f6nnen sowohl der von der anderen Seite vorgeschlagene Ansatz als auch der urspr\u00fcngliche Ansatz erfolgreich sein und es ist grunds\u00e4tzlich unerheblich, welchen man w\u00e4hlt. <\/p>\n
Eines Tages bereitete ein Programmierer aus meinem Team (nennen wir ihn Pasha) einen Patch mit \u00c4nderungen am System f\u00fcr 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\u00fcber, 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\u00f6glich, sich zu einigen. Wie immer dr\u00e4ngten die Fristen, und es musste eine L\u00f6sung gefunden werden; jemand musste eine erwachsene Position einnehmen. Pasha r\u00e4umte ein, dass beide Ans\u00e4tze ihre Daseinsberechtigung hatten, wollte jedoch, dass seine Variante akzeptiert wurde, da es keine offensichtlichen technischen Vorteile f\u00fcr keinen der beiden Ans\u00e4tze gab. <\/p>\n
Unsere Diskussion sah etwa so aus (ziemlich schematisch, nat\u00fcrlich dauerte das Gespr\u00e4ch eine halbe Stunde): <\/p>\n
\u2014 Pasha, wir haben in ein paar Tagen Feature Freeze. Es ist wichtig, dass wir alles sammeln und so schnell wie m\u00f6glich mit dem Testen beginnen. Wie k\u00f6nnen wir an Igor vorbeikommen?
Das Problem wurde gel\u00f6st, das Release wurde p\u00fcnktlich ver\u00f6ffentlicht, Pasha war nicht besonders unzufrieden, da er selbst die L\u00f6sung vorgeschlagen und umgesetzt hat. Igor war insgesamt zufrieden, da seine Meinung ber\u00fccksichtigt wurde und es so umgesetzt wurde, wie er es vorgeschlagen hatte.<\/p>\n
Eine andere Art eines \u00e4hnlichen Konflikts besteht in der Wahl zwischen technischen L\u00f6sungen\/Bibliotheken\/Ans\u00e4tzen 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\u00f6hnt. Es stellte sich heraus, dass das Projekt viel n\u00e4her 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\u00e4lfte wurde erst vor wenigen Wochen, einschlie\u00dflich meiner Person, versammelt. Die russische Teilmannschaft war kategorisch dagegen, von ihrem gewohnten Entwicklungsansatz abzur\u00fccken.<\/p>\n
Es begannen endlose schriftliche Diskussionen zwischen zwei Kontinenten, Briefe mit drei bis vier Bildschirmen flogen hin und her, in Gruppen-E-Mails und pers\u00f6nlichen, von Programmierern an Programmierer und Manager. Wie das oft der Fall ist, las au\u00dfer den Autoren und ihren leidenschaftlichen Unterst\u00fctzern niemand Briefe dieser L\u00e4nge. Die Chats knisterten vor Anspannung und \u00fcbermittelten in alle Richtungen umfangreiche \u00dcberlegungen zu den technischen Vorteilen von STL, wie gut sie getestet, sicher und \u00fcberhaupt wie sch\u00f6n das Leben mit ihr ist, und wie schrecklich ohne sie. <\/p>\n
Das Ganze zog sich ziemlich lange hin, bis ich schlie\u00dflich begriff, dass wir die technischen Aspekte der Frage diskutierten, w\u00e4hrend das Problem in Wirklichkeit nicht technischer Natur war. Das Problem lag nicht in den Vorz\u00fcgen 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\u00f6ffentlichung in der Produktion \u00fcbernahmen v\u00f6llig andere Leute aus anderen Teams, aus anderen L\u00e4ndern, den Support. Dieses riesige Ingenieurteam mit mehreren zehntausend Ingenieuren (insgesamt) konnte sich nur die grundlegendsten technischen Mittel leisten, sozusagen das Minimum minimorum. Alles, was \u00fcber den Ingenieurstandard hinausging, der im Unternehmen etabliert war, konnte physisch nicht weiter unterst\u00fctzt werden. Das Niveau des Teams wird durch das Niveau seiner schw\u00e4chsten Mitglieder bestimmt. Nachdem wir verstanden hatten die tats\u00e4chliche Motivation<\/i> der Handlungen des amerikanischen Teils des Teams, wurde diese Frage von der Agenda gestrichen, und wir entwickelten und ver\u00f6ffentlichten 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\u00f6nlicher Kontakt erforderlich.<\/p>\n
Aus Sicht des Arbeitsablaufs w\u00fcrde es in diesem konkreten Fall helfen, eine Beschreibung der verwendeten Mittel, die Anforderungen an diese, die Beschr\u00e4nkungen f\u00fcr die Hinzuf\u00fcgung neuer und die Begr\u00fcndung solcher Beschr\u00e4nkungen zu haben. Solche Dokumente entsprechen etwa den in den Punkten Reuse Strategy und Development Environment des \u201eManager's Handbook for Software Development\u201c beschriebenen. NASA<\/a><\/noindex>. Trotz seines Alters beschreibt es hervorragend alle grundlegenden Aktivit\u00e4ten und Phasen der Planung von Softwareentwicklungen dieser Art. Das Vorhandensein solcher Dokumente erleichtert den Diskussionsprozess dar\u00fcber, welche Komponenten und Ans\u00e4tze im Produkt verwendet werden k\u00f6nnen und warum.<\/p>\nAus kultureller Sicht w\u00e4re es offensichtlich, dass bei einer reiferen Haltung, bei der die Parteien versuchen, die tats\u00e4chliche Motivation der Handlungen ihrer Kollegen zu h\u00f6ren und zu verstehen und aus den Priorit\u00e4ten des Projekts und des Teams und nicht aus pers\u00f6nlichem Ego heraus handeln, Konflikte einfacher und schneller gel\u00f6st w\u00fcrden.<\/p>\n
In einem anderen Konflikt \u00fcber die Wahl einer technischen L\u00f6sung hat es ebenfalls einige Zeit gedauert, um die Motivation einer der Parteien zu verstehen (der Fall war wirklich ungew\u00f6hnlich), aber nachdem die Motivation klar war, war die L\u00f6sung offensichtlich. <\/p>\n
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\u00e4ter herausstellte, war Stas ein gro\u00dfer Fan offener Standards und Open-Source-Software und nutzte nur Tools und Betriebssysteme, deren Quellcodes \u00f6ffentlich verf\u00fcgbar sind und die \u00f6ffentlich dokumentierte Protokolle verwenden. Skype geh\u00f6rt nicht zu diesen Tools. Wir haben eine Menge Zeit mit Diskussionen \u00fcber Vor- und Nachteile dieses Ansatzes, Versuche, Skype-Alternativen auf verschiedenen Betriebssystemen zu starten, und Stas' Versuchen, das Team zu \u00fcberzeugen, auf andere Standards umzusteigen, damit er ihm pers\u00f6nlich per E-Mail schreiben, ihn pers\u00f6nlich anrufen oder ihm einen zweiten Computer speziell f\u00fcr Skype kaufen k\u00f6nnte, verbracht. Schlie\u00dflich 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\u00f6nnte sagen, um eine religi\u00f6se (f\u00fcr Stas). Selbst wenn wir Stas und Skype schlie\u00dflich verbinden w\u00fcrden (worauf bereits mehrere Monate verwendet wurden), w\u00fcrde das Problem mit jedem nachfolgenden Tool erneut auftreten. Ich hatte keine realen Mittel, um die Weltanschauung von Stas zu \u00e4ndern, und es gab keine Grundlage, um die Weltanschauung des Teams zu \u00e4ndern, das in dieser Umgebung gut arbeitete. Der Mensch und das Unternehmen waren einfach orthogonal in ihren Weltanschauungen. In solchen Situationen ist eine organisatorische L\u00f6sung oft eine gute Option. Wir haben Stas in ein anderes Team versetzt, wo er besser integriert war.<\/p>\n
Der Grund f\u00fcr diesen Konflikt liegt meiner Meinung nach im Missverh\u00e4ltnis zwischen der pers\u00f6nlichen 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\u00fcrlich ein Fehler des Managers. Es war von Anfang an falsch, ihn f\u00fcr ein Projekt dieser Art einzuplanen. Stas wechselte letztendlich zu einem Projekt zur Entwicklung von Open-Source-Software und war dort sehr erfolgreich.<\/p>\n
Ein gutes Beispiel f\u00fcr einen Konflikt, verursacht durch die gleichzeitig kindliche Haltung des Entwicklers und M\u00e4ngel im Arbeitsprozess \u2013 eine Situation, in der der Entwickler und das QA-Team unterschiedliche Erwartungen bez\u00fcglich der Bereitschaft eines Features hatten, das an QA \u00fcbergeben wurde, in Abwesenheit einer Definition von \u201edone\u201c. Der Entwickler war der Meinung, dass es ausreicht, den Code zu schreiben und das Feature \u00fcber den Zaun zu QA zu werfen \u2013 dort werden sie sich schon darum k\u00fcmmern. \u00dcbrigens war er ein recht erfahrener und reifer Programmierer, aber so war sein innerer Qualit\u00e4tsgrad. QA war damit nicht einverstanden und verlangte, dass er ihnen zeigt und beschreibt, was er selbst \u00fcberpr\u00fcft hatte, und sie verlangten ein Test-Szenario von ihm. Sie hatten in der Vergangenheit bereits Probleme mit der Funktionalit\u00e4t von diesem Entwickler und wollten ihre Zeit nicht erneut verschwenden. \u00dcbrigens hatten sie recht \u2013 das Feature funktionierte tats\u00e4chlich nicht, der Code wurde vor der \u00dcbergabe an QA nicht gepr\u00fcft. <\/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 und QA \u00fcber die Definition von \u201edone\u201c (wir machten sie nicht schriftlich, da wir den Prozess nicht zu b\u00fcrokratisch gestalten wollten), und bald trennten wir uns von diesem Spezialisten (zu unser aller Erleichterung).<\/p>\n
Aus Sicht des Arbeitsprozesses w\u00e4ren m\u00f6gliche Verbesserungen in diesem Fall eine Definition von \u201edone\u201c, Anforderungen an die Begleitung jeder Funktion durch Unit- und Integrationstests sowie eine Beschreibung des vom Entwickler durchgef\u00fchrten Tests. In einem unserer Projekte ma\u00dfen wir den Testabdeckungsgrad w\u00e4hrend CI, und wenn der Abdeckungsgrad nach dem Hinzuf\u00fcgen eines Patches fiel, wurden die Tests als nicht bestanden markiert, d.h. neuer Code konnte nur bei Vorliegen neuer Tests hinzugef\u00fcgt werden. <\/p>\n
Ein weiteres typisches Beispiel f\u00fcr einen Konflikt, der eng mit der Organisation des Arbeitsprozesses 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 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\u00dft der Kunde schlie\u00dflich, 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\u00e4hrend er das Ticket liest, wird ihm klar, dass nicht gen\u00fcgend Informationen zur L\u00f6sung des Problems vorhanden sind, und dass er weitere Logs und Dumps ben\u00f6tigt. Der Support fragt den Kunden nach zus\u00e4tzlichen Informationen. Und hier erkennt der Kunde, dass die ganze Zeit niemand an seinem Problem gearbeitet hat. Und es wird laut ...<\/p>\n
In dieser Situation ist die L\u00f6sung des Konflikts ziemlich offensichtlich und geradlinig (das Produkt reparieren, die Dokumentation und Tests aktualisieren, den Kunden bes\u00e4nftigen, einen Hotfix herausbringen usw.). Es ist wichtig, den Arbeitsprozess zu analysieren und zu verstehen, wer f\u00fcr die Organisation der Interaktion zwischen den beiden Teams verantwortlich ist und warum diese Situation \u00fcberhaupt m\u00f6glich wurde. Es ist klar, dass im Prozess etwas repariert werden muss \u2013 jemand sollte die Gesamt\u00fcbersicht proaktiv \u00fcberwachen, ohne erinnert werden zu m\u00fcssen. 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\u00e4\u00dfig kommunizieren und den Status der Tickets besprechen, die Sammlung der f\u00fcr das Debugging notwendigen Informationen sollte so weit wie m\u00f6glich automatisiert werden usw.<\/p>\n
Wie im Krieg versucht der Gegner, an der Schnittstelle zwischen zwei Einheiten zuzuschlagen, so ist in der Arbeit der schw\u00e4chste Punkt oft die Interaktion zwischen den Teams. Wenn die Manager f\u00fcr Support und Entwicklung ausreichend reif sind, k\u00f6nnen sie den Prozess selbst reparieren; wenn nicht, wird der Prozess weiterhin Konflikte und Probleme erzeugen, bis ein Manager eingreift, der die Situation beheben kann.<\/p>\n
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\u00fchren der Tests treten st\u00e4ndig auf, und die Ursachen f\u00fcr diese Probleme k\u00f6nnen sowohl das Produkt als auch die Tests und die Infrastruktur sein. Es ist oft problematisch, sich dar\u00fcber zu einigen, wer die erste Problemanalyse durchf\u00fchren, Bugs melden und die Protokolle des Produkts, der Tests und der Infrastruktur auswerten sollte. Konflikte sind hier h\u00e4ufig und gleichzeitig einheitlich. In F\u00e4llen mit intensiven Emotionen fallen die Beteiligten oft in eine kindliche Position zur\u00fcck und beginnen Diskussionen in der Art von: \u201eWarum sollte ich mich damit befassen?\u201c, \u201eBei ihnen geht es \u00f6fter kaputt\u201c usw. <\/p>\n
Aus Sicht des Arbeitsprozesses h\u00e4ngen die konkreten Schritte zur L\u00f6sung des Problems von der Zusammensetzung der Teams, der Art der Tests und des Produkts usw. ab. In einem unserer Projekte haben wir regelm\u00e4\u00dfige Bereitschaftsdienste eingef\u00fchrt, bei denen die Teams w\u00f6chentlich abwechselnd die Tests \u00fcberwacht haben. In einem anderen wurden die ersten Analysen immer von den Testentwicklern durchgef\u00fchrt, aber diese Analysen waren ziemlich grundlegend und das Produkt ziemlich stabil, sodass das ganz gut funktionierte. Das Wichtigste ist, Transparenz im Prozess zu gew\u00e4hrleisten, klare Erwartungen f\u00fcr alle Beteiligten zu schaffen und ein Gef\u00fchl von Fairness f\u00fcr alle zu vermitteln.<\/p>\n
Ist ein Konflikt in einer Organisation \u00fcberhaupt 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\u00e4rt wurden, und beim Kl\u00e4ren solcher Fragen k\u00f6nnen Konflikte entstehen. Dies ist ein Indikator daf\u00fcr, dass es Bereiche gibt, auf die man achten sollte und dass es Raum f\u00fcr Verbesserungen gibt. Schlecht ist es, wenn Konflikte sehr h\u00e4ufig auftreten und schwierig oder langwierig gel\u00f6st werden. Dies ist wahrscheinlich ein Zeichen f\u00fcr nicht ausreichend optimierte Arbeitsprozesse und mangelnde Reife des Teams.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-news"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Konfliktmanagement](\"\/wp-content\/uploads\/2019\/07\/de379c9eedec8cecda6651b5339a0277.jpg\")