DevOps oder wie wir unser Gehalt und die Zukunft der IT-Branche verlieren

Das Traurigste an der heutigen Situation ist, dass die IT zunehmend zu einem Bereich wird, in dem es überhaupt kein "Stopp" mehr für die Anzahl der Aufgaben pro Person gibt.

Wenn man Stellenangebote liest, sieht man manchmal nicht 2-3 Personen, sondern ein ganzes Unternehmen in einer Person. Alle sind in Eile, die technische Schulden steigen, das alte Legacy-System erscheint im Vergleich zu neuen Produkten als Perfektion, denn dort gibt es zumindest Dokumentationen und Kommentare im Code. Die neuen Produkte werden mit Lichtgeschwindigkeit entwickelt, aber oft sind sie noch ein Jahr nach ihrer Fertigstellung unbenutzbar, und dieses Jahr bringt oft keine Gewinne. Zudem sind die Ausgaben für die "Cloud" höher als die Verkäufe des Dienstes. Das Geld der Investoren fließt in die Betreuung eines noch nicht funktionierenden Dienstes, der jedoch bereits als funktionierend im Netz veröffentlicht wurde.
Ein Beispiel: ein bekanntes Unternehmen, dessen Remaster einer alten Spieleversion die niedrigsten Bewertungen in der Geschichte der Branche erhalten hat. Ich war einer derjenigen, die dieses Produkt gekauft haben, aber selbst jetzt funktioniert es schrecklich und sollte in dieser Form noch nicht auf den Markt kommen. Rückerstattungen, sinkende Bewertungen, eine enorme Anzahl von Sperren von Nutzern in Foren wegen Beschwerden über die Serviceleistung. Die Anzahl der Patches ist nicht beeindruckend, sondern erschreckend; trotzdem ist das Produkt unbrauchbar. Wenn dieser Ansatz solche Ergebnisse bei einem Unternehmen erzielt, das seit 1991 in der Entwicklung tätig ist, ist die Situation bei Firmen, die gerade erst anfangen, noch schlimmer.

Aber das haben wir aus der Sicht des Nutzers des Dienstes betrachtet, jetzt schauen wir uns die Probleme an, die bei den Mitarbeitern aufgetreten sind.

Ich höre häufig die Aussage, dass es keine DevOps-Teams geben sollte, dass es sich um eine Methodologie handelt usw., aber seltsamerweise haben die Unternehmen damit aufgehört, nach Nockern, DBAs, Infrastruktur-Engineers und Build-Engineers zu suchen – jetzt ist alles DevOps-Ingenieur in Personalunion. Natürlich gibt es in einigen Unternehmen solche Stellenangebote noch, aber es werden immer weniger. Viele nennen das Entwicklung, ich sehe darin persönlich eine Degeneration, es ist unmöglich, in allen Bereichen ein gutes Wissensniveau zu halten und dabei nicht mehr als 8 Stunden zu arbeiten. Natürlich – das sind Fantasien. In der Realität müssen viele ITler auch 12 oder 14 Stunden arbeiten, von denen 8 vergütet werden. Oft auch ohne Wochenenden, weil „ich habe eine Aufgabe bekommen, die Dokumente fehlen oder sind fehlerhaft, und der Service kostet Geld“, und für einen Fehler in der Cloud kann es grundsätzlich sein, dass man für mehrere Monate kein Gehalt bekommt, besonders wenn man als Einzelunternehmer arbeitet. Faktisch verlieren wir das Wort im Geschäft, zusammen mit der Aufteilung der Verantwortlichkeiten. Ich stelle immer häufiger fest, dass Manager sich in die Entwicklungsprozesse einmischen, ohne die geringste Ahnung davon zu haben; sie verwechseln Geschäftsdaten und die Arbeit der Anwendung, wodurch das Chaos beginnt.

