{"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\/es\/blog\/administrirovanie\/devops-ili-kak-my-teryaem-zarabotnuyu-platu-i-budushhee-it-otrasli","title":{"rendered":"DevOps o c\u00f3mo perdemos salarios y el futuro de la industria de TI","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Lo m\u00e1s triste de la situaci\u00f3n actual es que la TI se est\u00e1 convirtiendo gradualmente en un sector donde no existe la palabra 'alto' en la cantidad de responsabilidades para una sola persona. <\/p>\n

Al leer las ofertas de trabajo, a veces ya no ves a 2-3 personas, sino a toda una empresa en una sola persona, todos tienen prisa, la deuda t\u00e9cnica est\u00e1 creciendo, el viejo legado se ve como un modelo de perfecci\u00f3n en comparaci\u00f3n con los nuevos productos, porque al menos tiene documentaci\u00f3n y comentarios en el c\u00f3digo; los nuevos productos se desarrollan a la velocidad de la luz, pero al final no se pueden utilizar durante un a\u00f1o despu\u00e9s de su creaci\u00f3n, y a menudo ese a\u00f1o no genera ingresos; m\u00e1s bien, los gastos en la 'nube' superan las ventas del servicio. El dinero de los inversores se destina al mantenimiento de un servicio que a\u00fan no est\u00e1 funcionando, pero que ya se ha lanzado a la red como si estuviera operativo.<\/a><\/noindex>
\nPor ejemplo: una conocida empresa, cuyo remaster de un viejo juego recibi\u00f3 las calificaciones m\u00e1s bajas en la historia de la industria. Yo fui uno de los que compr\u00f3 este producto, pero incluso ahora funciona terriblemente, y por l\u00f3gica no deber\u00eda haber salido a la venta en tal estado. Reembolsos, ca\u00edda de calificaciones, un gran n\u00famero de baneos de usuarios en los foros por quejas sobre el funcionamiento de los servicios. La cantidad de parches no sorprende, sino que aterra, pero a\u00fan as\u00ed, el producto no es utilizable. Si este enfoque produce tales resultados en una empresa que ha estado desarrollando desde 1991, la situaci\u00f3n es a\u00fan peor para las empresas que reci\u00e9n comienzan sus actividades.<\/p>\n

Pero esto lo hemos visto desde la perspectiva del usuario del servicio; ahora examinemos los problemas que han surgido para los empleados. <\/p>\n

A menudo escucho la afirmaci\u00f3n de que no deber\u00edan existir equipos de DevOps, que es una metodolog\u00eda, etc., pero aqu\u00ed est\u00e1 el problema: las empresas, por alguna raz\u00f3n, han dejado de buscar SysAdmins, DBAs, ingenieros de infraestructura y constructores; ahora todo es un ingeniero de DevOps en una sola persona. Claro, en algunas empresas todav\u00eda hay esas vacantes, pero son cada vez menos. Muchos han llamado a esto una evoluci\u00f3n, yo personalmente lo considero una degradaci\u00f3n, es imposible mantener un buen nivel de conocimiento en todas las \u00e1reas y, al mismo tiempo, cumplir con un horario de trabajo de 8 horas. Por supuesto, esto es fantas\u00eda. En la realidad, muchos profesionales de TI se ven obligados a trabajar 12 o incluso 14 horas, de las cuales solo se pagan 8. Y a menudo sin d\u00edas libres, porque 'me asignaron una tarea, no hay documentaci\u00f3n o est\u00e1 mal hecha, y adem\u00e1s el servicio cuesta dinero', y con un solo error en la nube, en principio, podr\u00edas no recibir salario por un par de meses, especialmente si trabajas como aut\u00f3nomo. De hecho, estamos perdiendo la palabra en los negocios, junto con la divisi\u00f3n de deberes; cada vez me encuentro m\u00e1s con que los gerentes se inmiscuyen en los procesos de desarrollo, sin entender absolutamente nada, confunden los datos de negocio con el funcionamiento de la aplicaci\u00f3n, y como resultado, comienza el caos. <\/p>\n

Cuando comienza el caos, el negocio quiere encontrar un culpable, y aqu\u00ed se necesita un culpable universal; es dif\u00edcil responsabilizar a m\u00e1s de 10 personas, por lo que los gerentes combinan posiciones, ya que cuanto m\u00e1s responsabilidades tiene un especialista, m\u00e1s f\u00e1cil es demostrar su negligencia. Y en el contexto de Agile, encontrar al 'culpable' y castigar es la base de esta metodolog\u00eda de gesti\u00f3n empresarial. Agile ha salido del \u00e1mbito de TI desde hace tiempo, y su concepto principal ha pasado a ser la exigencia de resultados diarios. El problema es que un especialista altamente especializado no siempre tendr\u00e1 resultados diarios, por lo que ser\u00e1 m\u00e1s dif\u00edcil rendir cuentas, y esa es otra raz\u00f3n por la cual el negocio busca 'especialistas en todo'. Pero la raz\u00f3n principal, por supuesto, es el costo de la mano de obra: es la principal raz\u00f3n de todos los cambios; por un aumento, la gente acepta trabajar por s\u00ed misma y por otros. Pero al final, como en otros \u00e1mbitos, esto simplemente se ha convertido en una obligaci\u00f3n, a cambio de menor remuneraci\u00f3n por un mayor n\u00famero de servicios prestados. <\/p>\n

Actualmente, es com\u00fan ver incluso art\u00edculos que sugieren que los desarrolladores deben saber desplegar y ocuparse de la infraestructura junto con el ingeniero de DevOps, pero \u00bfa d\u00f3nde conduce esto? Correcto: a la ca\u00edda de la calidad de los servicios y de los desarrolladores. Hace apenas 2 d\u00edas, le explicaba a un desarrollador que se puede escribir y leer desde diferentes hosts, mientras que \u00e9l insist\u00eda con vehemencia en que nunca hab\u00eda visto eso y que solo hay en settings host, port, db, user, password y todo... Sin embargo, el desarrollador sabe c\u00f3mo ejecutar despliegues y escribir YAML... Pero ya se olvida de las pruebas unitarias y de los comentarios en el c\u00f3digo.<\/p>\n

En resumen, vemos lo siguiente: constantes horas extras, b\u00fasqueda de soluciones a problemas fuera del horario laboral, aprendizaje continuo durante los fines de semana, no para incrementar los ingresos, sino para mantenerse a flote. Los desarrolladores se ven obligados a ayudar al ingeniero de DevOps con CI\/CD, y si el desarrollador no tiene tiempo, comienza a agobiarse, los gerentes empiezan a presionar y, si eso no ayuda a incrementar las ganas de trabajar horas extras, se comienzan a aplicar sanciones y multas. La persona busca un nuevo lugar de trabajo, dejando tras de s\u00ed una deuda t\u00e9cnica del tama\u00f1o del Everest. Como resultado, la deuda empieza a aumentar tambi\u00e9n para los desarrolladores, ya que est\u00e1n obligados a escribir c\u00f3digo con menos refactorizaci\u00f3n para poder ayudar al antiguo o nuevo ingeniero de DevOps, mientras que a los gerentes les parece todo bien, porque hay un culpable y se ve f\u00e1cilmente, lo que significa que se ha cumplido la regla principal en Agile en la gesti\u00f3n: se ha encontrado al responsable y los resultados de su castigo son visibles. <\/p>\n

Alguna vez, en ITGM, di una charla titulada '\u00bfCu\u00e1ndo aprenderemos a decir<\/p>\n

Este art\u00edculo me llev\u00f3 parcialmente a este art\u00edculo<\/a><\/noindex>, pero m\u00e1s tarde puede que lo elabore en t\u00e9rminos menos evasivos.<\/p>\n

Solo los usuarios registrados pueden participar en la encuesta. Inicie sesi\u00f3n<\/a><\/noindex>, por favor.<\/p>\n

\u00bfTe has encontrado en el trabajo cuando un empleador intent\u00f3 reemplazarte por varias personas?<\/h2>\n