{"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\/da\/blog\/administrirovanie\/devops-ili-kak-my-teryaem-zarabotnuyu-platu-i-budushhee-it-otrasli","title":{"rendered":"DevOps eller hvordan vi taber vores l\u00f8n og fremtid inden for IT-branchen.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Det mest bekymrende ved den nuv\u00e6rende situation er, at IT-gradvis bliver en branche, hvor ordet \"stop\" slet ikke eksisterer i forhold til m\u00e6ngden af opgaver for \u00e9n person. <\/p>\n

N\u00e5r man l\u00e6ser jobopslag, ser man ikke sj\u00e6ldent ikke 2-3 personer, men en hel virksomhed samlet i \u00e9n person. Alle haster, teknisk g\u00e6ld stiger, gammel legacy ser ud til at v\u00e6re perfekt i sammenligning med nye produkter, da der i det mindste er dokumentation og kommentarer i koden. De nye produkter udvikles med lynets hast, men kan ofte ikke bruges i et \u00e5r efter deres f\u00e6rdigg\u00f8relse, og dette \u00e5r genererer ofte ikke noget overskud. Desuden er omkostningerne ved \"cloud\" h\u00f8jere end salget af tjenesten. Investorernes penge g\u00e5r til vedligeholdelse af en tjeneste, der endnu ikke fungerer, men som allerede er blevet lanceret som operationel.<\/a><\/noindex>
\nFor eksempel: et kendt firma, hvis remaster af et gammelt spil har f\u00e5et de laveste bed\u00f8mmelser i hele industriens historie. Jeg var en af dem, der k\u00f8bte dette produkt, men selv nu fungerer det forf\u00e6rdeligt, og teoretisk set skulle det slet ikke have v\u00e6ret lanceret i denne tilstand. Refunderinger, fald i ratings, et stort antal bans af brugere p\u00e5 forum for at klage over tjenesternes funktion. Antallet af patches er ikke imponerende, men skr\u00e6mmende, men alligevel \u2013 produktet er ikke brugbart. Hvis denne tilgang giver s\u00e5danne resultater for et firma, der har arbejdet med udvikling siden 91, s\u00e5 er situationen endnu v\u00e6rre for virksomheder, der lige er begyndt deres aktiviteter.<\/p>\n

Men det var vores syn p\u00e5 resultaterne af denne tilgang fra brugersiden af tjenesten; lad os nu se p\u00e5 de problemer, der er opst\u00e5et for medarbejderne. <\/p>\n

Jeg h\u00f8rer ofte p\u00e5standen, at der ikke skal v\u00e6re DevOps-teams, at det er en metodologi osv., men problemet er, at virksomhederne p\u00e5 en eller anden m\u00e5de er holdt op med at lede efter netv\u00e6rksfolk, DBAs, infrastrukturfolk og build-ingeni\u00f8rer \u2013 nu er det hele DevOps-ingeni\u00f8rens ansvar. Selvf\u00f8lgelig findes der stadig s\u00e5danne stillinger i nogle virksomheder, men de bliver f\u00e6rre. Mange kalder dette en udvikling, men personligt ser jeg det som en degradation; det er umuligt at opretholde et h\u00f8jt vidensniveau p\u00e5 alle omr\u00e5der, samtidig med at man skal arbejde h\u00f8jst 8 timer. Naturligvis er det fantasier. I virkeligheden er mange IT-folk tvunget til at arbejde 12-14 timer, hvoraf kun 8 er betalt. Og ofte uden weekender, fordi \"jeg fik en opgave, dokumentationen er ikke til stede eller er mangelfuld, og servicen koster\", og for en enkelt fejl i skyen kan man i princippet miste l\u00f8nnen i et par m\u00e5neder, is\u00e6r hvis man arbejder som selvst\u00e6ndig. Faktisk mister vi ordet i forretningen sammen med opdelingen af ansvar; jeg st\u00f8der oftere p\u00e5, at ledere blander sig i udviklingsprocesserne, uden at have forstand p\u00e5 dem, de forveksler forretningsdata med applikationsarbejde, hvilket f\u00f8rer til kaos. <\/p>\n

N\u00e5r kaosset begynder, \u00f8nsker forretningen at finde en syndebuk, og her er behovet for en universel syndebuk. Det er sv\u00e6rt at l\u00e6gge skylden p\u00e5 10+ personer, derfor samler lederne positionerne, for jo flere ansvar en enkelt specialist har, desto lettere er det at bevise hans uagtsomhed. I en Agile-ramme er det at finde den \"skyldige\" og straffe vedkommende grundl\u00e6ggende i metodologien for forretningsledelse. Agile er for l\u00e6ngst kommet ud af IT, og dens hovedkoncept er kravet om daglige resultater. Problemet er, at en specialiseret specialist ikke altid vil have et dagligt resultat, hvilket g\u00f8r det sv\u00e6rere at rapportere, og det er endnu en grund til, at forretningen \u00f8nsker \"specialister p\u00e5 alle omr\u00e5der\". Men den prim\u00e6re \u00e5rsag er selvf\u00f8lgelig l\u00f8nudgifter \u2013 det er den prim\u00e6re \u00e5rsag til alle \u00e6ndringer; for till\u00e6g er folk villige til at arbejde for sig selv og en anden. Men i sidste ende er det ligesom i andre omr\u00e5der, blot blevet en forpligtelse for mindre betaling for en st\u00f8rre m\u00e6ngde ydelser. <\/p>\n

Nu kan man ofte se artikler om, at udviklere ogs\u00e5 skal kunne deploye og arbejde med infrastrukturen ved siden af DevOps-ingeni\u00f8rer, men hvad f\u00f8rer det til? Rigtigt - en nedgang i kvaliteten af tjenester og en forringelse af udviklernes kvalitet. For blot 2 dage siden forklarede jeg en udvikler, at man kan skrive og l\u00e6se fra forskellige v\u00e6rter, men jeg blev ved med at h\u00f8re, at de aldrig havde set det f\u00f8r; der er indstillinger som orm host, port, db, user, password, og det er det.... Til geng\u00e6ld kan udvikleren starte deployment, skrive YAML-filer.... Men de glemmer allerede enhedstestene og kommentarerne i koden.<\/p>\n

Resultatet er, at vi ser f\u00f8lgende \u2013 konstant overarbejde, s\u00f8gning efter l\u00f8sninger p\u00e5 problemer uden for arbejdstiden, konstant l\u00e6ring i weekenderne, og ikke for at \u00f8ge indt\u00e6gterne, men for at holde sig flydende. Udviklerne er n\u00f8dt til at hj\u00e6lpe DevOps-ingeni\u00f8ren med CI\/CD, og hvis udvikleren ikke har tid, begynder de at blive overbebyrdede, og lederne begynder at give dem psykisk pres, og hvis det ikke \u00f8ger viljen til at arbejde overtid, s\u00e5 anvender de sanktioner og b\u00f8der, hvilket f\u00e5r personen til at s\u00f8ge et nyt job og efterlader en teknisk g\u00e6ld p\u00e5 st\u00f8rrelse med Everest. Som resultat begynder g\u00e6lden at vokse ogs\u00e5 for udviklerne, da de er n\u00f8dt til at skrive kode med mindre refactoring for at n\u00e5 at hj\u00e6lpe enten den gamle eller nye DevOps-ingeni\u00f8r, mens lederne er helt tilfredse, for der er en skyldig person, og han kan identificeres straks, hvilket betyder, at den grundl\u00e6ggende regel i Agile management er overholdt, den skyldige er fundet, og resultaterne af deres straf er synlige. <\/p>\n

Engang pr\u00e6senterede jeg p\u00e5 ITGM med et foredrag kaldet \"hvorn\u00e5r l\u00e6rer vi at sige 'nej'\" \u2013 dens resultater var meget sigende. Et enormt antal mennesker mener, at dette ord er tabu, og s\u00e5 l\u00e6nge vi ikke stopper med at tro det, vil problemerne kun vokse.<\/p>\n

Delvist blev jeg inspireret til denne artikel af denne artikel<\/a><\/noindex>, men jeg vil senere m\u00e5ske uddybe den med mindre indirekte termer.<\/p>\n

Kun registrerede brugere kan deltage i unders\u00f8gelsen. Log ind<\/a><\/noindex>, please.<\/p>\n

Har du oplevet, n\u00e5r arbejdsgiveren fors\u00f8ger at erstatte flere personer med dig?<\/h2>\n