La cosa più triste della situazione attuale è che l'IT sta diventando gradualmente un settore in cui non esiste affatto la parola “stop” riguardo al numero di responsabilità per una sola persona.
Leggendo le offerte di lavoro, a volte non vedi più 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é almeno ha documentazione e commenti nel codice; i nuovi prodotti vengono scritti a una velocità 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 “cloud” sono superiori alle vendite del servizio. I soldi degli investitori vengono spesi per mantenere un servizio che non funziona ancora, ma è già stato lanciato in rete come operativo.
Per esempio: una nota azienda, il cui remaster di un vecchio gioco ha ricevuto le valutazioni più 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 – il prodotto non è utilizzabile. Se questo approccio porta a tali risultati in una azienda che sviluppa dal '91, la situazione è ancora peggiore per le aziende che stanno appena iniziando la loro attività.
Ma questo è come visto i risultati di tale approccio dalla prospettiva dell'utente del servizio, ora guardiamo ai problemi che sono emersi per i dipendenti.
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 – ora tutto questo è 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; è impossibile mantenere un buon livello di conoscenze in tutti i settori e lavorare al contempo non più di 8 ore. Naturalmente, queste sono fantasie. In realtà, 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é "mi è stato assegnato un compito, la documentazione non esiste o è incompleta, oltretutto il servizio costa", e per un solo errore nel cloud si può 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à; mi capita sempre più 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.
Quando inizia il caos, il business cerca di trovare un colpevole, e qui c'è bisogno di un colpevole universale; attribuire la colpa a più di 10 persone è difficile, quindi i manager accorpano le posizioni, poiché più responsabilità ha un singolo specialista, più facile è dimostrare la sua negligenza. E nelle condizioni di Agile, trovare il «colpevole» e punirlo è alla base di questa metodologia di gestione. Agile è ormai uscito dall'IT, e il suo concetto principale è diventato – la richiesta di risultati quotidiani. Il problema è che uno specialista altamente specializzato non avrà sempre un risultato giornaliero, quindi rendere conto sarà più difficile, e questa è un'altra ragione per cui il business cerca «specialisti in tutto». Ma la causa principale è naturalmente il costo del lavoro – è 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 è diventato semplicemente un dovere, per una retribuzione minore rispetto a un numero maggiore di servizi forniti.
Oggi è 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ò? Giusto: a una diminuzione della qualità dei servizi e degli sviluppatori. Solo due giorni fa, ho spiegato a uno sviluppatore che si può 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ò, l sviluppatore sa come lanciare i deployment e scrivere YAML... Ma ha già dimenticato i test unitari e i commenti nel codice.
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é 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é c'è un colpevole e si vede subito, il che significa che la regola fondamentale nella gestione Agile è rispettata, il colpevole è stato trovato e i risultati della sua punizione sono evidenti.
In passato, presso ITGM, ho tenuto una conferenza intitolata «quando impareremo a dire 'no'» — i suoi risultati sono stati molto indicativi. Un enorme numero di persone ritiene che questa parola sia un tabù, e finché non smetteremo di pensarlo, i problemi continueranno a crescere.
In parte, questo articolo è stato ispirato da, ma in seguito potrei descriverlo in termini meno circostanziali.
Solo gli utenti registrati possono partecipare al sondaggio. , per favore.
Ti è mai capitato di lavorare quando il tuo datore di lavoro cercava di sostituire diverse persone con te?
65,6%Sì, mi capita regolarmente183
5,4%Sì, mi è capitato una volta15
15,4%Non me ne sono accorto43
13,6%Sono un idealista, lavoro oltre l'orario38
Hanno votato 279 utenti. 34 utenti si sono astenuti.
Fonte: habr.com
