¿Cómo puedo salir de una mala asignación de trabajo sin renunciar?

Soy un desarrollador de software. Recientemente, mi jefe me dijo que mi próxima asignación de proyecto consistirá en realizar un control de calidad manual en un sitio web que algunos colegas están construyendo.

Siento que pasar 6 meses haciendo esto en lugar de codificar es una pérdida de tiempo de desarrollador costoso y perjudicial para mi carrera. Cuando hablé con mi jefe sobre mis preocupaciones, dijo que lo sentía, pero que no tenían a nadie más para hacerlo. Originalmente, iba a escribir pruebas unitarias codificadas para el proyecto, pero ahora se ha degradado a solo pruebas manuales. Me siento tan devaluado por mi organización.

¿Cómo puedo salir de esta situación sin dejar mi trabajo? ¿Alguien tiene una solución creativa que pueda presentarle a mi jefe?

He sido desarrollador de software aproximadamente 6 años antes de recibir esta asignación, y dos años en un puesto junior en otro trabajo antes de eso. No tenemos un departamento de control de calidad, por lo general dependemos de nuestros clientes comerciales para realizar pruebas (estas son aplicaciones internas). Somos tres chicos y yo. Es un proyecto MVC, que es tecnología nueva para todos nosotros. Sin embargo, los demás estaban involucrados en la fase I del proyecto y yo no.

En este momento, estoy pensando en sugerirle a otra persona que haga la parte manual de la prueba con alguna orientación mía o, en su defecto, pedir rotar las funciones. E intenta automatizar parte de ello. También voy a actualizar mi currículum y actividades de networking, por si acaso.

Ok, aquí está mi actualización con lo que he hecho. Me tomó un poco de tiempo juntar las piezas. El equipo del proyecto ha decidido seguir adelante con las pruebas codificadas de la interfaz de usuario (usando las herramientas de Visual Studio 2012), así que al menos estaré aprendiendo algo y eliminando el dolor de la repetición. Tuvimos que convencer a mi jefe de este enfoque, pero todos los miembros de mi equipo me respaldaron. Además, algunas conversaciones recientes con gerentes sobre cómo se asigna el trabajo en el grupo me han ayudado a darme cuenta de que el problema de raíz no se puede solucionar. No hay suficiente trabajo bueno para todos y no es probable que eso cambie. Por lo tanto, también estoy buscando otros trabajos por ahí. Desearía poder marcar varias de las respuestas dadas como la respuesta porque muchos de ustedes dieron excelentes ideas y siento que incorporé varias en mi "solución". y en mi pensamiento. Gracias Comunidad de Stack Exchange.

¿Cuánto tiempo ha sido desarrollador de software antes de recibir esta asignación?
cerca de 6 años en este trabajo. Dos años en un puesto junior en otro trabajo antes de eso.
y tiene que ser prueba manual? ¿Tal vez puedas escribir algunas pruebas automatizadas?
¿Podría describir quién más está en el equipo del proyecto? Las respuestas probablemente serán diferentes si usted es la única persona en el equipo y no hay ninguna otra prueba de ningún tipo, y la gerencia decidió que iba a ser una prueba manual, en lugar de, digamos, una situación en la que tiene 5 desarrolladores, 2 QA probadores, integración continua y pruebas unitarias por todas partes, y... usted.
No tenemos un departamento de control de calidad, por lo general dependemos de nuestros clientes comerciales para realizar pruebas (estas son aplicaciones internas). Somos tres chicos y yo. Es un proyecto MVC, que es tecnología nueva para todos nosotros. Sin embargo, los demás estaban involucrados en la fase I del proyecto y yo no.
Gracias por la aclaración. Esa última parte es clave: probablemente no se trate de ti , sino de sacar la paja corta, ya que no estuviste profundamente involucrado en la primera fase. ¡Diablos, piensa en todas las cosas que puedes encontrar, mirándolas con nuevos ojos! :)
Muchas buenas sugerencias a continuación. Gracias a todos por sus aportes. Voy a probar algunas de estas ideas y les contaré cómo resulta. Sin embargo, siéntase libre de publicar más ideas. En este momento, estoy pensando en sugerirle a otra persona que haga la parte manual de la prueba con alguna orientación mía o, en su defecto, pedir rotar las funciones. E intenta automatizar parte de ello. También voy a actualizar mi currículum y actividades de networking, por si acaso.
Hacer que te despidan no es técnicamente dejar de fumar y también puede ser muy divertido.
"No tenemos control de calidad" : eso es bastante tonto de su gestión, ¿consideró convencerlos de contratar a un probador? Quiero decir, está bien, puede ser realmente difícil averiguar cuántos probadores serían mejores para el proyecto, está bien. Pero tener al menos un probador es solo una apuesta segura, realmente vale la pena intentarlo.
Bueno, odio arruinar tu desfile, pero a veces tienes que esforzarte y hacer el trabajo duro: no todo son arcoíris y unicornios. Aunque sugeriría dividir el trabajo entre los miembros del equipo para que cada uno diga 2 meses en control de calidad.
Si se nos permite escribir pruebas unitarias, ¡6 meses de pruebas manuales podrían reducirse enormemente!
Lo que he hecho en el pasado es esperar a que expire el contrato y no renovar. ...y dilo como un mes antes para que no supongan que lo harás. Además, en este estado, uno PUEDE dejar de fumar y aún así perder el disfrute SI tiene motivos suficientes.
Agradezco las actualizaciones sobre la situación. Situación difícil. La mejor de las suertes.

