{"id":89062,"date":"2020-07-18T07:41:57","date_gmt":"2020-07-18T05:41:57","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/devops-ili-kak-my-teryaem-zarabotnuyu-platu-i-budushhee-it-otrasli"},"modified":"2020-07-18T07:41:57","modified_gmt":"2020-07-18T05:41:57","slug":"devops-ili-kak-my-teryaem-zarabotnuyu-platu-i-budushhee-it-otrasli","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/devops-ili-kak-my-teryaem-zarabotnuyu-platu-i-budushhee-it-otrasli","title":{"rendered":"DevOps oder wie wir unser Gehalt und die Zukunft der IT-Branche verlieren","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Das Traurigste an der heutigen Situation ist, dass die IT zunehmend zu einem Bereich wird, in dem es \u00fcberhaupt kein \"Stopp\" mehr f\u00fcr die Anzahl der Aufgaben pro Person gibt. <\/p>\n

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\u00fcr die \"Cloud\" h\u00f6her als die Verk\u00e4ufe des Dienstes. Das Geld der Investoren flie\u00dft in die Betreuung eines noch nicht funktionierenden Dienstes, der jedoch bereits als funktionierend im Netz ver\u00f6ffentlicht wurde.<\/a><\/noindex>
\nEin 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\u00fcckerstattungen, sinkende Bewertungen, eine enorme Anzahl von Sperren von Nutzern in Foren wegen Beschwerden \u00fcber 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\u00e4tig ist, ist die Situation bei Firmen, die gerade erst anfangen, noch schlimmer.<\/p>\n

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. <\/p>\n

Ich h\u00f6re h\u00e4ufig die Aussage, dass es keine DevOps-Teams geben sollte, dass es sich um eine Methodologie handelt usw., aber seltsamerweise haben die Unternehmen damit aufgeh\u00f6rt, nach Nockern, DBAs, Infrastruktur-Engineers und Build-Engineers zu suchen \u2013 jetzt ist alles DevOps-Ingenieur in Personalunion. Nat\u00fcrlich gibt es in einigen Unternehmen solche Stellenangebote noch, aber es werden immer weniger. Viele nennen das Entwicklung, ich sehe darin pers\u00f6nlich eine Degeneration, es ist unm\u00f6glich, in allen Bereichen ein gutes Wissensniveau zu halten und dabei nicht mehr als 8 Stunden zu arbeiten. Nat\u00fcrlich \u2013 das sind Fantasien. In der Realit\u00e4t m\u00fcssen viele ITler auch 12 oder 14 Stunden arbeiten, von denen 8 verg\u00fctet werden. Oft auch ohne Wochenenden, weil \u201eich habe eine Aufgabe bekommen, die Dokumente fehlen oder sind fehlerhaft, und der Service kostet Geld\u201c, und f\u00fcr einen Fehler in der Cloud kann es grunds\u00e4tzlich sein, dass man f\u00fcr mehrere Monate kein Gehalt bekommt, besonders wenn man als Einzelunternehmer arbeitet. Faktisch verlieren wir das Wort im Gesch\u00e4ft, zusammen mit der Aufteilung der Verantwortlichkeiten. Ich stelle immer h\u00e4ufiger fest, dass Manager sich in die Entwicklungsprozesse einmischen, ohne die geringste Ahnung davon zu haben; sie verwechseln Gesch\u00e4ftsdaten und die Arbeit der Anwendung, wodurch das Chaos beginnt. <\/p>\n

Wenn das Chaos beginnt, sucht das Unternehmen den Schuldigen, und daf\u00fcr braucht man einen universellen Schuldigen. Es ist schwierig, die Schuld auf \u00fcber 10 Personen zu verteilen, daher b\u00fcndeln die Manager die Positionen, denn je mehr Pflichten ein Spezialist hat, desto einfacher ist es, seine Nachl\u00e4ssigkeit nachzuweisen. In einem Agile-Umfeld ist das Auffinden des \"Schuldigen\" und die Bestrafung die Grundlage dieser Managementmethodologie. Agile hat die IT-Welt l\u00e4ngst verlassen, und sein zentrales Konzept ist die Forderung nach t\u00e4glichen Ergebnissen. Das Problem ist, dass ein hochspezialisierter Fachmann nicht immer t\u00e4glich Ergebnisse liefern kann, was die Berichtserstattung erschwert. Dies ist ein weiterer Grund, warum Unternehmen \"Spezialisten f\u00fcr alles\" w\u00fcnschen. Aber der Hauptgrund ist nat\u00fcrlich der Lohnfonds \u2013 er ist die Hauptursache f\u00fcr alle Ver\u00e4nderungen. Menschen waren bereit, f\u00fcr sich selbst und die anderen zu arbeiten, um eine Erh\u00f6hung zu bekommen. Am Ende ist es, wie in anderen Bereichen, einfach zur Pflicht geworden, bei geringerem Lohn eine gr\u00f6\u00dfere Anzahl von Dienstleistungen anzubieten. <\/p>\n

Es gibt mittlerweile h\u00e4ufig Artikel, die besagen, dass auch Entwickler in der Lage sein m\u00fcssen, Deployments durchzuf\u00fchren und sich mit der Infrastruktur neben DevOps-Ingenieuren zu besch\u00e4ftigen. Aber was f\u00fchrt das dazu? Richtig \u2013 zu einem R\u00fcckgang der Servicequalit\u00e4t und zu einem R\u00fcckgang der Qualit\u00e4t der Entwickler. Erst vor zwei Tagen habe ich einem Entwickler erkl\u00e4rt, dass man von verschiedenen Hosts aus schreiben und lesen kann, und ich wurde vehement davon \u00fcberzeugt, 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\u2026. Daf\u00fcr kann der Entwickler Deployments durchf\u00fchren und YAML-Dateien schreiben\u2026. Aber er vergisst bereits die Unit-Tests und Kommentare im Code.<\/p>\n

Am Ende sehen wir Folgendes: st\u00e4ndige \u00dcberarbeitung, die Suche nach L\u00f6sungen f\u00fcr Probleme au\u00dferhalb der Arbeitszeit, kontinuierliches Lernen am Wochenende \u2013 und das nicht zur Steigerung des Einkommens, sondern um sich \u00fcber 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\u00fcben. Wenn das nicht dazu f\u00fchrt, dass die Bereitschaft zu \u00dcberstunden steigt, werden Sanktionen und Strafen angewendet. Der Mitarbeiter sucht eine neue Stelle und hinterl\u00e4sst technische Schulden in der Gr\u00f6\u00dfenordnung 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. <\/p>\n

Einst hielt ich auf ITGM einen Vortrag mit dem Titel \u201eWann lernen wir, \u201aNein\u2018 zu sagen?\u201c \u2013 die Ergebnisse waren sehr aufschlussreich. Eine enorme Anzahl von Menschen h\u00e4lt dieses Wort f\u00fcr ein Tabu, und solange wir das nicht \u00e4ndern, werden die Probleme nur zunehmen.<\/p>\n

Teilweise hat mich zu diesem Artikel dieser Artikel<\/a><\/noindex>, aber ich werde sp\u00e4ter m\u00f6glicherweise weniger umschweifende Begriffe verwenden.<\/p>\n

Nur registrierte Benutzer k\u00f6nnen an der Umfrage teilnehmen. Bitte melden Sie sich an.<\/a><\/noindex>Sind Sie an Contour interessiert?<\/p>\n

Haben Sie in Ihrer Arbeit Erfahrungen gemacht, wenn ein Arbeitgeber versucht hat, mehrere Personen durch Sie zu ersetzen?<\/h2>\n