Surullisinta nykytilanteessa on se, että IT:stä on vähitellen muodostumassa toimiala, jossa vastuumäärässä henkilöä kohden ei ole sanaa "stop".
Avoimia työpaikkoja lukiessa joskus ei näe edes 2-3 henkilöä, vaan koko yritys yhdessä henkilössä, kaikilla on kiire, tekninen velka kasvaa, vanha perintö näyttää täydellisyydeltä uusien tuotteiden taustalla, koska se ainakin koodissa on telakka ja kommentteja, uusia tuotteita kirjoitetaan valon nopeudella, mutta sen seurauksena niitä ei voi käyttää toista vuotta kirjoituksen jälkeen, ja usein tämä vuosi ei tuota voittoa, lisäksi kustannukset pilvi on korkeampi kuin palvelun myynti. Sijoittajien rahat menevät sellaisen palvelun ylläpitoon, joka ei vielä toimi, mutta joka on jo vapautettu verkostoon työntekijänä.
Esimerkkinä: tunnettu yritys, jonka vanhan pelin remasterointi sai alan historian alhaisimmat arvosanat. Olin yksi niistä, jotka ostivat tämän tuotteen, mutta nytkin tämä tuote toimii kauheasti, eikä teoriassa olisi pitänyt julkaista vielä tässä muodossa. Hyvitykset, luokituksen pudotus, valtava määrä käyttäjäkieltoja foorumeilla palveluiden toiminnasta valittamista varten. Laastarien määrä ei ilahduta, vaan pelottaa, mutta silti - tuote ei ole käyttökelpoinen. Jos tämä lähestymistapa johtaa tällaisiin tuloksiin vuodesta 91 lähtien kehittyneelle yritykselle, niin vasta aloittavien yritysten tilanne on vielä huonompi.
Mutta katsoimme tämän lähestymistavan tuloksia palvelun käyttäjän puolelta, ja nyt tarkastellaan työntekijöiden ongelmia.
Kuulen usein väitteen, että DevOps-tiimejä ei pitäisi olla, että tämä on metodologia jne., mutta ongelma on se, että jostain syystä yritykset ovat lakanneet etsimästä noksia, dba:ta, infruktoreita ja rakennusinsinöörejä - nyt kaikki on DevOps-insinööriä yhdessä henkilössä. Tietysti yksittäisissä yrityksissä tällaisia avoimia työpaikkoja on edelleen, mutta niitä on yhä vähemmän. Monet kutsuivat tätä kehitystä, näen henkilökohtaisesti tässä huononemisen, on mahdotonta ylläpitää hyvää tietämystä kaikilla alueilla ja samalla onnistua työskentelemään enintään 8 tuntia. Luonnollisesti nämä ovat fantasioita. Todellisuudessa monet IT-työntekijät joutuvat työskentelemään sekä 12 että 14 tuntia, joista palkallisia 8. Ja usein ilman vapaapäiviä, koska "sain tehtävän, siellä ei ole telakkaa tai käyriä ja palvelu maksaa", ja yhdestä pilvessä et voi periaatteessa saada palkkaa parissa kuukaudessa, varsinkin jos työskentelet IP-pohjaisesti. Itse asiassa menetämme sanan liiketoiminnassa, tehtävien eriyttämisen myötä joudun yhä useammin joutumaan siihen, että johtajat menevät kehitysprosesseihin ymmärtämättä yhtään mitään, sekoittavat liiketoimintadatan ja sovellusten toiminnan, minkä seurauksena kaaos. alkaa.
Kun kaaos alkaa, yritys haluaa löytää syyllisen, ja tähän tarvitaan yleinen syyllinen, on vaikea lyödä syyllistä yli 10 ihmiseen, joten johtajat yhdistävät asemansa, koska mitä enemmän tehtäviä yhdellä asiantuntijalla on, sitä helpompi on todistaa laiminlyöntinsä. Ja ketterissä olosuhteissa "syyllisten" löytäminen ja piiskaaminen on perusta tälle johtamismenetelmälle. Agile on ollut pitkään poissa IT:stä, ja sen pääkonseptista on tullut päivittäisten tulosten vaatimus. Ongelmana on, että pitkälle erikoistuneella asiantuntijalla ei aina ole päivittäistä tulosta, mikä tarkoittaa, että raportointi on vaikeampaa, ja tämä on toinen syy, miksi yritykset haluavat "asiantuntijoita kaikkeen". Mutta tärkein syy on tietysti palkkasumma - hän on kaikkien muutosten pääsyy, korvauksen vuoksi ihmiset suostuivat työskentelemään itselleen ja sille kaverille. Mutta loppujen lopuksi, kuten muillakin aloilla, siitä on nyt tullut yksinkertaisesti velvollisuus pienemmällä maksulla suuremmasta määrästä tarjottuja palveluita.
Nyt näet usein jopa artikkeleita, joita kehittäjien pitäisi jo pystyä ottamaan käyttöön, pitäisi käsitellä infrastruktuuria DevOps-insinöörin vieressä, mutta mihin tämä johtaa? Aivan oikein - palvelujen laadun laskuun, kehittäjien laadun laskuun. Kirjaimellisesti 2 päivää sitten selitin kehittäjälle, että voit kirjoittaa ja lukea eri isännistä, ja he todistivat minulle vaahdolla, että he eivät olleet koskaan nähneet mitään tällaista, tässä se on asetuksissa orm host, port, db, käyttäjä, salasana ja siinä se... Mutta kehittäjä osaa käynnistää käyttöönotot, kirjoittaa yamleja .... Mutta hän unohtaa jo koodissa olevat yksikkötestit ja kommentit.
Tuloksena näemme seuraavaa - jatkuvaa käsittelyä, ratkaisujen etsimistä ongelmiin työajan ulkopuolella, jatkuvaa koulutusta viikonloppuisin, eikä tulojen kasvattamiseksi, vaan itsemme pinnalla pitämiseksi. Kehittäjät pakotetaan auttamaan DevOps-insinööriä CI:n / CD:n kanssa, ja jos kehittäjällä ei ole aikaa, hän alkaa olla hiljaa ja johtajat alkavat kompostoida aivoja, ja jos tämä ei auta lisäämään halua tehdä ylitöitä, hae seuraamukset ja sakot, henkilö etsii uutta työpaikkaa jättäen taakseen Everestin kokoisen teknisen velan, minkä seurauksena velka alkaa kasvaa myös kehittäjien keskuudessa. Heidän on pakko kirjoittaa koodia pienemmällä refaktoroinnilla, jotta heillä olisi aikaa auttaa joko vanhaa tai uutta DevOps-insinööriä, ja johtajat ovat kaikkeen tyytyväisiä, koska syyllinen on ja hänet nähdään heti, mikä tarkoittaa, että Ketterän johtamisen pääsääntöä noudatetaan, syyllinen löydetään, hänen ruoskimisen tulokset näkyvät.
Kerran ITGM:ssä tein esityksen "kun opimme sanomaan ei" - sen tulokset olivat hyvin paljastavia. Valtava joukko ihmisiä uskoo, että tämä sana on tabu, ja kunnes emme enää ajattele niin, ongelmat vain kasvavat.
Osittain inspiroi minua kirjoittamaan tämän artikkelin., mutta kirjoitan sen ehkä vähemmän miellyttävin sanoin myöhemmin.
Vain rekisteröityneet käyttäjät voivat osallistua kyselyyn. , ole kiltti.
Oletko törmännyt työssäsi siihen, että työnantaja on yrittänyt korvata useita henkilöitä kanssasi?
-
65,6%Kyllä, törmään siihen säännöllisesti
-
5,4%Kyllä, tavattu 1 kerran15
-
15,4%En huomannut 43
-
13,6%Olen työnarkomaani, teen itse ylitöitä38
279 käyttäjää äänesti. 34 käyttäjää pidättyi äänestämästä.
Lähde: will.com