Tinselcity

Diferencias

Muestra las diferencias entre dos versiones de la página.

Enlace a la vista de comparación

Ambos lados, revisión anterior Revisión previa
Próxima revisión
Revisión previa
old:ay_ay_ay_agile [2020/11/19 10:17]
flynn
old:ay_ay_ay_agile [2021/03/17 15:26] (actual)
flynn
Línea 378: Línea 378:
 El inicio de la escena tiene algunas variaciones. En ocasiones el Arquitecto está en su mesa y alguien acude a preguntarle algo. Otras veces el Arquitecto asiste a una reunión con cuatro o cinco personas más. Otra variante común es que el Arquitecto esté haciendo su //paseillo// mirando entre las mesas, buscando alguien con quien gastar un par de horas sin hacer nada de particular. Sea como sea, la conversación empieza. Y luego continua. Y sigue continuando y continuando, dando vueltas a lo mismo o a cosas nuevas pero sin llegar nunca a una conclusión. El inicio de la escena tiene algunas variaciones. En ocasiones el Arquitecto está en su mesa y alguien acude a preguntarle algo. Otras veces el Arquitecto asiste a una reunión con cuatro o cinco personas más. Otra variante común es que el Arquitecto esté haciendo su //paseillo// mirando entre las mesas, buscando alguien con quien gastar un par de horas sin hacer nada de particular. Sea como sea, la conversación empieza. Y luego continua. Y sigue continuando y continuando, dando vueltas a lo mismo o a cosas nuevas pero sin llegar nunca a una conclusión.
  
-Los demás sí que llegan a la conclusión. Yo mismo he llegado ya muchas veces a la conclusión de que el Arquitecto en realidad solo está hablando //delante de ti// pero no está realmente hablando //contigo//. Habla consigo mismo. Pero no, no me referia a esto. Los demás llegan a una conclusión. Después de 30 minutos o de 5 horas, les oyes decir "Bueno, pues entonces hacemos esto" o "Pues voy a hacer esa opción" o "Lo pruebo y te digo algo" u otras cosas que casi rozan el "no queda más que decir; se acabó; damos por concluída la conversación". No solo eso, sino que terminan la conversación físicamente. //Se van//. Se alejan del Arquitecto y se van a su sitio. O se levantan de la reunión y recogen sus cosas. O a veces se levantan de su proprio puesto para huir hacia algún refugio como el baño, un cigarrillo, o alguna otra excusa para poner distancia entre ellos.+Los demás sí que llegan a la conclusión. Yo mismo he llegado ya muchas veces a la conclusión de que el Arquitecto en realidad solo está hablando //delante de ti// pero no está realmente hablando //contigo//. Habla consigo mismo. Pero no, no me refería a esto. Los demás llegan a una conclusión. Después de 30 minutos o de 5 horas, les oyes decir "Bueno, pues entonces hacemos esto" o "Pues voy a hacer esa opción" o "Lo pruebo y te digo algo" u otras cosas que casi rozan el "no queda más que decir; se acabó; damos por concluida la conversación". No solo eso, sino que terminan la conversación físicamente. //Se van//. Se alejan del Arquitecto y se van a su sitio. O se levantan de la reunión y recogen sus cosas. O a veces se levantan de su proprio puesto para huir hacia algún refugio como el baño, un cigarrillo, o alguna otra excusa para poner distancia entre ellos.
  
 Y entonces... el Arquitecto va detrás. Y entonces... el Arquitecto va detrás.
  