Respuestas (8)

Abandonar.

Vete en serio .

En una época en la que los sindicatos tienen mala fama, el único recurso que tenemos contra la mala gestión es votar con los pies.

Siento que pasar 6 meses haciendo esto en lugar de codificar es una pérdida de tiempo de desarrollador costoso y perjudicial para mi carrera.

Y cuando la gerencia no apoya el crecimiento de su carrera, es una gran señal de alerta. [En otras palabras, si su gerente le pidió que hiciera dos semanas de pruebas manuales, entonces podría valer la pena tomar una para el equipo. 6 meses de pruebas manuales equivalen a un cambio de trabajo.]

Por lo tanto, debe comenzar a distribuir su currículum de inmediato para que pueda pasar a un nuevo trabajo que respalde sus objetivos profesionales lo antes posible.

La pregunta dice específicamenteHow can I get out of this situation without leaving my job?
@enderland: Si alguien te preguntara: "¿Cómo puedo volar de Nueva York a San Francisco de forma económica sin un avión?", ¿Qué responderías? // Verás, a veces la gente no hace la pregunta correcta. Es algo que todo profesional veterano del software aprende en algún momento de su carrera. Si eres un profesional del software, espero que aprendas esto también.
@Jim G. Tal vez se podrían considerar helicópteros, cabalgar sobre pájaros u ovnis. ;)
@JB King: ¿Un helicóptero de Nueva York a San Francisco? ¿En serio?
Estoy dispuesto a considerar la posibilidad de que irme sea la única buena opción, pero primero me gustaría asegurarme de no pasar por alto otras opciones. Mi trabajo actual tiene muchas otras cosas a su favor. ¿Quizás hay un OVNI del que no estoy al tanto?
@Eden: Oye, si estás dispuesto a pasar seis meses buscando tu "OVNI", entonces tal vez no sea tan malo. Solo sé que seis meses haciendo pruebas manuales no se verán muy bien en el currículum de un desarrollador de software. Los posibles empleadores en futuras entrevistas de trabajo harán preguntas y se preguntarán por qué usted fue elegido (entre varios otros desarrolladores) para realizar seis meses de pruebas manuales.
@Jim G., la idea era tomar respuestas no convencionales. Imagino que Airwolf podría ir de Nueva York a San Francisco.
@JimG Me pregunto lo mismo acerca de por qué me eligieron, porque soy tan buen desarrollador como muchos de los demás en mi equipo y mejor que algunos.
@Eden: A los efectos de nuestra conversación, no dudo que lo seas. Desafortunadamente, por el momento, solo importa la opinión de su jefe. Y es por eso que creo que necesitas responder.
+1, no me importa si esto no es estrictamente una respuesta a la pregunta que se hizo; es la solución correcta al problema que se presentó. Seis años es mucho tiempo para pasar solo en su segundo trabajo; solo debe hacerlo si su trabajo está haciendo avanzar su carrera de manera constante. Seis meses de pruebas manuales, para un desarrollador, es una regresión profesional masiva; Estás saboteando tu futuro si haces esto.
@Eden Tomaron tu engrapadora y te trasladaron a la sala del horno. ¿Estás seguro de que todavía estás recibiendo un cheque de pago? Empieza a mirar alrededor un poco más. Es posible que se sorprenda de lo que hay por ahí. Cualquier trabajo en el que simplemente asuman que estarás bien con esto es uno en el que asumen que las personas se quedan solo por el bien de la inercia. No están poniendo el listón muy alto. Además, Blue Thunder, no Airwolf. Airwolf era ficción.
+1 Honestamente, si estuviera entrevistando al OP, NO HAY MANERA de contratarlo para un puesto de desarrollador después de 6 meses de prueba manual. ¡OP necesita ejecutarse!
@suslik: Ese es exactamente mi punto. Solo estaba diciendo la verdad. Sin embargo, esta respuesta fue fuertemente rechazada. Imagínate.
@JimG. Este sitio web está lleno de personas que publican preguntas como "He estado en una carrera sin salida durante los últimos X años, ¿cómo salgo de ella ahora?" y no puedes cuadrar ese círculo fácilmente. 6 meses en TI es mucho tiempo. No entiendo a las personas que votan negativamente esta respuesta. Si el OP preguntó "¿Cómo enciendo un tronco húmedo sin fósforos?" la respuesta correcta es "Lo siento amigo, probablemente no puedas". Esto es lo mismo, cuando la gerencia está tratando de que usted haga un control de calidad de 6 meses, no importa lo que le digan, ¡usted corre!

