DevOps alebo ako prichádzame o mzdy a budúcnosť IT priemyslu

Najsmutnejšie na súčasnej situácii je, že IT sa postupne stáva odvetvím, kde v počte povinností na osobu vôbec nie je slovo „stop“.

Pri čítaní voľných pozícií niekedy dokonca vidíte nie 2-3 ľudí, ale celú firmu v jednej osobe, všetci sa ponáhľajú, technický dlh narastá, staré dedičstvo vyzerá na pozadí nových produktov ako dokonalosť, pretože to minimálne má v kóde dock a komentáre, nové produkty sa píšu rýchlosťou svetla, no v dôsledku toho sa po ich napísaní nedajú použiť ešte rok a často tento rok neprináša zisk, navyše náklady na cloud je vyšší ako predaj služby. Peniaze investorov idú na údržbu služby, ktorá ešte nefunguje, no už bola uvoľnená do siete ako pracovník.
Ako príklad: známa spoločnosť, ktorej remaster starej hry získal najnižšie hodnotenia v histórii tohto odvetvia. Bol som jedným z tých, ktorí si kúpili tento produkt, ale aj teraz tento produkt funguje strašne a teoreticky by ešte nemal byť uvedený na trh v tejto forme. Vrátenie peňazí, pokles hodnotenia, obrovské množstvo zákazov používateľov na fórach za sťažnosti na prácu služieb. Počet náplastí nepoteší, ale desí, ale stále - produkt nie je použiteľný. Ak tento prístup vedie k takýmto výsledkom pre firmu, ktorá sa rozvíja od roku 91, tak pre firmy, ktoré len začínajú, je situácia ešte horšia.

My sme sa ale pozreli na výsledky tohto prístupu zo strany užívateľa služby a teraz sa pozrime na problémy, ktoré majú zamestnanci.

Často počujem tvrdenie, že by nemali existovať tímy DevOps, že ide o metodiku atď., ale problém je v tom, že spoločnosti z nejakého dôvodu prestali hľadať nokov, dba, infruktorov a inžinierov stavieb - teraz je to všetko inžinier DevOps v jedinej osobe. Samozrejme, v jednotlivých firmách sú stále takéto voľné miesta, ale je ich čoraz menej. Mnohí to nazývali vývoj, ja osobne v tom vidím degradáciu, nie je možné udržať si dobrú úroveň vedomostí vo všetkých oblastiach a zároveň zvládnuť pracovať maximálne 8 hodín. Prirodzene, sú to fantázie. V skutočnosti je veľa IT pracovníkov nútených pracovať 12 aj 14 hodín, z čoho je platených 8. A často bez dní voľna, pretože „dostal som úlohu, nie sú tu žiadne doky ani zákruty a služba stojí peniaze“. a za 1 v cloude v princípe nemôžeš dostať plat za pár mesiacov, hlavne ak pracuješ na IP. V biznise vlastne strácame slovo, spolu s rozdelením povinností sa čoraz častejšie stretávam s tým, že manažéri sa do vývojových procesov dostávajú bez toho, aby vôbec ničomu rozumeli, pletú si obchodné dáta a prevádzku aplikácií, v dôsledku toho začína chaos .

Keď začne chaos, biznis chce nájsť vinníka a tu potrebujete univerzálneho vinníka, ťažko zvaliť vinu na 10+ ľudí, preto manažéri spájajú svoje pozície, pretože čím viac povinností má 1 špecialista, tým ľahšie dokázať svoju nedbanlivosť. A v podmienkach Agile je hľadanie „vinníka“ a výprask základom tejto metodiky podnikania v manažmente. Agile je už dávno mimo IT a jeho hlavným konceptom sa stala požiadavka každodenných výsledkov. Problém je v tom, že vysoko špecializovaný špecialista nebude mať vždy denný výsledok, čo znamená, že bude ťažšie vykazovať, a to je ďalší dôvod, prečo podniky chcú „špecialistov na všetko“. Ale hlavny dovod je samozrejme vyplata - on je hlavnym dovodom vsetkych zmien, kvoli prispevkom sa ludia dohodli, ze budu pracovat pre seba a toho chlapa. Ale v konečnom dôsledku, ako aj v iných oblastiach, aj teraz sa to stalo jednoducho povinnosťou, za menšiu platbu za väčší počet poskytovaných služieb.

Teraz môžete často vidieť články, ktoré by vývojári už mali vedieť nasadiť, mali by sa zaoberať infraštruktúrou vedľa inžiniera DevOps, ale k čomu to vedie? Presne tak – k poklesu kvality služieb, k poklesu kvality developerov. Doslova pred 2 dňami som vývojárovi vysvetlil, že písať a čítať sa dá z rôznych hostiteľov a oni mi s penou na ústach dokázali, že niečo také ešte nevideli, tu je to v nastaveniach orm host, port, db, užívateľ, heslo a je to .... Ale vývojár vie, ako spustiť nasadenia, napísať yamls .... Na unit testy a komentáre v kóde už ale zabúda.

Vo výsledku vidíme nasledovné – neustále vybavovanie, hľadanie riešení problémov mimo pracovnej doby, neustále tréningy cez víkendy a nie preto, aby sme zvýšili príjem, ale aby sme sa držali nad vodou. Vývojári sú nútení pomáhať inžinierovi DevOps s CI / CD, a ak vývojár nemá čas, začne mlčať a manažéri začnú kompostovať mozgy, a ak to nepomôže zvýšiť túžbu pracovať nadčas, potom požiadajte penále a pokuty, človek si hľadá novú prácu, zanecháva za sebou technický dlh veľkosti Everestu, následkom čoho dlh začína narastať aj medzi developermi. sú nútení písať kód s menším refaktorovaním, aby mali čas pomôcť starému alebo novému inžinierovi DevOps a manažéri sú celkom spokojní so všetkým, pretože je tam vinník a je ho hneď vidieť, čo znamená, že hlavné pravidlo v agilnom manažmente je dodržané, vinník sa nájde, výsledky jeho bičovania viditeľné.

Raz na ITGM som urobil prezentáciu „keď sa naučíme povedať nie“ – jej výsledky boli veľmi objavné. Obrovské množstvo ľudí verí, že toto slovo je tabu, a kým si to neprestaneme myslieť, problémy budú len narastať.

Čiastočne ma inšpirovalo k napísaniu tohto článku. tento článok, ale možno to napíšem neskôr menej príjemnými výrazmi.

Do prieskumu sa môžu zapojiť iba registrovaní užívatelia. Prihlásiť saProsím.

Stretli ste sa v práci, keď sa vám zamestnávateľ snažil nahradiť viacerých ľudí?

• 65,6%Áno, stretávam sa s tým pravidelne

• 5,4%Áno, 1 krát 15

• 15,4%Nevšimol som si 43

• 13,6%Som workoholik, sám pracujem nadčas38

Hlasovalo 279 užívateľov. 34 používatelia sa zdržali hlasovania.

Zdroj: hab.com