DevOps ehk kuidas me kaotame palku ja IT-tööstuse tulevikku

Kõige kurvem tänases olukorras on see, et IT on järk-järgult muutumas tööstusharuks, kus kohustuste arvus inimese kohta pole sõna "stopp".

Vabu kohti lugedes näed vahel isegi mitte 2-3 inimest, vaid tervet firmat ühes isikus, kõigil on kiire, tehniline võlg kasvab, vana pärand uute toodete taustal tundub täiuslikkusena, sest vähemalt on tal dokid ja kommentaarid koodis, uued tooted kirjutatakse küll valguskiirusel, kuid lõpuks ei saa neid pärast kirjutamist veel aasta aega kasutada ja sageli ei too see aasta kasumit, pealegi "pilve" kulud ” on kõrgemad kui teenuse müük. Investorite raha kulub veel mittetöötava, kuid juba toimivana veebis välja antud teenuse ülalpidamisele.
Näiteks: tuntud ettevõte, mille vana mängu remaster sai kogu tööstuse ajaloo madalaimad hinnangud. Olin üks nendest, kes selle toote ostis, aga ka praegu töötab see toode kohutavalt ja teoreetiliselt poleks tohtinud sellisel kujul müüki tulla. Tagasimaksed, langevad reitingud, suur hulk kasutajate keelde foorumites teenuste töö kohta esitatavate kaebuste eest. Plaastrite arv ei ole hämmastav, vaid hirmuäratav, kuid siiski pole toode kasutatav. Kui 91. aastast areneva ettevõtte puhul viib selline lähenemine selliste tulemusteni, siis alles alustavate ettevõtete puhul on olukord veelgi hullem.

Kuid me vaatasime selle lähenemisviisi tulemusi teenusekasutaja poolelt ja vaatame nüüd probleeme, millega töötajad kokku puutusid.

Tihti kuulen väidet, et DevOpsi meeskondi ei tohiks eksisteerida, et see on metoodika jne, aga häda on selles, et ettevõtted on millegipärast lõpetanud noksi, dba, infrastruktuuri ja ehitusinseneride otsimise – nüüd on see kõik üksainus DevOpsi insener . Loomulikult on üksikutes ettevõtetes selliseid vabu kohti veel, aga neid jääb aina vähemaks. Paljud nimetasid seda arengut, ma isiklikult näen selles halvenemist, kõigis valdkondades on võimatu säilitada head teadmiste taset ja samal ajal töötada mitte rohkem kui 8 tundi. Loomulikult on need fantaasiad. Tegelikkuses on paljud IT-töötajad sunnitud töötama 12 või 14 tundi, millest 8 on tasustatud. Ja sageli ilma puhkepäevadeta, sest "Mulle anti ülesanne, puuduvad dokumendid või kõverad ja teenus maksab," ja 1 vea eest pilves ei saa põhimõtteliselt paari kuuga palka, eriti kui töötad üksikettevõtjana. Oleme sisuliselt kaotamas oma sõnaõigust ettevõtluses koos kohustuste jagamisega, üha enam puutun kokku sellega, et juhid sekkuvad arendusprotsessidesse, saamata neist üldse midagi aru, ajavad segamini äriandmed ja rakenduse toimimise ning selle tulemusena algab kaos.

Kui kaos algab, soovib ettevõte leida süüdlast ja siin on vaja universaalset süüdlast, raske on süüdistada 10+ inimest, nii et juhid ühendavad ametikohti, sest mida rohkem on ühel spetsialistil kohustusi, seda lihtsam on tõestama oma hooletust. Ja Agiilsetes tingimustes on “süüdlaste” leidmine ja piitsutamine selle juhtimise äritegevuse metoodika aluseks. Agile tuli IT-st juba ammu välja ning selle põhikontseptsiooniks sai igapäevaste tulemuste nõue. Probleem on selles, et kõrgelt spetsialiseerunud spetsialistil ei ole alati igapäevaseid tulemusi, mis tähendab, et aruandlus on keerulisem ja see on veel üks põhjus, miks ettevõtted tahavad "kõige asjatundjaid". Aga peamine põhjus on muidugi palgafond - see on kõigi muudatuste peamine põhjus, boonuse nimel leppisid inimesed enda ja selle tüübi heaks tööd tegema. Kuid lõpuks, nagu ka teistes valdkondades, on nüüd lihtsalt kohustuseks muutunud suurema hulga teenuste eest vähem maksta.

Tänapäeval näete sageli isegi artikleid, mis väidavad, et ka arendajad peaksid saama juurutada, peaksid töötama infrastruktuuri kallal koos DevOpsi inseneriga, kuid milleni see viib? See on õige – teenuste kvaliteedi langusele, arendajate kvaliteedi langusele. Just 2 päeva tagasi selgitasin arendajale, et saab kirjutada ja lugeda erinevatest hostidest ja nad vahutasid suust tõestamaks, et nad pole kunagi midagi sellist näinud, aga seadetes on orm host, port, db, user , parool ja ongi kõik…. Kuid arendaja teab, kuidas juurutusi käivitada, jamssi kirjutada... Kuid ta unustab juba koodis ühikutestid ja kommentaarid.

Sellest tulenevalt näeme järgmist - pidevad ületunnid, probleemidele lahenduste otsimine väljaspool tööaega, pidev treening nädalavahetustel ja mitte sissetulekute suurendamiseks, vaid enda vee peal hoidmiseks. Arendajad on sunnitud aitama DevOpsi inseneri CI/CD-ga ja kui arendajal pole aega, hakkab ta jänni jääma ning juhid hakkavad oma ajusid komposteerima ja kui see ei aita suurendada soovi ületunde teha, seejärel rakendatakse karistusi ja trahve, inimene otsib uut tööd, jättes endast maha Everesti suuruse tehnilise võla, mille tulemusena hakkab võlg arendajate seas kasvama, sest nad on sunnitud koodi kirjutama väiksema ümbertöötamisega, et jääks aega aidata kas vana või uut DevOpsi inseneri ja juhid on kõigega üsna rahul, sest süüdlane on kohal ja ta on kohe näha, mis tähendab põhireeglit aastal Agiilne juhtimine on järgitud, süüdlane leitud, tema piitsutamise tulemused on näha.

Pidasin kord ITGM-is ettekande “kui õpime ütlema “ei”” – selle tulemused olid väga paljastavad. Tohutu hulk inimesi usub, et see sõna on tabu, ja seni, kuni me nii ei mõtle, probleemid ainult süvenevad.

See artikkel on osaliselt inspireeritud minust see artikkel, kuid hiljem võin seda kirjeldada vähem viisakalt.

Küsitluses saavad osaleda ainult registreerunud kasutajad. Logi sissepalun.

Kas olete kunagi tööl kohanud olukorda, kus tööandja üritas teiega mitut inimest asendada?

  • 65,6%Jah, ma puutun sellega regulaarselt kokku183

  • 5,4%Jah, kohanud seda 1 kord15

  • 15,4%Ei pannud tähele43

  • 13,6%Olen töönarkomaan, teen ise ületunde38

279 kasutajat hääletas. 34 kasutajat jäi erapooletuks.

Allikas: www.habr.com

Lisa kommentaar