Mi mejor opción aquí es tratar de obtener una perspectiva lo más completa posible sobre lo que está pensando su jefe. El espectro puede incluir:

  • Estoy desesperado: esta prueba debe realizarse absolutamente y no podemos justificar el costo frente a la recompensa de las pruebas unitarias de codificación, tiene que ser manual. No hay nadie más en quien confíe, y nadie más a quien pueda prescindir, este es un momento de manos a la obra.
  • Tengo serias preocupaciones sobre esta persona: el último trabajo salió mal y me preocupa poner a este desarrollador en una posición de alta confianza, las pruebas manuales es donde pueden causar el menor daño.
  • Es probable que esto se convierta en algo peludo, gracias a Dios que tengo a alguien en quien puedo confiar para ponérmelo, sé que esta persona evitará que ocurra un desastre y estará allí en una crisis.
  • Se avecina un trabajo mucho más genial, si pongo a esta persona aquí haciendo esto ahora, tengo la opción de moverlo a lo increíble que está más adelante... No puedo y no quiero hablar de eso todavía, porque es demasiado incierto y no puedo hacer promesas.

Digo esto sin conocerte a ti, a tu jefe, ni a tu empresa. Todas estas son razones por las que he pedido a las personas que trabajen "por debajo de su nivel de pago" y solo una de ellas es una verdadera bofetada, y honestamente no haría la viñeta n. ° 2 sin tener una conversación con el empleado sobre las fallas en el desempeño en el pasado. Sin embargo, los gerentes varían, al igual que la situación.

Aquí no hay nada perfecto: sí, 6 meses de pruebas manuales para una persona de nivel medio (6 años me parecen de nivel medio) no es una compensación eficiente. Sin embargo, esperar 3 meses para contratar a un pasante barato puede retrasar un producto hasta el punto en que no cumpla con los requisitos de tiempo de comercialización en una industria competitiva, por lo que si tuviera que gastar 4 veces más dinero (suponiendo que un pasante gana un cuarto de lo que haces...), lo haría si ofreciera la esperanza de 10X la ganancia (que podría).

Pensamientos para pasos...

Si no lo ha hecho, tenga una larga conversación sincera con su jefe, sospecho que si no quiere dejar el trabajo en este momento, está dispuesto a "tomar uno para el equipo" en el entendido de que ganó. No estarás haciendo un trabajo desagradable para siempre y ocuparás un lugar destacado en la lista la próxima vez que se presenten las buenas oportunidades. Si ese no es el caso, debe averiguar por qué no valora su desempeño, incluso si tiene que apretar los dientes y preguntarle qué tiene de malo su desempeño, saber es mejor que no saber.

Cuándo/si eso no cambia nada, participe también en una discusión sobre "¿qué pasaría si lo intentamos?", si honestamente puede ver una forma en que el diseño de prueba automatizado puede hacer que el trabajo sea más eficiente y de mayor calidad con el mismo costo . a la empresa , entonces no debería tener problemas para venderlo. No conozco a ningún gerente que quiera vencer a la gente para que haga un trabajo desagradable sin costo alguno/ahorro de horario solo por el puro placer de hacerlo. Organice una oferta, intente venderlo: siempre vale la pena tomar la iniciativa para tratar de hacer el trabajo de manera más eficiente.

