Fondo
Trabajo en una empresa de consultoría informática de unas 200 personas. Como en muchas otras empresas, trabajamos en múltiples proyectos, con plazos cortos, con mucha presión, tanto de los responsables internos como de los clientes, etc.
La semana pasada un compañero de trabajo (B) de otro equipo se enojó durante una llamada a una persona del departamento de pruebas/QA y dijo en tono enojado “No te pagan para pensar, sino para hacer pruebas”. El meollo del asunto era que el evaluador principal del proyecto inundaba las tareas de Jira con cientos de comentarios con sugerencias, "Creo que", "Estaba pensando en", "Sugiero este desarrollo", etc. Estos comentarios no solicitados son muchas veces solo vagamente relacionado con el error. Debido a la política interna, solo cuando se abordan todos los comentarios, los errores se pueden cerrar, por lo que este probador estaba tomando como rehén y retrasando un proyecto ya retrasado.
En la llamada estaban: B, otros miembros del equipo de desarrollo, el jefe de proyecto (y B jefe directo), un jefe superior, el tester y parte de su equipo y el jefe directo de tester: nadie dijo nada sobre esa frase.
Preguntas
Discutimos sobre la oración entre nosotros y el pensamiento ampliamente aceptado es que es una oración pasable bajo estas o similares circunstancias, pero es preferible limitar su uso. También hablé con algunos amigos de diferentes industrias/campos que, en cambio, dijeron que todos están convencidos de que la sentencia no es aceptable en el lugar de trabajo. Mientras que los amigos de TI generalmente están de acuerdo con nuestra conclusión.
¿Es esta una sentencia aceptable bajo algunas circunstancias? Siempre está mal en el lugar de trabajo? ¿Podría exponer a quien lo dice a alguna consecuencia?
PD: no hay consecuencias para B por esta oración y también los comentarios no solicitados por parte del probador se detuvieron y todos los errores se cerraron (generalmente directamente por el administrador del probador)
actualización - 05/12
Muchas gracias a todos los que respondieron mi pregunta, tuve la oportunidad de leer muchas sugerencias y puntos de vista interesantes.
También tuve una charla rápida con B ayer y me explicó que el gerente directo del probador envió un correo electrónico disculpándose por el comportamiento del probador. Este administrador también ocupó el lugar del probador en el proyecto y todos los errores ahora están cerrados y el producto lanzado. Finalmente, este gerente movió (¿degradó?) al probador de una posición de líder del equipo de prueba/QA a una posición de simple probador de integración en otro proyecto.
Según usted y su experiencia, ¿es esta una sentencia aceptable en algunas circunstancias? Siempre está mal en el lugar de trabajo?
Cuando alguien dice "No te pagan por pensar, sino por hacer X", no debes tomarlo literalmente. En todos los casos, se le paga para que piense al menos un poco, de lo contrario, un robot estaría haciendo su trabajo.
Normalmente, esa frase se usa para cortar argumentos repetidos e improductivos y como una directiva para comenzar a trabajar.
En mi experiencia, es una declaración tonta para que alguien la use. Eso no significa que la razón implícita ("demasiada discusión, poco trabajo") sea incorrecta, solo que generalmente hay mejores formas de decirlo.
En este caso específico, el probador claramente inyectó opiniones de manera inapropiada en las tareas de Jira, en lugar de probar e informar errores como se esperaba. El compañero de trabajo del otro equipo que hizo la declaración también fue inapropiado.
La gerencia debe ayudar a todos a comprender sus roles y la cantidad de opinión personal que debe involucrarse. Si yo fuera el director de control de calidad, tendría una larga conversación tanto con el evaluador como con el compañero de trabajo. Deberían estar trabajando hacia el mismo objetivo, no disparándose pasivamente-agresivamente el uno al otro.
Si estás en TI, te pagan por pensar.
La oración que describe podría ser la cosa más incorrecta que he escuchado en mi carrera de TI. Al personal de TI nunca se le paga por pensar, de lo contrario, su trabajo estaría automatizado.
Parece que el problema real es que su compañero de trabajo simplemente no está utilizando los canales correctos para comunicar posibles mejoras, optando por incluirlos en temas relacionados con el seguimiento de errores en lugar de temas de sugerencias/mejoras.
Algunas posibles oraciones alternativas que podrías usar.
Hay muchas más oraciones que uno puede usar para transmitir su punto de vista sin hacer que su colega se sienta despreciado.
Esta no es una respuesta productiva por varias razones:
Debido a este arrebato, es posible que la persona de control de calidad note algo gravemente incorrecto que está fuera del alcance de sus deberes laborales, y no lo informe, y toda la empresa podría sufrir.
El compañero de trabajo B tiene razón en que la persona de control de calidad no está realizando correctamente sus funciones laborales y está afectando a otros trabajadores y a la propia empresa. El compañero de trabajo B no tenía razón al decir esta frase. Deben pedir disculpas y luego debe haber algún tipo de reunión para aclarar cómo se deben hacer las sugerencias y los comentarios, para asegurarse de que el proyecto siga adelante.
¿“No te pagan por pensar, sino por hacer X” siempre está mal en el ámbito laboral?
Tal vez no, pero siempre es una bandera roja. Algo podría estar mal en alguna parte, y ese mal debe abordarse.
Si esta frase "se escapa" de vez en cuando, puede que no sea el fin del mundo, pero si se convierte en un mantra, es probable que el "barco" se esté hundiendo. Encuentra un barco más saludable y más fuerte.
Por supuesto, hay otro lado del problema: la abundancia de comentarios, su calidad y qué hacer con ellos profesionalmente.
Lo primero que hay que hacer es analizar objetivamente los comentarios : ¿son realmente útiles para mejorar el proceso/prueba/producto?
Lo siguiente, es analizar el impacto y la urgencia de los comentarios. En base a esto, se hará una priorización. Después de eso, la acción derivada de los comentarios debe planificarse para implementarse en el proyecto.
En pocas palabras: TI sin pensar es una receta para el desastre . Tarde o temprano. De una manera u otra. Los ejemplos abundan en innumerables libros impresos y en Internet.
“No te pagan por pensar, sino por hacer pruebas”
Hacer un comentario como este siempre es inaceptable. La resolución de problemas, el pensamiento crítico y la síntesis son las razones por las que las organizaciones contratan personas; sugerir que estas no son contribuciones importantes de un colega es privarlo de sus derechos e irrespetuoso.
Es posible que su colega haya intentado expresar su frustración o brindar asesoramiento, pero este comentario en particular tampoco fue una forma productiva de hacerlo. Lamento que hayas experimentado esto.
Ponerlo de esta manera es de mala educación, obviamente. Una mejor manera hubiera sido "No estás haciendo tu trabajo. Lo que estás haciendo es perder el tiempo de todos y le cuesta dinero a la empresa". (También fue erróneo en cuanto a los hechos. A QA se le paga por pensar. El pensamiento adecuado habría evitado estos JIRA que desperdiciaron tiempo y dinero).
Pero el trabajo de control de calidad es garantizar que el producto tenga la calidad suficiente para la venta/envío. Producirán JIRA si hay problemas que un desarrollador necesita solucionar.
Si este empleado de control de calidad inunda a los desarrolladores con sugerencias puramente basadas en opiniones, eso es contraproducente. El desarrollador no hará y no debería hacer ningún cambio debido a tal sugerencia. Eso debería ir a un gerente de producto que debería decidir qué se debe hacer y crear tareas para realizar dicho cambio o no crear tales tareas.
Parece que este empleado de control de calidad estaba perdiendo el tiempo del desarrollador. Espero que QA obtenga un JIRA si algo no funciona como se supone que debe funcionar. Y a veces obtener un JIRA cuando algo funciona según lo diseñado, pero la forma en que está diseñado no es buena. No espero verme inundado con cientos de JIRA que todos rechazaré.
Entonces, puede haber un punto en el que perder el tiempo de alguien resulte en mala educación. Como dijiste además, parece haber funcionado. El empleado de control de calidad no entendió su trabajo, no hizo su trabajo, con malas consecuencias (retrasos) para la empresa, y la mala educación provocó un resultado: se solucionó el motivo de la mala educación. Supongo que alguien le explicó su trabajo.
PD. Si la persona de control de calidad no solo perdió el tiempo, sino que retrasó todo el proyecto al agregar un comentario "Creo que este botón debería ser verde en lugar de azul" después de que se le dijo repetidamente que no hiciera ese tipo de tonterías y luego se le dijo "No te pagan para pensar " es entendible.
El meollo del asunto era que el probador principal del proyecto estaba inundando las tareas de Jira con cientos de comentarios con sugerencias.
Personalmente, puedo ver cómo esto sería molesto si tiene que leer cada línea para averiguar si hay un error. Además, estos serían comentarios extremadamente improductivos si la idea ya se vendió al negocio y los comentarios tendrían que ser evaluados nuevamente por el negocio.
Simplemente quisiera señalar que los comentarios no son productivos ya que la idea ya está vendida y así es como la empresa quiere que se haga. También quisiera señalar que escribir cientos de comentarios sería contraproducente porque es difícil descifrar entre errores reales y si son simplemente comentarios.
Creo que gritar que no le pagan para pensar sería improductivo pero un arrebato comprensible. Aprovecharía esta oportunidad para sacar el meollo del asunto.
Mantén abiertos los canales de comunicación.
Un buen evaluador de control de calidad profundizará en el sistema que está desarrollando y detectará cosas que no se les dijo específicamente que buscaran. Tienen experiencia en el escrutinio de software y pueden tener aportes valiosos. Realmente no quieres cerrar este canal de información.
... Pero manténgalos organizados
Sin embargo, su empresa tiene un proceso para realizar un seguimiento de los errores (bien), con reglas que indican que un error no puede cerrarse hasta que se hayan abordado todos los comentarios (bien), y el probador está poniendo comentarios fuera del tema (malo). Debe guiar al probador para que coloque su entrada en el lugar correcto y no en el lugar equivocado. Como abreviatura, puedes empezar usando un texto como:
"Comentario cerrado, fuera de tema. Plantee un problema separado en (lugar apropiado) para esto".
Tienes que asegurarte de que el lugar apropiado realmente exista y funcione. Si su evaluador no tiene un lugar apropiado para informar "También noté eso", cosas a las que la gente responde, entonces usted mismo se trajo este problema.
Me pregunto si su proceso de comunicación actual solo consiste en hacer preguntas específicas (casos de prueba). ¿A dónde se supone que debe ir el evaluador si tiene algo que informar que no se le preguntó? ¿Ese canal está siendo tomado en serio? Poner comentarios en los informes de errores "debe abordar todos los comentarios antes de cerrar" puede ser un grito de ayuda.
Explique "no lo haré"
El papel del control de calidad no es decidir qué funciones se incluirán en el producto. Para hacer un producto exitoso, también debe decidir qué funciones no utilizará. Porque no son necesarios, o no son lo suficientemente valiosos como para agregarlos en el último momento y arriesgarse a que se venza el plazo. Debe explicarle a su evaluador que si bien valora las sugerencias, eso no significa que realmente las adoptará todas.
Marque la diferencia entre prestar atención a las sugerencias y adoptarlas. Si el probador propone una característica o mejora y usted decide no hacerlo, reconózcalo en lugar de hacer que parezca que ni siquiera vio la sugerencia.
Esta frase es aceptable solo si está tratando de desempeñar un papel de tirano y generalmente la usa un mal gerente. Por lo general, solo indica que la persona que lo usa no puede manejar el argumento o no puede escuchar a otras personas. La otra forma de esta frase es "porque yo lo digo". En su caso, suena como una forma simple de aislar a otra persona. No elijo ningún bando en la lucha, pero puedo verlo desde ambos ángulos (como control de calidad o como desarrollador, ya que tengo experiencia en ambos). Personalmente, en la situación que describió, descubrí que es mucho más productivo abrir un ticket separado para cada elemento diferente: para un control de calidad, abrir un ticket separado permite asegurarse de que se analizará el problema que se planteó. Como desarrollador, prefiero que el ticket en el que trabajo actualmente no se convierta en un área de alcance lento.
Sin embargo, hay algunos casos raros en los que se ha implementado la función, que funciona como se esperaba y en el papel se ve fantástico en la vida real, no tiene ningún sentido. La mayoría de los que suelen ser detectados por un buen control de calidad y los más difíciles, ya que todos hicieron lo mejor que pudieron, pero el resultado es cero o negativo. Siempre estoy atenta a cualquier pista sobre tales comentarios del control de calidad y trato de llevarla de vuelta a la mesa de dibujo. Por lo general, estos comentarios aparecen como comentarios no relacionados en el ticket. En tal caso, preferiría tener una discusión con la persona que proporciona dicha información para averiguar si este es el caso o no. Si las conversaciones con la persona que hace ese comentario realmente terminan en ese caso, entonces debe reaccionar de esa manera; de lo contrario, pídale a la persona que cree un boleto o créelo para ellos.
Básicamente, cuando estás llegando a un punto en el que una conversación puede ponerse un poco acalorada, es más productivo inhalar y exhalar, decir algo como "Necesito pensarlo y voy a responder en el ticket", recuperar la calma, escriba y, si está seguro de que tiene razón, escriba sus argumentos en el ticket sobre por qué es irrelevante/inválido/no importa ahora. Sin embargo, esta es una espada de dos filos, ya que si la otra persona tenía razón y usted no, lo ha documentado ahora.
Y tenga en cuenta que todas esas cosas no deben verse como desarrolladores (dba vs backend vs ui) vs QA vs cliente vs quien sea. La relación debe ser como devs + QA + client + whoever = great product. He estado en entornos con un fuerte entorno de "libre para todos" en los que actuaba de manera colaborativa y me trataban así a cambio.
Las pruebas son un caso algo especial cuando se trata de trabajo de TI. Especialmente pruebas formales, especialmente de regresión.
Si una prueba está predocumentada (lo que se hace para probar), y los resultados al final se reducen a PASA o FALLA, el resultado final aún dice "X, Y, Z... se hizo, al resultado de... .".
X, Y, Z que se están probando pueden definirse mediante una especificación de contrato con un cliente, la modificación de las pruebas puede redistribuir la responsabilidad de una manera muy desafortunada si surge un defecto (o en el peor de los casos, causa un daño real) que se habría detectado si el procedimiento de prueba se siguió exactamente. La otra cara de esta moneda es que si un defecto no se detecta mediante pruebas prescritas y acordadas, según el contrato, el producto aún puede venderse y facturarse como que cumple con las especificaciones, incluido el dedo medio como bonificación.
Desde una perspectiva más amplia, es posible que el trabajo (según las especificaciones) ya se haya descrito, ofrecido, calculado y VENDIDO. Si bien una modificación post-facto podría aumentar la eficiencia (¡ya calculada!), también aumenta el riesgo (¡ya calculado!).
Nyos