-Se levanta también y se va detrás y empieza a repetir algo de lo que ya se ha dicho para hacer que la conversación continue, aunque sea en otro lugar. La reunión pasa de la sala al pasillo. O de estar sentados a una mesa a estar de pie a dos metros de esa mesa. Del puesto de trabajo del Arquitecto al de la persona que vino a preguntar. Recuerdo que por lo menos en una ocasión le he visto decir que "ah, pues voy yo también al baño" para continuar la conversación antes, durante y después de hacer sus cosas.+Se levanta también y se va detrás y empieza a repetir algo de lo que ya se ha dicho para hacer que la conversación continúe, aunque sea en otro lugar. La reunión pasa de la sala al pasillo. O de estar sentados a una mesa a estar de pie a dos metros de esa mesa. Del puesto de trabajo del Arquitecto al de la persona que vino a preguntar. Recuerdo que por lo menos en una ocasión le he visto decir que "ah, pues voy yo también al baño" para continuar la conversación antes, durante y después de hacer sus cosas.
  
 La única estrategia que casi siempre es efectiva es el silencio. Cuando termino de hablar, no digo nada más. Y si él dice algo, yo no. Solo entonces da la conversación por agotada... O casi. Porque como mi sitio está frente al suyo, a veces al cabo de un minuto o así dice algo más y lo dice en un tono y a un volumen calculado perfectamente para que se pueda interpretar tanto como que sigue hablando conmigo como que simplemente hace un comentario casual en voz alta para sí mismo. La única estrategia que casi siempre es efectiva es el silencio. Cuando termino de hablar, no digo nada más. Y si él dice algo, yo no. Solo entonces da la conversación por agotada... O casi. Porque como mi sitio está frente al suyo, a veces al cabo de un minuto o así dice algo más y lo dice en un tono y a un volumen calculado perfectamente para que se pueda interpretar tanto como que sigue hablando conmigo como que simplemente hace un comentario casual en voz alta para sí mismo.
Línea 392: Línea 392:
 Un día el Arquitecto me enseña una de sus chapuzas. Una particularmente mala mezclando Promesas y callbacks cuando en realidad no necesita ninguna de las dos. Un día el Arquitecto me enseña una de sus chapuzas. Una particularmente mala mezclando Promesas y callbacks cuando en realidad no necesita ninguna de las dos.
  
-Se lo digo, suavemente, sugiriendo una solución mucho más simple. Dice algo como "pero es que es asíncrono; necesito la promesa...". Se lo enseño, intentanto que no parezca que su código es una estupidez absoluta sino simplemente que se puede hacer más fácil de otra forma.+Se lo digo, suavemente, sugiriendo una solución mucho más simple. Dice algo como "pero es que es asíncrono; necesito la promesa...". Se lo enseño, intentando que no parezca que su código es una estupidez absoluta sino simplemente que se puede hacer más fácil de otra forma.
  
 No se queda muy convencido, pero me dice: No se queda muy convencido, pero me dice:
Línea 430: Línea 430:
 >> Blabla - más >> Blabla - más
 > Aha, pero ya lo depuro yo... > Aha, pero ya lo depuro yo...
->> Blablabla - le quita el ratón de la mano y añade: - dale Alt Shift P.+>> Blablabla - le arranca literalmente el ratón de la mano y añade: - Dale Alt Shift P.
 > . . . > . . .
  
Línea 507: Línea 507:
 Existe una tendencia muy clara de los desarrolladores del equipo a no interesarse lo más mínimo por las herramientas que usan. No intervienen en su instalación, ni en su configuración, ni en nada. Existe una tendencia muy clara de los desarrolladores del equipo a no interesarse lo más mínimo por las herramientas que usan. No intervienen en su instalación, ni en su configuración, ni en nada.
  
-Hace un rato Reginald ha ejecutado Maven y le ha dado un error. Ha avisado a la persona "de sistemas" para que se lo arregle y mientras se lo arregla ha salido a fumar.+Hace un rato Montgomery ha ejecutado Maven y le ha dado un error. Ha avisado a la persona "de sistemas" para que se lo arregle y mientras se lo arregla ha salido a fumar.
  
 ---- ----
Línea 697: Línea 697:
  
  
-Edit: Crystal me dice que no me sorprenda. Y que no espere respuesta. Y que si incluyo al Traje en los mails tampoco espere respuesta suya.+Edit: Chrystal me dice que no me sorprenda. Y que no espere respuesta. Y que si incluyo al Traje en los mails tampoco espere respuesta suya.
  
 ---- ----