Cuando/si eso no cambia nada, se encuentra en una encrucijada, su gerente tiene todo el derecho de exigirle que haga este trabajo a su manera, si no lo ha convencido de que su manera ahorra dinero, y no lo ha hecho. t manejó una nueva asignación, entonces tiene la obligación de hacer lo que se le indica si desea continuar cobrando su salario. Estás en la encrucijada: ¿vale la pena el salario? ¿Conseguirías una mejor situación cambiando de empresa? Esa es una decisión que solo tú puedes tomar. Mi enfoque sería:

  • Sea lo más eficiente posible: demuestre que incluso en una tarea que odia, puede hacer un buen trabajo. De hecho, demuestre que puede hacer un trabajo tan bueno que esto es un gran desperdicio de sus profundas habilidades. Siempre que sea posible, permita que otra persona haga este trabajo fácilmente y busque cualquier forma de mejorar la eficiencia que pueda (por ejemplo, en la mayoría de los casos de prueba manual, existe la oportunidad de escribir scripts de ayuda que no son "pruebas automatizadas"). " pero son muy útiles: scripts de restablecimiento de bases de datos, scripts de configuración de cuentas de usuario, reconstrucción/reinstalación automatizada, pequeñas cosas que hacen que el mundo sea mucho mejor para todos).

  • Busque un nuevo trabajo cada vez que se sienta frustrado. No hay razón para hacer una loca búsqueda de trabajo de "Quiero renunciar ahora mismo", simplemente mantenga abiertas las opciones.

  • Red, red, red: si esta es una empresa lo suficientemente grande, alguien está haciendo algo interesante, si su jefe no puede darle un buen trabajo, tal vez otro grupo pueda hacerlo.

  • esté disponible, sea útil y positivo, pero tenga en cuenta que su trabajo se definió como una prueba, y no quiere ser tan útil que termine descuidando el trabajo que se le pidió que hiciera a la luz del trabajo que parece más interesante, a menos que usted tiene un claro visto bueno de su jefe. Es totalmente posible involucrarse en un trabajo más interesante de esta manera, pero debe asegurarse de no haber eludido por completo a las personas a cargo.

Algunos muy buenos elementos de reflexión aquí.

Ok, creo que es obvio a partir de la otra respuesta que se va una opción. Sin embargo, dado que has dicho esto

Cuando hablé con mi jefe sobre mis preocupaciones, dijo que lo sentía, pero que no tenían a nadie más para hacerlo.

Voy a suponer que no sugirió ninguna otra opción que no sea "No quiero hacer esto". Su jefe probablemente esté bastante ocupado, este puede ser un proyecto importante o crítico o simplemente no quiere microgestionarlo.

Lo que tienes que hacer es sugerir

  1. Alguien mas haga esta prueba
  2. Podrás hacerlo con pruebas automatizadas, etc.

Encuentre a alguien más para hacer la prueba

Como ingeniero de software a tiempo completo con 8 años de experiencia, su tiempo es (o debería ser...) bastante valioso desde el punto de vista financiero. Su jefe debería sentirse terriblemente mal por tener que hacer algo que casi cualquier persona podría hacer sin casi ninguna experiencia en software ni experiencia previa con el producto. Pagar a un desarrollador de software para que haga un trabajo extra es una gran pérdida de su dinero.

A su jefe probablemente no le importen sus intereses personales. Le importa mucho más terminar el proyecto y que cueste menos. Tienes que hacerle ver este problema en términos que le interesen.

Si tiene los medios, sugiérale a su jefe que haga uno de los siguientes

  1. Contratar a otra persona temporalmente
  2. Haga que otro miembro del equipo a quien se le pague menos haga el trabajo
  3. Delegado a un departamento de control de calidad

Creo que lo ideal es que sugiera el número 1: pregúntele a su jefe si sería beneficioso contratar a un empleado a tiempo parcial. Si trabajas cerca de una universidad, esto es perfecto. Encuentre a alguien que esté interesado en el desarrollo web o algo similar (o realmente, solo necesita una persona inteligente que quiera trabajar un poco) y contrátelos por un pequeño porcentaje de lo que es su costo total para la empresa por hora.

Aunque el n.° 2 y el n.° 3 no parecen factibles dada su situación específica, para otros en situaciones similares, cualquiera puede ser una posibilidad muy viable.

Haz la tarea... pero no manualmente

Es posible que no pueda sacar el trabajo de su equipo. Es posible que usted y su pequeño grupo tengan que hacer la prueba. En este caso, todavía tienes algunas opciones.

Recuerda que a tu jefe le importan las cosas diferentes a ti. Quieres poner las cosas en sus términos.

  1. Sugiera un enfoque en el que todo su equipo haga algo como 4 días de desarrollo, 1 día de prueba. De alguna manera dividir el trabajo entre todos los desarrolladores.
  2. Desarrollo de pruebas automatizadas.

