Una de las frases que más stress me causa es no funciona. Como desarrollador, administrador de sistemas o incluso líder técnico he tenido que escuchar esta frase acompañada del elemento que no funciona descrito de forma tan ambigua que la frase en sí no sirve de nada, ¿te ha pasado?
- El correo no funciona
- La página web no funciona
- El servidor no funciona
- ...
Lo más frustrante es ir a ese elemento en concreto con el peor escenario posible en la cabeza y ver que sí funciona. El correo funciona y puedes ver logs de conexiones exitosas y ningún fallo, puedes ver la página web en tu navegador y puedes conectarte a ese servidor sin problemas.
¿Qué es lo que no funciona?
Hay muchos de nosotros que da igual qué rol juguemos en un equipo de desarrollo. De seguro todos hemos cometido la fatídica acción de decir no funciona. ¡Ala! ¿Pero qué no funciona? ¿Qué estás haciendo específicamente que no te funciona? Esta frase está al mismo nivel que en local funciona de muchos desarrolladores siendo el caso contrapuesto. No hay contexto, no se dice qué es exactamente lo que no funciona. Solo nos quedan dos opciones ante esta situación:
- Ignorar. Sí, muchos deciden ignorar. Es el peor de los casos porque quien emite la incidencia no recibe ninguna retroalimentación, lo seguirá haciendo y tendrá la sensación de que a quién envía las incidencias no es nada profesional y razón no le falta. No es una actitud muy profesional.
- Restar importancia. Hemos hecho la comprobación general y no vemos ese no funciona que clama la incidencia por lo que automáticamente le restamos importancia en el triage. Este es un caso mejor porque la notificación de cambio de prioridad le llegará a quien emite y podrá quejarse, pero igualmente si no argumentamos el porqué de la resta de importancia podemos caer en el mismo error de quién emitió la incidencia.
- Cerrar. Es decir, en local funciona o cerrada con el estado no reproducible. Este caso es igual al anterior. Un poco mejor porque al menos al especificar el motivo del cierre de la incidencia damos pistas a quien abrió la incidencia para que pueda argumentar de forma más correcta.
Lo que realmente debemos hacer como profesionales es cambiar el estado de la incidencia a necesita más información y asignarla a quien la emitió. Esta es la decisión correcta porque sin un contexto, sin saber qué falla no podemos ayudar a la resolución de la incidencia.
Puede ser que el envío de un email no esté funcionando por una configuración incorrecta del cliente de correo y se haya emitido como un el correo no funciona o puede que el certificado haya caducado y el servidor en realidad no funcione para el envío de correo pero sí para acceder a la bandeja de entrada.
Especificar bien una incidencia
Debemos especificar claramente los detalles de la incidencia y esto no solo aplica a quien escribe/abre las incidencias sino a todos, porque en algún momento todos necesitamos notificar un error. Debemos indicar:
- ¿Qué no funciona? Si la frase es simple está mal construida. Debe haber más complementos en el predicado. No funciona el correo mal. No funciona el correo cuando intento enviar un email mejor. No funciona el correo cuando envío un email de mi cuenta a otra de GMail ideal. Debe quedar claro el escenario del problema.
- ¿Cómo lo reproducimos? Hay que explicar el contexto, qué estamos haciendo para recibir ese comportamiento anómalo. Si el correo funciona cuando envío a Yahoo pero no cuando envío a GMail hay que especificarlo. Si no sucede siempre sino solo a veces también es importante reseñarlo. Funciona desde la oficina pero no desde el móvil cuando estás conectado con datos, ¡hay que decirlo!
- Información del error Normalmente cuando algo no funciona o tiene un comportamiento anómalo queda patente por algún mensaje de error. Una captura de pantalla o copiar ese mensaje de error para la incidencia sería un buen dato para poder entender de qué se trata con mayor velocidad.
Puedes probar con algún compañero que esté cerca, que intente reproducir el caso de error y compruebe si también le sucede. Siendo positivo o negativo el caso tendrás más información para la incidencia y su estudio para su resolución.
Conclusiones
Por favor, dejad de usar no funciona a secas como incidencia o notificación de que algo no funciona. Sed más claros a la hora de especificar qué es lo que no funciona, qué hacéis, qué errores recibís y toda la información que se pueda aportar. No por emitir el mensaje lo más rápido posible se va a solucionar antes, el proceso de obtener información para saber qué está mal puede verse interferido si la información es incompleta.
¿Te ha pasado este escenario? ¿Qué medidas has aplicado o ha aplicado tu empresa para intentar paliarlo? ¿Aún sigue pasando aún así? ¡Déjanos tu comentario!