Línea 703: Línea 703:
 No-gestión de la crisis... No-gestión de la crisis...
  
-Esto me lo cuenta Henry. Crystal nos decía que si acaso nos sorprendía la (no-)respuesta que estábamos teniendo. Henry dice...+Esto me lo cuenta Henry. Chrystal nos decía que si acaso nos sorprendía la (no-)respuesta que estábamos teniendo. Henry dice...
  
 > ¿Sorprendido? Me sorprendí por última vez el martes cuando le pedí a Karen que organizase los turnos para ir a la oficina y me contestó: "A ver, esto es un equipo Scrum; organizaros vosotros. ¡Ya tenéis que saber hacerlo!" y miró complacida a [el otro traje] que asintió con la cabeza. Después me miraron como si hubiera planteado una estupidez. Desde ese momento me van a sorprender ya pocas cosas. > ¿Sorprendido? Me sorprendí por última vez el martes cuando le pedí a Karen que organizase los turnos para ir a la oficina y me contestó: "A ver, esto es un equipo Scrum; organizaros vosotros. ¡Ya tenéis que saber hacerlo!" y miró complacida a [el otro traje] que asintió con la cabeza. Después me miraron como si hubiera planteado una estupidez. Desde ese momento me van a sorprender ya pocas cosas.
Línea 855: Línea 855:
 No me meto en la conversación porque sé que no acabaría bien, pero todos sabemos perfectamente que el Arquitecto está en casa porque es el Arquitecto. No me meto en la conversación porque sé que no acabaría bien, pero todos sabemos perfectamente que el Arquitecto está en casa porque es el Arquitecto.
  
-Jenny comenta que lo de hacer turno hasta las nueve de la noche le dificulta mucho cuidar de su hijo y que eso les pasa a varios. El Traje dice casualmente que eso //"no es un riesgo para el cliente"//. Mirando en el diccionario escum-español veo que la expresión significa más o menos "me importan una mierda tus problemas" o "¿tengo cara de que me importen a mi tus problemas?", según la entonación.+Jenny comenta que lo de hacer turno hasta las nueve de la noche le dificulta mucho cuidar de su hijo y que eso les pasa a varios. El Traje dice casualmente que eso //"no es un riesgo para el cliente"//. Mirando en el diccionario scum-español veo que la expresión significa más o menos "me importan una mierda tus problemas" o "¿tengo cara de que me importen a mi tus problemas?", según la entonación.
  
 ---- ----
Línea 964: Línea 964:
 Creo que una de las cosas que más me llama la atención del proyecto es la absurda y ridícula consideración que se tiene del tiempo. Creo que una de las cosas que más me llama la atención del proyecto es la absurda y ridícula consideración que se tiene del tiempo.
  
-Por un lado, se obliga a los desarrolladores y analistas a ficher múltiples veces y a imputar tiempos a tareas teniendo que cuadrar estos tiempos con precisión de minutos en un mes. Vamos, que no puede haber un descuadre de más de un minuto o dos en los tiempos registrados cada mes.+Por un lado, se obliga a los desarrolladores y analistas a fichar múltiples veces y a imputar tiempos a tareas teniendo que cuadrar estos tiempos con precisión de minutos en un mes. Vamos, que no puede haber un descuadre de más de un minuto o dos en los tiempos registrados cada mes.
  
 Esto, en sí mismo, es algo que podría, haciendo algo de esfuerzo, llegar a aceptar. Personalmente no creo que sea posible registrar los tiempos con esa precisión, particularmente en un entorno en el que muchas tareas ni siquiera están definidas. Al final lo que ocurre es que todo el mundo //rellena// tareas. Es decir, los tiempos //cuadran// pero no son reales en absoluto. Si asumimos esa mentira, bueno, es algo que por lo menos se puede hacer. Esto, en sí mismo, es algo que podría, haciendo algo de esfuerzo, llegar a aceptar. Personalmente no creo que sea posible registrar los tiempos con esa precisión, particularmente en un entorno en el que muchas tareas ni siquiera están definidas. Al final lo que ocurre es que todo el mundo //rellena// tareas. Es decir, los tiempos //cuadran// pero no son reales en absoluto. Si asumimos esa mentira, bueno, es algo que por lo menos se puede hacer.