La primera sugerencia permite que todo su equipo esté más comprometido y detecte más problemas rápidamente. Tiene más ojos para encontrar errores/problemas de usabilidad mucho más cerca de su creación en lugar de que una persona tenga la tarea de encontrar TODOS los problemas. Puede presentarle esto fácilmente a su jefe en este sentido (después de todo, tiene mucho más sentido si va a obligar a los desarrolladores de software a realizar pruebas en lugar de tener una persona de control de calidad o alguien dedicado a ello...) y seamos Honestamente, si todos ustedes van a tener que hacer pruebas manuales, casi garantizan que alguien comenzará a escribir pruebas automatizadas.

El segundo también se puede enmarcar fácilmente de tal manera que su jefe pueda aprobarlo. Debería ser fácil decir algo como: "Este va a ser un proyecto largo. El desarrollo de pruebas automatizadas creará un conjunto de herramientas de diferentes pruebas automatizadas que podemos usar a lo largo de este proyecto y permitirá que los cambios se prueben rápidamente hacia el etapas posteriores del proyecto".

La clave para cualquier sugerencia que haga que su jefe cambie de opinión es presentarla de tal manera que todos salgan ganando. Debe ser una sugerencia que no solo respalde su carrera/objetivos personales, sino que también promueva las metas comerciales de su jefe.

+1: no manualmente. No hay razón para hacer pruebas repetitivas manualmente. Aprenda Selenium y ayude al equipo a diseñar las páginas web para que las pruebas sean estables. Si el equipo de desarrollo no admite pruebas automatizadas, entonces es hora de irse.
@kevincline Esto honestamente debería ser una respuesta. Todo el mundo parece categorizar injustamente a QA como destructores de teclados sin sentido cuando puede ser mucho más que eso. Utilizar herramientas para pruebas automatizadas, escribir scripts de prueba complejos, determinar estrategias de prueba y administrar la creación e implementación de entornos de prueba es un trabajo altamente técnico y gratificante. No se debe descartar cómo usar esta oportunidad para aprender estas habilidades puede mejorar las habilidades de uno como desarrollador de software, pero también mejorar su carrera.
Gran parte de esta respuesta es buena, pero los insultos a los probadores de software son inapropiados, en mi opinión.

Cualquier sugerencia que haga debe enmarcarse como un ganar-ganar, lo cual es difícil de hacer en este escenario.

Un problema es que si simplemente te niegas o haces el trabajo bajo tolerancia, serás visto como alguien que antepone sus propias metas profesionales a corto plazo a las del equipo/empresa; si es solo a corto plazo (y 6 meses de una carrera de 40 años no es una cadena perpetua para las minas de sal) y tiene razones válidas para permanecer en la empresa (capacitación, inversión, perspectivas a largo plazo), entonces puede ser mejor para sobrellevarlo.

Tu jefe sabe que este no es un buen trabajo, de ahí la disculpa. Si tuvieran opciones obvias, sospecho que las habrían tomado.

Tomar la ruta del "desarrollador costoso" solo es válido si hay otro trabajo de desarrollo por hacer; si la empresa tiene problemas financieros, es posible que conceda el punto, haga que su función sea redundante y contrate a un QA / probador mucho más barato o incluso subcontrate.

Las soluciones pueden ser:

apalancamiento : su jefe está a la defensiva porque se ha disculpado; toma la iniciativa y pide algo a cambio cuando termines el proyecto. Asegúrese de que esté claramente identificado (entrenamiento, un rol particular en el próximo equipo) y póngalo por escrito.

expansión : solicite que se aumente el tamaño del puesto para incluir más áreas que ayudarán en su carrera; esto podría ser tener una temporada como Product Owner o Scrum Master en un marco ágil, o tener un rol que incluiría resolver algunos de los problemas que encuentre

Rotación : solicite que el rol rote alrededor del equipo, de modo que tal vez solo sean dos meses a la vez, y se incluirán otras funciones.

automatización : rechace la automatización frente a las pruebas manuales. Investigue el tema y presente casos de costo-beneficio sólidos y bien formados que muestren que la automatización de las pruebas será mejor a largo plazo que el trabajo de prueba manual.

