Wie soll ich dem Front-End mitteilen, dass es standardmäßig keine Fehler mehr an das Back-End weitergeben soll?

Hier gibt es mehrere Dinge zu beheben:

• Aus technischer Sicht ist die Fehlerantwort des Backends fehlerhaft , wenn Ihr Frontend eine Fehlerantwort erhält und sie nicht sagen können , dass es ihre Schuld ist . Korrigieren Sie Ihr Backend so, dass es mit verständlichen Nachrichten antwortet und Sie es nicht immer wieder erklären müssen.

• Aus organisatorischer Sicht sollte ein Fehler, den Sie untersuchen, beweisen, dass es nicht Ihre Rolle ist, und neu zuweisen, ein Fehler sein, der zur Anzahl der Fehler zählt . Sie haben erfolgreich daran gearbeitet.

Aber am wichtigsten:

• Was zum Teufel machst du aus Produktsicht? Warum arbeitet ihr zwei Teams gegeneinander? Warum vergeben Sie Tickets, anstatt mit Ihren Kollegen zu sprechen? Was sollEs kann passieren, dass der Frontend-Entwickler Sie anruft und sagt: "Hey, ich habe diesen fiesen Fehler hier, ich habe es versucht, aber ich kann nicht herausfinden, warum sich das Backend so verhält. Haben Sie Zeit, das mit mir zu lösen? Ich habe alles eingestellt hoch, Sie können vorbeikommen oder wir können Bildschirme teilen". Und dann arbeitet man gemeinsam daran, bis der Fehler behoben ist und das Produkt funktioniert. Das Produkt wird kein bisschen besser durch eine Anzahl von Fehlern, eine Neuzuweisung von Tickets oder die Schuldzuweisung an ein Team gegenüber einem anderen. Es macht keinen Sinn, zwei Teams zu haben. Es ist ein Produkt. Kein Produkt ohne Frontend und kein Produkt ohne Backend. Ihre Organisationsstruktur richtet sich nach Unternehmensanforderungen, nicht nach Produktanforderungen. Und es zeigt.

Was können Sie reparieren? Ich weiß nicht. Sie könnten sich zurückziehen, die Stellung halten, sicherstellen, dass Tickets korrekt neu zugewiesen werden, andere die Schuld übernehmen und Ihre Fehlerzahl steigt. So funktionieren Unternehmen, Sie scheffeln Geld, während dumme Leute über Ihnen sich fragen, warum ihr Produkt so beschissen ist, verglichen mit der riesigen Menge Geld, die sie hineinstecken. Oder Sie könnten versuchen, die Hauptstraße zu nehmen. Untersuchen Sie das nächste Mal den Fehler, wenn er im Frontend zu sein scheint, werfen Sie das Ticket nicht einfach zurück, sprechen Sie mit jemandem, bilden Sie ein Team mit ihm und beheben Sie den Fehler gemeinsam. Konzentrieren Sie sich darauf, die Arbeit zu erledigen, nicht auf Unternehmenskennzahlen. Sie werden vielleicht überrascht sein, wie viel lohnender die Arbeit ist, wenn es darum geht, Dinge zu erledigen, anstatt Tickets abzulenken und anderen die Schuld zu geben. Vielleicht nicht. Vielleicht ist Ihr Konzern zu weit weg, als dass Sie etwas bewirken könnten. Dann musst du entscheiden, ob sie dir genug bezahlen, um es zu ertragen.

Ich bin frustriert darüber, dass ich RCA für Dinge mache, für die ich keine Anerkennung bekomme, oder mit anderen Worten, ich verschwende Zeit mit Dingen, die nicht meine Aufgabe sein sollten.

Ihre Anreizstruktur ist vermasselt.

Höchstwahrscheinlich tut das Front-End-Team dies auch, um eine Anerkennung für Inspektionsarbeiten zu erhalten, die es nicht ausgeführt hat.

Wenn Sie wollen, dass sich das Verhalten des Front-End-Teams ändert, müssen die Manager die Anreizstruktur und die Art und Weise ändern, wie Entwickler beurteilt werden.

Ich war einmal in einer ähnlichen Situation, mit der zusätzlichen Wendung, dass das Frontend Software und das Backend Hardware war (kein Zugriff auf die Codebasen des anderen). Du erwähntest:

Das QE-Team wird einen Fehler melden, der besagt, dass "das Ausführen von X, dann Y, dann Z auf der Benutzeroberfläche einen Fehler auslöst, wenn dies nicht der Fall sein sollte".