Línea 1025: Línea 1025:
 Esto es lo que ocurre cada tres semanas, con cada nuevo //sprint//((Los números son reales, sacados del último mensaje de estos, el de ayer. Y suelen ser números parecidos a estos, sí. La mayoría de las cosas se van arrastrando y he visto tareas que se llevan arrastrando más de dos años sin que nadie se plantee ni hacerlas ni eliminarlas)). No hay, obviamente, ningún tipo de planificación de los //sprints//. Tampoco hay ningún tipo de revisión al cierre de un //sprint//. Este mensaje es lo único que marca, de algún modo, un //sprint//. Esto es lo que ocurre cada tres semanas, con cada nuevo //sprint//((Los números son reales, sacados del último mensaje de estos, el de ayer. Y suelen ser números parecidos a estos, sí. La mayoría de las cosas se van arrastrando y he visto tareas que se llevan arrastrando más de dos años sin que nadie se plantee ni hacerlas ni eliminarlas)). No hay, obviamente, ningún tipo de planificación de los //sprints//. Tampoco hay ningún tipo de revisión al cierre de un //sprint//. Este mensaje es lo único que marca, de algún modo, un //sprint//.
  
-Los //sprints// están agrupados en dos ciclos de entregas anuales. Eso supone que hay aproximadamente unos 8 o 9 //sprints// por ciclo. No se hace tampoco ninguna planificación con el equipo al principio de uno de estos ciclos. De hecho, el principio de un ciclo queda difuminado por dos detalles: antes de que empiece ya hay gente del equipo trabajando en la siguiente versión; y, después de que temrine sigue habiendo gente trabajando en la versión anterior. Yo mismo he hecho tareas((y digo tareas, no corrección de errores)) de una versión anterior unos 3 meses después de la fecha de entrega de esa versión, y he hecho tareas que estaban planificadas pero no se entregarán hasta dentro de casi un año.+Los //sprints// están agrupados en dos ciclos de entregas anuales. Eso supone que hay aproximadamente unos 8 o 9 //sprints// por ciclo. No se hace tampoco ninguna planificación con el equipo al principio de uno de estos ciclos. De hecho, el principio de un ciclo queda difuminado por dos detalles: antes de que empiece ya hay gente del equipo trabajando en la siguiente versión; y, después de que termine sigue habiendo gente trabajando en la versión anterior. Yo mismo he hecho tareas((y digo tareas, no corrección de errores)) de una versión anterior unos 3 meses después de la fecha de entrega de esa versión, y he hecho tareas que estaban planificadas pero no se entregarán hasta dentro de casi un año.
  
 Si no hay nada de esa planificación, ¿cómo ocurren las cosas? Bueno, ocurren porque como equipo Agile no somos ni Agile ni equipo. Cada //analista// hace su planificación como quiere. Que generalmente significa que no hace planificación en absoluto sino que va directamente al desarrollador con el que suele trabajar o que le cae bien o lo que sea y le dice que le va a pasar algunas tareas y que ya las irán viendo. Si no hay nada de esa planificación, ¿cómo ocurren las cosas? Bueno, ocurren porque como equipo Agile no somos ni Agile ni equipo. Cada //analista// hace su planificación como quiere. Que generalmente significa que no hace planificación en absoluto sino que va directamente al desarrollador con el que suele trabajar o que le cae bien o lo que sea y le dice que le va a pasar algunas tareas y que ya las irán viendo.
Línea 1388: Línea 1388:
 ---- ----
  
