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

Das Traurigste an der heutigen Situation ist, dass IT langsam zu einer Branche wird, in der es überhaupt kein "Stop" für die Anzahl der Aufgaben für eine Person gibt.

Wenn man Stellenangebote liest, sieht man manchmal nicht nur 2-3 Personen, sondern ein ganzes Unternehmen in einer Person. Alle sind in Eile, die technische Schuld wächst, das alte Legacy-System sieht im Vergleich zu neuen Produkten perfekt aus, weil es zumindest Dokumentation und Kommentare im Code gibt. Neue Produkte werden mit Lichtgeschwindigkeit geschrieben, aber letztendlich kann man sie ein Jahr nach ihrer Erstellung nicht nutzen, und oft bringt dieses Jahr keinen Gewinn. Darüber hinaus sind die Ausgaben für "Cloud" höher als die Verkäufe des Dienstes. Das Geld der Investoren fließt in die Unterhaltung eines noch nicht funktionierenden Dienstes, der jedoch bereits als betriebsbereit in die Welt gesetzt wurde.
Ein Beispiel: Ein bekanntes Unternehmen, dessen Remaster eines alten Spiels die niedrigsten Bewertungen in der Geschichte der Branche erhalten hat. Ich war einer derjenigen, die dieses Produkt gekauft haben, aber selbst jetzt funktioniert dieses Produkt schrecklich und sollte eigentlich nicht in dieser Form verkauft werden. Rückzahlungen, sinkende Bewertungen, eine enorme Anzahl von Bans für Benutzer in Foren aufgrund von Beschwerden über die Dienste. Die Anzahl der Patches ist nicht bewundernswert, sondern erschreckend, aber trotzdem – das Produkt ist nicht nutzbar. Wenn dieser Ansatz bei einem Unternehmen, das seit 1991 entwickelt, solche Ergebnisse liefert, ist die Situation bei Unternehmen, die erst anfangen, noch schlimmer.

Doch nun haben wir die Ergebnisse eines solchen Ansatzes aus der Sicht des Nutzers des Dienstes betrachtet; lassen Sie uns nun die Probleme ansehen, die bei den Mitarbeitern aufgetreten sind.

Ich höre oft die Behauptung, dass es keine DevOps-Teams geben sollte, dass es sich um eine Methodik handelt und so weiter. Aber das Problem ist, dass Unternehmen anscheinend aufgehört haben, nach Nocke, DBA, Infrastrukturmitarbeitern und Build-Ingenieuren zu suchen – jetzt ist das alles ein einzelner DevOps-Ingenieur. Natürlich gibt es in einigen Unternehmen solche Stellenanzeigen noch, aber es werden immer weniger. Viele nennen das eine Entwicklung, ich sehe persönlich darin eine Degression. Es ist unmöglich, in allen Bereichen ein hohes Wissensniveau aufrechtzuerhalten und dabei zu schaffen, nicht mehr als 8 Stunden zu arbeiten. Natürlich – das sind Fantasien. In der Realität sind viele ITler gezwungen, 12 oder 14 Stunden zu arbeiten, von denen 8 bezahlt werden. Oft ohne Wochenenden, weil „ich habe eine Aufgabe, die Dokumentation ist nicht vorhanden oder fehlerhaft, und der Service kostet noch Geld“, und für einen Fehler in der Cloud kann man im Grunde genommen monatelang kein Gehalt bekommen, besonders wenn man als Einzelunternehmer arbeitet. Faktisch verlieren wir das Wort im Geschäftsleben, zusammen mit der Aufteilung der Verantwortlichkeiten. Ich stelle immer häufiger fest, dass Manager in die Entwicklungsprozesse eingreifen, ohne überhaupt etwas davon zu verstehen. Sie verwechseln Geschäftsdaten und die Funktionweise der Anwendung, was letztendlich zu Chaos führt.

Wenn das Chaos beginnt, möchte das Geschäft den Schuldigen finden, und hier braucht man einen universellen Schuldigen. Es ist schwierig, die Schuld auf mehr als 10 Personen zu werfen, also vereinheitlichen die Manager die Positionen, denn je mehr Pflichten ein Spezialist hat, desto einfacher ist es, seine Nachlässigkeit nachzuweisen. Unter den Bedingungen von Agile ist das Finden eines "Schuldigen" und dessen Bestrafung die Grundlage dieser Methodik im Management. Agile ist längst über die IT hinaus gewachsen, und sein Hauptkonzept ist jetzt das Erfordernis nach täglichen Ergebnissen. Das Problem ist, dass ein Spezialist mit einer engen Spezialisierung nicht immer ein tägliches Ergebnis liefern kann, was bedeutet, dass es schwieriger wird, einen Bericht zu erstatten, und das ist ein weiterer Grund, warum das Geschäft "Spezialisten für alles" möchte. Aber der Hauptgrund ist natürlich die Lohnkosten – sie sind der Hauptgrund für alle Veränderungen. Aus diesem Grund waren die Menschen bereit, für sich und für den anderen zu arbeiten. Am Ende ist es, wie in anderen Bereichen, einfach zur Pflicht geworden, für eine geringere Bezahlung eine größere Anzahl von Dienstleistungen zu erbringen.

Aktuell kann man oft sogar Artikel sehen, die besagen, dass Entwickler auch deployen und sich zusammen mit dem DevOps-Ingenieur um die Infrastruktur kümmern sollten. Aber was führt das zu? Richtig – zu einem Rückgang der Servicequalität und der Qualifikation der Entwickler. Erst vor 2 Tagen habe ich einem Entwickler erklärt, dass man von verschiedenen Hosts aus lesen und schreiben kann, und mir wurde hitzig erklärt, dass sie so etwas noch nie gesehen haben. Es gibt doch die Einstellungen mit orm host, port, db, user, password und das war's… Aber dafür kann der Entwickler Deployments starten und YAMLs schreiben… Vergisst aber bereits die Unit-Tests und Kommentare im Code.

Am Ende sehen wir Folgendes: ständige Überstunden, die Suche nach Lösungen für Probleme außerhalb der Arbeitszeit, ständiges Lernen am Wochenende, und das nicht, um das Einkommen zu steigern, 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, ist er überfordert, und die Manager fangen an, ihm Druck zu machen. Wenn das nicht hilft, um die Bereitschaft zu erhöhen, Überstunden zu machen, werden Sanktionen und Strafen verhängt, und die Person sucht sich eine neue Arbeitsstelle, wobei sie einen technischen Schuldenberg hinterlässt, der so hoch ist wie der Everest. Infolgedessen beginnt die Schuldenlast auch bei den Entwicklern zu wachsen, da sie gezwungen sind, Code mit weniger Refactoring zu schreiben, um dem alten oder neuen DevOps-Ingenieur rechtzeitig zu helfen. Die Manager sind damit jedoch vollkommen zufrieden, denn der Schuldige ist vorhanden und sofort sichtbar, und somit ist die Grundregel des Agile-Managements erfüllt: der Schuldige ist gefunden, die Ergebnisse seiner Bestrafung sind sichtbar.

Einst habe ich auf ITGM mit einem Vortrag „Wann lernen wir, ‚Nein‘ zu sagen“ referiert – die Ergebnisse waren sehr aufschlussreich. Eine enorme Anzahl von Menschen betrachtet dieses Wort als Tabu, und solange wir das nicht ändern, werden die Probleme nur zunehmen.

Teilweise wurde ich zu diesem Artikel inspiriert durch diesen Artikel, aber ich werde ihn möglicherweise später in weniger umschweifenden Begriffen ausformulieren.

Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte einloggen.