🥇DevOps nebo jak ztrácíme mzdu a budoucnost IT odvětví

Nejvíc smutné na dnešní situaci je, že IT se postupně stává odvětvím, kde vůbec neexistuje slovo "stop" co se týče povinností pro jednu osobu.

Při čtení inzerátů na pracovní pozice už někdy nevidíš 2-3 lidi, ale celou firmu v jedné osobě, všichni se ženou, technický dluh roste, staré legacy v kontrastu s novými produkty vypadá jako dokonalost, protože v něm aspoň existuje dokumentace a komentáře v kódu, nové produkty se píší závratnou rychlostí, ale nakonec jimi nelze užívat ještě rok po jejich napsání, a často tento rok nepřináší zisk, ba naopak, náklady na "cloud" jsou vyšší než prodeje služby. Peníze investorů odcházejí na udržení ještě nefungující služby, která už však byla uvedena do oběhu jako funkční.
Příklad: známá společnost, jejíž remaster staré hry získal nejnižší hodnocení v historii odvětví. Byl jsem jedním z těch, kdo si tento produkt zakoupil, ale i teď tento produkt funguje příšerně, a teoreticky by ještě neměl být v takovém stavu uváděn do prodeje. Vrácení peněz, pády hodnocení, obrovské množství banů uživatelů na fórech za stížnosti na fungování služeb. Počet patchů neoslňuje, spíše děsí, ale přesto – produkt není použitelný. Pokud tento přístup vede k takovým výsledkům ve společnosti, která se zabývá vývojem od roku 91, pak situace ve společnostech, které teprve začínají svou činnost, je ještě horší.

Ale podívali jsme se na výsledky tohoto přístupu z pohledu uživatele služby, nyní se podívejme na problémy, které vznikly u zaměstnanců.

Často slyším tvrzení, že DevOps týmy by neměly existovat, že je to metodologie atd., ale problém je, že společnosti nějak přestaly hledat nocky, dba, infrastruktury a build inženýry – nyní je to všechno DevOps inženýr v jednom. Samozřejmě, v některých jednotlivých firmách takové pozice stále existují, ale je jich stále méně. Mnozí to nazývají vývojem, já osobně v tom vidím degradaci; nelze udržovat dobrý úroveň znalostí ve všech směrech a zároveň stíhat pracovat maximálně 8 hodin. Samozřejmě – to jsou fantazie. Ve skutečnosti musí mnozí IT odborníci pracovat i 12, 14 hodin, z nichž je placeno jen 8. A často i bez víkendů, protože „mám úkol, dokumentace není, nebo je chybná, a ještě k tomu služba něco stojí“, a za 1 chybu v cloudu můžete v podstatě nedostávat plat po dobu několika měsíců, zejména pokud pracujete na IČO. V podstatě ztrácíme slovo v byznysu, spolu se dělením povinností, stále častěji se setkávám s tím, že manažeři zasahují do procesů vývoje, přičemž vůbec nerozumí, pletou si obchodní data a práci aplikace, a v důsledku toho začne chaos.

Když začne chaos, byznys chce najít viníka, a zde potřebuje univerzálního viníka; přehodit vinu na 10+ lidí je těžké, proto manažeři zjednodušují pozice, protože čím více povinností má 1 odborník, tím snazší je dokázat jeho nedbalost. A v podmínkách Agile je hledání „viníka“ a jeho potrestání základem této metodologie řízení byznysu. Agile dávno vyšel z IT, a jeho hlavní koncept se stal – požadavek na denní výsledky. Problém je v tom, že specialistovi s úzkou specializací nemusí vždy vycházet denní výsledek, a tedy bude těžší se vykázat, a to je další důvod, proč byznys chce „specialisty na všechno“. Ale hlavní důvod je samozřejmě mzdový fond – je to hlavní příčina všech změn, kvůli přídavkům lidé souhlasili pracovat za sebe a toho druhého. Ale nakonec, jako v jiných oblastech, se to prostě stalo nyní povinností, za nižší plat za větší množství poskytovaných služeb.

Dnes můžeme často vidět dokonce články o tom, že by i vývojáři měli umět nasazovat, měli by se zabývat infrastrukturou vedle DevOps inženýra, ale kam to vede? Správně – k poklesu kvality služeb, k poklesu kvality vývojářů. Doslova před 2 dny jsem vysvětloval vývojáři, že psaní a čtení může probíhat z různých hostitelů, a s nadšením mi dokazovali, že to nikdy neviděli, tady máme v nastavení orm host, port, db, user, password a to je vše…. Ale vývojář umí spouštět nasazení, psát yml soubory…. Už ale zapomíná na unit testy a komentáře v kódu.

Nakonec vidíme následující – neustálé přepracovávání, hledání řešení problémů mimo pracovní dobu, neustálé vzdělávání o víkendech, a to ne pro růst příjmů, ale pro udržení se na hladině. Vývojáři jsou nuceni pomáhat DevOps inženýrovi s CI/CD, a pokud má vývojář málo času, začne se tlak zvyšovat, a manažeři začnou zatěžovat hlavu, a pokud to nepomůže zvýšit chuť pracovat přesčas, začnou uplatňovat postihy a pokuty, člověk hledá nové pracovní místo, zanechávajíc po sobě technický dluh ve velikosti Everestu, v důsledku toho dluh začíná růst i u vývojářů, protože jsou nuceni psát kód s menším refaktoringem, aby stihli pomoci buď starému nebo novému DevOps inženýrovi, a manažeři jsou s tím stále spokojeni, protože viník je jasný a je vidět hned, což znamená, že bylo dodrženo základní pravidlo Agile v managementu, viník nalezen, výsledky jeho potrestání jsou viditelné.

Kdysi jsem na ITGM vystupoval s přednáškou „Kdy se naučíme říkat 'ne'“ – její výsledky byly velmi výmluvné. Ohromné množství lidí si myslí, že toto slovo je tabu, a dokud to tak budeme považovat, problémy se budou jen zhoršovat.

Částečně mě k tomuto článku přivedla tento článek, ale později jej možná podrobněji rozepíšu méně obratnými termíny.

Pouze registrovaní uživatelé se mohou účastnit ankety. Přihlaste se, prosím.