DevOps ali kako izgubljamo plače in prihodnost IT industrije

Najbolj žalostno v trenutni situaciji je, da IT postopoma postaja panoga, kjer pri številu odgovornosti na osebo sploh ni besede "stop".

Ko berete prosta delovna mesta, včasih celo ne vidite 2-3 ljudi, ampak celotno podjetje v eni osebi, vsem se mudi, tehnični dolgovi rastejo, stara zapuščina je na ozadju novih izdelkov videti kot popolnost, ker je vsaj ima priklop in komentarje v kodi, novi izdelki se pišejo s svetlobno hitrostjo, vendar jih posledično ni več mogoče uporabljati še eno leto po tem, ko so napisani, in pogosto to leto ne prinese dobička, poleg tega so stroški oblak je višji od prodaje storitve. Denar vlagateljev gre za vzdrževanje storitve, ki še ne deluje, a je že bila sproščena v omrežje kot delavec.
Kot primer: znano podjetje, katerega remaster stare igre je prejel najnižje ocene v zgodovini industrije. Bil sem eden tistih, ki je kupil ta izdelek, vendar tudi zdaj ta izdelek deluje grozljivo in teoretično še ne bi smel biti izdan v tej obliki. Povračila, padec ocene, ogromno število prepovedi uporabnikov na forumih zaradi pritožb glede dela storitev. Število obližev ne razveseli, ampak grozi, a vseeno - izdelek ni uporaben. Če ta pristop vodi do takšnih rezultatov za podjetje, ki se razvija od leta 91, potem je za podjetja, ki šele začenjajo, stanje še slabše.

Pogledali pa smo rezultate tega pristopa na strani uporabnika storitve, zdaj pa poglejmo težave, ki jih imajo zaposleni.

Pogosto slišim izjave, da ne bi smelo biti ekip DevOps, da je to metodologija itd., Toda težava je v tem, da so podjetja iz nekega razloga prenehala iskati noks, dba, infrastrukture in gradbene inženirje - zdaj je vse inženir DevOps v eni sami osebi. Seveda so v posameznih podjetjih takšna prosta delovna mesta še vedno, a jih je vedno manj. Mnogi so temu rekli razvoj, sam v tem vidim degradacijo, nemogoče je ohraniti dobro raven znanja na vseh področjih, hkrati pa uspeti delati največ 8 ur. Seveda so to fantazije. V resnici je veliko IT delavcev prisiljenih delati tako 12 kot 14 ur, od tega je plačanih 8. In pogosto brez prostih dni, ker »dobil sem nalogo, ni pristanišč in ovinkov, storitev pa stane«, in za 1 v oblaku lahko načeloma ne dobiš plače v parih mesecih, sploh če delaš na IP. Pravzaprav v poslu izgubljamo besedo, z delitvijo nalog se vedno bolj soočam s tem, da se menedžerji vtikajo v razvojne procese, ne da bi se čisto nič razumeli, zamenjujejo poslovne podatke in delovanje aplikacij, posledično kaos. se začne.

Ko se začne kaos, želi posel najti krivca, tukaj pa rabiš univerzalnega krivca, težko je zvaliti krivdo na 10+ ljudi, zato si menedžerji združijo položaje, saj več kot ima 1 specialist, lažje je dokazati njegovo malomarnost. In v pogojih Agile je iskanje "krivega" in šeškanje osnova te metodologije za poslovanje v managementu. Agile že dolgo ni več v IT, njegov glavni koncept pa je postal zahteva za vsakodnevne rezultate. Težava je v tem, da visoko specializiran specialist ne bo imel vedno dnevnega rezultata, kar pomeni, da ga bo težje poročati, in to je še en razlog, zakaj podjetja želijo »strokovnjake za vse«. Ampak glavni razlog je seveda plačilna lista - on je glavni razlog za vse spremembe, zavoljo dodatka so ljudje pristali delati zase in za tistega tipa. A na koncu je, tako kot na drugih področjih, zdaj preprosto postala obveznost, manjše plačilo za večje število opravljenih storitev.

Zdaj lahko pogosto vidite celo članke, da bi morali biti razvijalci že sposobni namestiti, bi se morali ukvarjati z infrastrukturo poleg inženirja DevOps, toda do česa to vodi? Tako je – do padca kakovosti storitev, do padca kakovosti razvijalcev. Dobesedno pred 2 dnevoma sem razvijalcu razložil, da lahko pišete in berete z različnih gostiteljev, in dokazali so mi s peno na ustih, da še nikoli niso videli česa takega, tukaj je v nastavitvah ali gostitelj, vrata, db, uporabnik, geslo in to je to .... Toda razvijalec ve, kako zagnati uvedbe, napisati yaml .... Pozablja pa že na enotne teste in komentarje v kodi.

Kot rezultat vidimo naslednje - nenehno obdelavo, iskanje rešitev za težave izven delovnega časa, nenehno usposabljanje ob vikendih in ne za povečanje dohodka, ampak za to, da ostanemo na površju. Razvijalci so prisiljeni pomagati inženirju DevOps s CI / CD, in če razvijalec nima časa, začne utihniti, menedžerji pa začnejo kompostirati možgane, in če to ne pomaga povečati želje po nadurnem delu, se prijavi kazni in glob, oseba išče novo službo, za seboj pa pusti tehnični dolg v velikosti Everesta, posledično začne dolg rasti tudi med razvijalci. so prisiljeni pisati kodo z manj refactoringa, da bi imeli čas pomagati bodisi staremu bodisi novemu DevOps inženirju, menedžerji pa so z vsem zadovoljni, ker obstaja krivec in se ga takoj vidi, kar pomeni, glavno pravilo pri Agile managementu je upoštevano, krivec je najden, rezultati njegovega bičanja so vidni.

Nekoč sem na ITGM naredil predstavitev "ko se naučimo reči ne" - njeni rezultati so bili zelo razkrivajoči. Ogromno ljudi meni, da je ta beseda tabu, in dokler ne bomo nehali tako razmišljati, bodo težave le še naraščale.

Delno me je spodbudilo k pisanju tega članka. Ta članek, vendar ga bom morda pozneje napisal v manj prijetnih izrazih.

V anketi lahko sodelujejo samo registrirani uporabniki. Prijaviti se, prosim.

Ste se pri delu srečali s tem, da je delodajalec z vami poskušal zamenjati več ljudi?

  • 65,6%Da, redno naletim na to

  • 5,4%Da, srečal 1-krat15

  • 15,4%Nisem opazil 43

  • 13,6%Sem deloholik, sam delam nadure38

Glasovalo je 279 uporabnikov. 34 uporabnika sta se vzdržala.

Vir: www.habr.com

Dodaj komentar