O máis triste na situación actual é que as TI estase a converter aos poucos nunha industria na que non hai ningunha palabra "parar" en absoluto no número de responsabilidades por persoa.
Ao ler prazas vacantes, ás veces ata ves non 2-3 persoas, senón unha empresa enteira nunha soa persoa, todos teñen présa, a débeda técnica está crecendo, o vello legado parece a perfección no fondo dos novos produtos, porque polo menos ten un peirao e comentarios no código, os novos produtos escríbense á velocidade da luz, pero, como resultado, non se poden usar durante un ano máis despois de que se escriban, e moitas veces este ano non trae beneficios, ademais, o custo de a nube é superior ás vendas do servizo. O diñeiro dos investidores vai para o mantemento dun servizo que aínda non funciona, pero que xa foi liberado á rede como traballador.
Como exemplo: unha coñecida empresa cuxa remasterización dun xogo antigo recibiu as valoracións máis baixas da historia da industria. Eu fun un dos que comprou este produto, pero aínda agora este produto funciona terriblemente e, en teoría, aínda non debería ter sido lanzado nesta forma. Reembolsos, caída de valoración, un gran número de prohibicións de usuarios nos foros por queixas sobre o traballo dos servizos. O número de parches non encanta, pero aterroriza, pero aínda así - o produto non é utilizable. Se este enfoque leva a tales resultados para unha empresa que leva desenvolvendo desde o ano 91, entón para as empresas que están empezando, a situación é aínda peor.
Pero analizamos os resultados deste enfoque por parte do usuario do servizo, e agora vexamos os problemas que teñen os empregados.
Moitas veces escoito a afirmación de que non debería haber equipos DevOps, que esta é unha metodoloxía, etc., pero o problema é que, por algún motivo, as empresas deixaron de buscar noks, dba, infructors e enxeñeiros de construción; agora todo é un enxeñeiro de DevOps. nunha soa persoa. Iso si, nas empresas individuais aínda hai vacantes deste tipo, pero cada vez son menos. Moitos chamaron a este desenvolvemento, eu persoalmente vexo a degradación nisto, é imposible manter un bo nivel de coñecemento en todas as áreas e, ao mesmo tempo, conseguir traballar non máis de 8 horas. Por suposto, estas son fantasías. En realidade, moitos traballadores de TI vense obrigados a traballar tanto 12 como 14 horas, das cales 8 son remuneradas, e moitas veces sen días libres, porque “deronme unha tarefa, non hai muelles nin curvas, e o servizo custa cartos”. e por 1 na nube, en principio podes non conseguir un soldo nun par de meses, sobre todo se traballas en réxime de IP. De feito, estamos perdendo a palabra nos negocios, xunto coa separación de funcións, cada vez enfróntome máis ao feito de que os xestores entran en procesos de desenvolvemento sen entender nada, confunden os datos empresariais e o funcionamento das aplicacións, como resultado, comeza o caos. .
Cando comeza o caos, as empresas queren atopar o culpable, e aquí necesitas un culpable universal, é difícil botarlle a culpa a máis de 10 persoas, polo que os xestores unen as súas posicións, porque cantas máis funcións teña un especialista, máis fácil será demostrar a súa neglixencia. E nas condicións de Agile, atopar os “culpables” e azotes é a base desta metodoloxía para facer negocios na xestión. Agile leva moito tempo fóra das TIC, e o seu concepto principal converteuse no requisito dos resultados diarios. O problema é que un especialista altamente especializado non sempre terá un resultado diario, polo que será máis difícil denunciar, e esta é outra das razóns polas que as empresas queren “especialistas en todo”. Pero a razón principal, por suposto, é a nómina: el é o principal motivo de todos os cambios, polo ben do subsidio, a xente aceptaba traballar para si e para ese tipo. Pero ao final, como noutros ámbitos, agora simplemente converteuse nunha obriga, por un menor pago por un maior número de servizos prestados.
Agora podes ata ver a miúdo artigos que os desenvolvedores xa deberían poder implementar, deberían tratar a infraestrutura xunto a un enxeñeiro de DevOps, pero a que leva isto? É certo - a unha caída na calidade dos servizos, a unha caída na calidade dos desenvolvedores. Literalmente hai 2 días, expliqueille ao programador que podes escribir e ler desde diferentes hosts, e demostráronme con escuma na boca que nunca viran nada así, aquí está na configuración orm host, port, db, usuario, contrasinal e xa está.... Pero o programador sabe como lanzar despregamentos, escribir yamls.... Pero xa se esquece das probas unitarias e dos comentarios do código.
Como resultado, vemos o seguinte: procesamento constante, busca de solucións a problemas fóra do horario laboral, formación constante os fins de semana e non para aumentar os ingresos, senón para manternos a flote. Os desenvolvedores están obrigados a axudar a un enxeñeiro de DevOps con CI / CD, e se o desenvolvedor non ten tempo, comeza a calar e os xestores comezan a compostar cerebros, e se isto non axuda a aumentar o desexo de traballar horas extras, entón solicita sancións e multas, a persoa busca un novo traballo, deixando atrás unha débeda técnica do tamaño do Everest, como resultado, a débeda comeza a crecer tamén entre os desenvolvedores. vense obrigados a escribir código con menos refactorización para ter tempo para axudar a un enxeñeiro de DevOps antigo ou novo, e os xestores están bastante contentos con todo, porque hai un culpable e pódese ver enseguida, o que significa que obsérvase a regra principal na xestión áxil, atópase o culpable, visibles os resultados da súa flagelación.
Unha vez no ITGM fixen unha presentación "cando aprendemos a dicir que non": os seus resultados foron moi reveladores. Un gran número de persoas cren que esta palabra é tabú, e ata que non deixemos de pensalo, os problemas só crecerán.
En parte inspiroume para escribir este artigo., pero quizais o escribirei en termos menos agradables máis adiante.
Só os usuarios rexistrados poden participar na enquisa. , por favor.
Encontrácheste no traballo cando o empresario intentou substituír a varias persoas contigo?
-
65,6%Si, atópome con el regularmente
-
5,4%Si, atopouse 1 vez15
-
15,4%Non se decate43
-
13,6%Son un adicto ao traballo, eu mesmo fago horas extra38
Votaron 279 usuarios. 34 usuarios abstivéronse.
Fonte: www.habr.com