und dann würden diese Tickets an Sie weitergeleitet werden. Wenn ich solche Tickets bekam, würde ich sie zurückwerfen, da "mehr Informationen benötigt". Ich habe nichts UI-bezogenes in meinem Backend, daher sagt mir das Ticket des QE-Teams nicht viel, was für mich von Bedeutung ist. Stattdessen würden wir im Wesentlichen verlangen, dass das Frontend-Team ein separates untergeordnetes Ticket schreibt – nicht das ursprüngliche Ticket neu zuweist – das besagt: „Wenn ich eine so-und-so- Anfrage an das Backend sende, die so formatiert ist , wird das Ergebnis abgeschnitten.“ .

Dies verhindert, dass das Frontend-Team Probleme faul über die Wand wirft und Sie die Arbeit erledigen lässt. Sie müssen das Problem bis zur Schnittstelle zwischen uns debuggen. Das Endergebnis war, dass 95 % der Bugs, die sie an uns schickten, tatsächlich Backend-Probleme waren. Der Prozess des Debuggens bis zur Schnittstelle würde ziemlich klar machen, auf welcher Seite das Problem lag. Es ist schwer, eine Beschreibung dessen zu schreiben, was das Backend falsch macht, wenn das Problem am Frontend liegt. Wenn sie es trotzdem versuchen, sind solche Tickets normalerweise trivial zu identifizieren, indem sie beispielsweise zeigen, dass der gleiche Prozess wie erwartet funktioniert, wenn sie ein anderes Frontend verwenden.

Die Verwendung eines zweiten Tickets zwischen dem Frontend- und dem Backend-Team bedeutet auch, dass Sie ungültige Tickets mit extremen Vorurteilen schließen können, und es wirkt sich überhaupt nicht auf das ursprüngliche Ticket des QE-Teams aus. Während einer Retrospektive können Sie die Anzahl der vom Frontend-Team eingereichten Tickets anzeigen, die entweder ungültig waren oder nicht genügend Informationen enthielten, um Maßnahmen ergreifen zu können, wodurch das Problem für das Management viel sichtbarer und offensichtlicher werden sollte.

Hören Sie im Wesentlichen auf, die Schnittstelle zwischen Frontend und Backend zu überschreiten. Sie haben tatsächlich den Zugang und die Fähigkeiten, um in die Codebasen des anderen zu blicken (anders als in meinem Fall), aber nur weil Sie es können , heißt das nicht, dass Sie es tun sollten . Ein großer Teil des Grundes für die Aufteilung von Software in solche Teile besteht darin, dass sie sich gegenseitig wie Black Boxes mit klar definierten Schnittstellen behandeln können. Ein Backend-Bug sollte ohne jeglichen Bezug zu einem bestimmten Frontend, nur zur Schnittstelle des Backends, ticketfähig sein. Wenn Sie sich über diese Grenze in den Code eines anderen Teams beugen müssen, um Ihr Ticket zu untersuchen, dann ist derjenige, der dieses Ticket eingereicht hat, noch nicht mit seinem Teil fertig.

Ich fand es besonders hilfreich, ein alternatives, vereinfachtes Frontend zum Testen zu haben. Mein Team hat selten Tests mit dem offiziellen Frontend (GUI) durchgeführt. Wir haben von Grund auf ein Befehlszeilenprogramm zusammengestellt, das alle Backend-Funktionen einzeln ausführen konnte und keine der Geschäftslogiken des Frontends enthielt. Dadurch konnten wir unser Backend problemlos isoliert testen und sein Verhalten anhand der Spezifikation überprüfen. Wenn ein Fehler vom Frontend-Team einging, testeten wir die gleiche Abfolge von Funktionen manuell mit unserem Dienstprogramm. Wenn wir das gleiche Problem gesehen haben, lag der Fehler höchstwahrscheinlich im Backend. Als es bei uns gut funktionierte, lag das Problem fast immer im Frontend. Wir konnten Tickets, die eigentlich keine Backend-Probleme waren, mit einem 5-minütigen Test leicht identifizieren, anstatt 2 Stunden damit zu verbringen, uns damit zu beschäftigen.

Dies wurde dem Team von unseren Managern mitgeteilt, dass wir Fehler nicht neu zuweisen sollten, wie ich es beschrieben habe, aber das Problem besteht weiterhin.