Wenn das Chaos beginnt, sucht das Unternehmen den Schuldigen, und dafür braucht man einen universellen Schuldigen. Es ist schwierig, die Schuld auf über 10 Personen zu verteilen, daher bündeln die Manager die Positionen, denn je mehr Pflichten ein Spezialist hat, desto einfacher ist es, seine Nachlässigkeit nachzuweisen. In einem Agile-Umfeld ist das Auffinden des "Schuldigen" und die Bestrafung die Grundlage dieser Managementmethodologie. Agile hat die IT-Welt längst verlassen, und sein zentrales Konzept ist die Forderung nach täglichen Ergebnissen. Das Problem ist, dass ein hochspezialisierter Fachmann nicht immer täglich Ergebnisse liefern kann, was die Berichtserstattung erschwert. Dies ist ein weiterer Grund, warum Unternehmen "Spezialisten für alles" wünschen. Aber der Hauptgrund ist natürlich der Lohnfonds – er ist die Hauptursache für alle Veränderungen. Menschen waren bereit, für sich selbst und die anderen zu arbeiten, um eine Erhöhung zu bekommen. Am Ende ist es, wie in anderen Bereichen, einfach zur Pflicht geworden, bei geringerem Lohn eine größere Anzahl von Dienstleistungen anzubieten.

Es gibt mittlerweile häufig Artikel, die besagen, dass auch Entwickler in der Lage sein müssen, Deployments durchzuführen und sich mit der Infrastruktur neben DevOps-Ingenieuren zu beschäftigen. Aber was führt das dazu? Richtig – zu einem Rückgang der Servicequalität und zu einem Rückgang der Qualität der Entwickler. Erst vor zwei Tagen habe ich einem Entwickler erklärt, dass man von verschiedenen Hosts aus schreiben und lesen kann, und ich wurde vehement davon überzeugt, dass er so etwas noch nie gesehen hat. Es gibt in den Einstellungen die Parameter orm host, port, db, user, password und das war's…. Dafür kann der Entwickler Deployments durchführen und YAML-Dateien schreiben…. Aber er vergisst bereits die Unit-Tests und Kommentare im Code.

Am Ende sehen wir Folgendes: ständige Überarbeitung, die Suche nach Lösungen für Probleme außerhalb der Arbeitszeit, kontinuierliches Lernen am Wochenende – und das nicht zur Steigerung des Einkommens, sondern um sich über Wasser zu halten. Entwickler sind gezwungen, dem DevOps-Ingenieur bei CI/CD zu helfen, und wenn der Entwickler keine Zeit hat, wird es kritisch, und die Manager beginnen, Druck auszuüben. Wenn das nicht dazu führt, dass die Bereitschaft zu Überstunden steigt, werden Sanktionen und Strafen angewendet. Der Mitarbeiter sucht eine neue Stelle und hinterlässt technische Schulden in der Größenordnung des Everest. Infolgedessen wachsen die Schulden auch bei den Entwicklern, da sie gezwungen sind, Code mit weniger Refactoring zu schreiben, um entweder dem alten oder dem neuen DevOps-Ingenieur zu helfen. Die Manager sind damit zufrieden, denn der Schuldige ist gefunden, und man sieht sofort, wer verantwortlich ist. Damit ist die Hauptregel im Agile-Management befolgt: Der Schuldige ist identifiziert, die Ergebnisse seiner Bestrafung sind sichtbar.

Einst hielt ich auf ITGM einen Vortrag mit dem Titel „Wann lernen wir, ‚Nein‘ zu sagen?“ – die Ergebnisse waren sehr aufschlussreich. Eine enorme Anzahl von Menschen hält dieses Wort für ein Tabu, und solange wir das nicht ändern, werden die Probleme nur zunehmen.

Teilweise hat mich zu diesem Artikel dieser Artikel, aber ich werde später möglicherweise weniger umschweifende Begriffe verwenden.

Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte melden Sie sich an.Sind Sie an Contour interessiert?

Haben Sie in Ihrer Arbeit Erfahrungen gemacht, wenn ein Arbeitgeber versucht hat, mehrere Personen durch Sie zu ersetzen?

• 65,6%Ja, ich mache regelmäßig solche Erfahrungen183

• 5,4%Ja, ich habe es 1 Mal erlebt15

• 15,4%Ich habe nichts bemerkt43

• 13,6%Ich bin ein Arbeitstier und arbeite selbst Überstunden38

279 Nutzer haben abgestimmt. 34 Nutzer haben sich enthalten.

Quelle: habr.com