El rendimiento, la percepción y el teléfono escacharrado…

¿cúal será la realidad? Dice el doctor House que los pacientes siempre mienten… yo digo que los usuarios no siempre dicen la verdad cuando hablan de rendimiento… al final las consecuencias son similares: House o yo acabamos dando palos de ciego. Lo más curioso de la situación es que, al contrario de los pacientes de House, los usuarios no mienten de manera consciente tratando de ocultar trapos sucios. Los usuarios no siempre dicen la verdad por dos motivos: el primero, por que su percepción le engaña a menudo, el segundo por que no siempre es el usuario que sufre el problema de rendimiento el que nos da la información.

Os voy a contar una historia que ilustra la situación.

Llamada a soporte postventa de un cliente. En concreto llama el Director del departamento de producción de Tromperris. El nunca toca el software de gestión de Tromperris, pero que más da, el es el Jefe y resulta que sus indios están en pie de guerra por que los informes vitales que imprimen todos, absolutamente todos, los días tardan la barbaridad de diez minutos en generarse ¡inaceptable!. La gente de soporte se acojona, no sin motivo, por que ha llamado el Jefe y tal y escala el problema ‘ipso facto’ sin recabar más información. Así que aquí estoy yo lidiando con el problema.

¿Por qué el Jefe llamó y dijo diez minutos?. La historia es como sigue:

Jefe: Supervisor, ¿cuál es el problema más grave que hay con la aplicación de gestión de Tromperris?

Supervisor: No, sé… quizás los informes, algunos tardan mucho…

Jefe: ¿Cuánto es mucho?

Supervisor: No se… preguntaré a los indios, que son los que se quejan…

Indio: Los informes que más tardan son los de fin de mes, tardan más que el resto… como tres minutos…

Supervisor: Que barbaridad, ¡tres minutos!… Hay que tomar medidas inmediatas… se lo diré al jefe…

[El indio se encoje de hombros y sigue a los suyo…]

Supervisor: Jefe, ya se lo que tardan los informes… ¡casi cinco minutos!

Jefe: Ahora mismo llamo, ¡cinco minutos perdidos todos los días!, no puede ser…

[El jefe llama a soporte]

