Najtužnije u današnjoj situaciji je to što IT postupno postaje industrija u kojoj nema riječi "stop" u broju odgovornosti po osobi.
Kad čitate natječaje, ponekad čak vidite ne 2-3 osobe, već cijelu tvrtku u jednoj osobi, svi su u žurbi, tehnički dug raste, stara ostavština na pozadini novih proizvoda izgleda kao savršenstvo, jer barem ima dokove i komentare u kodu, novi proizvodi se pišu brzinom svjetlosti, ali se na kraju ne mogu koristiti još godinu dana nakon što su napisani, a često ta godina ne donosi dobit, štoviše, troškovi „oblaka“ ” veći su od prodaje usluge. Novac investitora troši se na održavanje servisa koji još ne radi, ali je već pušten na internet kao radni.
Kao primjer: poznata tvrtka čiji je remaster stare igre dobio najniže ocjene u cijeloj povijesti industrije. Ja sam bila jedna od onih koji su kupili ovaj proizvod, ali i sada ovaj proizvod djeluje užasno, te teoretski ne bi trebao doći u prodaju u ovakvom obliku. Povrat novca, pad ocjena, ogroman broj zabrana korisnika na forumima zbog pritužbi na rad usluga. Broj zakrpa nije nevjerojatan, već zastrašujući, ali svejedno proizvod nije upotrebljiv. Ako ovakav pristup dovodi do takvih rezultata za tvrtku koja se razvija od 91. godine, onda je za tvrtke koje tek počinju situacija još gora.
No, mi smo rezultate ovakvog pristupa promatrali sa strane korisnika usluga, a sada pogledajmo probleme s kojima su se susreli zaposlenici.
Često čujem izjave da DevOps timovi ne bi trebali postojati, da je to metodologija itd., ali problem je u tome što su tvrtke iz nekog razloga prestale tražiti noksove, dba, infrastrukturne i build inženjere - sada je sve jedan DevOps inženjer . Naravno, takvih radnih mjesta u pojedinim tvrtkama još ima, ali ih je sve manje. Mnogi su ovo nazvali razvojem, ja osobno u tome vidim degradaciju, nemoguće je održati dobru razinu znanja u svim područjima, a u isto vrijeme uspjeti raditi ne više od 8 sati. Naravno, to su fantazije. U stvarnosti, mnogi informatičari prisiljeni su raditi 12 ili 14 sati, od čega je plaćeno 8. I to često bez slobodnih dana, jer “dobio sam zadatak, nema dokumenata ni krivih, a usluga košta”, a za 1 grešku u oblaku u principu ne možeš dobiti plaću za par mjeseci, pogotovo ako radiš kao individualni poduzetnik. Suštinski gubimo riječ u poslovanju, podjelom odgovornosti, sve više se suočavam s činjenicom da se menadžeri petljaju u razvojne procese, a da ih uopće ne razumiju, brkaju poslovne podatke i rad aplikacije, a kao Kao rezultat toga počinje kaos.
Kad krene kaos, biznis želi pronaći krivca, a tu treba univerzalni krivac, teško je svaliti krivnju na 10+ ljudi, pa menadžeri spajaju pozicije, jer što više odgovornosti jedan stručnjak ima, to je lakše dokazati njegov nemar. A u Agile uvjetima pronalaženje “krivih” i bičevanje temelj je ove metodologije poslovanja u menadžmentu. Agile je davno proizašao iz IT-a, a njegov glavni koncept postao je uvjet svakodnevnih rezultata. Problem je u tome što visoko specijalizirani stručnjak neće uvijek imati dnevne rezultate, što znači da će ga biti teže izvještavati, a to je još jedan razlog zašto tvrtke žele “stručnjake za sve”. Ali glavni razlog je naravno platni spisak - to je glavni razlog svih promjena, ljudi su zbog bonusa pristali raditi za sebe i za tog tipa. Ali na kraju, kao iu drugim područjima, sada je to jednostavno postala odgovornost, za manje plaćanje većeg broja pruženih usluga.
Danas često čak možete vidjeti članke koji navode da bi programeri također trebali biti u mogućnosti implementirati, trebali raditi na infrastrukturi zajedno s DevOps inženjerom, ali čemu to vodi? Tako je – do pada kvalitete usluga, do pada kvalitete developera. Prije samo 2 dana objasnio sam developeru da možete pisati i čitati s različitih hostova, a oni su s pjenom na usta dokazivali da nikad nisu vidjeli ovako nešto, ali u postavkama postoji orm host, port, db, user , lozinka i to je to… Ali programer zna kako pokretati implementacije, pisati yams... Ali već zaboravlja na jedinične testove i komentare u kodu.
Kao rezultat vidimo sljedeće - stalne prekovremene sate, traženje rješenja problema izvan radnog vremena, stalne treninge vikendom, a ne da bismo povećali prihode, već da bismo se održali. Programeri su prisiljeni pomoći DevOps inženjeru s CI/CD-om, a ako programer nema vremena, počinje zaglavljivati, a menadžeri počinju kompostirati svoje mozgove, a ako to ne pomogne povećati želju za prekovremenim radom, tada se primjenjuju kazne i novčane kazne, osoba traži novi posao, ostavlja iza sebe tehnički dug veličine Everesta, kao rezultat toga dug počinje rasti među programerima, jer prisiljeni su pisati kod s manje refactoringa kako bi imali vremena pomoći bilo starom ili novom DevOps inženjeru, a menadžeri su sasvim zadovoljni sa svime, jer je krivac tu i vidi se odmah, što znači osnovno pravilo u agilnom upravljanju se prati, krivac je pronađen, rezultati njegovog bičevanja su vidljivi.
Jednom sam održao prezentaciju na ITGM-u “Kada naučimo reći “ne”” - rezultati su bili vrlo razotkrivajući. Ogroman broj ljudi smatra da je ova riječ tabu, a sve dok ne prestanemo tako misliti, problemi će samo rasti.
Ovaj članak sam djelomično inspirirao ja, ali kasnije ću to možda opisati manje pristojnim riječima.
U anketi mogu sudjelovati samo registrirani korisnici. , molim.
Jeste li se ikada na poslu susreli da vam je poslodavac pokušao zamijeniti nekoliko ljudi?
-
65,6%Da, redovito nailazim na to183
-
5,4%Da, naišao sam 1 put15
-
15,4%Nisam primijetio43
-
13,6%Ja sam radoholičar, i sam radim prekovremeno38
Glasovalo je 279 korisnika. Suzdržana su bila 34 korisnika.
Izvor: www.habr.com