Lo más triste de la situación actual es que la TI se está convirtiendo gradualmente en un sector donde no existe la palabra 'alto' en la cantidad de responsabilidades para una sola persona.
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écnica está creciendo, el viejo legado se ve como un modelo de perfección en comparación con los nuevos productos, porque al menos tiene documentación y comentarios en el código; los nuevos productos se desarrollan a la velocidad de la luz, pero al final no se pueden utilizar durante un año después de su creación, y a menudo ese año no genera ingresos; más 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ún no está funcionando, pero que ya se ha lanzado a la red como si estuviera operativo.
Por ejemplo: una conocida empresa, cuyo remaster de un viejo juego recibió las calificaciones más bajas en la historia de la industria. Yo fui uno de los que compró este producto, pero incluso ahora funciona terriblemente, y por lógica no debería haber salido a la venta en tal estado. Reembolsos, caída de calificaciones, un gran número 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ún así, el producto no es utilizable. Si este enfoque produce tales resultados en una empresa que ha estado desarrollando desde 1991, la situación es aún peor para las empresas que recién comienzan sus actividades.
Pero esto lo hemos visto desde la perspectiva del usuario del servicio; ahora examinemos los problemas que han surgido para los empleados.
A menudo escucho la afirmación de que no deberían existir equipos de DevOps, que es una metodología, etc., pero aquí está el problema: las empresas, por alguna razón, 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ía hay esas vacantes, pero son cada vez menos. Muchos han llamado a esto una evolución, yo personalmente lo considero una degradación, es imposible mantener un buen nivel de conocimiento en todas las áreas y, al mismo tiempo, cumplir con un horario de trabajo de 8 horas. Por supuesto, esto es fantasía. 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ías libres, porque 'me asignaron una tarea, no hay documentación o está mal hecha, y además el servicio cuesta dinero', y con un solo error en la nube, en principio, podrías no recibir salario por un par de meses, especialmente si trabajas como autónomo. De hecho, estamos perdiendo la palabra en los negocios, junto con la división de deberes; cada vez me encuentro más 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ón, y como resultado, comienza el caos.
Cuando comienza el caos, el negocio quiere encontrar un culpable, y aquí se necesita un culpable universal; es difícil responsabilizar a más de 10 personas, por lo que los gerentes combinan posiciones, ya que cuanto más responsabilidades tiene un especialista, más fácil es demostrar su negligencia. Y en el contexto de Agile, encontrar al 'culpable' y castigar es la base de esta metodología de gestión empresarial. Agile ha salido del ámbito 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á resultados diarios, por lo que será más difícil rendir cuentas, y esa es otra razón por la cual el negocio busca 'especialistas en todo'. Pero la razón principal, por supuesto, es el costo de la mano de obra: es la principal razón de todos los cambios; por un aumento, la gente acepta trabajar por sí misma y por otros. Pero al final, como en otros ámbitos, esto simplemente se ha convertido en una obligación, a cambio de menor remuneración por un mayor número de servicios prestados.
Actualmente, es común ver incluso artículos que sugieren que los desarrolladores deben saber desplegar y ocuparse de la infraestructura junto con el ingeniero de DevOps, pero ¿a dónde conduce esto? Correcto: a la caída de la calidad de los servicios y de los desarrolladores. Hace apenas 2 días, le explicaba a un desarrollador que se puede escribir y leer desde diferentes hosts, mientras que él insistía con vehemencia en que nunca había visto eso y que solo hay en settings host, port, db, user, password y todo... Sin embargo, el desarrollador sabe cómo ejecutar despliegues y escribir YAML... Pero ya se olvida de las pruebas unitarias y de los comentarios en el código.
En resumen, vemos lo siguiente: constantes horas extras, búsqueda 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í una deuda técnica del tamaño del Everest. Como resultado, la deuda empieza a aumentar también para los desarrolladores, ya que están obligados a escribir código con menos refactorización 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ácilmente, lo que significa que se ha cumplido la regla principal en Agile en la gestión: se ha encontrado al responsable y los resultados de su castigo son visibles.
Alguna vez, en ITGM, di una charla titulada '¿Cuándo aprenderemos a decir
Este artículo me llevó parcialmente a, pero más tarde puede que lo elabore en términos menos evasivos.
Solo los usuarios registrados pueden participar en la encuesta. , por favor.
¿Te has encontrado en el trabajo cuando un empleador intentó reemplazarte por varias personas?
65,6%Sí, me encuentro regularmente183
5,4%Sí, me encontré una vez15
15,4%No lo noté43
13,6%Soy un adicto al trabajo, trabajo horas extras38
Votaron 279 usuarios. 34 usuarios se abstuvieron.
Fuente: habr.com