Grandes soluciones, especialmente dada la descripción del entorno del OP, que parece una situación en la que hay un poco de mala gestión y mucho espacio para sugerencias y formas de convertir esto en algo positivo. Si el OP puede obtener algún movimiento en cualquiera de sus sugerencias, y mucho menos en todas ellas, es una muy buena experiencia en comunicación, argumentación constructiva, gestión de recursos, etc., y qué buen conjunto de experiencias para hablar en futuras entrevistas de trabajo. , si el OP finalmente sigue adelante, en lugar de algo como "Mis talentos se desperdiciaron" (lo que aún puede ser cierto).
Buen punto sobre tener una mejor historia de entrevista si prueba algunas opciones primero...
Desafortunadamente, tomar uno para el equipo puede dañar tu carrera. Ahora eres parte del equipo, pero en 6 meses, todos pensarán en ti como "el probador".
@thursdaysgeek: equilibrar los objetivos personales y los objetivos del equipo siempre es difícil, especialmente en un entorno ágil/scrum. Espero que mi equipo ponga el resultado del "usuario" por delante de sus objetivos personales, lo que generalmente significa el "resultado del equipo". Mi equipo lo sabe y confía en mí para asegurarme de que nadie termine con solo "brotes en su plato" (para usar la frase de nuestro equipo) y sin la promesa de un "postre". Para ser claros, nunca sugeriría simplemente "tomar uno para el equipo" a menos que haya obtenido algún tipo de influencia por escrito de su jefe en cuanto a la recompensa/beneficio que obtendría. Lo aprendí de la manera difícil yo mismo.
@thursdaysgeek: también sugeriría que ser capaz de demostrar la capacidad de negociar un caso comercial convincente en el que todos ganen, cara a cara con su gerente, es un aspecto importante para muchas carreras. Cuando recluto, aumentar la cohesión en el equipo de desarrollo es de igual importancia que la habilidad y la habilidad técnica; Las excelentes habilidades técnicas son irrelevantes para mí si se combinan con un enfoque de ganar-perder, de confrontación o pasivo-agresivo en las discusiones.
@GuyM: suenas competente y racional. Ganar-ganar es el mejor resultado, pero hay casos en los que la gerencia no está interesada en nada más que en sus propios objetivos a corto plazo. Todavía se puede encontrar una situación de ganar-ganar en algunos de esos casos, pero no en todos. Sin embargo, también tiene algunos buenos puntos, métodos para ayudar a trabajar con equipos disfuncionales.

No hay razón para hacer pruebas repetitivas manualmente. Aprenda Selenium y ayude al equipo a diseñar las páginas web para que las pruebas sean estables. Si el equipo de desarrollo no admite pruebas automatizadas, entonces es hora de buscar una mejor posición.

Sería injusto categorizar el control de calidad como un destructor de teclados sin sentido cuando puede ser mucho más que eso. Utilizar herramientas para pruebas automatizadas, escribir scripts de prueba complejos, determinar estrategias de prueba y administrar la creación e implementación de entornos de prueba es un trabajo altamente técnico y gratificante. No se debe descartar cómo usar esta oportunidad para aprender estas habilidades puede mejorar las habilidades de uno como desarrollador de software, pero también mejorar su carrera.

@gnat: bien, deberías obtener la mitad del representante para este.

Envíe a su gerente el enlace a este artículo:

Las cinco razones principales (incorrectas) por las que no tiene probadores

Este es uno de los puntos del artículo:

No importa lo difícil que sea encontrar probadores, siguen siendo más baratos que los programadores. Mucho más barato. Y si no contrata probadores, tendrá programadores haciendo pruebas. Y si crees que es malo cuando tienes probadores que salen en masa, solo espera hasta que veas lo caro que es reemplazar a ese programador estrella, a $100,000 al año, que se cansó de que le dijeran "dedica unas semanas a probar antes de lanzar " y pasó a una empresa más profesional. Podría contratar a tres evaluadores durante un año solo para cubrir la tarifa del reclutador en el programador de reemplazo.

Escatimar en los probadores es una economía falsa tan escandalosa que simplemente estoy asombrado de que más personas no lo reconozcan.

