Das Unternehmen macht jeden Softwareentwickler zu einem 1-jährigen Zeitarbeiter ohne Sozialleistungen. Dies führt zu Kurzfristigkeit im Code

In einem Kommentar haben Sie Ihre Frage wie folgt präzisiert:

Welche Optionen gibt es, um die kurzfristige Perspektive der Entwickler zu korrigieren, die sich in den Code einfügt?

Anstatt direkt auf die spezifischen Herausforderungen einzugehen, die Sie beschreiben (z. B. wie Sie mit Ihrem frustrierenden Scrum Master umgehen), halte ich es für sinnvoller, einen Schritt zurückzutreten, herauszuzoomen und einen Rahmen für die Lösung dessen zu berücksichtigen, was Sie als Qualitätsprobleme am Arbeitsplatz wahrnehmen , Im Algemeinen.

Das Problem mit der Qualität am Arbeitsplatz ist, dass sie in vielen Situationen willkürlich und sehr persönlich ist. Sie haben selbst in einem anderen Kommentar darauf angespielt, als Sie sagten:

Ich bin die Art von Person, die Probleme löst, lange nachdem andere sie als nicht wert abgetan haben, sie zu beheben

Das sagt mir, dass Sie wahrscheinlich eine strengere Qualitätsbewertung haben als einige andere, mit denen Sie arbeiten. Unterschiede in der Wahrnehmung von Qualität oder Prozess führen fast immer zu den Konflikten, die Sie haben. Es kann sich leicht in eine Spirale von Argumenten verwandeln, ohne sich darauf zu konzentrieren, was Sie tatsächlich erreichen wollen.

Bevor Sie also versuchen, eines Ihrer spezifischen Probleme zu lösen, treten Sie einen Schritt zurück. Mach Folgendes:

• Bestimmen Sie auf hoher Ebene, was die Ziele Ihres Unternehmens sind.
• Bestimmen Sie, wie oder warum diese Ziele für Ihr Projekt relevant sind.
• Gestalten Sie Ihre Probleme durch die Linse dieser Ziele neu, so wie sie für Ihr Projekt gelten
• Überlegen Sie, ob Ihre Probleme tatsächlich noch gelöst werden müssen, und entwickeln Sie in diesem Fall eine Lösung, die einen klaren Bezug zu Ihren identifizierten Zielen herstellt.

Softwareentwicklung ist (fast immer) Mittel zum Zweck. Die Softwarequalität und/oder die Arten von Problemen, die Ihre Kurzzeitentwickler einführen, können für einen Perfektionisten wirklich frustrierend sein. Es kann wie ein unüberwindbares Problem erscheinen. Aber indem Sie die obigen Schritte befolgen, können Sie sich selbst helfen, diese Probleme aus der Sicht des Unternehmens und nicht aus Ihrer persönlichen Sicht zu sehen.

Dies ist wichtig, da es zu einem von zwei Ergebnissen führen kann:

• Sie werden vielleicht erkennen, dass die Dinge, die Sie als Probleme ansehen, keine wirklichen Probleme sind. Dies ist ein allgemeiner Moment der Offenbarung für Softwareentwickler und Softwareentwicklungsmanager, die daran gewöhnt sind, nach Perfektion zu streben. Die meisten offiziell ausgebildeten Softwareentwickler wurden in der Idee geschult, dass es immer die beste Antwort oder die beste Lösung gibt, und nur diese zählt. In der realen Welt ist gut genug gut genug. Wenn ein Softwareteam Ergebnisse generiert, die die Anforderungen des Unternehmens erfüllen und zu den Unternehmenszielen passen, ist das alles.

Wenn Sie keine Möglichkeit finden, eine „massive React.jsx-Datei“ für die Unternehmensziele relevant zu machen, müssen Sie aufhören, sich darüber Gedanken zu machen. Aber wenn Sie zeigen können, dass der Umsatz in direktem Zusammenhang mit der Fähigkeit Ihres Unternehmens steht, seine Ziele zu erreichen, dann können Sie etwas Zugkraft bekommen.

