La cosa più triste della situazione attuale è che l'IT sta diventando un settore in cui non esiste affatto la parola "stop" per il numero di mansioni per persona.
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é almeno ha documentazione e commenti nel codice. I nuovi prodotti sono sviluppati a una velocità 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 è ancora operativo, ma che è già stato rilasciato in rete come funzionante.
Per esempio: un'azienda famosa, il cui remaster di un vecchio gioco ha ricevuto le valutazioni più 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 è 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 è ancora peggiore per le aziende che stanno appena iniziando la loro attività.
Ma questo è come abbiamo esaminato i risultati di tale approccio dalla prospettiva dell'utente del servizio; ora diamo un'occhiata ai problemi emersi per i dipendenti.
Spesso sento affermare che non dovrebbero esserci team DevOps, che sia solo una metodologia, ma il problema è che le aziende sembrano aver smesso di cercare professionisti come DBA, specialisti di infrastruttura e ingegneri build – ora tutto è 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; è 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à, molti professionisti IT sono costretti a lavorare anche 12 o 14 ore, di cui vengono retribuite solo 8. Spesso senza nemmeno avere weekend, perché "mi è stato assegnato un compito, la documentazione è 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à; sempre più 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.
Quando inizia il caos, le aziende cercano un colpevole, e qui serve un colpevole universale; addossare la colpa a più di dieci persone è difficile, quindi i manager uniscono le posizioni, poiché più responsabilità ha un singolo specialista, più è facile dimostrare la sua negligenza. Nella metodologia Agile, trovare il "colpevole" e infliggere punizioni è alla base di come si gestisce il business. Agile è uscito da tempo dal settore IT, e la sua concezione principale è diventata la richiesta di risultati quotidiani. Il problema è che uno specialista altamente specializzato non ha sempre un risultato giornaliero, e quindi sarà più difficile rendicontare, e questa è un'altra ragione per cui le aziende cercano "specialisti in tutto". Ma la ragione principale è ovviamente il costo del lavoro - è la causa fondamentale di tutti i cambiamenti; per un aumento, le persone accettavano di lavorare per sé stesse e per qualcun altro. Ma alla fine, proprio come in altri settori, questo è semplicemente diventato un obbligo, con un compenso inferiore per una maggiore quantità di servizi forniti.
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ò? Esatto: a un deterioramento della qualità dei servizi e a un abbassamento delle competenze degli sviluppatori. Proprio due giorni fa stavo spiegando a uno sviluppatore che si può 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à dimenticato i test unitari e i commenti nel codice.
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é un debito tecnico grande come l'Everest; di conseguenza, il debito inizia a crescere anche per gli sviluppatori, poiché 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é c'è un colpevole e lo si vede subito, il che significa che la regola principale dell'Agile nella gestione è rispettata: il colpevole è stato trovato e i risultati del suo punimento sono evidenti.
Tempo fa, su ITGM ho tenuto una conferenza intitolata «quando impareremo a dire “no”» — i risultati sono stati molto rivelatori. Un numero enorme di persone considera questa parola un tabu, e finché non smetteremo di pensarla così, i problemi continueranno a crescere.
In parte, questo articolo è stato ispirato da, ma in seguito potrei descriverlo in termini meno evasivi.
Solo gli utenti registrati possono partecipare al sondaggio. , per favore.
Vi è mai capitato nel lavoro di quando un datore di lavoro ha cercato di sostituire più persone con voi?
65,6%Sì, mi capita regolarmente183
5,4%Sì, è capitato una volta15
15,4%Non l'ho notato43
13,6%Sono un workaholic, lavoro straordinari38
279 utenti hanno votato. 34 utenti si sono astenuti.
Fonte: habr.com
