Motto:
Es war einmal, als sich der Igel und der kleine Bär im Wald trafen.
- Hallo, Igel!
- Hallo, kleiner Bär!
Wort für Wort, Witz für Witz wurde der Igel vom kleinen Bären ins Gesicht geschlagen ...
Nachfolgend finden Sie eine Diskussion unseres Teamleiters sowie des RAS-Produktentwicklungsdirektors Igor Marnat über die Besonderheiten von Arbeitskonflikten und mögliche Methoden zu deren Bewältigung.
Die meisten Konflikte, denen wir bei der Arbeit begegnen, entwickeln sich nach einem Szenario, das dem im obigen Epigraph beschriebenen ähnelt. Es gibt mehrere Teilnehmer, die einander zunächst recht wohlwollend gegenüberstehen; sie versuchen, ein Problem zu lösen, aber am Ende bleibt das Problem ungelöst, und aus irgendeinem Grund erweisen sich die Beziehungen zwischen den Diskussionsteilnehmern als gestört.
Das Leben ist vielfältig und das oben beschriebene Szenario kann variieren. Manchmal ist die Beziehung zwischen den Teilnehmern zunächst nicht sehr gut, manchmal gibt es nicht einmal ein Problem, das einer direkten Lösung bedarf (wie zum Beispiel im Epigraph), manchmal bleibt die Beziehung nach der Diskussion dieselbe wie vor Beginn, aber Das Problem ist letztendlich nicht gelöst.
Was ist allen Situationen gemeinsam, die als Arbeitskonfliktsituation definiert werden können?
Erstens gibt es zwei oder mehr Seiten. Эти стороны могут занимать различное место в организации, находиться в отношениях равенства (коллеги в команде), или на разных уровнях иерархии (начальник — подчинённый), быть индивидуальными (сотрудник) или групповыми (в случаях конфликта между сотрудником и командой или двумя командами), usw. Die Wahrscheinlichkeit eines Konflikts und die Leichtigkeit seiner Lösung werden stark vom Grad des Vertrauens zwischen den Beteiligten beeinflusst. Je besser die Parteien einander kennen, desto höher ist das Vertrauen, desto höher ist die Chance, dass sie zu einer Einigung kommen. Beispielsweise kommt es bei Mitgliedern eines verteilten Teams, die noch nie persönlich miteinander interagiert haben, eher zu Konflikten wegen eines einfachen Arbeitsproblems als bei Personen, die zumindest einige persönliche Interaktionen hatten. Daher ist es bei der Arbeit in verteilten Teams sehr wichtig, sicherzustellen, dass sich alle Teammitglieder regelmäßig persönlich treffen.
Zweitens befinden sich die Parteien in einer Konfliktsituation am Arbeitsplatz in der Situation, ein Problem zu lösen, das für eine der Parteien, für beide oder für die Organisation als Ganzes wichtig ist. Gleichzeitig verfügen die Parteien aufgrund der Besonderheiten der Situation in der Regel über genügend Zeit und verschiedene Möglichkeiten zur Lösung (formell, informell, Treffen, Briefe, Managemententscheidungen, Vorhandensein von Zielen und Plänen des Teams usw.). Tatsache einer Hierarchie usw.). Das unterscheidet sich von der Lösung eines arbeitsbezogenen (oder nicht arbeitsbezogenen) Problems in einer Organisation beispielsweise von der Lösung einer wichtigen Frage: „Äh, Junge, aus welcher Gegend kommst du?!“ auf der Straße oder der Konflikt aus dem Epigraph. Bei der Lösung eines Arbeitsproblems kommt es auf die Qualität des Arbeitsprozesses und die Lösungskultur im Team an.
Drittens ist der bestimmende Faktor des Konflikts (aus der Sicht unserer Diskussion) die Tatsache, dass die Prozessparteien nicht unabhängig voneinander zu einer für alle Parteien passenden Lösung des Problems kommen können. Die Situation erfordert das Eingreifen eines Dritten, eines externen Schiedsrichters. Dieser Punkt mag kontrovers erscheinen, aber im Wesentlichen ist es die Situation, die wir anstreben sollten, wenn die Konfliktsituation ohne das Eingreifen eines externen Schiedsrichters erfolgreich gelöst wurde, das Problem erfolgreich gelöst wurde und sich die Beziehungen der Parteien nicht verschlechterten . Von einem solchen Konflikt werden wir höchstwahrscheinlich gar nichts wissen, oder wir erfahren es zufällig, nachdem er gelöst ist. Je mehr Probleme ein Team alleine lösen kann, desto effektiver wird es sein.
Ein weiteres erwähnenswertes charakteristisches Merkmal des Konflikts ist der Grad der emotionalen Intensität während der Entscheidung. Konflikte sind nicht unbedingt mit einem hohen emotionalen Niveau verbunden. Die Teilnehmer müssen nicht schreien und mit den Armen wedeln, damit die Situation im Wesentlichen zu einem Konflikt wird. Das Problem ist nicht gelöst, es besteht eine gewisse emotionale Anspannung (vielleicht äußert sich diese nicht deutlich nach außen), was bedeutet, dass wir uns einer Konfliktsituation gegenübersehen.
Ist es überhaupt notwendig, in Konfliktsituationen einzugreifen, oder ist es besser, der Lösung ihren Lauf zu lassen und abzuwarten, bis sich das Problem von selbst löst? Müssen. Es liegt nicht immer in Ihrer Macht oder Kompetenz, den Konflikt vollständig zu lösen, aber in jeder Situation, in einem Konflikt jeglichen Ausmaßes können Sie eine erwachsene Position einnehmen und so mehrere weitere Menschen um sich herum dazu bringen, die negativen Folgen des Konflikts abzumildern Konflikte lösen und zu ihrer Lösung beitragen.
Bevor wir uns einige Beispiele für Konfliktsituationen ansehen, werfen wir einen Blick auf einige wichtige Punkte, die allen Konflikten gemeinsam sind.
Bei der Lösung eines Konflikts ist es wichtig, über dem Kampf zu stehen und nicht in ihm zu stehen (das nennt man auch „eine Metaposition einnehmen“), also nicht Teil einer der Parteien im Lösungsprozess zu sein. Andernfalls stärkt die Entscheidungsunterstützung durch einen externen Schiedsrichter nur die Position einer der Parteien zum Nachteil der anderen Partei. Wichtig bei der Entscheidungsfindung ist, dass sie von allen Beteiligten moralisch akzeptiert, also „erkauft“ wird, wie man sagt. Auch wenn die Parteien mit der getroffenen Entscheidung nicht zufrieden waren, stimmten sie zumindest aufrichtig zu, sie umzusetzen. Wie sie sagen, um anderer Meinung sein und sich verpflichten zu können. Sonst verändert sich der Konflikt lediglich in seiner Erscheinung, der Schwelbrand bleibt unter dem Torfmoor liegen und flammt irgendwann unweigerlich wieder auf.
Der zweite Punkt, der teilweise mit dem ersten zusammenhängt, besteht darin, dass Sie, wenn Sie sich bereits entschieden haben, an der Lösung des Konflikts mitzuwirken, diesen aus kommunikativer und kontextbezogener Sicht so ernst wie möglich nehmen. Sprechen Sie persönlich mit jeder der Parteien. Für den Anfang separat mit jedem. Geben Sie sich nicht mit der Post zufrieden. Im Falle eines verteilten Teams sprechen Sie zumindest per Videoschaltung. Geben Sie sich nicht mit Hörensagen und Augenzeugenberichten zufrieden. Verstehen Sie die Geschichte, was jede Seite will, warum sie es will, was sie erwartet, haben sie schon einmal versucht, dieses Problem zu lösen, was passieren wird, wenn es nicht gelöst wird, welche Lösungen sehen sie, wie stellen sie sich die Position der Partei vor? andere Seite, was denken sie, richtig oder falsch usw. Laden Sie unvoreingenommen den gesamten möglichen Kontext in Ihren Kopf und gehen Sie davon aus, dass alle Recht haben. Sie befinden sich nicht innerhalb des Konflikts, Sie befinden sich außerhalb davon, in einer Metaposition. Wenn der Kontext nur in einem Beitragsthread verfügbar ist, lesen Sie ihn zumindest vollständig und die dazugehörigen Threads und Dokumente. Nachdem Sie es gelesen haben, sprechen Sie immer noch mit Ihrer Stimme. Es ist fast garantiert, dass Sie etwas Wichtiges hören, das nicht in der Post enthalten ist.
Der dritte wichtige Punkt ist der allgemeine Ansatz zur Kommunikation. Das sind gewöhnliche Dinge, nichts Kosmisches, aber sie sind sehr wichtig. Wir versuchen nicht, Zeit zu sparen, wir reden mit allen Teilnehmern, wir kritisieren die Person nicht, aber wir denken über die Konsequenzen ihres Handelns nach (nicht „du bist unhöflich“, sondern „vielleicht sind die Jungs dadurch beleidigt). „Dieses Ding“), wir geben die Möglichkeit, das Gesicht zu wahren, wir führen Gespräche persönlich, nicht vor der Leitung.
Konflikte werden in der Regel durch einen von zwei Gründen verursacht. Die erste hängt damit zusammen, ob sich eine Person zum Zeitpunkt des Konflikts in der Position eines Erwachsenen oder in der Position eines Kindes befindet (mehr dazu weiter unten). Dies liegt an seiner emotionalen Reife, der Fähigkeit, mit seinen Emotionen umzugehen (was übrigens nicht immer mit seinem Alter zusammenhängt). Der zweite häufige Grund ist die Unvollkommenheit des Arbeitsprozesses, die zu Grauzonen führt, in denen die Verantwortung zwischen den Beteiligten verteilt ist, die Erwartungen der Parteien füreinander nicht transparent sind und die Rollen im Prozess verschwimmen.
Dementsprechend muss ein Manager bei der Lösung eines Konflikts (wie auch jedes anderen Problems) drei Perspektiven im Auge behalten: kurzfristig – um das Problem/Konflikt hier und jetzt zu lösen, mittelfristig – um die Wahrscheinlichkeit eines erneuten Konflikts zu minimieren Aus dem gleichen Grund und langfristig - um eine Erwachsenenkultur in der Teamperson zu kultivieren.
Jeder von uns hat ein inneres Kind, etwa drei oder vier Jahre alt. Bei der Arbeit schläft er die meiste Zeit, wacht aber manchmal auf und übernimmt die Kontrolle. Das Kind hat seine eigenen Prioritäten. Es ist ihm wichtig, darauf zu bestehen, dass dies sein Sandkasten ist, seine Mutter ihn mehr liebt, seine Maschine die beste ist (das Design ist das beste, er programmiert das Beste, ...). In einer Konfliktsituation kann ein Kind Spielzeug drücken, mit den Füßen stampfen und seinen Spatel knacken, aber es kann die Probleme von Erwachsenen nicht lösen (Lösungsarchitektur, Ansätze für automatisierte Tests, Veröffentlichungstermine usw.), es denkt nicht in Nutzen für das Team. Ein Kind im Konflikt kann ermutigt, getröstet und ins Bett geschickt werden, indem man es bittet, seinen Erwachsenen anzurufen. Bevor Sie ein Gespräch in einer Konfliktsituation beginnen, stellen Sie sicher, dass Sie mit einem Erwachsenen und nicht mit einem Kind sprechen und dass Sie sich selbst in der Position eines Erwachsenen befinden. Wenn Ihr ehrliches Ziel im Moment darin besteht, ein ernstes Problem zu lösen, befinden Sie sich in der Lage eines Erwachsenen. Wenn Ihr Ziel darin besteht, mit den Füßen zu stampfen und Ihr Schulterblatt zu knacken, ist dies eine kindische Position. Schicken Sie Ihr inneres Kind ins Bett und rufen Sie einen Erwachsenen an oder verschieben Sie das Gespräch. Eine Person trifft eine emotionale Entscheidung und sucht dann nach einer rationalen Rechtfertigung dafür. Eine Entscheidung, die ein Kind auf der Grundlage seiner Prioritäten trifft, wird nicht optimal sein.
Die Position eines Kindes oder Erwachsenen wird neben dem Verhalten im Konfliktfall auch durch das Maß an Verantwortung geprägt, das eine Person zu übernehmen bereit ist. In ihren extremen Erscheinungsformen sieht die kindische Position eines Programmierers, die ich mehr als einmal getroffen habe, so aus: Ich habe den Code geschrieben, ihn zur Überprüfung geschickt – meine Arbeit ist beendet. Prüfer sollten es überprüfen und genehmigen, die Qualitätssicherung sollte es prüfen. Wenn es Probleme gibt, werden sie mich darüber informieren. Seltsamerweise verhalten sich manchmal sogar ziemlich reife und erfahrene Menschen so. Das andere Ende der Skala ist, dass eine Person sich selbst dafür verantwortlich sieht, sicherzustellen, dass ihr Code funktioniert, durch Tests abgedeckt wird, von ihr persönlich überprüft wurde, die Überprüfung erfolgreich bestanden hat (falls erforderlich, gibt es kein Problem damit, Prüfer anzupingen und Probleme zu besprechen). B. per Sprache usw.) und unterdrückt wurde, wird die Qualitätssicherung bei Bedarf Hilfe leisten, Testszenarien werden beschrieben usw. Im Normalfall beginnt der Programmierer entweder näher am erwachsenen Ende der Skala oder bewegt sich mit zunehmender Erfahrung dorthin (vorausgesetzt, die richtige Kultur wird im Team gepflegt). Im Extremfall arbeitet er weiter, nimmt meist eine kindische Haltung ein, dann kommt es zwischen ihm und dem Team immer wieder zu Problemen und Konflikten.
Die Förderung der richtigen, ausgereiften Kultur in einem Team ist eine wichtige Aufgabe für jeden Manager. Es erfordert viel Zeit und täglichen Aufwand, aber das Ergebnis ist es wert. Es gibt zwei Möglichkeiten, die Teamkultur zu beeinflussen: mit gutem Beispiel voranzugehen (was auf jeden Fall befolgt wird; das Team orientiert sich immer an der Führungskraft) und das richtige Verhalten zu besprechen und zu belohnen. Hier gibt es auch nichts Abstruses oder sehr Formales, einfach bei der Diskussion von Problemen merken, dass man hier etwas hätte machen können, betonen, dass man gemerkt hat, wann es richtig entschieden wurde, Lob, Notiz beim Release-Review usw.
Betrachten wir einige typische Konfliktsituationen, von einfach bis komplex:
Konflikte, die nichts mit Arbeitsproblemen zu tun haben
Nicht selten kommt es zu Konflikten am Arbeitsplatz, die nichts mit der Arbeit zu tun haben. Ihr Auftreten und ihre einfache Lösung stehen in der Regel in direktem Zusammenhang mit dem Grad der emotionalen Intelligenz der Teilnehmer und ihrem Reifegrad und nicht mit der Perfektion oder Unvollkommenheit des Arbeitsprozesses.
Typische Beispiele: Jemand benutzt die Waschmaschine oder die Dusche nicht oft genug, was andere nicht mögen, jemand ist stickig, während andere Wind bekommen, wenn sie das Fenster öffnen, jemand ist zu laut und wieder andere brauchen Ruhe zum Arbeiten, und bald. Es ist besser, die Lösung solcher Konflikte nicht zu verzögern und ihnen nicht ihren Lauf zu lassen. Sie lösen sich nicht von allein, lenken Sie täglich von der Arbeit ab und vergiften die Atmosphäre im Team. Zum Glück ist die Lösung meist kein großes Problem – reden Sie einfach ruhig (natürlich im Einzelgespräch) mit einem Kollegen, der die Hygiene vernachlässigt, sorgen Sie für bequeme Sitzgelegenheiten für Menschen, die Stille/Kühle bevorzugen, kaufen Sie schallabsorbierende Kopfhörer oder installieren Sie Trennwände , usw.
Ein weiteres Beispiel, das mir im Laufe meiner Arbeit mehrfach begegnet ist, ist die psychische Inkompatibilität von Teammitgliedern. Aus irgendeinem Grund können Menschen einfach nicht zusammenarbeiten; jede Interaktion endet in einem Skandal. Manchmal liegt das daran, dass Menschen zu einem drängenden Thema (normalerweise politisch) gegensätzliche Ansichten vertreten und nicht wissen, wie sie diese aus der Arbeit heraushalten können. Sie davon zu überzeugen, einander zu tolerieren oder ihr Verhalten zu ändern, ist eine eher aussichtslose Aufgabe. Die einzige Ausnahme, auf die ich gestoßen bin, sind junge Kollegen mit einer offenen Wahrnehmung; ihr Verhalten kann durch regelmäßige Gespräche immer noch schrittweise geändert werden. Normalerweise lässt sich das Problem erfolgreich lösen, indem man sie in verschiedene Teams aufteilt oder zumindest sehr selten die Möglichkeit bietet, sich bei der Arbeit zu überschneiden.
In allen oben genannten Situationen lohnt es sich, mit allen Teilnehmern persönlich zu sprechen, die Situation zu besprechen, zu fragen, ob sie in diesem Fall überhaupt ein Problem sehen, welche ihrer Meinung nach Lösungsansätze vorliegen und ihre Beteiligung an der Umsetzung sicherzustellen Entscheidung.
Unter dem Gesichtspunkt der Optimierung des Arbeitsprozesses (der mittelfristigen Perspektive, die ich erwähnt habe) kann hier nicht viel getan werden; der einzige Optimierungspunkt besteht darin, den Kompatibilitätsfaktor bei der Teambildung zu berücksichtigen und nicht Menschen einzusetzen Im Vorfeld gemeinsam klären, wer in Konflikt geraten wird.
Aus Sicht der Teamkultur treten solche Situationen viel seltener in Teams mit einer ausgereiften Kultur auf, in der die Menschen das Team und die Kollegen respektieren und wissen, wie sie Probleme selbstständig lösen können. Darüber hinaus lassen sich solche Konflikte viel einfacher (häufig automatisch) in Teams lösen, in denen ein hohes Maß an Vertrauen herrscht, die Menschen schon lange zusammenarbeiten und/oder häufig außerhalb der Arbeit kommunizieren.
Konflikte im Zusammenhang mit Arbeitsthemen:
Solche Konflikte werden in der Regel durch beide Gründe gleichzeitig verursacht, sowohl emotionale (die Tatsache, dass sich einer der Teilnehmer nicht in der Position eines Erwachsenen befindet) als auch die Unvollkommenheit des Arbeitsprozesses selbst. Die vielleicht häufigste Art von Konflikten, auf die ich gestoßen bin, sind Konflikte bei Codeüberprüfungen oder Architekturdiskussionen zwischen Entwicklern.
Ich möchte hier zwei typische Fälle hervorheben:
1) Im ersten Fall kann der Entwickler keine Codeüberprüfung von einem Kollegen erhalten. Der Patch wird zur Überprüfung gesendet und es passiert nichts. Auf den ersten Blick gibt es keinen offensichtlichen Konflikt zwischen den beiden Seiten, aber wenn man darüber nachdenkt, handelt es sich um einen ziemlichen Konflikt. Das Arbeitsproblem ist nicht gelöst, eine der Parteien (die auf eine Bewertung wartet) verspürt offensichtliches Unbehagen. Ein extremer Untertyp dieses Falles ist die Entwicklung in einer Community oder in verschiedenen Teams, wobei der Prüfer aufgrund des Ladevorgangs oder anderer Umstände möglicherweise nicht an diesem bestimmten Code interessiert ist, der Überprüfungsanfrage möglicherweise überhaupt keine Beachtung schenkt und der externe Schiedsrichter (ein für beide Seiten gemeinsamer Manager) ) existiert möglicherweise überhaupt nicht.
Der Lösungsansatz, der in einer solchen Situation hilft, bezieht sich genau auf die langfristige Perspektive, die Kultur eines Erwachsenen. Erstens funktionieren intelligente Aktivitäten. Sie sollten nicht erwarten, dass der in der Rezension hängende Code die Aufmerksamkeit des Rezensenten selbst erregt. Wir müssen den Rezensenten helfen, auf ihn aufmerksam zu machen. Pingani ein paar Leute, stellen Sie eine Frage zu Syncape, nehmen Sie an Diskussionen teil. Offensichtlich schadet Aufdringlichkeit eher, als dass sie hilft. Sie müssen Ihren gesunden Menschenverstand walten lassen. Zweitens funktioniert die Vorbereitung gut. Wenn das Team versteht, was passiert und warum, warum dieser Code überhaupt benötigt wird, der Entwurf im Voraus mit allen besprochen und vereinbart wurde, ist es wahrscheinlicher, dass die Leute einem solchen Code Aufmerksamkeit schenken und ihn für die Arbeit akzeptieren. Drittens funktioniert Autorität. Wenn Sie bewertet werden möchten, führen Sie selbst viele Bewertungen durch. Führen Sie hochwertige Bewertungen durch, mit echten Schecks, echten Tests und nützlichen Kommentaren. Wenn Ihr Spitzname im Team bekannt ist, ist die Chance größer, dass Ihr Code wahrgenommen wird.
Aus Workflow-Sicht sind mögliche Verbesserungen hier eine korrekte Priorisierung, die darauf abzielt, dem Entwickler zu helfen, seine Ziele und die des Teams zu erreichen (andere überprüfen, Briefe an die Community schreiben, dem Code eine Architekturbeschreibung, Dokumentation, Tests beifügen, an Diskussionen teilnehmen). Community usw.), verhindern, dass Patches zu lange in der Warteschlange hängen und so weiter.
2) Der zweite häufige Fall von Konflikten bei Code- oder Designüberprüfungen sind unterschiedliche Ansichten zu technischen Problemen, dem Codierungsstil und der Auswahl der Tools. Von großer Bedeutung ist dabei das Maß an Vertrauen zwischen den Teilnehmern, die Zugehörigkeit zum gleichen Team und die Erfahrung in der Zusammenarbeit. Eine Sackgasse entsteht, wenn einer der Teilnehmer eine kindische Haltung einnimmt und nicht versucht zu hören, was der Gesprächspartner ihm mitteilen möchte. Oft kann sowohl der von der Gegenpartei vorgeschlagene als auch der ursprünglich vorgeschlagene Ansatz durchaus erfolgreich sein, und es spielt grundsätzlich keine Rolle, welchen man wählt.
Eines Tages bereitete ein Programmierer aus meinem Team (nennen wir ihn Pasha) einen Patch mit Änderungen am Paketbereitstellungssystem vor, der von Kollegen aus einer benachbarten Abteilung entwickelt und unterstützt wurde. Einer von ihnen (Igor) hatte seine eigene klare Meinung darüber, wie genau Linux-Dienste bei der Bereitstellung von Paketen konfiguriert werden sollten. Diese Meinung unterschied sich von dem im Patch vorgeschlagenen Ansatz und sie konnten sich nicht einigen. Wie üblich liefen die Fristen ab und es musste eine Entscheidung getroffen werden; es war notwendig, dass einer von ihnen eine Erwachsenenposition einnahm. Pascha erkannte, dass beide Ansätze ein Recht auf Leben haben, aber er wollte, dass seine Option durchgelassen wurde, weil Weder die eine noch die zweite Option hatten offensichtliche technische Vorteile.
Unsere Diskussion sah ungefähr so aus (natürlich sehr schematisch, das Gespräch dauerte eine halbe Stunde):
- Pasha, wir haben in ein paar Tagen einen Feature-Freeze. Es ist wichtig, dass wir alles zusammenbringen und so schnell wie möglich mit den Tests beginnen. Wie kommen wir durch Igor?
— Er möchte Dienste anders einrichten, er hat dort Kommentare für mich eingefügt ...
- Und was gibt es da, große Veränderungen, viel Aufregung?
- Nein, es gibt ein paar Stunden Arbeit, aber am Ende gibt es keinen Unterschied, es wird so oder so funktionieren, warum ist das notwendig? Ich habe etwas gemacht, das funktioniert, akzeptieren wir es.
- Hören Sie, wie lange diskutieren Sie das alles schon?
- Ja, wir markieren jetzt schon seit anderthalb Wochen die Zeit.
- Ähm... können wir ein Problem in ein paar Stunden lösen, das bereits anderthalb Wochen gedauert hat, und es nicht tun?
- Nun ja, aber ich möchte nicht, dass Igor denkt, dass ich nachgegeben habe ...
- Hören Sie, was ist Ihnen wichtiger, eine Freilassung zusammen mit Ihrer inneren Entscheidung zu erteilen oder Igor zu töten? Wir können es blockieren, dann besteht aber eine gute Chance, mit der Veröffentlichung durchzukommen.
- Nun ja... es wäre natürlich cool, Igor die Nase abzuwischen, aber okay, die Veröffentlichung ist wichtiger, da stimme ich zu.
- Ist es dir wirklich so wichtig, was Igor denkt? Um ehrlich zu sein, ist ihm das völlig egal, er will lediglich eine einheitliche Herangehensweise an verschiedenen Stellen der Sache, für die er verantwortlich ist.
- Nun gut, lassen Sie mich tun, was er in den Kommentaren verlangt, und beginnen wir mit dem Testen.
- Danke, Pascha! Ich war mir sicher, dass ihr beide reifer seid, obwohl Igorek älter ist als ihr :)
Das Problem wurde gelöst, die Veröffentlichung wurde pünktlich veröffentlicht, Pasha verspürte keine große Unzufriedenheit, weil er selbst hat eine Lösung vorgeschlagen und umgesetzt. Igor war im Allgemeinen zufrieden, weil... Seine Meinung wurde berücksichtigt und sie taten, was er vorschlug.
Eine andere Art von im Wesentlichen demselben Konflikt ist die Wahl zwischen technischen Lösungen/Bibliotheken/Ansätzen in einem Projekt, insbesondere in einem verteilten Team. Bei einem der Projekte, das als Verwendung von C/C++ positioniert war, stellte sich heraus, dass die technische Leitung des Projekts kategorisch gegen die Verwendung von STL (Standard Template Library) war. Dabei handelt es sich um eine Standardsprachenbibliothek, die die Entwicklung vereinfacht, und unser Team ist damit bestens vertraut. Es stellte sich heraus, dass das Projekt viel näher an C als an C++ liegt, was das Team nicht sonderlich begeisterte, denn Das Management hat sein Bestes gegeben und wirklich coole Plus-Spieler rekrutiert. Gleichzeitig war der amerikanische Teil des Teams, sowohl Ingenieure als auch Manager, schon lange im Unternehmen tätig, mit der aktuellen Situation vertraut und mit allem zufrieden. Der russische Teil des Teams (einschließlich mir) wurde erst vor kurzem, innerhalb weniger Wochen, zusammengestellt. Der russische Teil des Teams wollte den gewohnten Entwicklungsansatz kategorisch nicht aufgeben.
Endlose schriftliche Diskussionen begannen zwischen den beiden Kontinenten, Briefe flogen auf drei oder vier Bildschirmen hin und her, in Gruppenmailings und persönlichen Mailings, von Programmierern zu Programmierern und Managern. Wie üblich wurden Briefe dieser Länge von niemandem außer den Autoren und ihren glühenden Unterstützern gelesen. Die Chats knarrten vor Spannung, in denen auf mehreren Bildschirmen Gedanken über die technischen Vorteile des STL ausgetauscht wurden, wie gut es getestet wurde, wie sicher es ist und wie wunderbar das Leben damit ist und wie schrecklich es ohne es ist .
Das alles dauerte ziemlich lange, bis mir schließlich klar wurde, dass wir über die technischen Aspekte des Problems diskutierten, das Problem jedoch in Wirklichkeit nicht technischer Natur war. Das Problem sind nicht die Vor- oder Nachteile von STL oder die Schwierigkeit, ohne STL zu arbeiten. Das Problem ist eher organisatorischer Natur. Wir mussten nur verstehen, wie das Unternehmen, für das wir arbeiteten, funktionierte. Keiner von uns hatte zuvor Erfahrung in einem solchen Unternehmen. Die Sache war, dass, nachdem der Code entwickelt und in die Produktion freigegeben wurde, der Support von ganz anderen Leuten aus anderen Teams und aus anderen Ländern übernommen wurde. Dieses riesige Ingenieursteam von insgesamt mehreren zehntausend Ingenieuren konnte sich nur ein völlig einfaches Minimum an technischen Mitteln leisten, sozusagen ein Minimum Minimorum. Alles, was über den im Unternehmen physisch etablierten technischen Standard hinausgeht, könnte in Zukunft nicht mehr unterstützt werden. Das Niveau eines Teams wird durch das Niveau seiner schwächsten Mitglieder bestimmt. Nachdem wir es verstanden hatten echte Motivation Aufgrund der Maßnahmen des amerikanischen Teils des Teams wurde dieses Thema von der Tagesordnung gestrichen und gemeinsam haben wir das Produkt unter Verwendung der vom Unternehmen übernommenen Standards erfolgreich entwickelt und veröffentlicht. Briefe und Chats funktionierten in diesem Fall nicht gut; es bedurfte mehrerer Reisen und viel persönlicher Kommunikation, um auf einen gemeinsamen Nenner zu kommen.
Aus Sicht des Arbeitsablaufs wäre es in diesem speziellen Fall hilfreich, eine Beschreibung der verwendeten Tools, deren Anforderungen, Einschränkungen beim Hinzufügen neuer Tools und eine Begründung dieser Einschränkungen zu haben. Solche Dokumente entsprechen in etwa den in den Abschnitten „Wiederverwendungsstrategie und Entwicklungsumgebung“ des „Managerhandbuchs für Softwareentwicklung“ beschriebenen Dokumenten . Trotz seines Alters beschreibt es alle wesentlichen Aktivitäten und Planungsschritte einer solchen Softwareentwicklung perfekt. Mit solchen Dokumenten lässt sich ganz einfach diskutieren, welche Komponenten und Ansätze in einem Produkt verwendet werden können und warum.
Aus kultureller Sicht natürlich mit einer reiferen Position, in der die Parteien versuchen, die wahre Motivation des Handelns ihrer Kollegen zu hören und zu verstehen und auf der Grundlage der Prioritäten des Projekts und des Teams und nicht des persönlichen Egos zu handeln , würde der Konflikt einfacher und schneller gelöst werden.
Bei einem anderen Konflikt um die Wahl einer technischen Lösung brauchte ich ebenfalls merklich viel Zeit, um die Motivation einer der Parteien zu verstehen (es war ein sehr ungewöhnlicher Fall), aber nachdem die Motivation klar war, lag die Lösung auf der Hand.
Die Situation ist folgende: Ein neuer Entwickler erscheint in einem Team von etwa 20 Leuten, nennen wir ihn Stas. Zu dieser Zeit war Skype unser Standardtool für die Kommunikation im Team. Wie sich später herausstellte, war Stas ein großer Fan offener Standards und Open-Source-Software und verwendete nur Tools und Betriebssysteme, deren Quellen öffentlich zugänglich waren und die öffentlich beschriebene Protokolle verwendeten. Skype gehört nicht zu diesen Tools. Мы потратили уйму времени на обсуждения достоинств и недостатков этого подхода, попыток запуска аналогов скайпа на разных операционных системах, попытках Стаса убедить команду перейти на другие стандарты, писать ему персонально по почте, звонить ему персонально по телефону, купить ему второй компьютер специально для скайпа, usw. Schließlich wurde mir klar, dass dieses Problem im Wesentlichen nicht technischer oder organisatorischer Natur ist, sondern eher ideologischer, man könnte sogar sagen religiöser Natur (für Stas) ist. Selbst wenn wir Stas und Skype irgendwann verbinden würden (was mehrere Monate dauerte), würde das Problem bei jedem späteren Gerät erneut auftreten. Ich hatte keine wirklichen Mittel zur Verfügung, um Stas‘ Weltanschauung zu ändern, und es gab keinen Grund, zu versuchen, die Weltanschauung eines Teams zu ändern, das in diesem Umfeld perfekt funktionierte. Die Person und das Unternehmen waren in ihrer Weltanschauung einfach orthogonal. In solchen Situationen ist eine gute Lösung organisatorisch. Wir haben Sta zu einem anderen Team versetzt, wo er organischer war.
Der Grund für diesen Konflikt ist meiner Meinung nach die Diskrepanz zwischen der persönlichen Kultur einer bestimmten Person (die eine starke Meinung vertritt, die keine Kompromisse zulässt) und der Kultur des Unternehmens. In diesem Fall ist es natürlich der Fehler des Managers. Es war zunächst falsch, ihn mit einem solchen Projekt zu beauftragen. Stas wechselte schließlich zu einem Open-Source-Softwareentwicklungsprojekt und zeichnete sich dort aus.
Ein gutes Beispiel für einen Konflikt, der sowohl durch die kindische Einstellung des Entwicklers als auch durch die Unzulänglichkeiten des Arbeitsprozesses verursacht wird, ist eine Situation, in der der Entwickler und das QA-Team mangels einer Definition von erledigt unterschiedliche Erwartungen an die Bereitschaft haben Die Funktion wurde an die Qualitätssicherung übergeben. Der Entwickler glaubte, dass es ausreichte, den Code zu schreiben und das Feature über den Zaun zur Qualitätssicherung zu werfen – dort würden sie es klären. Übrigens ein ziemlich reifer und erfahrener Programmierer, aber das war seine interne Qualitätsschwelle. QA war damit nicht einverstanden und verlangte, ihnen zu zeigen und zu beschreiben, was er selbst überprüft hatte, und verlangte ein Testskript für sie. Sie hatten in der Vergangenheit Probleme mit der Funktionalität dieses Entwicklers und wollten ihre Zeit nicht noch einmal verschwenden. Übrigens hatten sie Recht – die Funktion funktionierte wirklich nicht, er überprüfte den Code nicht, bevor er ihn an die Qualitätssicherung schickte.
Um die Situation zu lösen, bat ich ihn, mir zu zeigen, dass wirklich alles funktionierte (es funktionierte nicht und er musste es reparieren), wir sprachen mit dem Team und mit der QA-Definition von erledigt (sie haben es nicht geschafft). weil wir den Prozess nicht zu bürokratisch machen wollten), nun, wir trennten uns bald von diesem Spezialisten (zur allgemeinen Erleichterung).
Aus der Sicht des Arbeitsablaufs sind mögliche Verbesserungen in diesem Fall das Vorhandensein einer Definition von erledigt, Anforderungen für die Unterstützung der einzelnen Unit-Funktionen und Integrationstests sowie eine Beschreibung der vom Entwickler durchgeführten Tests. In einem der Projekte haben wir den Grad der Codeabdeckung durch Tests während der CI gemessen und wenn der Abdeckungsgrad nach dem Hinzufügen eines Patches sank, wurden die Tests als fehlgeschlagen markiert, d. h. Jeder neue Code konnte nur hinzugefügt werden, wenn es neue Tests dafür gab.
Ein weiteres typisches Beispiel für einen Konflikt, der eng mit der Organisation des Arbeitsprozesses zusammenhängt. Wir haben ein Produkt, ein Produktentwicklungsteam, ein Supportteam und einen Kunden. Der Kunde hat Probleme mit dem Produkt und kontaktiert den Support. Der Support analysiert das Problem und versteht, dass das Problem im Produkt liegt, und leitet das Problem an das Produktteam weiter. Das Produktteam hat gerade viel zu tun, eine Veröffentlichung rückt näher, sodass ein Ticket mit einem Problem von einem Kunden, das zwischen den anderen Tickets des Entwicklers, dem es zugewiesen ist, verloren gegangen ist, mehrere Wochen lang unbeachtet bleibt. Der Support geht davon aus, dass der Entwickler an dem Problem des Kunden arbeitet. Der Kunde wartet und hofft, dass an seinem Problem gearbeitet wird. In Wirklichkeit passiert noch nichts. Nach ein paar Wochen beschließt der Kunde schließlich, sich für den Fortschritt zu interessieren und fragt beim Support nach, wie es läuft. Der Support fordert Entwicklung. Der Entwickler schaudert, durchsucht die Ticketliste und findet dort ein Ticket des Kunden. Als er das Ticket eines Kunden liest, wird ihm klar, dass es nicht genügend Informationen gibt, um das Problem zu lösen, und dass er mehr Protokolle und Dumps benötigt. Der Support fordert vom Kunden zusätzliche Informationen an. Und dann stellt der Kunde fest, dass die ganze Zeit niemand an seinem Problem gearbeitet hat. Und der Donner wird zuschlagen ...
In dieser Situation ist die Lösung des Konflikts selbst ziemlich offensichtlich und linear (Reparatur des Produkts, Aktualisierung der Dokumentation und Tests, Befriedigung des Kunden, Veröffentlichung eines Hotfixes usw.). Es ist wichtig, den Arbeitsprozess zu analysieren und zu verstehen, wer für die Organisation der Interaktion zwischen den beiden Teams verantwortlich ist und warum diese Situation überhaupt möglich war. Es ist klar, was dabei behoben werden muss – jemand muss das Gesamtbild ohne Mahnungen von Kunden proaktiv überwachen. Tickets des Kunden sollten sich von anderen Tickets der Entwickler abheben. Der Support sollte schauen, ob das Entwicklungsteam gerade an seinen Tickets arbeitet und wenn nicht, wann es mit der Arbeit beginnen kann und mit Ergebnissen zu rechnen ist. Support und Entwicklung sollten regelmäßig den Status von Tickets kommunizieren und besprechen, die Sammlung der für das Debuggen notwendigen Informationen sollte so weit wie möglich automatisiert werden usw.
So wie im Krieg der Feind versucht, die Verbindungsstelle zwischen zwei Einheiten zu treffen, so ist auch bei der Arbeit meist die Interaktion zwischen den Teams der heikelste und verwundbarste Punkt. Wenn die Support- und Entwicklungsmanager alt genug sind, können sie den Prozess selbst beheben. Wenn nicht, wird der Prozess weiterhin Konflikte und Probleme erzeugen, bis ein Manager eingreift, der die Situation beheben kann.
Ein weiteres typisches Beispiel, das ich immer wieder in verschiedenen Unternehmen gesehen habe, ist eine Situation, in der ein Produkt von einem Team geschrieben wird, automatische Integrationstests dafür von einem zweiten Team geschrieben werden und die Infrastruktur, auf der alles betrieben wird, von einem dritten Team begleitet wird Team. Bei der Durchführung von Tests treten ständig Probleme auf, deren Ursache sowohl das Produkt als auch die Tests und die Infrastruktur sein können. Es ist in der Regel problematisch, sich darauf zu einigen, wer die Erstanalyse von Problemen, Dateifehlern, Analyseprotokollen des Produkts, Tests und Infrastruktur usw. durchführen soll. Konflikte sind hier sehr häufig und gleichzeitig einheitlich. Bei hoher emotionaler Intensität verfallen die Teilnehmer oft in eine kindische Position und in der Serie beginnen Diskussionen: „Warum sollte ich daran herumbasteln“, „sie brechen öfter zusammen“ usw.
Aus Workflow-Sicht hängen die spezifischen Schritte zur Lösung eines Problems von der Zusammensetzung der Teams, der Art der Tests und des Produkts usw. ab. In einem der Projekte haben wir einen periodischen Dienst eingeführt, bei dem die Teams die Tests Woche für Woche einzeln überwachten. Im anderen Fall wurde die anfängliche Analyse immer von den Testentwicklern durchgeführt, aber die Analyse war sehr einfach und das Produkt war recht stabil, sodass es gut funktionierte. Der Schlüssel liegt darin, sicherzustellen, dass der Prozess transparent ist, dass die Erwartungen für alle Parteien klar sind und dass sich die Situation für alle fair anfühlt.
Sind Konflikte in einer Organisation überhaupt ein Problem? Ist es ein schlechtes Zeichen, dass es in Ihrem Team häufig (oder nur gelegentlich) zu Konflikten kommt? Im Allgemeinen nein, denn wenn es Wachstum und Entwicklung gibt, gibt es eine Art Dynamik, dann entstehen Probleme, die noch nie zuvor gelöst wurden, und bei deren Lösung können Konflikte entstehen. Dies ist ein Indikator dafür, dass einige Bereiche Aufmerksamkeit erfordern und dass es Bereiche mit Verbesserungspotenzial gibt. Schlimm ist es, wenn Konflikte sehr häufig auftreten, schwer zu lösen sind oder lange dauern. Dies ist höchstwahrscheinlich ein Zeichen für unzureichend rationalisierte Arbeitsprozesse und eine unzureichende Reife des Teams.
Source: habr.com