{"id":89062,"date":"2020-07-18T07:41:57","date_gmt":"2020-07-18T05:41:57","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/devops-ili-kak-my-teryaem-zarabotnuyu-platu-i-budushhee-it-otrasli"},"modified":"2020-07-18T07:41:57","modified_gmt":"2020-07-18T05:41:57","slug":"devops-ili-kak-my-teryaem-zarabotnuyu-platu-i-budushhee-it-otrasli","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/devops-ili-kak-my-teryaem-zarabotnuyu-platu-i-budushhee-it-otrasli","title":{"rendered":"DevOps o come perdiamo il salario e il futuro del settore IT","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La cosa pi\u00f9 triste della situazione attuale \u00e8 che l'IT sta diventando gradualmente un settore in cui non esiste affatto la parola \u201cstop\u201d riguardo al numero di responsabilit\u00e0 per una sola persona. <\/p>\n

Leggendo le offerte di lavoro, a volte non vedi pi\u00f9 2-3 persone, ma un'intera azienda in una sola persona, tutti corrono, il debito tecnico cresce, il vecchio legacy, rispetto ai nuovi prodotti, appare come un capolavoro, perch\u00e9 almeno ha documentazione e commenti nel codice; i nuovi prodotti vengono scritti a una velocit\u00e0 incredibile, ma alla fine non possono essere utilizzati per un anno dopo la loro scrittura, e spesso quel primo anno non genera profitti, addirittura, le spese per il \u201ccloud\u201d sono superiori alle vendite del servizio. I soldi degli investitori vengono spesi per mantenere un servizio che non funziona ancora, ma \u00e8 gi\u00e0 stato lanciato in rete come operativo.<\/a><\/noindex>
\nPer esempio: una nota azienda, il cui remaster di un vecchio gioco ha ricevuto le valutazioni pi\u00f9 basse nella storia dell'industria. Sono stato uno di quelli che ha acquistato questo prodotto, ma anche ora questo prodotto funziona terribilmente e, in teoria, non avrebbe dovuto essere in vendita in questa forma. Restituzioni di denaro, calo della valutazione, enorme numero di ban degli utenti nei forum a causa di lamentele sul funzionamento dei servizi. Il numero di patch non meraviglia, ma allarma, eppure \u2013 il prodotto non \u00e8 utilizzabile. Se questo approccio porta a tali risultati in una azienda che sviluppa dal '91, la situazione \u00e8 ancora peggiore per le aziende che stanno appena iniziando la loro attivit\u00e0.<\/p>\n

Ma questo \u00e8 come visto i risultati di tale approccio dalla prospettiva dell'utente del servizio, ora guardiamo ai problemi che sono emersi per i dipendenti. <\/p>\n

Spesso sento affermare che non dovrebbero esistere team DevOps, che si tratta di una metodologia, ecc., ma ecco il problema: le aziende per qualche motivo hanno smesso di cercare esperti di rete, DBA, infrastruttori e ingegneri di build \u2013 ora tutto questo \u00e8 rappresentato da un ingegnere DevOps singolo. Certo, in alcune aziende ci sono ancora queste posizioni, ma sono sempre meno. Molti hanno definito questo un progresso, io personalmente lo vedo come una degradazione; \u00e8 impossibile mantenere un buon livello di conoscenze in tutti i settori e lavorare al contempo non pi\u00f9 di 8 ore. Naturalmente, queste sono fantasie. In realt\u00e0, molti professionisti IT sono costretti a lavorare anche 12 o 14 ore, di cui solo 8 sono pagate. E spesso senza giorni di riposo, perch\u00e9 \"mi \u00e8 stato assegnato un compito, la documentazione non esiste o \u00e8 incompleta, oltretutto il servizio costa\", e per un solo errore nel cloud si pu\u00f2 sostanzialmente non ricevere lo stipendio per un paio di mesi, soprattutto se si lavora come libero professionista. Di fatto stiamo perdendo la parola nel business, insieme alla divisione delle responsabilit\u00e0; mi capita sempre pi\u00f9 spesso di vedere manager che si intromettono nei processi di sviluppo, senza capirne nulla, confondono i dati aziendali con il funzionamento dell'applicazione, e di conseguenza inizia il caos. <\/p>\n

Quando inizia il caos, il business cerca di trovare un colpevole, e qui c'\u00e8 bisogno di un colpevole universale; attribuire la colpa a pi\u00f9 di 10 persone \u00e8 difficile, quindi i manager accorpano le posizioni, poich\u00e9 pi\u00f9 responsabilit\u00e0 ha un singolo specialista, pi\u00f9 facile \u00e8 dimostrare la sua negligenza. E nelle condizioni di Agile, trovare il \u00abcolpevole\u00bb e punirlo \u00e8 alla base di questa metodologia di gestione. Agile \u00e8 ormai uscito dall'IT, e il suo concetto principale \u00e8 diventato \u2013 la richiesta di risultati quotidiani. Il problema \u00e8 che uno specialista altamente specializzato non avr\u00e0 sempre un risultato giornaliero, quindi rendere conto sar\u00e0 pi\u00f9 difficile, e questa \u00e8 un'altra ragione per cui il business cerca \u00abspecialisti in tutto\u00bb. Ma la causa principale \u00e8 naturalmente il costo del lavoro \u2013 \u00e8 la causa principale di tutte le modifiche, per un aumento, le persone accettavano di lavorare per se stesse e per qualcun altro. Ma alla fine, come in altri settori, questo \u00e8 diventato semplicemente un dovere, per una retribuzione minore rispetto a un numero maggiore di servizi forniti. <\/p>\n

Oggi \u00e8 comune vedere articoli che affermano che anche gli sviluppatori devono saper gestire il deployment e occuparsi dell'infrastruttura insieme agli ingegneri DevOps, ma a cosa porta tutto ci\u00f2? Giusto: a una diminuzione della qualit\u00e0 dei servizi e degli sviluppatori. Solo due giorni fa, ho spiegato a uno sviluppatore che si pu\u00f2 scrivere e leggere da host diversi, ma lui ha insistito che non aveva mai visto una cosa del genere, che ci sono solo le impostazioni orm host, port, db, user, password, e basta... Per\u00f2, l sviluppatore sa come lanciare i deployment e scrivere YAML... Ma ha gi\u00e0 dimenticato i test unitari e i commenti nel codice.<\/p>\n

Alla fine, vediamo questo: lavori straordinari continui, ricerca di soluzioni a problemi al di fuori dell'orario lavorativo, continuo apprendimento nei fine settimana, non per crescere economicamente, ma per mantenere la propria posizione. Gli sviluppatori sono costretti ad aiutare gli ingegneri DevOps con CI\/CD, e se uno sviluppatore non ha tempo, inizia a sentirsi sopraffatto, i manager iniziano a stressare, e se questo non aumenta il desiderio di lavorare oltre l'orario, si iniziano a imporre sanzioni e multe. La persona cerca un nuovo lavoro, lasciando un debito tecnico grande come l'Everest; di conseguenza, il debito inizia a crescere anche per gli sviluppatori, poich\u00e9 sono costretti a scrivere codice con meno refactoring per riuscire ad aiutare il vecchio o il nuovo ingegnere DevOps, e i manager sono del tutto soddisfatti, poich\u00e9 c'\u00e8 un colpevole e si vede subito, il che significa che la regola fondamentale nella gestione Agile \u00e8 rispettata, il colpevole \u00e8 stato trovato e i risultati della sua punizione sono evidenti. <\/p>\n

In passato, presso ITGM, ho tenuto una conferenza intitolata \u00abquando impareremo a dire 'no'\u00bb \u2014 i suoi risultati sono stati molto indicativi. Un enorme numero di persone ritiene che questa parola sia un tab\u00f9, e finch\u00e9 non smetteremo di pensarlo, i problemi continueranno a crescere.<\/p>\n

In parte, questo articolo \u00e8 stato ispirato da questo articolo<\/a><\/noindex>, ma in seguito potrei descriverlo in termini meno circostanziali.<\/p>\n

Solo gli utenti registrati possono partecipare al sondaggio. Accedi<\/a><\/noindex>, per favore.<\/p>\n

Ti \u00e8 mai capitato di lavorare quando il tuo datore di lavoro cercava di sostituire diverse persone con te?<\/h2>\n