Warum sprechen Sie das nicht mit Ihrem Vorgesetzten an? Das scheint der richtige Kanal zu sein.

Am Ende unserer Sprints hinke ich bei der Fehlerzählung hinterher und es sieht so aus, als wäre meine Leistung sehr schlecht.

Warum dokumentierst du das nicht und stellst es in deinen Sprints dar? „Deshalb bin ich hinterher …“

Am Ende unserer Sprints hinke ich bei der Fehlerzählung hinterher und es sieht so aus, als wäre meine Leistung sehr schlecht.

Klingt so, als würden Sie das falsche Problem lösen. Aber zuerst...

Ich denke, viele der anderen Antworten gehen davon aus, dass hinter dem, was das andere Team tut, Bosheit steckt, aber es kann eine Reihe von Faktoren geben, warum Fehler fälschlicherweise neu zugewiesen werden können. Sie sind nicht alle gute Gründe, aber sie sind Gründe:

• Sie glauben, dass das Ticket eher ein Problem in Ihrem Team ist, und prüfen es
• Es sieht ähnlich aus wie andere Tickets, die sie gesehen haben und die von Ihrem Team verursacht wurden
• Sie sind mit Tickets überhäuft und wollen abladen
• Ihnen fehlt die Fähigkeit zu ermitteln
• Sie wollen keine Fehlerkorrekturen durchführen

Letztendlich, wenn es ein systematisches Problem gibt, das Sie bereits bei Ihrem Chef angesprochen haben, sollten Sie ihn fragen, was er von Ihnen möchte, wenn Sie ein Ticket erhalten, das nicht so aussieht, als wäre es untersucht worden, bevor es neu zugewiesen wurde.

Mögliche Dinge, die Ihr Chef von Ihnen verlangen könnte:

• Weisen Sie das Ticket zurück, ohne etwas zu berühren
• Weisen Sie das Ticket mit einem Kommentar zurück, der erklärt, warum es erneut geprüft werden sollte
• Arbeite trotzdem am Ticket
• Arbeiten Sie am Ticket, aber führen Sie Aufzeichnungen über die „verschwendete“ Zeit
• Sprich es sofort mit deinem Chef an
• Sprich es sofort mit dem Boss des anderen Teams an
• Sprechen Sie es sofort mit jemandem an, der den Support-Flow überwacht
• Fahrkarte ignorieren
• Schließen Sie das Ticket, da es sich nicht um einen Fehler handelt
• Schließen Sie das Ticket als kein Fehler und erstellen Sie ein neues Ticket, um das Problem zu verfolgen
• Greifen Sie zum Telefon und sprechen Sie mit der Person, die es Ihnen zugewiesen hat
• Holen Sie die zweite Meinung eines Kollegen ein und tun Sie einen der oben genannten Schritte, wenn Sie beide einverstanden sind
• Etwas ganz anderes

Jede Antwort hier, die vorschreibt, was Sie unter diesen Umständen tun sollten, ist RATEN, was Ihr Chef von Ihnen möchte. Zum Glück müssen Sie nicht raten, Sie können einfach Ihren Chef fragen.

Während Ihr Chef gesagt hat, dass Tickets nicht ohne ordnungsgemäße Untersuchung hin und her vergeben werden sollten, gibt Ihnen das keine Erlaubnis, willkürlich eine der oben genannten Optionen auszuwählen und dies zu tun. Wenn jemand die Richtlinie nicht befolgt, bedeutet dies nicht, dass Sie die Richtlinie auch nicht befolgen sollten (wie einige andere Antworten nahe legen).

Nun wollen Sie in Bezug auf Ihren Arsch auch persönlich Fälle dokumentieren, in denen Ihre eigene Fähigkeit, effektiv zu arbeiten, beeinträchtigt wurde. Und wenn Sie mit Ihrem Chef über Leistung sprechen, sollten Sie sich darauf beziehen. Wenn Ihr Chef mit dieser verschwendeten Zeit zufrieden ist, dann gibt es kein Problem. Natürlich, wenn Ihr Chef mit der verschwendeten Zeit nicht zufrieden ist, haben Sie zumindest gemäß seinen Anweisungen gehandelt.

Ich stimme den anderen Antworten nicht zu. Ich war in dieser Situation und hier ist, was ich getan habe, um es zu beheben.