Tendría cuidado con este enfoque; si bien es muy probable que sea cierto, la empresa solo obtendría el beneficio económico despidiendo a todos los desarrolladores que están realizando pruebas y contratando probadores más baratos. Es posible que estén tratando de evitar despedir a un buen empleado para el que no hay trabajo durante los próximos seis meses, con la esperanza de que las cosas mejoren.
Además, no estoy seguro si querría insultar la inteligencia de mi jefe. Esto me parece un poco pasivo agresivo para mi gusto. No digo que sea una mala idea, pero definitivamente sugeriría un enfoque más ligero.
@GuyM: En mi humilde opinión, en este caso, obligar a los desarrolladores a trabajar como probadores parece aún peor (lo más probable es que sea una de las decisiones equivocadas tomadas por la misma gerencia que llevó a la empresa a la necesidad de despidos, y el futuro de dicha empresa rara vez es brillante; ¿sería mejor que lo despidieran después de trabajar como esclavo durante 6 meses como probador?
@ jmort253: Definitivamente sugeriría un enfoque más ligero, ¿podría proporcionar un ejemplo de tal enfoque? No quise que fuera insultante (ciertamente no tienes que frotar las narices de tus jefes en ese artículo), pero, dado que Spolsky es bien conocido y respetado, su opinión podría ser considerada.
Hola Steve. Por supuesto. El consejo es sólido y usted destacó un gran punto de un estimado profesional. Sin embargo, hablar desde la experiencia tratando de persuadir a las personas para que vean mi punto de vista, diciendo "mira, Fulano dice X, así que deberíamos hacer X" a veces puede resultar contraproducente. Dicho esto, usar los argumentos de Spolsky para formular y adaptar sus propios argumentos puede funcionar mejor que dejar un enlace en la bandeja de entrada de su jefe. ¡Espero que esto ayude! :)
Lo superó. Justo en el dinero.
@SteveV - Depende; He visto empresas que tienen problemas a corto plazo debido a problemas de flujo de efectivo que se han resuelto en ese período de tiempo, y algunas que se han hundido. Mucho depende de los pros y los contras de la empresa a largo plazo.
@GuyM: ¿Se imagina a una empresa así tratando de ahorrar en las facturas de limpieza y pidiéndole al desarrollador que trabaje como conserje durante unos meses hasta que la situación financiera mejore?
@SteveV: ese tipo de argumento de "hombre de paja" no es realmente útil en este contexto. En este momento, hay muchas empresas que se enfrentan a problemas de inversión y de flujo de efectivo, que se preocupan por sus equipos y tienen dificultades con las opciones. Si tuviera que elegir entre despedir a un empleado y encontrar un trabajo alternativo que podría no encajar completamente con su conjunto de habilidades, elegiría lo último, pero lo discutiré en detalle con ellos, en lugar de encogerme de hombros, hacer que su función sea redundante y luego contratar a personas más baratas. . No todas las empresas pueden simplemente contratar a más y más personas para cubrir roles mientras que otros están infrautilizados.
@SteveV - y para tomar en serio su discusión sobre el hombre de paja por un segundo; ¿Recortaría el contrato de limpieza para salvar los puestos de trabajo del personal y posiblemente la empresa? Sí. ¿Le pediría a un desarrollador que fuera más limpio? No. Le pediría al personal que haga todo lo posible para mantener la oficina limpia y ordenada, y probablemente me apresure a asegurarme de que esté presentable antes de que un cliente/inversor entre por la puerta, y tal vez cada noche. ¿Qué harías?
@GuyM: para mí, parece que eres tú quien se está volviendo loco;). La publicación original no sugiere nada sobre los problemas financieros de la empresa. Además, dice "no hay departamento de control de calidad, por lo general depende de nuestros clientes comerciales para realizar pruebas" . Parece que no es un contratiempo temporal, es solo la forma en que funciona la empresa; no tienen controles de calidad, por lo que siempre están buscando a algún pobre diablo que haga pruebas (y puede estar seguro de que nunca será uno de los gerentes)
@GuyM: ¿Le pediría a un desarrollador que sea más limpio? No. ---------- Aquí tienes, esa es una respuesta a la situación de "dev go to be tester". Como estaba tratando de decir, este enfoque es inaceptable. ---------- Le pediría al personal que hiciera todo lo posible para mantener la oficina limpia y ordenada, y probablemente me apresuraría a asegurarme de que estuviera presentable antes de que un cliente/inversionista entrara por la puerta, y tal vez cada noche. ¿Qué harías? ---------- Probablemente, lo mismo (pero no soy gerente, soy desarrollador)
De hecho, estoy sugiriendo algunas cosas. En primer lugar, decirle a un gerente que una solución a un problema de recursos a corto plazo es reestructurar o aumentar la plantilla puede tener consecuencias inesperadas, y vale la pena considerar cuáles podrían ser antes de hacer la sugerencia, y lo que podrían significar para usted personalmente. En segundo lugar, si no ha recibido una buena explicación de una llamada de la gerencia que cree que es incorrecta, puede valer la pena pedir una explicación antes de hacer suposiciones. Los buenos gerentes responderán y se esforzarán más la próxima vez. No trabajes para malos jefes.
@GuyM en mi experiencia personal, las tácticas "sencillas" como la sugerida en esta respuesta, funcionaron . Es probable que sea el caso cuando realmente tiene sentido señalar sin rodeos a mgmt las prácticas profesionales establecidas para hacerles entender que están orinando contra el viento.

