Lo más triste en la situación actual es que la TI se está convirtiendo gradualmente en una industria en la que no existe la palabra "detener" en absoluto en la cantidad de tareas por persona.
Al leer las vacantes, a veces incluso ves no 2-3 personas, sino una empresa completa en una persona, todos tienen prisa, la deuda técnica está creciendo, el antiguo legado se ve perfecto en el contexto de los nuevos productos, porque al menos tiene documentos y comentarios en el código, nuevo Los productos se escriben a la velocidad de la luz, pero como resultado, no se pueden usar hasta un año después de su escritura y, a menudo, este año no genera ganancias, además, los costos de la "nube" son más altos que 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 liberado a la red como trabajador.
Como ejemplo: una empresa conocida cuya remasterización de un juego antiguo recibió las calificaciones más bajas en la historia de la industria. Yo fui uno de los que compró este producto, pero incluso ahora este producto funciona terriblemente y, en teoría, no debería haber salido a la venta de esta forma. Reembolsos, caída de calificaciones, una gran cantidad de prohibiciones de usuarios en foros por quejas sobre servicios. La cantidad de parches no es sorprendente, sino aterradora, pero de todos modos: el producto no se puede usar. Si este enfoque conduce a tales resultados para una empresa que se ha estado desarrollando desde el 91, entonces para las empresas que recién comienzan, la situación es aún peor.
Pero analizamos los resultados de este enfoque desde el lado del usuario del servicio, y ahora veamos los problemas que tienen los empleados.
A menudo escucho la afirmación de que los equipos de DevOps no deberían existir, que esta es una metodología, etc., pero el problema es que las empresas, por alguna razón, dejaron de buscar nudos, dba, constructores de infraestructura e ingenieros de construcción; ahora todo es un ingeniero de DevOps en una sola persona. Por supuesto, todavía hay vacantes en empresas individuales, pero cada vez hay menos. Muchos llamaron a esto desarrollo, yo personalmente veo degradación en esto, es imposible mantener un buen nivel de conocimiento en todas las áreas, y al mismo tiempo lograr trabajar no más de 8 horas. Naturalmente, estas son fantasías. En realidad, muchos especialistas en TI se ven obligados a trabajar 12 o 14 horas, de las cuales se pagan 8. Y a menudo los siete días de la semana, porque "me dieron una tarea, no hay muelles ni curvas, e incluso el servicio cuesta dinero", y por 1 Un error en la nube puede, en principio, hacer que no obtengas un salario en un par de meses, sobre todo si trabajas en una IP.De hecho, estamos perdiendo nuestra palabra en los negocios, junto con la separación de funciones, cada vez me encuentro más con el hecho de que los gerentes se meten en los procesos de desarrollo, generalmente sin entender nada sobre ellos, confunden los datos comerciales y el funcionamiento de la aplicación, como resultado comienza el caos.
Cuando comienza el caos, la empresa quiere encontrar al culpable, y aquí se necesita un culpable universal, es difícil culpar a más de 10 personas, por lo tanto, los gerentes combinan posiciones, porque cuantas más responsabilidades tiene un especialista, más fácil es demostrar su negligencia. Y en las condiciones de Agile, encontrar al “culpable” y azotar es la base de esta metodología de hacer negocios en la gestión. Agile dejó la TI durante mucho tiempo y su concepto principal se convirtió en el requisito de los resultados diarios. El problema es que un especialista altamente especializado no siempre tendrá un resultado diario, por lo que será más difícil informar, y esta es otra razón por la que el negocio quiere “expertos en todo”. Pero la razón principal, por supuesto, es la nómina: es la razón principal de todos los cambios, en aras de una bonificación, la gente acordó trabajar para ellos y para ese tipo. Pero al final, como en otras áreas,simplemente se ha convertido ahora en un deber, por menos pago por más servicios prestados.
Ahora, a menudo puede ver incluso artículos sobre lo que los desarrolladores ya deberían poder implementar, deberían ocuparse de la infraestructura junto a un ingeniero de DevOps, pero ¿a qué conduce esto? Así es, a una caída en la calidad de los servicios, a una caída en la calidad de los desarrolladores. Hace apenas 2 días, le expliqué al desarrollador que se puede escribir y leer desde diferentes hosts, y me demostraron con espuma en la boca que nunca habían visto tal cosa, aquí están en settings orm host, port, db, user, password y ya está .... Pero el desarrollador sabe cómo ejecutar implementaciones, escribir yamls ... Pero ya se olvida de las pruebas unitarias y los comentarios en el código.
Como resultado, vemos lo siguiente: exceso de trabajo constante, búsqueda de soluciones a problemas fuera del horario laboral, capacitación constante los fines de semana, y no para aumentar los ingresos, sino para mantenernos 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 coser y los gerentes comienzan a golpear sus cerebros, y si esto no ayuda a aumentar el deseo de trabajar horas extras, luego aplica sanciones y multas, la persona está buscando un nuevo trabajo. dejando atrás una deuda técnica del tamaño del Everest, como resultado, la deuda comienza a crecer entre los desarrolladores, porque se ven obligados a escribir código con menos refactorización para tener tiempo de ayudar tanto al antiguo como al nuevo ingeniero de DevOps, y los gerentes están bastante contentos con todo, porque hay un culpable y es inmediatamente visible, lo que significa que se observa la regla principal en la gestión ágil, se encuentra al culpable,los resultados de sus azotes son visibles.
Una vez en ITGM di una charla “cuando aprendemos a decir no”, sus resultados fueron muy reveladores. Un gran número de personas cree que esta palabra es tabú, y hasta que dejemos de pensar de esa manera, los problemas solo crecerán.
Parte de este artículo se inspiró en este artículo , pero más adelante probablemente lo escribiré en términos menos suaves.