Soweit es mich als Entwickler betrifft, ist es meine Aufgabe, wenn mir ein Fehler zugewiesen wird, ihn zu untersuchen. Nur wenn ich bestätige, dass es nicht in meiner Verantwortung liegt, es zu beheben, oder ich es aus irgendeinem Grund nicht beheben kann, weise ich es einem anderen Entwickler/Team zu. Wenn ich es nicht reproduzieren kann oder nicht verstehe, warum es ein Problem ist, werde ich es demjenigen zurückgeben, der es angesprochen hat.

Sie sollten Ihren Vorgesetzten fragen, ob er damit einverstanden ist, dass Entwickler vor einer Neuzuweisung Nachforschungen anstellen sollten. Wenn sie es nicht tun, sind Sie vollgestopft, aber vorausgesetzt, sie bitten sie, eine Ankündigung zu machen, damit dies für alle klar ist. Wenn dies wiederholt vorkommt, bringen Sie es öffentlich an einem Ort zur Sprache, der für Ihren Arbeitsplatz am besten geeignet ist. Zum Beispiel eine Retrospektive oder ein Statusmeeting. Zum Beispiel: „Ich habe diese Woche viel Zeit damit verbracht, Fehler zu untersuchen, die mir von FE neu zugewiesen wurden und sich tatsächlich als FE-Probleme herausstellten. Wie passiert das? Warum kann FE das nicht herausfinden, bevor es mir neu zugewiesen wird? ermitteln sie nicht richtig?".

Das mag einigen Leuten kleinlich oder beschuldigend erscheinen, aber in einer Situation, in der Leute ihre Arbeit auf Sie werfen, in der Hoffnung, dass ein Teil davon hängen bleibt oder ihnen zumindest etwas Zeit und Ihre Kosten verschafft wird, denke ich, dass es so ist gerechtfertigt.

Ändern Sie die Regeln des Fehlerverfolgungssystems

Wenn Benutzer eines Fehlerverfolgungssystems es missbrauchen, müssen die Berechtigungen, die sie verwenden und die zu dem Missbrauch führen, widerrufen werden. In diesem Fall die Möglichkeit, die Zuordnung von Tickets zu anderen Teams zu ändern.

Bewertungsgremien

Ich habe an ziemlich großen Programmen gearbeitet, bei denen viele Teams für viele Teile verantwortlich waren. Daher durfte kein Entwickler ein Ticket einseitig einem anderen Team zuweisen. Es gab kein festes System, um Sie daran zu hindern, einem anderen Team zuzuordnen, aber wenn Sie es täten, würde jemand an Ihrem Schreibtisch sitzen und fragen, was zum Teufel Sie tun. Wenn jemand ein Ticket einem anderen Team zuweisen wollte, hatte er zwei Möglichkeiten:

• Finden und überzeugen Sie jemanden im anderen Team, es zu nehmen.
• Senden Sie das Ticket an ein Prüfungsgremium, in dem ein Vertreter jedes Teams anwesend war. Dort würden sie es sich ansehen und besprechen, welches Team für die Behebung des Problems verantwortlich sei.

Ihr Vorgesetzter hat Ihnen die Antwort bereits mitgeteilt.

Sie alle dürfen Bugs nicht an andere Teams weitergeben.

Wenn sie Ihnen einen Fehler zuweisen, antworten Sie, dass Sie angewiesen wurden, ihre Arbeit nicht zu stören, und setzen Sie Ihren Tag fort. Sie schaffen das Problem, indem Sie mit ihnen statt mit Ihrem Vorgesetzten zusammenarbeiten.

Sie können ihre Nachrichten unbeantwortet lassen, bis der „Haufen“ groß genug ist, damit Ihr Vorgesetzter sie im Mikromanagement verwalten und alle auf einmal bearbeiten kann.

Um es mit einem Beispiel zu verdeutlichen: „QA hat entschieden, dass der Fehler wahrscheinlich in der Arbeit Ihres Teams liegt, und ManagerX hat uns mitgeteilt, dass Sie uns keine Fehler neu zuweisen sollen, und deshalb priorisieren wir die Arbeitslast, die uns ursprünglich zugewiesen wurde. Wenn ja in der Lage sind, den Fehler zu lokalisieren und festzustellen, dass es sich tatsächlich um einen Fehler in einer bestimmten Ausgabe des Backends handelt, werden wir dies dann als Priorität betrachten, damit wir Ihr Team nicht verzögern."