-WiP:+Una vez entras en la aplicación, aterrizas en una página con diferentes paneles de información y acciones. En uno de esos paneles hay "herramientas externas". Son una serie de iconos que enlazan con otras aplicaciones relacionadas. No todos los usuarios tienen acceso a todas las herramientas, pero pueden solicitarlo. Así que cada icono tiene 2 versiones, una activa (normal) y otra desactivada (gris). 
 +  
 +Hay una carpeta donde se guardan estas imágenes. Todos los ficheros de estos iconos (unos 20) siguen una misma nomenclatura''portada_nombreAplicacion.gif'' para el normal y ''portada_nombreAplicacionDes.gif'' para el desactivado/gris. 
 + 
 +Hoy Monty ha recibido la tarea de renovar uno de estos iconos. No cambia nada más que el icono. El enlace es igual, la aplicación es la misma. Solo cambia el icono. Media hora después, Gerald le ha hecho notar a Monty que necesita poner también la versión en gris. Como Monty estaba ya un poco cansado, ha terminado Gerald la tarea. 
 + 
 +Así que ahora hay unos 20 iconos con un nombre como ''portada_nombre.gif'' y ''portada_nombreDes.gif'', uno que se llama ''transporteAll.gif'' y su versión gris que se llama ''transporteDesactivado.gif''. Por supuesto, el icono antiguo, que ya no se usa, sigue ahí en el repositorio, porque si la consistencia importa poco, borrar lo que ya no se usa importa incluso menos. 
 + 
 +Ya solo me quedan 4 semanas aquí. 
 + 
 +---- 
 + 
 +Hay un wiki para el equipo de desarrollo. 
 + 
 +Bueno, hay mucha historia ahí, claro, porque a nadie parece importarle el wiki. Pero bueno, eso ya no me preocupa. El wiki tiene documentación de desarrollo, explica cómo hacer bastantes cosas de "la parte de front"
 + 
 +Pero el wiki tiene una pequeña trampa. Como vi que se empeñaban en copiar y pegar las cosas sin entenderlas. Poco a poco fui cambiando los ejemplos de código por imágenes. Así como mínimo tienen que teclearlo y quizá con eso se les quede un poco más en la cabeza. Eh, no creo, pero ojalá. El caso es que hay una parte de la documentación que no la he escrito yo sino la diseñadora/maquetadora que nos dejó hace medio año. Antes de irse, dejó cinco o seis páginas de documentación de "interfaz de usuario". La mayoría son imágenes de cómo deben quedar las cosas, pero en alguna de las páginas también hay algún trozo de código que puso ella. El código no es bueno, pero esos trozos de código no los cambié por imágenes porque me pareció que no merecía la pena y que se entendería que no era código bueno porque, de hecho, es bastante malo. 
 + 
 +Pues hoy Monty ha ido directo a copiar uno de esos trozos de código. 
 + 
 +Por suerte, Edward estaba ahí. 
 + 
 +>No, no, espera. Este código no está bien. Mira, hay un ''<img>'' con el ''onClick'' puesto ahí directamente. Eso **claramente** no puede ser así. 
 +>>Ah - dice Monty 
 + 
 +Me lo comentan y les digo que sí, que efectivamente ese código no esta bien y no se debe copiar. //"Ah, vale, vale"// - dice Monty. 
 + 
 +Por si acaso, edito el wiki y marco las cuatro páginas con un aviso grande, rojo y en negrita que dice que el código no es bueno y que no debe copiarse. Por si acaso también, me acerco a Monty y le enseño el aviso. //"Ah, vale, vale"// - dice Monty, otra vez. 
 + 
 +Veinte minutos después, Monty //hace commit// y sube al repositorio su cambio. El cambio, por supuesto, lleva exactamente //"un ''<img>'' con el ''onClick'' puesto ahí directamente"//. Porque, obvio, está copiado directamente del wiki. 
 + 
 +Yo no tengo ningún interés de tener conflictos a estas alturas, claro, así que no le digo nada. Pero como me entra ya la duda de si a lo mejor es que es cosa mía, se lo enseño a Edward. Lo ve. 
 + 
 +>¿Eh? Pero, ¿qué...? Ah... ah, ya. Que ha hecho lo que le ha salido de las narices. En fin... 
 + 
 +Sí, "en fin". En fin, Monty [[old:ay_ay_ay_agile:hacemuchotiempo|me recuerda a alguien de hace muchos años]]. 
 + 
 +---- 
 + 
 +Esto es un ejemplo bastante representativo... 
 + 
 +En el año 2013 se crea una tarea para desarrollar en la aplicación un apartado de //Preguntas Frecuentes//
 + 
 +Diez días después, un desarrollador de aquella época sube la //propuesta// al repositorio. Es solo eso, una propuesta. Básicamente poco más que una página maquetada con media docena de preguntas de ejemplo con una respuesta que dice, literalmente: "Respuestaaaaaaaaaaaaaaa". Tiene un poco de JavaScript para desplegar las respuestas. Insisto en que se sube al repositorio. Esto significa que, automáticamente pasa a producción algún tiempo después, sin enlazar desde ningún sitio pero presente. 
 + 
 +Seis meses, en Febrero, después la propuesta no ha progresado. En la tarea de JIRA no hay ningún comentario en absoluto sobre la propuesta en sí. No hay nada que refleje ningún avance ni ninguna decisión. Lo único que hay es un cambio de estado, hecho en grupo a varias tareas, que simplemente dice que queda //"para versiones futuras"//
 + 
 +Para eso de las verrsiones futuras, se abre inmediatamente otra tarea en la que se //investiga// la idea de las preguntas frecuentes. Se registran unas cuantas semanas de trabajo de tres o cuatro personas a lo largo de los siguientes meses. Se sube una nueva propuesta, esta vez más completa con las preguntas ya en una tabla de base de datos, al repositorio para su evaluación. 
 + 
 +A final de Marzo sube el último cambio al repositorio. En Mayo, sin más comentario, la tarea se marca como resuelta. La tabla de base de datos con las preguntas está vacía. La funcionalidad está desactivada. Todo el código está presente y desplegado en producción, claro está. 
 + 
 +No parece haber más movimiento hasta 3 años después cuando, sin más comentario, la tarea pasa a estar //"Cerrada"// y //"Solucionada"// y al mismo tiempo se abre otra tarea nueva para dar de baja toda la funcionalidad. El motivo de dar de baja la funcionalidad es que, tras tener la funcionalidad en producción tres años, no se ha usado nunca. No se ha hecho disponible para ningún perfil, el tema "está bastante anticuado" y "posiblemente se haga la gestión de FAQ" en un portal de Sharepoint que se está planteando utilizar para varias cosas. El portal de Sharepoint llegará un par de años después. 
 + 
 +No se elimina nada en absoluto del código. Las tablas siguen vacías pero presentes a día de hoy en la base de datos. Se deja todo el código ahí, como un ajusticiado a la entrada de la ciudad que avisa al visitante de que lo único que va a encontrar aquí es podredumbre y muerte. 
 + 
 +Pero no, no, el código no queda ahí colgado fuera de la ciudad. Ni siquiera en una pila de cadáveres en un rincón. Queda, junto con docenas más, repartido por la aplicación, sin nada que lo distinga del código "bueno". Son cadáveres en las calles, vestidos y arreglados. Incluso cuidados, porque de vez en cuando se ven que alguien sin saber que están muertos, les pone bien el sombrero, les arregla un par de estilos que nunca se verán, o les cambia un par de funciones de un JavaScript que nunca se ejecuta. 
 + 
 +----
  
 Mientras espero que llegue el día oficial de dejar esto para siempre, me dedico a pensar qué único detalle técnico podría resumir todo este proyecto. Ahora mismo tengo algunos candidatos en la cabeza. Mientras espero que llegue el día oficial de dejar esto para siempre, me dedico a pensar qué único detalle técnico podría resumir todo este proyecto. Ahora mismo tengo algunos candidatos en la cabeza.
