{"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 salari 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 un settore in cui non esiste affatto la parola \"stop\" per il numero di mansioni per persona. <\/p>\n

Leggendo gli annunci di lavoro, a volte non si vede neanche 2-3 persone, ma un'intera azienda in un singolo individuo. Tutti sono in fretta, il debito tecnico cresce, il vecchio legacy, rispetto ai nuovi prodotti, sembra una perfezione, perch\u00e9 almeno ha documentazione e commenti nel codice. I nuovi prodotti sono sviluppati a una velocit\u00e0 smisurata, ma alla fine non possono essere utilizzati per un altro anno dopo la loro scrittura, e spesso quest'anno non genera profitti. Inoltre, le spese per il \"cloud\" superano le vendite del servizio. I soldi degli investitori vengono spesi per mantenere un servizio che non \u00e8 ancora operativo, ma che \u00e8 gi\u00e0 stato rilasciato in rete come funzionante.<\/a><\/noindex>
\nPer esempio: un'azienda famosa, il cui remaster di un vecchio gioco ha ricevuto le valutazioni pi\u00f9 basse della storia dell'industria. Sono stato uno di quelli che ha acquistato questo prodotto, ma anche adesso il prodotto funziona malissimo e, in teoria, non avrebbe dovuto essere messo in vendita in queste condizioni. Rimborso, caduta del rating, un enorme numero di ban per gli utenti nei forum a causa delle lamentele sul funzionamento dei servizi. Il numero di patch non \u00e8 impressionante, ma orripilante, eppure il prodotto rimane inutilizzabile. Se questo approccio porta a risultati del genere da parte di un'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 abbiamo esaminato i risultati di tale approccio dalla prospettiva dell'utente del servizio; ora diamo un'occhiata ai problemi emersi per i dipendenti. <\/p>\n

Spesso sento affermare che non dovrebbero esserci team DevOps, che sia solo una metodologia, ma il problema \u00e8 che le aziende sembrano aver smesso di cercare professionisti come DBA, specialisti di infrastruttura e ingegneri build \u2013 ora tutto \u00e8 ridotto a un ingegnere DevOps che svolge il lavoro da solo. Certo, in alcune aziende queste posizioni esistono ancora, ma sono sempre meno. Molti lo hanno definito sviluppo, ma personalmente vedo in questo una forma di degrado; \u00e8 impossibile mantenere un buon livello di conoscenze in tutte le aree e allo stesso tempo lavorare meno di 8 ore. Naturalmente, sono fantasie. In realt\u00e0, molti professionisti IT sono costretti a lavorare anche 12 o 14 ore, di cui vengono retribuite solo 8. Spesso senza nemmeno avere weekend, perch\u00e9 \"mi \u00e8 stato assegnato un compito, la documentazione \u00e8 assente o scadente, e il servizio costa anche\", e per un errore nel cloud potresti anche non ricevere lo stipendio per un paio di mesi, soprattutto se lavori come libero professionista. Di fatto, stiamo perdendo parola nel business, insieme alla divisione delle responsabilit\u00e0; sempre pi\u00f9 spesso mi trovo di fronte a manager che si intromettono nei processi di sviluppo, senza capire nulla in merito, confondendo dati aziendali e funzionamento dell'applicazione, con il risultato che inizia il caos. <\/p>\n

Quando inizia il caos, le aziende cercano un colpevole, e qui serve un colpevole universale; addossare la colpa a pi\u00f9 di dieci persone \u00e8 difficile, quindi i manager uniscono le posizioni, poich\u00e9 pi\u00f9 responsabilit\u00e0 ha un singolo specialista, pi\u00f9 \u00e8 facile dimostrare la sua negligenza. Nella metodologia Agile, trovare il \"colpevole\" e infliggere punizioni \u00e8 alla base di come si gestisce il business. Agile \u00e8 uscito da tempo dal settore IT, e la sua concezione principale \u00e8 diventata la richiesta di risultati quotidiani. Il problema \u00e8 che uno specialista altamente specializzato non ha sempre un risultato giornaliero, e quindi sar\u00e0 pi\u00f9 difficile rendicontare, e questa \u00e8 un'altra ragione per cui le aziende cercano \"specialisti in tutto\". Ma la ragione principale \u00e8 ovviamente il costo del lavoro - \u00e8 la causa fondamentale di tutti i cambiamenti; per un aumento, le persone accettavano di lavorare per s\u00e9 stesse e per qualcun altro. Ma alla fine, proprio come in altri settori, questo \u00e8 semplicemente diventato un obbligo, con un compenso inferiore per una maggiore quantit\u00e0 di servizi forniti. <\/p>\n

Oggi si possono trovare articoli che affermano che anche gli sviluppatori dovrebbero essere in grado di effettuare deployment e gestire l'infrastruttura insieme agli ingegneri DevOps. Ma a cosa porta tutto ci\u00f2? Esatto: a un deterioramento della qualit\u00e0 dei servizi e a un abbassamento delle competenze degli sviluppatori. Proprio due giorni fa stavo spiegando a uno sviluppatore che si pu\u00f2 scrivere e leggere da host diversi, mentre lui sosteneva con veemenza di non aver mai visto nulla del genere; in settings ci sono host, port, db, user, password e basta... Ma l sviluppatore sa come eseguire i deployment e scrivere i file YAML... Tuttavia ha gi\u00e0 dimenticato i test unitari e i commenti nel codice.<\/p>\n

In conclusione, assistiamo a quanto segue: continui stravolgi, ricerche di soluzioni ai problemi al di fuori dell'orario lavorativo, formazione continua nei fine settimana, non per aumentare i guadagni, ma per mantenere la propria posizione. Gli sviluppatori sono costretti ad aiutare l'ingegnere DevOps con CI\/CD e, se uno sviluppatore non ha tempo, inizia a sovraccaricarsi, mentre i manager iniziano a stressare, e se questo non aumenta il desiderio di lavorare straordinari, si ricorre a sanzioni e multe. La persona cerca un nuovo lavoro, lasciando dietro di s\u00e9 un debito tecnico grande come l'Everest; di conseguenza, il debito inizia a crescere anche per gli sviluppatori, poich\u00e9 devono scrivere codice con meno refactoring per riuscire ad aiutare sia il vecchio che il nuovo ingegnere DevOps. E i manager sono perfettamente soddisfatti, poich\u00e9 c'\u00e8 un colpevole e lo si vede subito, il che significa che la regola principale dell'Agile nella gestione \u00e8 rispettata: il colpevole \u00e8 stato trovato e i risultati del suo punimento sono evidenti. <\/p>\n

Tempo fa, su ITGM ho tenuto una conferenza intitolata \u00abquando impareremo a dire \u201cno\u201d\u00bb \u2014 i risultati sono stati molto rivelatori. Un numero enorme di persone considera questa parola un tabu, e finch\u00e9 non smetteremo di pensarla cos\u00ec, 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 evasivi.<\/p>\n

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

Vi \u00e8 mai capitato nel lavoro di quando un datore di lavoro ha cercato di sostituire pi\u00f9 persone con voi?<\/h2>\n