Põhjustav mure tänases olukorras on see, et IT muutub järk-järgult valdkonnaks, kus sõna „peatuma” ei ole üldse, kuna ühe inimese kohustuste hulk suureneb pidevalt.
Tööpakkumisi lugedes näed mõnikord juba mitte 2-3 inimest, vaid terve ettevõtte ühes isikus, kõik kiirustavad, tehnoloogilised kohustused kasvavad, vana legacy tundub uute toodete taustal täiuslikkuse kehastusena, sest seal on vähemalt dokumentatsioon ja kommentaarid koodis, uued tooted kirjutatakse valguskiirusel, kuid lõpuks ei saa neid kasutada enne aastat pärast nende valmimist, ja kõige hullem, et see aasta ei too kasumit, pigem on „pilve” kulud suuremad kui teenuse müük. Investorite raha läheb veel mitte töötava teenuse üleval pidamiseks, mis on juba välja lastud kui toimiv.
Näiteks: tuntud ettevõte, kelle vanema mängu remaster on saanud tööstuse ajaloo madalaimad hinnangud. Ma olin üks neist, kes selle toote ostis, kuid isegi nüüd töötab see toode kohutavalt ning ei tohiks sellisel kujul müügile tulla. Raha tagastamine, reitingute langus, tohutu arv kasutajabaneeringuid foorumites seoses teenuste tööga. Patchide arv ei hämmasta, vaid šokeerib, kuid toode on ikkagi kasutamiskõlbmatu. Kui selline lähenemine toob selliseid tulemusi ettevõttes, mis on arendamisega tegelenud alates 1991. aastast, siis alustavate ettevõtete olukord on veel halvem.
Kuid vaatame nüüd seda lähenemist teenuse kasutaja vaatepunktist, nüüd aga vaadakem probleeme, mis on tekkinud töötajatele.
Ma kuulen tihti väidet, et DevOps meeskondi ei tohiks olla, et see on lihtsalt metodoloogia jne, aga probleem on selles, et ettevõtted on mingil põhjusel lõpetanud spetsialistide, dba-de, infrastruktuuriinseneride ja build-inseneride otsimise – nüüd on see kõik üksik DevOps insener. Muidugi on mõnes ettevõttes selliseid vabu ametikohti veel, kuid neid on järjest vähem. Paljud on seda nimetanud arenguks, aga mina näen selles allakäiku – on võimatu hoida igas valdkonnas head teadmiste taset ja samas töötada mitte rohkem kui 8 tundi. Loomulikult on see vaid fantaasia. Tões, paljud IT-spetsialistid peavad töötama 12–14 tundi, millest makstakse ainult 8. Ja tihti ka ilma nädalavahetusteta, sest "minule anti ülesanne, dokumente pole või need on vigased, ja teenus maksab liiga palju", ning ühe vea puhul pilves võid üldiselt palka mitu kuud mitte saada, eriti kui töötad FIE-na. Me kaotame tegelikult sõna äris koos kohustuste jagamisega, ma sattun üha enam olukordadesse, kus juhid sekkuvad arendusprotsessidesse, mõistmata nendest üldse midagi, nad ajavad segamini ärilisi andmeid ja rakenduse tööd, mille tulemusel algab kaos.
Kui caos tekib, soovib ettevõte leida süüdlase, ja siis on vaja universaalset süüdlast; on keeruline süü kanda 10+ inimesele, mistõttu juhid ühendavad ametikohti, kuna mida rohkem on ühe spetsialisti kohustusi, seda lihtsam on tõestada tema hooletust. Agile’i kontekstis on 'süüdlase' leidmine ja karistamine äritegevuse juhtimise meetodoloogia alused. Agile on ammu IT-st välja kasvanud ja selle peamine kontseptsioon on igapäevaste tulemuste nõudmine. Probleem on selles, et kitsas spetsialiseerumisega spetsialistil ei pruugi igapäevaselt tulemusi olla, seega on aruandlus keerulisem, ja see on veel üks põhjus, miks ettevõtted soovivad 'kõiki ametikohti katvaid spetsialiste'. Kuid peamine põhjus on siiski palgakulud – see on kõigi muutuste aluseks; lisatasu nimel nõustusid inimesed töötama enda ja teiste eest. Lõpptulemusena on see nagu teistes valdkondades – sellest on saanud kohustus, millega pakutakse rohkem teenuseid väiksema tasu eest.
Praegu näeb sageli artikleid, kus väidetakse, et arendajad peavad oskama kasutada deploy't ja tegelema infrastruktuuriga koos DevOps inseneriga. Kuid kuhu see viib? Õigesti – teenuste kvaliteedi langusele ja arendajate kvaliteedi halvenemisele. Just paar päeva tagasi selgitasin arendajale, et kirjutamine ja lugemine võib toimuda erinevatelt hostidelt, aga tema tõestas sõnaselgelt, et ei ole kunagi sellist asju näinud. Tal on olemas settings'is orm host, port, db, user, password ja kõik… Kuid arendaja oskab käivitada deploy'sid ja kirjutada YAML'e… Kuid unustab juba ühitestid ja kommentaarid koodis.
Kokkuvõttes näeme järgmist – pidevad ületöötamised, probleemide lahendamine väljaspool tööaega, pidev õppimine nädalavahetustel, ja mitte suurtulu saavutamiseks, vaid enda pinnal püsimiseks. Arendajad peavad aitama DevOps inseneri CI/CD-s, ja kui arendajal pole aega, algab tal ülekoormus, ning juhid hakkavad ajusid segama, ning kui see ei aita suurendada soovi teha ületööd, võivad nad rakendada karistusi ja trahve. Inimene otsib uut töökohta, jättes maha tehnilise võla, mis on suur nagu Everest, mille tulemusena võlg hakkab suurenema ka arendajatel, kuna nad peavad kirjutama koodi vähem refaktoorides, et jõuda kas iidse või uue DevOps insenerini aidata. Ja juhid on sellega täiesti rahul, kuna süüdistatava leidmine on lihtne ja nähtav, seega on peamine reegel Agile juhtimises täidetud – süüdlane on leitud, ja karistamise tulemused on nähtavad.
Kordagi ITGM-is esitasin ettekande "Kui me õpime ütlema 'ei'" — selle tulemused olid väga kõnekad. Suur hulk inimesi arvab, et see sõna on tabu, ja kuni me ei lakka nii arvamast, probleemid ainult kasvavad.
Osaliselt inspireeris mind sellele artiklile, kuid hiljem kirjutan ma selle võib-olla vähem ümber käivate terminitega.
Ainult registreeritud kasutajad saavad küsitluses osaleda. , palun.
Kas olete töö käigus kokku puutunud olukordadega, kus tööandja üritas teid asendada mitme inimesega?
65,6%Jah, puutun regulaarselt kokku183
5,4%Jah, olen kokku puutunud 1 kord15
15,4%Ei ole märganud43
13,6%Olen tööholik, töötan ise ületunde38
Häälestasid 279 kasutajat. 34 kasutajat jäid erapooletuks.
Allikas: habr.com