Línea 1404: Línea 1461:
  
 Porque estas dos líneas representan mucho más de lo que se ve a simple vista. Incluso más de lo que se ve después de pensar en ellas unos minutos. Hay por ahí otras líneas parecidas, como un ''parseFloat(24)'' en una página, pero quedarse en eso que se ve es muy superficial. Creo sinceramente que, si quisiera, podría llegar a dar toda una charla de más de una hora((Y hasta dos horas, si no fuera tan aburrido)) sobre esas dos líneas. Porque estas dos líneas representan mucho más de lo que se ve a simple vista. Incluso más de lo que se ve después de pensar en ellas unos minutos. Hay por ahí otras líneas parecidas, como un ''parseFloat(24)'' en una página, pero quedarse en eso que se ve es muy superficial. Creo sinceramente que, si quisiera, podría llegar a dar toda una charla de más de una hora((Y hasta dos horas, si no fuera tan aburrido)) sobre esas dos líneas.
 +
 +----
 +
 +== Epílogo ==
 +
 +Finalmente me fui del proyecto -y de la empresa- hace unos días.
 +
 +No hubo grandes despedidas, pero sí algunas pequeñas. Una, quizá dos personas que seguramente son de lo poco salvable del equipo, se despidieron de mi charlando un rato. Otro par ya lo había hecho antes, porque en estos últimos días muchos han tenido que cogerse //"obligados"// los días de vacaciones que les quedaban. Del resto alguno ni siquiera sabía que me iba hasta que ha ocurrido.
 +
 +Los dos Trajes se despidieron en una charla de media hora en la que, "de muy buen rollo", me recordaron que ellos esperaban otra cosa de mi, que la vida es así, y que aunque seguían pensando que no necesitaban cambiar nada, iban a hacer algún despido //pronto//. No sé si fue la forma de decírmelo, pero me pareció algo //poco agradable// de decirme en esa situación.
 +
 +En fin, aunque sospechaba que sería él por cómo lo dijeron, hoy me ha llegado la confirmación de que han despedido a Monty. Así, sin más. No puedo decir que me alegre, porque realmente no me alegro, pero por otra parte se lo venía buscando desde hacía tiempo. En los últimos meses estuvo trabajando con supervisión directa y muy cercana de Karen. Y seguramente él no sospechaba nada, pero yo tenía la sensación de que le estaba evaluando, y que no lo estaba haciendo precisamente bien.
 +
 +Me da un poco de pena la situación en que se queda Edward. Queda como el único con la etiqueta //"front"// y con todas las papeletas para que le caiga encima un montón de porquería. No creo que tarde mucho en buscarse otra cosa, y cuando eso pase... bueno, supongo que el equipo quedará como estaba antes de que entráramos nosotros tres. Solo Gunther, el especialista en datos, sigue como fichaje reciente. El resto... un montón de ruinas en un equilibrio inestable de peleas y gritos.
 +
 +Queda solo una cosa... En algún momento me llegué a preguntar si quizá perderían el contrato. El concurso era en estos meses con la adjudicación a partir de Febrero de 2021. Y me preguntaba esto porque, bueno, la empresa había perdido recientemente la renovación de un contrato similar. Pero por simple curiosidad (y por un poco de casualidad) me encontré leyendo por encima el pliego de requerimientos y condiciones del concurso de mantenimiento y resulta que está escrito con la colaboración del Traje y del Arquitecto. No tengo pruebas, obviamente, pero tampoco tengo dudas. El pliego incluye detalles técnicos que no tendría porqué incluir y que son reflejo directo de lo que el Traje y el Arquitecto quieren hacer. Sí, ya, eso sería ligéramente sucio. Solo son 6 millones y pico de euros que pagamos entre todos. 6 millones para mantener las tonterías del Arquitecto desde su casa... En fin... Sí, se lo han renovado, claro.