Corrigiendo malas costumbres del trabajo

A veces, por la ansiedad o por querer concretar una tarea asignada en el menor tiempo posible, hago una rutina en mi trabajo que me produce unos errores, o mejor dicho, que tiene arraigadas ciertas “malas costumbres”, que con el tiempo terminan siendo tóxicas para la carrera profesional de cualquiera.
Quizás no seas del rubro del Testing (QC, por ahí lo llaman), o ni siquiera estés vinculado con el mundillo de “SISTEMAS”; pero hoy te comparto estas experiencias para que VOS analices, estudies tu rutina y puedas mejorar tu trabajo. Arrancamos?

Revisar muy poco la documentación.

El primer error que cometo siempre, es NO revisar minuciosamente toda la documentación que recibo de otra área sobre el proyecto. Normalmente quien te generó la documentación, te recibe con muy mala cara cuando apareces preguntando cuestiones que se encuentran no solo registradas, sino que detalladas en un documento (sea funcional o más técnico). Testing, y más cuando se utilizan métodos ágiles; puede que no reciba mucha documentación para poder orientarse en las pruebas pero las veces en las que si lo hace, hay que dedicar tiempo a leer esos documentos. De ello depende luego, el diseño de las pruebas y la ejecución de los casos de pruebas. Si no hay una buena compresión de los registros que uno recibe, SÍ es hora de preguntar.

No preguntar y aparentar haber entendido, cuando “NO ENTENDÍ NADA”.

Si bien, estas “Malas costumbres” son propias de quién les escribe, he observado al conversar con muchos colegas que esto pasa más seguido de lo que pensaba.
Uno asiste a una capacitación o lee la documentación del proyecto y en realidad no comprende uno o varios puntos de lo que, se supone, debería asimilar; pero a la hora de pensar en las pruebas, se da cuenta que de verdad no entendió nada o una gran parte. Muchas veces, en mi propia experiencia, hay una persona que lee muy bien ciertas expresiones (gesticulaciones, muecas, miradas, suspiros o caras tristes directamente) y entonces se produce la repregunta por si el tema en cuestión se está entendiendo correctamente pero, y si la persona que te esta explicando no tiene las habilidades para reconocer que no estoy entendiendo absolutamente nada de lo qué dice?
Es mejor preguntar, y quedar (algunas veces) como tonto que guardar dudas que en el futuro nos van a embarrar el camino.

Al solicitar ayuda técnica o derivar un informe de un incidente (bug), NO entregar toda la información completa y clara.

Muchas veces, me surgen inconvenientes por instalación o de cuando implementan un proyecto en los ambientes disponibles a efectos de Testing/Homologación. Ahora bien, en cuanto me oriento hacia soporte interno para solicitar ayuda, la mayor parte de estas veces, jamás les daba una introducción. Siempre planteaba el problema, esperando que entendieran de qué módulo estaba hablando, con qué versión y con lo poco que les comentaba del problema actual pretendía que me resolvieran la situación al instante.

Esto lo fui corrigiendo, y hasta el día de hoy siempre veo una mejora continua en asuntos de comunicación con otros sectores, de la siguiente manera:

En primer lugar, y aprovechando los conocimientos de Testing y estandarización que adquirí gracias a las Normas ISO 9001-2008 y ISO 9001-2015 arme un esquema de conversación efectiva, estructurada así.

  • Contar un poco lo que estoy probando, o qué me encuentro haciendo antes del error. Si es necesario les cuento de qué trata la nueva funcionalidad
  • Mostrar el error, con evidencias (capturas de pantalla, vídeos, fotos*, etc)
  • Describir todos los datos de ejecución, más las pre-condiciones necesarias. Y UN PASO A PASO BIEN DETALLADO. O volver a repetir la prueba frente a la persona a la que le estas pidiendo ayuda.

Dar por entendido un informe.

Al realizar el informe de defectos, se da por entendido que el mismo es claro para todo el mundo. Y tengo la suerte que siempre alguien de alto rango esta observando mis informes. Entonces de ahora en más reviso 3 veces el informe para darle un formato claro, para usar frases comunes a todos los niveles de la jerarquía y detallar, cuando es debido, cierta información.

Nunca está de más, pedir una lectura a otro compañero (control cruzado). O dejar un rato lo que se está haciendo para retomarlo más tarde y recomenzar la idea central con otra perspectiva.
Por el momento, estos son mis errores más comunes. Y los tuyos cuáles son?

Podes usar el campo de abajo para dejarme tus comentarios al respecto y NO hace falta que te desempeñes en el mismo rubro que yo. Te leemos!

Berón Gómez Fabricio Nahuel

Argentino de treinta y tantos años. Dos hijos y escorpiano. Geek, un poco otaku, Barmanager y Testmanager. Intenté hacer música durante algún tiempo. Solo tu mente puede desatar tus manos [Mustafa Yoda] Me podes contactar para asesoría en referencia a bartending por: https://calendly.com/nhettogomez/entrevista-inicial

You may also like...

Deja una respuesta

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