{"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\/sv\/blog\/administrirovanie\/devops-ili-kak-my-teryaem-zarabotnuyu-platu-i-budushhee-it-otrasli","title":{"rendered":"DevOps eller hur vi f\u00f6rlorar v\u00e5r l\u00f6n och framtiden f\u00f6r IT-branschen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Det mest sorgliga i dagens situation \u00e4r att IT gradvis blir en bransch d\u00e4r det \u00f6verhuvudtaget inte finns n\u00e5got ord som \"stopp\" n\u00e4r det kommer till antalet arbetsuppgifter f\u00f6r en person. <\/p>\n

N\u00e4r man l\u00e4ser jobbbeskrivningar ser man ibland inte bara 2-3 personer utan en hel f\u00f6retag personifierat, alla har br\u00e5ttom, den tekniska skulden v\u00e4xer, gammal legacy ser perfekt ut i j\u00e4mf\u00f6relse med nya produkter eftersom det \u00e5tminstone finns dokumentation och kommentarer i koden, nya produkter skrivs i ljusets hastighet men i slut\u00e4ndan kan de inte anv\u00e4ndas \u00e4nnu ett \u00e5r efter att de skrivits, och oftast ger det \u00e5ret inga int\u00e4kter, snarare att kostnaderna f\u00f6r \"molnet\" \u00e4r h\u00f6gre \u00e4n f\u00f6rs\u00e4ljningen av tj\u00e4nsten. Investerarnas pengar g\u00e5r till att underh\u00e5lla en tj\u00e4nst som \u00e4nnu inte fungerar men som redan har sl\u00e4ppts online som en fungerande.<\/a><\/noindex>
\nEtt exempel: ett v\u00e4lk\u00e4nt f\u00f6retag vars remaster av en gammal spel fick de l\u00e4gsta betygen i hela branschens historia. Jag var en av dem som k\u00f6pte denna produkt, men \u00e4ven nu fungerar denna produkt f\u00f6rf\u00e4rligt och borde egentligen inte ha sl\u00e4ppts i detta skick. \u00c5terbetalningar, fallande betyg, ett stort antal anv\u00e4ndarbannlysningar p\u00e5 forum f\u00f6r klagom\u00e5l p\u00e5 tj\u00e4nsternas funktion. Antalet patchar imponerar inte, utan skr\u00e4mmer, men \u00e4nd\u00e5 - produkten \u00e4r inte anv\u00e4ndbar. Om denna metod leder till s\u00e5dana resultat f\u00f6r ett f\u00f6retag som har utvecklat sedan 91, s\u00e5 \u00e4r situationen \u00e4nnu v\u00e4rre f\u00f6r f\u00f6retag som just har p\u00e5b\u00f6rjat sin verksamhet.<\/p>\n

Men detta har vi sett ur anv\u00e4ndarens perspektiv, nu l\u00e5t oss titta p\u00e5 de problem som har uppst\u00e5tt f\u00f6r de anst\u00e4llda. <\/p>\n

Jag h\u00f6r ofta p\u00e5st\u00e5endet att det inte borde finnas DevOps-team, att det \u00e4r en metodologi osv., men h\u00e4r \u00e4r problemet: f\u00f6retag har p\u00e5 n\u00e5got s\u00e4tt slutat att s\u00f6ka efter nockar, DBA, infrastrukturtekniker och build-ingenj\u00f6rer \u2013 nu \u00e4r allt en DevOps-ingenj\u00f6r i en och samma person. Sj\u00e4lvklart finns det fortfarande s\u00e5dana tj\u00e4nster i vissa f\u00f6retag, men antalet minskar. M\u00e5nga kallar detta en utveckling, jag ser personligen detta som en nedgradering, det \u00e4r om\u00f6jligt att uppr\u00e4tth\u00e5lla en h\u00f6g kunskapsniv\u00e5 inom alla omr\u00e5den och \u00e4nd\u00e5 kunna arbeta h\u00f6gst 8 timmar. Naturligtvis \u00e4r det fantasier. I verkligheten tvingas m\u00e5nga IT-anst\u00e4llda arbeta 12-14 timmar, varav 8 \u00e4r betalda. Ofta \u00e4ven utan helger, eftersom \"jag fick en uppgift, dokumentationen \u00e4r bristf\u00e4llig eller felaktig, och tj\u00e4nsten kostar dessutom\", och f\u00f6r ett enda misstag i molnet kan du i praktiken g\u00e5 m\u00e5nader utan l\u00f6n, s\u00e4rskilt om du arbetar som egenf\u00f6retagare. Vi f\u00f6rlorar faktiskt r\u00f6st i aff\u00e4rsverksamheten, tillsammans med arbetsf\u00f6rdelningen, jag st\u00f6ter allt oftare p\u00e5 att chefer blandar sig i utvecklingsprocesser, utan att f\u00f6rst\u00e5 n\u00e5got alls om dem, de f\u00f6rv\u00e4xlar aff\u00e4rsdata med applikationsarbete, vilket leder till kaos. <\/p>\n

N\u00e4r kaoset b\u00f6rjar vill f\u00f6retaget hitta den skyldige, och h\u00e4r beh\u00f6vs en universell skyldig, att l\u00e4gga skulden p\u00e5 10+ personer \u00e4r sv\u00e5rt, d\u00e4rf\u00f6r sl\u00e5r chefer ihop positioner, ju fler ansvarsomr\u00e5den en specialist har, desto enklare \u00e4r det att bevisa hans f\u00f6rsummelse. Och under Agile-f\u00f6rh\u00e5llanden \u00e4r att hitta \"den skyldige\" och straffa honom \u2013 grunden f\u00f6r denna metodik och aff\u00e4rsledning. Agile har l\u00e4nge l\u00e4mnat IT, och den grundl\u00e4ggande konceptet har blivit \u2013 krav p\u00e5 dagliga resultat. Problemet \u00e4r att en smal expert inte alltid kommer att ha ett dagligt resultat, vilket g\u00f6r det sv\u00e5rare att redovisa, och det \u00e4r ytterligare en anledning till varf\u00f6r f\u00f6retaget vill ha \"specialister p\u00e5 allt\". Men den verkliga orsaken \u00e4r f\u00f6rst\u00e5s l\u00f6nesumman \u2013 det \u00e4r den huvudsakliga orsaken till alla f\u00f6r\u00e4ndringar, f\u00f6r att f\u00e5 bonusar gick folk med p\u00e5 att arbeta f\u00f6r sig sj\u00e4lva och f\u00f6r den andra. Men i slut\u00e4ndan, precis som inom andra omr\u00e5den, har detta helt enkelt blivit en skyldighet f\u00f6r en l\u00e4gre betalning f\u00f6r fler tj\u00e4nster. <\/p>\n

Numera kan man ofta se artiklar som s\u00e4ger att utvecklare ocks\u00e5 m\u00e5ste kunna deploya och arbeta med infrastrukturen tillsammans med DevOps-ingenj\u00f6ren, men vad leder det till? R\u00e4tt \u2013 en f\u00f6rs\u00e4mring av tj\u00e4nsternas kvalitet och en minskning av utvecklarnas kompetens. F\u00f6r bara tv\u00e5 dagar sedan f\u00f6rklarade jag f\u00f6r en utvecklare att man kan l\u00e4sa och skriva fr\u00e5n olika v\u00e4rdar, men jag fick h\u00f6ra, med stor \u00f6vertygelse, att de aldrig har sett n\u00e5got s\u00e5dant, att det bara finns i inst\u00e4llningarna: orm host, port, db, user, password och allt\u2026. Men utvecklaren kan k\u00f6ra deployer, skriva YAML-filer\u2026. Men de gl\u00f6mmer bort enhetstester och kommentarer i koden.<\/p>\n

I slut\u00e4ndan ser vi f\u00f6ljande \u2013 st\u00e4ndiga \u00f6vertidsarbeten, s\u00f6kande av l\u00f6sningar p\u00e5 problem utanf\u00f6r arbetstid, konstant l\u00e4rande p\u00e5 helger, och inte f\u00f6r att \u00f6ka inkomsterna, utan f\u00f6r att h\u00e5lla sig flytande. Utvecklare tvingas hj\u00e4lpa DevOps-ingenj\u00f6ren med CI\/CD, och om utvecklaren inte har tid b\u00f6rjar det bli f\u00f6r mycket att hantera, och cheferna b\u00f6rjar komplicera livet f\u00f6r dem, och om det inte hj\u00e4lper att \u00f6ka viljan att arbeta \u00f6vertid, s\u00e5 till\u00e4mpas straff och b\u00f6ter, och personen s\u00f6ker sig till ett nytt arbete, vilket l\u00e4mnar efter sig en teknisk skuld stor som Everest, som b\u00f6rjar v\u00e4xa \u00e4ven hos utvecklarna, eftersom de tvingas skriva kod med mindre refaktorering f\u00f6r att hinna hj\u00e4lpa antingen den gamla eller den nya DevOps-ingenj\u00f6ren, och cheferna \u00e4r n\u00f6jda, eftersom den skyldige finns och \u00e4r synlig direkt, s\u00e5 det grundl\u00e4ggande regelverket i Agile-management \u00e4r f\u00f6ljt, den skyldige \u00e4r funnen, och resultaten av deras bestraffning \u00e4r tydliga. <\/p>\n

En g\u00e5ng h\u00f6ll jag ett f\u00f6redrag p\u00e5 ITGM med titeln \"n\u00e4r l\u00e4r vi oss att s\u00e4ga 'nej'\" \u2013 dess resultat var v\u00e4ldigt tydliga. Ett stort antal m\u00e4nniskor anser att det ordet \u00e4r tabu, och s\u00e5 l\u00e4nge vi forts\u00e4tter att t\u00e4nka s\u00e5 kommer problemen bara att \u00f6ka.<\/p>\n

Delvis inspirerades jag till denna artikel av denna artikel<\/a><\/noindex>, men senare kanske jag formulerar den med mindre omst\u00e4ndliga termer.<\/p>\n

Endast registrerade anv\u00e4ndare kan delta i omr\u00f6stningen. Logga in<\/a><\/noindex>, tack.<\/p>\n

Har du st\u00f6tt p\u00e5 situationer p\u00e5 jobbet d\u00e4r arbetsgivaren f\u00f6rs\u00f6ker ers\u00e4tta flera personer med dig?<\/h2>\n