A legszomorúbb a mai helyzetben az, hogy az IT fokozatosan olyan ágazattá válik, ahol egy ember feladatai között egyáltalán nincs meg a „stop” szó.
Pályázatok olvasása közben néha már nem is 2-3 emberről van szó, hanem egy egész cégről egy személyben, mindenki siet, a technológiai adósság nő, a régi legacy meglepetésként tűnik fel az új termékek hátterében, mert abban legalább van dokumentáció és kódkommentek, míg az új termékek fénysebességgel készülnek, de végül egy éven át nem lehet használni őket az elkészítésük után, és sok esetben ez az év nem hoz nyereséget, sőt, a „felhő” költségei magasabbak, mint a szolgáltatás értékesítése. A befektetők pénze egy még nem működő szolgáltatás fenntartására megy el, amelyet már online adtak ki mint működőt.
Például: egy ismert cég, amelynek egy régi játék remasterelve a legrosszabb értékeléseket kapta az ipar történetében. Én voltam az egyik, aki megvásárolta ezt a terméket, de még most is borzalmasan működik, és elvileg még ilyen formában nem kellett volna értékesítésre kerülnie. A pénzvisszatérítés, a besorolás csökkenése, a felhasználók hatalmas száma a fórumokon a szolgáltatások működésével kapcsolatos panaszok miatt. A javítások száma nem csodálatos, hanem rémisztő, de ennek ellenére a termék nem használható. Ha ez a megközelítés ilyen eredményekhez vezet egy ilyen régi fejlesztőcégnél, amely 91 óta foglalkozik fejlesztéssel, akkor azoknál a cégeknél, amelyek most kezdik tevékenységüket, a helyzet még rosszabb.
De most úgy néztük meg ennek a megközelítésnek az eredményeit a szolgáltatás felhasználójának tükrében, most pedig nézzük meg a problémákat, amelyek a munkavállalóknál merültek fel.
Gyakran hallom azt az állítást, hogy nem szükséges DevOps csapat, hogy ez egy módszertan stb., de a helyzet az, hogy a cégek valamiért abbahagyták a nockok, dba, infrastruktúra szakemberek és build mérnökök keresését – most minden DevOps mérnök a szó szoros értelmében. Természetesen néhány cég esetében még léteznek ilyen állások, de ezek száma folyamatosan csökken. Sokan ezt fejlődésnek nevezik, én azonban ebben a leépülést látom, lehetetlen párhuzamosan fenntartani minden területen a magas szintű tudást, és emellett nem tudni dolgozni többet 8 óránál. Természetesen – ez utópiák. A valóságban sok IT-s kénytelen 12-14 órát dolgozni, amiből 8 órát fizetnek. És sokszor hétvégén is, mert "feladatot kaptam, a dokumentáció hiányos vagy hibás, és a szolgáltatás is túl sokba kerül", ráadásul egy hiba a felhőben lényegében akár hónapok bérét is felemésztheti, különösen, ha egyéni vállalkozóként dolgozol. Valójában elveszítjük a szót az üzletben, együtt a felelősségek elosztásával, egyre gyakrabban találkozom azzal, hogy a menedzserek beavatkoznak a fejlesztési folyamatokba, anélkül, hogy bármit is értenének hozzá, összekeverik az üzleti adatokat és az alkalmazás működését, így káosz kezdődik.
Amikor káosz tör ki, az üzlet keresi a felelősöket, és itt szükség van egy univerzális bűnbakra, hiszen nehéz 10+ emberre rábízni a hibát, ezért a menedzserek összevonják a pozíciókat, hiszen minél több feladata van egy szakembernek, annál könnyebb bizonyítani a gondatlanságát. Az Agile környezetében a "felelős" megtalálása és megbüntetése az üzleti menedzsment alapja. Az Agile régóta kilépett az IT-ból, és fő koncepciója lett a napi eredmények követelése. A probléma az, hogy a szűkebb szakértelemmel rendelkező szakember nem mindig tud napi eredménnyel előállni, tehát nehezebb számot adni, és ez még egy oka annak, hogy az üzlet "mindenhez értő szakembereket" keres. De a fő ok természetesen a munkabér – ez az összes változás alapja, az emberek a bérnövekedés érdekében magukra és még egy másikra is vállalják a munkát. De végül, mint más szektorokban, ez egyszerűen a kötelezettséggé vált, alacsonyabb díjért nagyobb mennyiségű szolgáltatást biztosítva.
Manapság gyakran találkozunk olyan cikkekkel, amelyek azt állítják, hogy a fejlesztőknek is tudniuk kell telepíteni és az infrastruktúrával foglalkozniuk kell a DevOps mérnök mellett. De mi ennek az eredménye? Helyesen – a szolgáltatások minőségének csökkenése, a fejlesztők minőségének csökkenése. Két nappal ezelőtt éppen egy fejlesztőnek magyaráztam, hogy a különböző hosztokból is lehet írni és olvasni, de hevesen bizonygatta, hogy ilyet még sosem látott. Ott van a beállításokban az orm hoszt, port, db, felhasználó, jelszó, és ennyi… De a fejlesztő tud telepítéseket indítani, YAML fájlokat írni… Csakhogy már elfelejti az egységteszteket és a kódkommenteket.
A dolgok végül a következőképpen alakulnak – folyamatos túlórák, a problémák megoldásának keresése munkaidőn kívül, folyamatos tanulás a hétvégéken, és nem a jövedelem növelése érdekében, hanem saját maguk fenntartásáért. A fejlesztők kénytelenek segíteni a DevOps mérnöknek a CI/CD-ben, és ha a fejlesztőnek nincs ideje, az elkezd elmerülni, és a menedzserek kezdenek zavarni, és ha ez nem növeli a túlmunkára való kedvet, büntetéseket és díjakat alkalmaznak. Az ember új munkahelyet keres, maga után hagyva egy Everest méretű technikai adósságot, ennek következtében az adósság kezdi növekedni a fejlesztők körében is, mivel azokat kényszerítik, hogy kevesebb refaktoringgal írjanak kódot, hogy segítsenek akár a régi, akár az új DevOps mérnöknek, a menedzsereket pedig minden kielégíti, hiszen a hibás azonosítva van, és azonnal látható, tehát az Agile alapvető szabálya a menedzsmentben teljesítve van, a bűnös megtalálva, a büntetésének eredményei nyilvánvalóak.
Később az ITGM-en tartottam egy előadást „Mikor tanulunk meg nemet mondani?” – az előadás eredményei nagyon figyelemre méltóak voltak. Hatalmas számú ember gondolja, hogy ez a szó tabu, és amíg ezt nem hagyjuk abba, a problémák csak fokozódni fognak.
Részben ez a cikk ösztönzött engem, de később valószínűleg részletesebben írok róla kevésbé körmönfont kifejezésekkel.
Csak a regisztrált felhasználók vehetnek részt a szavazáson. , kérem.
Találkoztál már olyan helyzettel, amikor a munkáltató több embert próbált helyettesíteni veled?
65,6%Igen, rendszeresen találkozom vele183
5,4%Igen, egyszer már találkoztam vele15
15,4%Nem észleltem43
13,6%Munkaalkoholista vagyok, egyedül is túlmunkázom38
279 felhasználó szavazott. 34 felhasználó tartózkodott.
Forrás: habr.com
