Najsmutnejšie na súčasnej situácii je to, že IT sa postupne stáva odvetvím, kde vôbec neexistuje slovo „stop“ vo vzťahu k počtu povinností na jedného človeka.
Pri čítaní inzerátov na pracovné pozície už niekedy dokonca vidíš nie 2-3 ľudí, ale celú firmu v jednej osobe. Všetci sú v zhonu, technický dlh rastie, staré legacie v pozadí nových produktov vyzerajú ako dokonalosť, pretože aspoň v nich sú dokumentácia a komentáre v kóde. Nové produkty sú vytvárané rýchlosťou svetla, ale nakoniec ich nie je možné používať ešte rok po ich napísaní, a často tento rok neprináša zisk. Navyše náklady na „cloud“ sú vyššie ako predaj služieb. Peniaze investorov idú na údržbu ešte nefunkčnej služby, ktorá už bola uvedená do siete ako funkčná.
Napríklad: známa firma, ktorej remaster starého hry dostal najnižšie hodnotenie v histórii odvetvia. Bol som jedným z tých, ktorí si tento produkt kúpili, ale ani teraz tento produkt nefunguje dobre a mala by byť ešte predávaná v takomto stave. Vrátenie peňazí, pokles hodnotenia, obrovské množstvo banov používateľov na fórach za sťažnosti na fungovanie služieb. Počet patchov nie je úžasný, ale desivý, a predsa – produkt nie je použiteľný. Ak tento prístup vedie k takýmto výsledkom u firmy, ktorá sa zaoberá vývojom od roku 1991, potom je situácia u firiem, ktoré len začínajú, ešte horšia.
Ale toto sme sa pozreli na výsledky takéhoto prístupu z pohľadu používateľa služby, a teraz sa pozrime na problémy, ktoré vznikli zamestnancom.
Často počujem tvrdenie, že DevOps tímy by nemali existovať, že je to len metodológia a podobne, ale problém je, že firmy akosi prestali hľadať sysadminov, DBA, infraštrukturistov a build inžinierov – teraz je z toho všetko DevOps inžinier v jednej osobe. Samozrejme, v niektorých spoločnostiach ešte existujú takéto voľné pozície, ale týchto je čoraz menej. Mnohí to nazvali rozvojom, ja osobne to vidím ako degradáciu; nie je možné udržiavať dobrú úroveň vedomostí vo všetkých smeroch a zároveň stíhať robiť prácu maximálne 8 hodín. Je jasné, že to sú fantázie. V realite majú mnohí IT pracovníci povinnosť pracovať aj 12, 14 hodín, pričom platených je len 8. A často aj bez víkendov, pretože "mám úlohu, dokumentácia nie je, alebo je nesprávna, navyše za službu sa musí platiť", a za jednu chybu v cloude môžete v principe nedostať mzdu na niekoľko mesiacov, obzvlášť ak pracujete na IČO. V skutočnosti strácame slovo v biznise, spolu s rozdelením povinností, čoraz častejšie sa stretávam s tým, že manažéri zasahujú do vývojových procesov, pričom ničomu nerozumejú; pletú si obchodné dáta a prácu aplikácie, a tak nastáva chaos.
Keď nastane chaos, biznis chce nájsť vinníka, a tu potrebujú univerzálneho vinníka; hodiť vinu na viac ako 10 ľudí je ťažké, preto manažéri zlúčia pozície, lebo čím viac povinností má jeden odborník, tým jednoduchšie je dokázať jeho nedbanlivosť. A v podmienkach Agile je hľadanie "vinníka" a jeho trestanie základnou doktrínou tejto metodológie riadenia biznisu. Agile už dávno vyšlo z IT a jeho hlavná koncepcia sa stala – požiadavka na každodenné výsledky. Problém je, že úzko špecializovaný odborník nie vždy dosiahne každodenné výsledky, a teda bude ťažšie sa za niečo zodpovedať, a to je ďalší dôvod, prečo biznis chce „špecialistov na všetko“. Ale hlavnou príčinou je samozrejme mzdový fond – ten je hlavnou príčinou všetkých zmien, za príplatok sa ľudia ochotne súhlasili robiť za seba aj za kolegu. No v konečnom dôsledku, rovnako ako v iných oblastiach, sa to len stalo povinnosťou, za nižšiu odmenu za väčšie množstvo poskytovaných služieb.
Dnes často vídame dokonca aj články o tom, že by mali vývojári zvládať nasadzovanie a mať na starosti infraštruktúru spolu s inžinierom DevOps, ale kam to vedie? Správne – k poklesu kvality služieb a k poklesu kvality vývojárov. Len pred dvoma dňami som vysvetľoval vývojárovi, že je možné písať a čítať z rôznych hostiteľov, a on mi s hnevom dokázal, že to nikdy nevidel, existujú len nastavenia orm host, port, db, user, password a hotovo…. Zato vývojár vie spúšťať nasadenia, písať YAML…. Ale už zabúda na unit testy a komentáre v kóde.
Na konci vidíme nasledujúce – neustále prepracovávanie, hľadanie riešení problémov mimo pracovného času, neustále vzdelávanie cez víkend, a nie pre zvýšenie príjmov, ale na to, aby si udržali zamestnanie. Vývojári sú nútení pomáhať inžinierovi DevOps s CI/CD, a ak vývojár nemá čas, začína byť preťažený, manažéri mu začínajú robiť problémy, a ak to nepomôže zvýšiť chuť pracovať nadčasy, začnú sa zavádzať sankcie a pokuty, človek hľadá nové miesto, odchádza s technickým dlhom veľkým ako Everest, a tak sa dlh zvyšuje aj u vývojárov, pretože sú nútení písať kód s menšou refaktorizáciou, aby stihli pomôcť buď starému alebo novému inžinierovi DevOps, a manažérov to úplne vyhovuje, pretože vinník je prítomný a je ho vidieť okamžite, a teda je dodržané základné pravidlo Agile v manažmente, vinník je nájdený, výsledky jeho trestu sú viditeľné.
Niekedy som na ITGM vystupoval s prednáškou „kedy sa naučíme hovoriť „nie““ – jej výsledky boli veľmi výrečné. Obrovské množstvo ľudí považuje toto slovo za tabu, a pokiaľ to tak budeme naďalej považovať, problémy budú len narastať.
Čiastočne ma k tomuto článku inšpirovala, ale neskôr možno opíšem jej menej obchádzajúcimi termínmi.
Len registrovaní používatelia sa môžu zúčastniť prieskumu. , prosím.
Stretli ste sa vo svojej práci s tým, že zamestnávateľ sa vás snažil nahradiť niekoľkými osobami?
65,6%Áno, stretávam sa pravidelne183
5,4%Áno, stretol som sa 1 krát15
15,4%Nevšimol som si43
13,6%Som workoholik, sám pracujem nadčasy38
Hlasovalo 279 používateľov. Zdržali sa 34 používateľov.
Zdroj: habr.com