Dies könnte eine großartige Gelegenheit für Sie sein, proaktiv zu sein – planen Sie jeden Tag etwas Zeit mit dem Leiter (oder einem geeigneten Vertreter) des anderen Teams ein, um die Tickets gemeinsam zu sichten .

Sie erhalten eine bessere Vorstellung von den Prozessen des anderen, kommen wahrscheinlich schneller zu Schlussfolgerungen und reduzieren vor allem das Siloing. Sie haben jetzt jeden Tag Zeit, sich auf diese Aufgabe zu konzentrieren, und Ihre Bemühungen sind jetzt messbar.

Ein schlechter Manager wird Ihnen sagen, dass Sie Zeit verschwendet haben, und Ihnen sagen, dass Sie aufhören sollen, und ich würde dies als Zeichen dafür nehmen, dass sich die Dinge in diesem Unternehmen nicht ändern werden.
Ein guter Manager erkennt, dass Sie etwas Wertvolles getan haben.
Ein großartiger Manager wird Ihnen helfen, die Idee zu entwickeln und den Prozess auszubügeln (und denken Sie daran, Ihnen Anerkennung zu zollen!)

Ich kann mir nur schwer vorstellen, wie viel Zeit Ihres Arbeitstages für die Fehlerbehebung aufgewendet werden kann. Sie sprechen von Front-End und Back-End, was meiner Meinung nach auf eine Art Web-Stack hindeutet, aber wie kann die Fehlerbehebung ein solches Problem sein, dass ganze Teams das Problem umgehen und versuchen, die Verantwortung dafür zu vermeiden?

Wenn Sie Web-Apps entwickeln, sollte der Untersuchungsteil des Designprozesses die Anforderungen an die App deutlich machen. Jeder Entwickler sollte dann Klarheit darüber haben, was von dem Produkt erwartet wird.

Was ich vermute, ist, dass von vielen Junior-Entwicklern erwartet wird, dass sie an Technologien auf einem fortgeschritteneren Niveau arbeiten, als sie dazu in der Lage sind. Wer will schon einen Senior-Entwickler einstellen, wenn man einfach einen Haufen Neulinge dazu bringen kann, für einen Bruchteil des Preises zu arbeiten?

Anstatt die Verantwortung für ihre Arbeit zu übernehmen, geben diese Leute einfach den Schwarzen Peter weiter, weil sie nicht wissen, wie sie das Problem beheben können. Es ist oft schwer zuzugeben, dass man ein Problem nicht lösen kann. Vor allem, wenn Sie Ihren Arbeitgeber mögen und denken, dass es ihn im Stich lässt, wenn Sie nicht in der Lage sind, etwas für ihn zu tun.

Ich verstehe wirklich nicht, wie, ob ein Problem Front-End oder Back-End ist, jemanden davon abhalten sollte, ein Problem zu beheben. Ja, ich möchte als Frontend-Entwickler angestellt werden, aber wenn die Angular-App mit einer MySQL-Datenbank interagieren muss, ist es meine Aufgabe, dies zu erledigen.

Ich kann nicht vor Erschöpfung die Hände schütteln und aufhören zu arbeiten, nur weil ich plötzlich mit etwas arbeite, das technisch nicht nach vorne gerichtet ist. Es scheint eine Trennung in der Funktionsweise dieser Teams zu geben, sie sollten zwei Teile einer zusammenhängenden Einheit sein. Diese Wir-und-Sie-Mentalität ist einer guten Softwareentwicklung nicht förderlich.

Führen Sie, wie in einem Kommentar vorgeschlagen, Due Diligence durch, führen Sie Ihre Tests durch, und wenn Sie keinen Fehler im Backend finden, schließen Sie das Ticket einfach als "kein Fehler".

Frontend hat Ihnen das Ticket weitergeleitet und als Kollege sollten Sie davon ausgehen, dass es professionell und aus einem bestimmten Grund getan wurde: Nach einiger Zeit bemerkt vielleicht jemand einen Trend und beschließt, nachzuforschen.

Klingt kleinlich? Denn es ist...

Riskant? Vielleicht; nur du kannst sagen wie viel...

Wenn die Metrik „Anzahl geschlossener Tickets“ lautet, wird das Frontend meiner Meinung nach den neuen Ansatz im Backend-Ticketmanagement schnell bemerken.

Wie kann man dem Front-End mitteilen, dass es standardmäßig keine Fehler mehr zurückgibt?