Jefe: Los informes tardan 10 minutos (si exagero un poco seguro que me hacen más caso, piensa, no sin razón…

Soporte: Ahora mismo los escalamos… (si ha llamado el Jefe y dice que es tan grave lo será ¿no?)

Como yo ya se que los usuarios no siempre dicen la verdad, trato de objetivar la información. Así que sin más, cojo una traza con el profiler de Sql Server y trazo todas las consultas que tarden más de tres minutos y que veo… que no hay consulta alguna que tarde más de tres minutos, así que difícil será que algún informe tarde cinco minutos… es más, tras bajar el tiempo de filtrado, no veo la consulta que el informe lanza por ningún lado. Sospechoso… a lo mejor el informe no se lanza con tanta frecuencia como el usuario dice… miro los logs de la aplicación y parece que el informe en cuestión ¡solo se lanza a final de cada mes!.

Ejecuto el informe, y el profiler no miente, dos minutos de consulta. Algo normal para el volumen de información consultado. Lanzo el informe de nuevo, cronometro en mano y tres minutos hasta que lo tengo en pantalla. Correcto.

Al final la cosa se enmaraña, como no, lo que sea para no bajarnos del burro… así que ahí estoy yo en el cliente, con el indio…

Yo: Aupa, así que el informe tarda diez minutos… yo no veo eso en las trazas…

Indio: ¿diez minutos? No… menos, pero es lento…

Yo: ¿Cuánto crees que debería tardar el informe?

Indio: No se, unos tres minutos o así… total le saco una vez al mes.

Yo: Lanza el informe que cronometramos…

[Tres minutos después]

Yo: Tres minutos….

Indio: Pensé que era más… como solo le saco una vez al mes y el resto van más rápido…

Moralejas:

  1. No te fíes de lo que te cuentan solo de lo que te cuentan los profilers y los logs…
  2. En cuestiones de rendimiento, todo el mundo exagera.

Solo actuar en base a datos y dejar de lado percepciones y cadenas de exageraciones va a permitir que en cuestiones de rendimiento no demos palos de ciego.

¡Un saludo!

10 comentarios en “El rendimiento, la percepción y el teléfono escacharrado…”

  1. Buenas Rodrigo,
    Gran verdad la que cuentas aquí, aunque opino que no sólo es que los clientes mientan, que lo hacen, sino que de manera insconciente se produce algo muy típico entre las personas humanas: la comunicación se distorsina!

    Un abrazo crack

    JC’s

  2. Informes! has tenido que poner el ejemplo con informes! un año! un año me pase sufriendo casi línea por línea esa historia en varios proyectos, con las misma connotaciones y similar resultado… ahora ya me encargo de incluir las estimaciones en la documentación jejeje

    Muy bueno si señor. Algo que todos vemos pero que nadie dice (en voz alta).

  3. Hace ya algún tiempo traté de hacer ver al entonces mi “jefe” que deberíamos dotar a las aplicaciones de logs para comprobar los cortes de luz.
    Teníamos problemas similares al del rendimiento; aparecían errores en las instlaciones de nuestro software estándard que resultaban del fallo en el suministro eléctrico, lo sabíamos y los codigos y descripciones de los errores lo teníamos documentados como tal, además todo cálculo acumulado persistente se veía afectado por su “disparidad” con la realidad.

    Cuando en casos como estos llegaba la hora de preguntar al usuario “¿Tiene cortes de luz?” siempre era NO, NO… hasta que después de muchas llamadas, hablabas con varias personas, y comentando “como el que no quiere la cosa” preguntábamos de nuevo y en un tono muy cordial “Que tal llevais los cortes de luz estos últimos meses?” y la respuesta acojonaba “Bueno, la verdad es que desde que todos los del poligono nos quejamos a la compañía de luz solo tenemos uno o dos a la semana…”. Así nos ocurría con buena parte de los usuarios.

    Yo creo firmemente una cosa, un usuario en esta situación se asusta y debe de pensar “Como diga que la fuente del problema es ajena al software no me ayudarán a reorganizar la BBDD dañada o el problema en la discordancia de información..” y alguno mienten para no verse solos en la cura, y tambien porque saben que no tienen copia de seguridad y quieren que les ayudes.

  4. Estimado Rodrigo,

    en esos casos, tendrías que haber sacado la clásica cantinela de “Pues aproveche señora y lléves Tromperris *2.0*, dónde se ha optimizado de sobremanera el rendimiento de los informes: un 200%, de 10 minutos baja a sólo 3! Lléveselo señora, ¡qué me lo quitan de las manos!” x-DDD

    saludos

  5. Recuerdo la llamada de un vendedor en un cliente: “la aplicación no funciona, instale y seguí todo los pasos pero no funciona, a ver revisa tu código para ver que esta pasando”

    Obviamente tirar a depurar a Visual Studio, es lo peor que se puede hacer. Y al vendedor no le quedo la más fácil que decir: “la aplicación esta mal”.

    La respuesta fue: “si no veo el error no puedo hacer nada, desde acá no puedo probar nada para que funcione”. Ya en un próxima visita, junto con el vendedor se identifico que el problema era la configuración del servidor IIS del cliente…

    Y nuevamente la moraleja: Antes empezar a escalar o depurar, identifica realmente el problema, no basta con lo que usuario dice.

    Saludos,

  6. La historia, aunque parafraseada, se parece mucho a la de User Stories Applied, ¿no? (Cap 5. The User’s Manager, Five Minutes Does Not Equal One Minute)

  7. @alberto: Si, la historia que tu comentas, inspiro este post. Eso y el que justo la semana en que lo leí, sufrí los problemas que relato en el post.

    ¡Un saludo!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *