DevOps o come stiamo perdendo salari e futuro del settore IT

La cosa più triste nella situazione attuale è che l’IT sta gradualmente diventando un settore in cui non esiste alcuna parola “stop” nel numero di responsabilità per persona.

Quando leggi i posti vacanti, a volte vedi anche non 2-3 persone, ma un'intera azienda in una persona, tutti hanno fretta, il debito tecnico sta crescendo, la vecchia eredità sembra la perfezione sullo sfondo dei nuovi prodotti, perché almeno ha un dock e commenti nel codice, i nuovi prodotti vengono scritti alla velocità della luce, ma di conseguenza non possono essere utilizzati per un altro anno dopo la loro scrittura e spesso quest'anno non porta profitto, inoltre, il costo di il cloud è superiore alle vendite del servizio. Il denaro degli investitori va al mantenimento di un servizio che non è ancora funzionante, ma che è già stato rilasciato alla rete come lavoratore.
Ad esempio: una nota azienda la cui rimasterizzazione di un vecchio gioco ha ricevuto le valutazioni più basse nella storia del settore. Sono stato uno di quelli che hanno acquistato questo prodotto, ma anche adesso questo prodotto funziona malissimo e in teoria non avrebbe dovuto essere ancora rilasciato in questa forma. Rimborsi, calo della valutazione, un numero enorme di divieti di utenti sui forum per reclami sul lavoro dei servizi. Il numero di patch non delizia, ma terrorizza, ma comunque il prodotto non è utilizzabile. Se questo approccio porta a tali risultati per un'azienda che si sta sviluppando dal 91, allora per le aziende che hanno appena iniziato la situazione è ancora peggiore.

Ma abbiamo esaminato i risultati di questo approccio da parte dell'utente del servizio, e ora diamo un'occhiata ai problemi che hanno i dipendenti.

Sento spesso l'affermazione che non dovrebbero esserci team DevOps, che questa è una metodologia, ecc., Ma il problema è che, per qualche motivo, le aziende hanno smesso di cercare nok, dba, infruttori e ingegneri di costruzione: ora è tutto un ingegnere DevOps in una sola persona. Naturalmente, nelle singole aziende ci sono ancora tali posti vacanti, ma sono sempre meno. Molti hanno chiamato questo sviluppo, personalmente vedo un degrado in questo, è impossibile mantenere un buon livello di conoscenza in tutte le aree e allo stesso tempo riuscire a lavorare non più di 8 ore. Naturalmente queste sono fantasie. In realtà molti informatici sono costretti a lavorare sia 12 che 14 ore, di cui 8 pagate, e spesso senza giorni di riposo, perché “mi hanno dato un compito, non ci sono banchine né curve e il servizio costa”. e per 1 nel cloud, in linea di principio, non puoi ottenere uno stipendio in un paio di mesi, soprattutto se lavori su base IP. In effetti, stiamo perdendo la parola negli affari, insieme alla separazione dei compiti, mi trovo sempre più di fronte al fatto che i manager entrano nei processi di sviluppo senza capire nulla, confondono i dati aziendali e il funzionamento delle applicazioni, di conseguenza, il caos inizia.

Quando inizia il caos, gli affari vogliono trovare il colpevole, e qui hai bisogno di un colpevole universale, è difficile attribuire la colpa a più di 10 persone, quindi i manager uniscono le loro posizioni, perché più compiti ha 1 specialista, più facile è dimostrare la sua negligenza. E nelle condizioni di Agile, trovare il “colpevole” e sculacciare è la base di questa metodologia per fare affari nella gestione. Agile è uscito da tempo dall'IT e il suo concetto principale è diventato il requisito dei risultati quotidiani. Il problema è che non sempre uno specialista altamente specializzato avrà un risultato giornaliero, il che significa che sarà più difficile fare report, e questo è un altro motivo per cui le aziende vogliono “specialisti in tutto”. Ma il motivo principale, ovviamente, è il libro paga: lui è il motivo principale di tutti i cambiamenti, per amore dell'indennità, le persone hanno accettato di lavorare per se stesse e per quel ragazzo. Ma alla fine, come in altri settori, ora è diventato semplicemente un obbligo, pagare meno per un numero maggiore di servizi forniti.

Ora spesso puoi persino vedere articoli che gli sviluppatori dovrebbero già essere in grado di implementare, dovrebbero occuparsi dell'infrastruttura accanto a un ingegnere DevOps, ma cosa porta questo? Esatto: a un calo della qualità dei servizi, a un calo della qualità degli sviluppatori. Letteralmente 2 giorni fa, ho spiegato allo sviluppatore che puoi scrivere e leggere da host diversi, e mi hanno dimostrato con la schiuma alla bocca che non avevano mai visto niente del genere, eccolo nelle impostazioni om host, port, db, utente, password e basta.... Ma lo sviluppatore sa come avviare distribuzioni, scrivere yaml .... Ma si dimentica già dei test unitari e dei commenti nel codice.

Di conseguenza, vediamo quanto segue: elaborazione costante, ricerca di soluzioni a problemi al di fuori dell'orario di lavoro, formazione costante nei fine settimana e non per aumentare il reddito, ma per mantenerci a galla. Gli sviluppatori sono costretti ad aiutare un ingegnere DevOps con CI / CD e, se lo sviluppatore non ha tempo, inizia a tacere e i manager iniziano a compostare i cervelli, e se ciò non aiuta ad aumentare il desiderio di fare gli straordinari, quindi applicare sanzioni e multe, la persona cerca un nuovo lavoro, lasciando dietro di sé un debito tecnico delle dimensioni dell'Everest, di conseguenza, il debito inizia a crescere anche tra gli sviluppatori. sono costretti a scrivere codice con meno refactoring per avere tempo di aiutare il vecchio o il nuovo ingegnere DevOps, e i manager sono abbastanza contenti di tutto, perché il colpevole c'è e può essere visto subito, il che significa che si osserva la regola principale nella gestione Agile, si trova il colpevole, si vedono i risultati della sua fustigazione.

Una volta all'ITGM ho fatto una presentazione "quando impariamo a dire di no" - i suoi risultati sono stati molto rivelatori. Un numero enorme di persone crede che questa parola sia un tabù e finché non smetteremo di pensarla così, i problemi non potranno che aumentare.

Mi ha parzialmente ispirato a scrivere questo articolo. Questo articolo, ma forse lo scriverò in seguito in termini meno piacevoli.

Solo gli utenti registrati possono partecipare al sondaggio. AccediPer favore.

Ti sei imbattuto sul lavoro in cui il datore di lavoro ha cercato di sostituire diverse persone con te?

• 65,6%Sì, mi imbatto regolarmente

• 5,4%Sì, riscontrato 1 volta15

• 15,4%Non me ne sono accorto43

• 13,6%Sono un maniaco del lavoro, anch'io faccio gli straordinari38

279 utenti hanno votato. 34 utenti si sono astenuti.

Fonte: habr.com