A jelenlegi helyzetben az a legszomorúbb, hogy az informatika fokozatosan olyan iparággá válik, ahol az egy főre jutó felelősségek számában egyáltalán nincs szó „stop”.
Az üresedéseket olvasva néha még az is látszik, hogy nem 2-3 ember, hanem egy egész cég egy személyben, mindenki siet, a műszaki adósság egyre nő, a régi örökség tökéletesnek tűnik az új termékek hátterében, mert legalább dokkolóval és megjegyzésekkel rendelkezik a kódban, az új termékek fénysebességgel íródnak, de ennek következtében a megírásuk után még egy évig nem használhatók, és gyakran ez az év nem hoz nyereséget, sőt a felhő magasabb, mint a szolgáltatás eladásai. A befektetők pénze egy még nem működő, de már dolgozóként a hálózatba került szolgáltatás fenntartására megy.
Példaként: egy jól ismert cég, amelynek egy régi játékának remasterje az iparág történetének legalacsonyabb értékelését kapta. Én is azok közé tartoztam, akik ezt a terméket vásárolták, de még most is borzasztóan működik ez a termék, és elméletileg még nem kellett volna ebben a formában megjelennie. Visszatérítések, értékelések csökkenése, hatalmas számú felhasználói tiltás a fórumokon a szolgáltatások munkájával kapcsolatos panaszok miatt. A foltok száma nem örömet okoz, hanem elriaszt, de mégis - a termék nem használható. Ha ez a megközelítés egy 91 óta fejlődő cégnél ilyen eredményre vezet, akkor a most induló cégeknél még rosszabb a helyzet.
De megnéztük ennek a megközelítésnek az eredményeit a szolgáltatás igénybevevője részéről, és most nézzük meg, milyen problémákkal küzdenek a munkavállalók.
Gyakran hallom azt a kijelentést, hogy ne legyenek DevOps csapatok, hogy ez egy módszertan stb., de az a baj, hogy a cégek valamiért felhagytak a nok, dba, infructorok és build mérnökök keresésével – most már minden DevOps mérnök. egyetlen személyben. Persze az egyes cégeknél még vannak ilyen üresedések, de egyre kevesebb. Sokan ezt fejlődésnek nevezték, én személy szerint degradációt látok ebben, lehetetlen minden területen jó tudásszintet fenntartani, ugyanakkor nem lehet 8 óránál többet dolgozni. Természetesen ezek fantáziák. A valóságban sok informatikus kénytelen 12 és 14 órát is dolgozni, ebből 8. És sokszor szabadnapok nélkül, mert „feladatot kaptam, nincs dokk vagy kanyar, és pénzbe kerül a szolgáltatás”. a felhőben pedig 1-ért elvileg nem kaphatsz fizetést pár hónap alatt, főleg ha IP alapon dolgozol. Valójában szót veszítünk az üzleti életben, a feladatok szétválásával együtt egyre gyakrabban szembesülök azzal, hogy a vezetők úgy szállnak bele a fejlesztési folyamatokba, hogy egyáltalán nem értenek hozzá, összekeverik az üzleti adatokat és az alkalmazások működését, ennek következtében káosz alakul ki. elkezdődik.
Amikor elkezdődik a káosz, az üzlet meg akarja találni a tettest, és itt egy univerzális bűnösre van szükség, nehéz 10+ emberre hárítani a felelősséget, ezért a vezetők egyesítik álláspontjukat, mert minél több feladata van egy szakembernek, annál könnyebb bizonyítja hanyagságát. Az Agilis körülmények között pedig a „bűnös” megtalálása és a fenekelés az alapja ennek a menedzsment üzletviteli módszertannak. Az Agile már régóta kimaradt az informatikából, és fő koncepciója a napi eredmény követelményévé vált. A probléma az, hogy egy magasan szakosodott szakembernek nem mindig lesz napi eredménye, ami azt jelenti, hogy nehezebb lesz beszámolni, és ez egy másik ok, amiért a vállalkozások „mindenre szakembert” szeretnének. De a fő ok természetesen a bérszámfejtés - ő a fő oka minden változásnak, a pótlék kedvéért az emberek beleegyeztek, hogy maguknak és annak a srácnak dolgozzanak. De végül, mint más területeken, most is egyszerűen kötelezettséggé vált, kisebb összegért, több szolgáltatásért.
Mostanában gyakran még olyan cikkeket is láthatunk, amelyeket a fejlesztőknek már tudniuk kellene telepíteni, egy DevOps mérnök mellett kell az infrastruktúrával foglalkozniuk, de mihez vezet ez? Ez így van - a szolgáltatások minőségének csökkenéséhez, a fejlesztők minőségének csökkenéséhez. Szó szerint 2 napja elmagyaráztam a fejlesztőnek, hogy lehet írni-olvasni különböző hostokról, és habbal bebizonyították nekem, hogy ilyet még nem láttak, itt van a beállításokban orm host, port, db, felhasználó, jelszó és ennyi... De a fejlesztő tudja, hogyan indítsa el a telepítéseket, írjon yamlokat .... De a kódban már megfeledkezik az egységtesztekről és a megjegyzésekről.
Ennek eredményeként a következőket látjuk - folyamatos feldolgozás, munkaidőn kívüli problémamegoldások keresése, hétvégenként folyamatos képzés, és nem a bevétel növelése, hanem a talpon tartás. A fejlesztők kénytelenek segíteni egy DevOps mérnöknek CI-vel / CD-vel, és ha a fejlesztőnek nincs ideje, akkor elkezd elhallgatni, a menedzserek pedig elkezdik komposztálni az agyakat, és ha ez nem segít növelni a túlórázási kedvet, akkor jelentkezzen. szankciók és pénzbírságok miatt az illető új állást keres, Everest méretű műszaki tartozást hagyva maga után, ennek hatására a fejlesztők körében is nőni kezd az adósság. kénytelenek kevesebb refaktorizálással kódot írni, hogy legyen idejük segíteni akár egy régi, akár egy új DevOps mérnöknek, és a menedzserek mindennel elégedettek, mert van egy bűnös, akit azonnal látnak, ami azt jelenti, hogy Az agilis gazdálkodás fő szabályát betartják, a bűnöst megtalálják, korbácsolásának eredménye látható.
Egyszer az ITGM-en tartottam egy prezentációt „amikor megtanulunk nemet mondani” – az eredményei nagyon leleplezőek voltak. Nagyon sokan úgy gondolják, hogy ez a szó tabu, és amíg nem hagyjuk abba a gondolkodást, a problémák csak növekedni fognak.
Részben inspirált a cikk megírására., de később talán kevésbé kellemes kifejezésekkel írom le.
A felmérésben csak regisztrált felhasználók vehetnek részt. , kérem.
Találkozott-e már a munkahelyén, amikor a munkáltató több embert próbált helyettesíteni Önnel?
-
65,6%Igen, rendszeresen belefutok
-
5,4%Igen, 1 alkalommal találkoztam15
-
15,4%Észre sem vette43
-
13,6%Munkamániás vagyok, magam is túlórázom38
279 felhasználó szavazott. 34 felhasználó tartózkodott.
Forrás: will.com