Andererseits scheint die Tatsache, dass ein Telefonnummern-Eingabefeld nicht die gewünschte Funktionalität hatte, ein ernstes Problem zu sein, das leicht in einen Kontext einzuordnen ist, den das Unternehmen versteht. Aber es hört sich so an, als ob es sich eher um ein Problem falscher Anforderungen als um Fluktuation unter den Entwicklern handelt.

Letztendlich stellen Unternehmen keine Softwareentwicklungsteams ein, weil sie die beste Software der Welt entwickeln wollen. Sie stellen Softwareentwicklungsteams ein, weil sie kundenspezifische Software als eine Möglichkeit zur Lösung ihrer Geschäftsprobleme ansehen. Wenn Sie also als Teamleiter auf Dinge stoßen, die Sie für Probleme halten, ist der beste Ansatz, sich selbst mit den Unternehmenszielen und diesen Geschäftsproblemen zu vergleichen.

Und wenn Sie sich dann immer noch sicher sind, dass es sich um ein Problem handelt, stellen Sie sicher, dass Sie es aus der Sicht des Unternehmens und nicht aus der Sicht der reinen Softwareentwicklung einrahmen. Ein Unternehmen, das Softwareentwicklung als Ware – als Mittel zum Zweck – betrachtet, wird Umsätze nicht ohne Weiteres als ernsthaftes Problem betrachten, es sei denn, Sie helfen ihm zu verstehen, warum, in für sie verständlichen Begriffen und mit einer Lösung, die in ihrem Rahmen sinnvoll ist.

Das Verhalten Ihrer Kollegen basiert auf deren Anreizen. Ihre Anreize sind auf einem sehr hohen Niveau angesetzt.

Ich weiß nicht, was Ihre Erfahrung oder Ihr Platz in der Organisation ist, aber da Sie nicht einmal ein Mitspracherecht bei den Prozessen haben, die für die Entwicklung verwendet werden, glaube ich nicht, dass Sie einen Platz mit bedeutender organisatorischer Macht einnehmen. (Und übrigens, ihr macht die dunkelste Form von Dark Scrum, von der ich je gehört habe). Du bist super neu. Du hast keine Verbündeten. Ihr Vorgesetzter ist entweder fatalistisch oder es ist ihm egal. Ihre Organisation ist so unfunktional organisiert, dass die Personalabteilung (dh das Verwaltungspersonal) darüber entscheidet, wie Entwickler behandelt werden.

Du hast also eigentlich nur eine Möglichkeit:

Arbeiten Sie hier weiter, bis Sie die Fähigkeiten und Erfahrungen haben, um woanders besser zu arbeiten, dann tun Sie das. Und vielleicht Unternehmen besser durchleuchten.

Das ist genau das, was Ihr „Star-Temp-Entwickler“ gesagt hat, denn das ist eine kluge Reaktion auf die Umgebung, in der sie sich befinden.

Ich habe das Gefühl, dass die meisten (wenn nicht alle) Entwickler Zeitarbeiter sind, das hätte ein Warnsignal sein sollen, bevor Sie überhaupt beigetreten sind.

Wie @AndreiROM (ich bin nicht an die Tagging-Etikette von StackOverflow gewöhnt) vorgeschlagen hat, wäre die beste Alternative, „diese Leute ihren Zirkus so führen zu lassen, wie sie möchten“.

Das Problem scheint die Unternehmenskultur zu sein. Wenn es keine starke, definierte Gruppe von Entwicklern gibt, die Standardpraktiken und definierte Programmiererwartungen durchsetzen können, bedeutet dies, dass das Boot nicht richtig verankert ist und es nur eine Frage der Zeit ist, bis es an Land treibt.

Entweder:

Holen Sie sich ein gutes Projekt, um es Ihrem Portfolio hinzuzufügen, und steigen Sie kurzfristig aus

oder...

Versuchen Sie, substanzielle, unternehmensweite Änderungen vorzunehmen

Option A ist wahrscheinlich insgesamt die beste Option, und Sie könnten problemlos nach anderen Optionen suchen.