Schnappen Sie sich alle relevanten Leute für ein kurzes Treffen und sagen Sie ihnen:

Ich bin frustriert darüber, dass ich RCA für Dinge mache, für die ich keine Anerkennung bekomme, oder mit anderen Worten, ich verschwende Zeit mit Dingen, die nicht meine Aufgabe sein sollten. Am Ende unserer Sprints hinke ich bei der Fehlerzählung hinterher und es sieht so aus, als wäre meine Leistung sehr schlecht.

Fragen Sie sie, wie ihrer Meinung nach damit umgegangen werden sollte. Lassen Sie Ihren Vorgesetzten anwesend sein. Hören Sie zuerst zu.

Erstens, wenn Sie ein Team haben, das am Frontend arbeitet, und ein anderes Team, das am Backend arbeitet, ist es eine gute Idee, die Systeme so zu gestalten, dass Frontend-Bugs zu Fehlermeldungen und anderen Meldungen führen, die eindeutig das Frontend betreffen. und dito für Backend. Probleme im Front-End sollten nicht zu Back-End-Fehlern führen, die den Eindruck erwecken, dass das Back-End das Problem ist, und dann viel RCA erfordern, um festzustellen, dass dies nicht der Fall ist. Wenn Sie alle in einem Team gewesen wären, könnten Sie mit dieser Art von Hin und Her davonkommen. Aber da Sie getrennte Teams mit getrennten Sprints sind, wird die Weitergabe des Schwarzen Peters die Dinge sehr ineffizient machen, wie Sie festgestellt haben. Sie haben hier also eindeutig ein Systemproblem.

Natürlich ist das Problem wahrscheinlich etwas, dessen Lösung viel Zeit und Mühe kosten würde (z. B. wie viele Fehler müssten umgestaltet werden?), Und Sie suchen nach einer schnellen magischen Beschwörung, die Sie ihnen sagen können, die das Problem verursacht Geh weg. Diese Beschwörung lautet:

Hey Front-End-Leute – ich habe bemerkt, dass wir viele Bugs bekommen, die zunächst so aussehen, als wären sie Front-End-Bugs, sich dann aber als Back-End-Bugs herausstellen oder umgekehrt. Beispielsweise hat das Back-End-Team letzten Monat X Bugs erhalten, von denen sich Y als Front-End-Bugs herausstellten. Ich habe das Gefühl, dass es unser Leben viel einfacher machen und uns viel Zeit sparen könnte, wenn wir dieses Hin und Her reduzieren würden. Können wir ein Treffen abhalten, um bessere Kriterien für das Triaging von Fehlern und das Einreichen als Front-End oder Back-End zu vereinbaren? Ich habe einige Ideen, die ich teilen kann, wenn Sie möchten.

Seltsam für mich ist, dass Sie als Motivation angeben, nicht an so vielen Fehlern arbeiten zu wollen. Ist das Beheben von Fehlern nicht Ihr Job? Wenn ja, warum beschweren Sie sich? Beheben Sie einfach weiter die Fehler, markieren Sie die Tickets als erledigt und erzählen Sie Ihrem Chef am Ende des Quartals, wie Sie so viele Fehler behoben haben und eine Gehaltserhöhung erhalten sollten. Oder wenn es nicht Ihre Aufgabe ist, na ja, tun Sie es nicht? Sollten Sie nicht einen Manager haben, der Ihnen sagt, an welchen Tickets Sie arbeiten sollen, anstatt einige andere Team-Dump-Tickets bei sich zu haben? Normalerweise sollen Tickets zuerst an Ihren Scrum Master gehen, damit er sie beim nächsten Sprint-Meeting Personen zuweisen kann .

Fangen Sie an, jeden Fehler dem Frontend zuzuweisen, ohne ihn anzusehen. Das Problem mit dem Frontend-Team (und Ihrem Vorgesetzten) löst sich natürlich innerhalb weniger Tage.

Solange sie für ihre Taten belohnt werden, indem sie vor den Managern großartig aussehen, und Sie derjenige sind, der Berichte über schlechte Leistungen vorlegen muss, hat das Front-End-Team keinen Grund, ihr Verhalten zu stoppen; und das werden sie nicht. Die Manager scheinen sich auch nicht genug darum zu kümmern, etwas dagegen zu unternehmen. Wenn die Dinge so weitergehen, werden Sie den Sturz ertragen, lange bevor das Front-End-Team einen Rückschlag erleidet.