Het meest trieste in de huidige situatie is dat de IT stilaan een industrie aan het worden is waar geen woord "stop" staat in het aantal verantwoordelijkheden per persoon.
Bij het lezen van vacatures zie je soms niet eens 2-3 mensen, maar een heel bedrijf in één persoon, iedereen heeft haast, technische schulden groeien, de oude erfenis ziet eruit als perfectie tegen de achtergrond van nieuwe producten, omdat het in ieder geval heeft een dock en opmerkingen in de code, nieuwe producten worden met de snelheid van het licht geschreven, maar als gevolg daarvan kunnen ze na het schrijven nog een jaar niet worden gebruikt, en vaak levert dit jaar geen winst op, bovendien de kosten van de cloud is hoger dan de verkoop van de dienst. Het geld van investeerders gaat naar het onderhoud van een dienst die nog niet werkt, maar die al als werker aan het netwerk is vrijgegeven.
Als voorbeeld: een bekend bedrijf wiens remaster van een oude game de laagste beoordelingen in de geschiedenis van de branche kreeg. Ik was een van degenen die dit product kocht, maar zelfs nu werkt dit product vreselijk en had het in theorie nog niet in deze vorm mogen worden uitgebracht. Restituties, beoordelingsdaling, een groot aantal gebruikersverboden op de forums voor klachten over het werk van services. Het aantal patches verheugt niet, maar beangstigt, maar toch - het product is niet bruikbaar. Als deze aanpak tot dergelijke resultaten leidt voor een bedrijf dat zich sinds 91 ontwikkelt, dan is de situatie voor bedrijven die net beginnen nog erger.
Maar we hebben gekeken naar de resultaten van deze aanpak van de kant van de gebruiker van de dienst, en laten we nu eens kijken naar de problemen die werknemers hebben.
Ik hoor vaak de bewering dat er geen DevOps-teams zouden moeten zijn, dat dit een methodologie is, enz., maar het probleem is dat bedrijven om de een of andere reden zijn gestopt met zoeken naar noks, dba, infructoren en build-engineers - nu is het allemaal een DevOps-engineer bij één persoon. Natuurlijk zijn er in individuele bedrijven nog steeds dergelijke vacatures, maar die worden steeds minder. Velen noemden deze ontwikkeling, ik zie hier persoonlijk achteruitgang in, het is onmogelijk om op alle gebieden een goed kennisniveau te behouden en tegelijkertijd niet langer dan 8 uur te werken. Natuurlijk zijn dit fantasieën. In werkelijkheid zijn veel IT'ers gedwongen om zowel 12 als 14 uur te werken, waarvan 8 uur betaald, en vaak zonder vrije dagen, want "Ik kreeg een taak, er zijn geen dokken of bochten en de service kost geld". en voor 1 in de cloud kun je in principe niet binnen een paar maanden salaris krijgen, zeker niet als je op IP-basis werkt. In feite verliezen we het woord in het bedrijfsleven, samen met de scheiding van taken, word ik steeds vaker geconfronteerd met het feit dat managers ontwikkelingsprocessen ingaan zonder ook maar iets te begrijpen, ze verwarren bedrijfsgegevens en de werking van applicaties, met als resultaat chaos begint.
Wanneer chaos begint, wil het bedrijfsleven de boosdoener vinden, en hier heb je een universele boosdoener nodig, het is moeilijk om de schuld bij 10+ mensen te leggen, dus verenigen managers hun posities, want hoe meer taken 1 specialist heeft, hoe gemakkelijker het is om zijn nalatigheid bewijzen. En in de omstandigheden van Agile is het vinden van de "schuldige" en spanking de basis van deze methodologie voor zakendoen in management. Agile is al lang uit de IT en het belangrijkste concept is de vereiste geworden voor dagelijkse resultaten. Het probleem is dat een zeer gespecialiseerde specialist niet altijd een dagelijks resultaat zal hebben, waardoor het moeilijker zal zijn om te rapporteren, en dit is nog een reden waarom bedrijven "specialisten in alles" willen. Maar de belangrijkste reden is natuurlijk de loonlijst - hij is de belangrijkste reden voor alle veranderingen, omwille van de toelage kwamen mensen overeen om voor zichzelf en die man te werken. Maar uiteindelijk is het, net als op andere gebieden, nu gewoon een verplichting geworden, tegen een kleinere vergoeding voor een groter aantal geleverde diensten.
Nu zie je vaak zelfs artikelen voorbij komen dat ontwikkelaars al zouden moeten kunnen inzetten, naast een DevOps engineer de infrastructuur zouden moeten afhandelen, maar waar leidt dit toe? Dat klopt - tot een daling van de kwaliteit van services, tot een daling van de kwaliteit van ontwikkelaars. Letterlijk 2 dagen geleden legde ik de ontwikkelaar uit dat je van verschillende hosts kunt schrijven en lezen, en ze bewezen me met schuim op de mond dat ze nog nooit zoiets hadden gezien, hier is het in de instellingen ofm host, poort, db, gebruiker, wachtwoord en dat is alles .... Maar de ontwikkelaar weet hoe hij implementaties moet starten, yamls moet schrijven .... Maar hij vergeet unit tests en opmerkingen in de code al.
Als resultaat zien we het volgende - constant verwerken, zoeken naar oplossingen voor problemen buiten werktijd, constant trainen in het weekend, en niet om het inkomen te verhogen, maar om het hoofd boven water te houden. Ontwikkelaars worden gedwongen een DevOps-engineer te helpen met CI / CD, en als de ontwikkelaar geen tijd heeft, begint hij te zwijgen en beginnen managers hersenen te composteren, en als dit niet helpt om de wens om overuren te maken, solliciteer dan straffen en boetes, de persoon is op zoek naar een nieuwe baan en laat een technische schuld achter ter grootte van de Everest, met als gevolg dat de schuld ook onder ontwikkelaars begint te groeien. ze worden gedwongen om code te schrijven met minder refactoring om tijd te hebben om een oude of een nieuwe DevOps-engineer te helpen, en managers zijn best tevreden met alles, want er is een schuldige en hij kan meteen worden gezien, wat betekent dat de hoofdregel in Agile management wordt nageleefd, de schuldige wordt gevonden, de resultaten van zijn geseling zichtbaar.
Eens bij ITGM heb ik een presentatie gehouden "wanneer we leren nee te zeggen" - de resultaten waren zeer onthullend. Een groot aantal mensen gelooft dat dit woord taboe is, en totdat we niet meer zo denken, zullen de problemen alleen maar groter worden.
Heeft me gedeeltelijk geïnspireerd om dit artikel te schrijven., maar misschien schrijf ik het later in minder prettige bewoordingen.
Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. , Alsjeblieft.
Ben je op het werk tegengekomen toen de werkgever meerdere mensen met jou probeerde te vervangen?
-
65,6%Ja, ik loop er regelmatig tegenaan
-
5,4%Ja, 1 keer tegengekomen15
-
15,4%Niet opgemerkt43
-
13,6%Ik ben een workaholic, ik maak zelf overuren38
279 gebruikers hebben gestemd. 34 gebruikers onthielden zich van stemming.
Bron: www.habr.com