Option B hingegen bedeutet, dass Sie bereit und in der Lage sind, sich gegen den Strom zu stemmen und versuchen, fest angestellte Entwickler zu bekommen und Ihre bereits bestehenden Technologieschulden loszuwerden. Diese Option kann eine gute Heldengeschichte ergeben, um zu versuchen, die Leiter hinaufzuklettern, wenn Sie danach suchen. Aber ich würde davon abraten.

Es scheint mir, als würden Sie eine verlierende Hand spielen:

• Ihr Manager hat nicht das Gefühl, dass er über das politische Kapital verfügt, um auf Veränderungen zu drängen (was auf Anhieb ein Warnsignal dafür ist, dass er nur dazu da ist, den Status quo durchzusetzen)
• Die Vorgesetzten verstehen nicht, dass ihr Schiff auf eine Katastrophe zusteuert (eine weitere rote Flagge)
• Der Scrum Master hat keine Ahnung, dass die Arbeit, die er zu Ende drängt, nutzlos ist oder, schlimmer noch, Ihre Codebasis beschädigt (ein weiteres Warnsignal).
• Die Mitarbeiter spielen das System aus, um Boni zu erhalten (kein Unternehmen hat es jemals geschafft, mangelndes Engagement für die Bedürfnisse und Ziele des Unternehmens zu fördern).
• obwohl man die drohende Katastrophe sieht, sind einem die eigenen Hände gebunden

Am einfachsten wäre es, sich nach einem neuen Job umzusehen und diesen Leuten (Verrückten?) zu überlassen, wie sie ihren Zirkus führen, wie sie wollen.

Wenn Sie jedoch eine Weile dabei bleiben möchten, sollten Sie sich einige langfristige Ziele setzen, was Sie verbessern möchten, und anfangen, kleine, inkrementelle Änderungen voranzutreiben.

Kämpfen Sie beispielsweise darum, ein paar technische Mitarbeiter (Vollzeit) zu beschäftigen, und schicken Sie sie zu den Besprechungen zur Erfassung der Anforderungen, damit die Zeitarbeitsentwickler bessere Spezifikationen erhalten. Oder überprüfen Sie die Anforderungen selbst, bevor die Arbeit erledigt wird (dies könnte eine gute Notlösung sein).

Drängen Sie langsam auf mehr Vollzeit-Entwickler oder holen Sie sich die, die Sie auf die Überprüfung der Codequalität der Aushilfen konzentrieren müssen. Holen Sie sich, wer auch immer die Überprüfungen durchführt, um die Codequalität in ihre Kriterien aufzunehmen usw.

Ein entscheidender Punkt ist, dass Sie sehr starke Kommunikationswege mit dem Scrum Master aufbauen und ihn dazu bringen sollten, zu erkennen, dass Sie in das, was erledigt wird, einbezogen werden müssen (besprechen Sie die Überprüfung der Anforderungen vor Sprints usw.). Sie beide müssen Verbündete sein und sicherstellen, dass die geleistete Arbeit relevant und zukunftssicher ist, und nicht nur, dass ein Entwickler sein oder ihr schlecht definiertes Ziel erreicht.

Mit der Zeit können Sie eine „gut genug“-Situation schaffen, die es Ihnen ermöglicht, die von Ihnen aufgebauten technischen Schulden anzugehen.

Es gibt keinen Vorteil für die Entwickler, die Dinge richtig zu machen. Es gibt jedoch einen Vorteil, um Dinge schnell zu erledigen – den Bonus. Ich habe keine Strafen für minderwertige Arbeit gesehen und die Tatsache hinzugefügt, dass ihr Vertrag in x Monaten verlängert werden könnte oder nicht, und Sie haben den Entwicklern im Grunde genommen den Anreiz genommen, die Dinge richtig zu machen.

Bestimmen Sie, was für Sie/Ihr Unternehmen wichtig ist, und strukturieren Sie Ihr Belohnungssystem entsprechend. Ihr aktuelles Belohnungssystem schätzt die Liefergeschwindigkeit, nicht die Qualität.