¿Existen partes del proyecto en términos de arquitectura, usabilidad u otras funciones del proyecto, además del desarrollo y las pruebas, en las que podría verse agregando valor al proyecto?

Por supuesto, otra forma de darle la vuelta a esto sería considerar si el equipo podría dividir las pruebas para que no todo recaiga sobre sus hombros y, por lo tanto, esa carga sea manejada por varias personas.

¡Guau! Ni siquiera había considerado... ¿Crees que el jefe de @Eden ha considerado esta opción?
@JimG. Sí, si su jefe no consideró esa opción realmente obvia, entonces es un mal jefe o está tratando de hacer que Eden renuncie voluntariamente para que la empresa no tenga que pagar el desempleo. Deberías aplicar la Navaja de Hanlon y todo eso, pero decirle a un desarrollador "no, no puedes jugar con la nueva y brillante tecnología, puedes sentarte en un rincón y hacer pruebas repetitivas" es simplemente malo.
@Tacroy: 1000% de acuerdo.
Esta es quizás una de las posibles oportunidades que surge de esto. Dado que OP puede llegar a una posición en la que puede liderar el diseño de las especificaciones de requisitos. y tiene el poder de exigirle al equipo de desarrollo arquitectura y funcionalidad, un rol de QA-arquitectónico (que en este caso incluirá algunas pruebas para verificar los requisitos también) podría incluso impulsar la carrera. Esto supone que BOSS piensa que es una buena idea darle ese tipo de poder a OP. Solo borrando las especificaciones de prueba. es sólo una pérdida de tiempo.

Le sugiero que un período de prueba le dará la oportunidad de mejorar su programación porque sabrá lo que buscan los probadores y lo frustrante que es trabajar con una interfaz de usuario mal diseñada como usuario. La perspectiva de los no programadores es un conocimiento terriblemente valioso. Esto NO es tiempo perdido.

En los últimos más de 30 años, tuve que hacer muchos proyectos especiales que no me entusiasmaban tanto. Cada uno de ellos resultó ser valioso para mí de maneras que no había anticipado y varios de ellos resultaron en nuevas opciones de carrera para mí, incluida la obtención de un trabajo más rápido que mis compañeros de trabajo cuando despedimos a 700 personas. Este tipo de tareas son oportunidades para expandir su comprensión y conjunto de habilidades y no tienen precio.

Voté a favor porque hay mucho que decir para hacerte más valioso en una organización. ¡Esto no solo garantiza que será más probable que tenga un puesto que se ajuste a sus habilidades, sino que también podría agregar a su publicación que lo hace parecer más un jugador de equipo! :)
Creo que hay una mejora porque mirará el diseño de su aplicación futura con el conocimiento de lo doloroso que puede ser para el usuario. Aprender lo que piensan los probadores y los usuarios nunca ha sido parte de mi tiempo. Los programadores necesitan salir de esa mentalidad de "Estoy en la zona y no quiero que me molesten las necesidades de nadie". Es contraproducente y es parte de la razón por la cual tanto software es difícil de usar y molesta tanto a los usuarios. Tu trabajo incluye mucho más que solo tú y el código.
sabrá lo que buscan los evaluadores y lo frustrante que es trabajar con una interfaz de usuario mal diseñada como usuario -------------- 1) los evaluadores buscan errores (¡sorpresa!); la interfaz de usuario mal diseñada es el resultado de un especialista en interfaz de usuario y un gerente de producto incompetentes; todo eso no tiene nada que ver con la programación, por lo que no puedo ver cómo podría ayudar en el futuro (a menos que alguien busque un programador con ambiciones de experto en interfaz de usuario, etc.)
en la mayoría de los lugares donde he trabajado, los programadores diseñan la GUI. Los programadores buscan errores de una manera diferente a como lo hacen los programadores, solo muestra tu ignorancia de que crees que no aprenderías algo.
Seis meses de pruebas manuales es una muy mala decisión para un programador. Eso es suficiente para desaprender hábitos de programación energéticos y perder tiempo frente a la tecnología actual.
¿Cómo puedo salir de una mala asignación de trabajo sin renunciar?
RespuestasAquíPolítica de privacidad1y, 0v