¿Cómo debo decirle al front-end que deje de pasar errores al back-end de forma predeterminada?

Hay varias cosas que arreglar aquí:

• Desde una perspectiva técnica, si su interfaz recibe una respuesta de error y no pueden decir que es su culpa , entonces la respuesta de error de backend es defectuosa . Arregla tu backend para responder con mensajes que se puedan entender y no necesitarás explicarlo una y otra vez.

• Desde la perspectiva de una organización, un error que usted inspecciona, prueba que no es su parte y reasigna debe ser un error que cuenta para el conteo de errores. Trabajaste con éxito en ello.

Pero lo mas importante:

• Desde la perspectiva del producto, ¿qué diablos estás haciendo? ¿Por qué ustedes dos equipos trabajan uno contra el otro? ¿Por qué está asignando boletos en lugar de hablar con sus colegas? que deberiaLo que sucede es que el desarrollador de frontend te llama y dice "oye, tengo este error desagradable aquí, lo intenté pero no puedo entender por qué el backend se comporta de esta manera, ¿tienes tiempo para resolver esto conmigo? Lo he configurado todo arriba, puedes venir o podemos compartir pantallas". Y luego trabajan juntos en esto hasta que se corrige el error y el producto funciona. El producto no mejora ni un poco con el recuento de errores, la reasignación de boletos o culpar a un equipo sobre otro. No tiene sentido tener dos equipos. Es un producto. No hay producto sin frontend y no hay producto sin backend. Su estructura organizativa está configurada por las necesidades corporativas, no por las necesidades del producto. Y eso nos muestra.

¿Qué puedes arreglar? No sé. Podría agacharse, mantener el fuerte, asegurarse de que los boletos se reasignen correctamente, otros asuman la culpa y su recuento de errores aumente. Así es como funciona la empresa, tú ganas dinero mientras que los estúpidos de arriba se preguntan por qué su producto es tan malo en comparación con la enorme cantidad de dinero que invierten en él. O podría intentar tomar el camino correcto. La próxima vez, investigue el error, si parece estar en el Frontend, no devuelva el boleto, hable con alguien, forme un equipo con ellos y arreglen el error juntos .. Concéntrese en hacer el trabajo, no en las métricas corporativas. Es posible que se sorprenda de cuánto más gratificante es el trabajo cuando se trata de hacer las cosas, en lugar de desviar las multas y culpar a los demás. Tal vez no. Tal vez tu corporación esté demasiado avanzada para que marques la diferencia. Luego tienes que decidir si te pagan lo suficiente para soportarlo.

Estoy frustrado porque estoy haciendo RCA en cosas por las que no obtengo crédito, o en otras palabras, estoy perdiendo el tiempo haciendo cosas que no deberían ser mi trabajo.

Tu estructura de incentivos está jodida.

Lo más probable es que el equipo de front-end también esté haciendo esto para obtener crédito por el trabajo de inspección que no ha realizado.

Si desea que cambie el comportamiento del equipo front-end, los gerentes deben cambiar la estructura de incentivos y la forma en que se juzga a los desarrolladores.

Estuve en una situación similar en un punto, con el giro adicional de que el frontend era un software y el backend era un hardware (sin acceso a las bases de código de los demás). Mencionaste:

el equipo de QE presentará un error que indica que "hacer X, luego Y, luego Z en la interfaz de usuario arrojará un error cuando no debería".

y luego estos boletos serían enviados a usted. Cuando obtenía boletos como esos, los devolvía diciendo que "necesita más información". No tengo nada relacionado con la interfaz de usuario en mi backend, por lo que el ticket del equipo de QE no me dice mucho que sea significativo para mí. En su lugar, básicamente requeriríamos que el equipo de frontend escribiera un ticket secundario separado, no que reasignara el ticket original, que diga "cuando envío tal y tal solicitud al backend que tiene este formato , el resultado se trunca". .

Esto evita que el equipo de front-end arroje problemas perezosamente por encima de la pared y haga que usted haga el trabajo. Tienen que depurar el problema hasta la interfaz entre nosotros. El resultado final fue que el 95% de los errores que nos enviaron eran en realidad problemas de back-end. El proceso de depuración de la interfaz dejaría bastante claro de qué lado estaba el problema. Es difícil escribir una descripción de lo que está haciendo mal el backend cuando el problema está en el frontend. Si lo intentan de todos modos, dichos tickets suelen ser triviales de identificar (por ejemplo) mostrando que el mismo proceso funciona como se esperaba cuando se usa una interfaz diferente.

El uso de un segundo ticket entre los equipos frontend y backend también significa que puede cerrar los tickets no válidos con un perjuicio extremo y no afecta en absoluto al ticket original del equipo QE. Durante una retrospectiva, puede mostrar la cantidad de tickets presentados por el equipo de front-end que no eran válidos o no tenían suficiente información para poder actuar, lo que debería hacer que el problema sea mucho más visible y obvio para la gerencia.

Esencialmente, deja de cruzar la interfaz entre el frontend y el backend. De hecho, tiene el acceso y el conjunto de habilidades para echar un vistazo a las bases de código de los demás (a diferencia de mi caso), pero el hecho de que pueda no significa que deba hacerlo . Una gran parte de la razón para separar el software en partes como esa es para que puedan tratarse entre sí como cajas negras con interfaces claramente definidas. Un error de backend debe ser objeto de notificación sin ninguna referencia a un frontend en particular, solo a la interfaz del backend. Si tiene que cruzar ese límite en el código de otro equipo para investigar su multa, entonces quien presentó esa multa aún no ha terminado con su parte.

Encontré particularmente útil tener una interfaz alternativa y simplificada para usar en las pruebas. Mi equipo rara vez hizo pruebas usando la interfaz oficial (GUI). Creamos una utilidad de línea de comandos desde cero que podía ejecutar todas las funciones de backend individualmente y que no contenía ninguna de las lógicas comerciales que había en el frontend. Eso nos permite probar fácilmente nuestro backend de forma aislada y verificar su comportamiento con respecto a la especificación. Cuando llegaba un error del equipo frontend, probábamos la misma secuencia de funciones manualmente usando nuestra utilidad. Si vimos el mismo problema, lo más probable es que el error estuviera en el backend. Cuando funcionó bien para nosotros, el problema casi siempre estaba en la interfaz. Podríamos identificar fácilmente los tickets que en realidad no eran problemas de back-end con una prueba de 5 minutos en lugar de pasar 2 horas investigando.

Nuestros gerentes le han comunicado al equipo que no deberíamos reasignar errores como he descrito, pero el problema persiste.

¿Por qué no hablas de esto con tu jefe? Parece que ese sería el canal correcto.

Al final de nuestros sprints, estoy atrasado en el conteo de errores y parece que mi desempeño es muy bajo.

¿Por qué no documentas esto y lo presentas en tus sprints? "Por eso estoy atrasado..."

Al final de nuestros sprints, estoy atrasado en el conteo de errores y parece que mi desempeño es muy bajo.

Parece que estás resolviendo el problema equivocado. Pero primero...

Creo que muchas de las otras respuestas suponen que hay malicia detrás de lo que está haciendo el otro equipo, pero puede haber una serie de factores por los que los errores pueden reasignarse erróneamente. No todas son buenas razones, pero son razones:

• Piensan que es más probable que el ticket sea un problema en su equipo y están evaluando
• Se parece a otras entradas que han visto que han sido causadas por su equipo.
• Están abrumados con boletos y buscan descargar
• Carecen de la capacidad de investigar.
• No quieren corregir errores.

En última instancia, si hay algún tipo de problema sistemático que ya le planteó a su jefe, debe preguntarle qué le gustaría que hiciera cuando recibe un boleto que no parece haber sido investigado antes de ser reasignado.

Posibles cosas que su jefe puede pedirle que haga:

• Asignar el ticket de vuelta sin tocar nada
• Asigne el ticket de vuelta con un comentario que explique por qué debe volver a examinarse
• Trabaja en el boleto de todos modos
• Trabaje en el ticket, pero mantenga un registro del tiempo "desperdiciado"
• Plantéalo de inmediato con tu jefe
• Plantéalo inmediatamente con el jefe del otro equipo.
• Plantéelo de inmediato con alguien que esté supervisando el flujo de soporte.
• ignorar el billete
• Cierra el ticket como si no fuera un error
• Cierre el ticket como si no fuera un error y cree un nuevo ticket para rastrear el problema
• Levanta el teléfono y habla con la persona que te lo asignó
• Busque la segunda opinión de un colega y haga una de las anteriores si ambos están de acuerdo.
• Algo completamente diferente

Cualquier respuesta aquí que prescriba lo que debe hacer en esta circunstancia es ADIVINAR lo que su jefe le gustaría que hiciera. Por suerte, no es necesario que adivines, solo puedes preguntarle a tu jefe.

Si bien su jefe ha dicho que los boletos no deben asignarse de un lado a otro sin una investigación adecuada, eso no le da licencia para elegir arbitrariamente uno de los anteriores y hacerlo. Si alguien no sigue la política, tampoco significa que usted no deba seguir la política (como sugieren otras respuestas).

Ahora, en términos de cubrir su trasero, también desea documentar personalmente los casos en los que su propia capacidad para trabajar de manera efectiva se ha visto comprometida. Y cuando discuta el desempeño con su jefe, esto es a lo que debe referirse. Si tu jefe está contento con esta pérdida de tiempo, entonces no hay problema. Por supuesto, si tu jefe no está contento con el tiempo perdido, al menos habrás actuado de acuerdo con sus instrucciones.

No estoy de acuerdo con las otras respuestas. He estado en esta situación y esto es lo que hice para solucionarlo.

En lo que a mí respecta, como desarrollador, cuando se me asigna un error, mi trabajo es investigarlo. Solo si verifico que no es mi responsabilidad arreglarlo o por alguna razón no puedo arreglarlo, lo reasigno a otro desarrollador/equipo. Si no puedo reproducirlo o no puedo entender por qué es un problema, lo asignaré de nuevo a quien lo planteó.

Debe preguntarle a su gerente si está de acuerdo en que los desarrolladores deben investigar antes de reasignar. Si no lo hacen, está satisfecho, pero suponiendo que les pidan que hagan un anuncio para que esto quede claro para todos. Si esto sigue ocurriendo, menciónelo públicamente en cualquier lugar que sea mejor en su lugar de trabajo. Una reunión retrospectiva o de estado, por ejemplo. Por ejemplo: "Pasé mucho tiempo esta semana investigando errores que FE me había reasignado y que resultaron ser problemas de FE. ¿Cómo está sucediendo esto? ¿Por qué FE no puede resolver esto antes de reasignarme? ¿Están ¿No están investigando adecuadamente?".

Esto puede parecer insignificante o culpabilizador para algunas personas, pero en una situación en la que las personas te arrojan su trabajo con la esperanza de que algo se mantenga, o al menos les dará algo de tiempo y el gasto tuyo, creo que es justificado.

Cambiar las reglas del sistema de seguimiento de errores

Si los usuarios de un sistema de seguimiento de errores lo están haciendo mal, entonces los privilegios que están usando y que están dando como resultado el mal uso deben ser revocados. En este caso la posibilidad de cambiar la asignación de entradas a otros equipos.

Tableros de revisión

He trabajado en programas bastante grandes que tenían muchos equipos responsables de muchas partes. Como tal, a ningún desarrollador se le permitió reasignar unilateralmente un boleto a otro equipo. No había un sistema estricto para evitar que te reasignaras a otro equipo, pero si lo hicieras, alguien estaría en tu escritorio preguntándote qué diablos estás haciendo. Si alguien quería asignar una entrada a un equipo diferente, tenía dos opciones:

• Encuentra y convence a alguien del otro equipo para que lo tome.
• Envíe el boleto a una junta de revisión que tenía un representante de cada equipo presente. Allí lo mirarían y discutirían qué equipo era el responsable de arreglarlo.

Su gerente ya le ha dicho la respuesta.

Todos ustedes no deben reasignar errores a los otros equipos.

Cuando le asignen un error, responda que se le ha indicado que no interfiera con su trabajo y continúe con su día. Usted está creando el problema al cooperar con ellos en lugar de con su gerente.

Puede dejar que sus mensajes queden sin respuesta hasta que sea un "montón" lo suficientemente grande como para que su gerente pueda microgestionarlos y tratar con todos ellos a la vez.

Para aclarar con un ejemplo, "QA ha juzgado que el error es probable en el trabajo de sus equipos y ManagerX nos ha dicho que no debe reasignarnos errores y, por lo tanto, estamos priorizando la carga de trabajo que se nos asignó originalmente. Si usted es capaz de localizar el error y encontrar que es un error en una salida específica del back-end, lo tomaremos como prioridad para no retrasar a su equipo".

Esta podría ser una gran oportunidad para que usted sea proactivo: programe un tiempo todos los días con el líder (o algún representante adecuado) del otro equipo para evaluar los boletos juntos .

Obtendrá una mejor idea de los procesos de los demás, probablemente llegará a conclusiones más rápido y, lo que es más importante, reducirá el aislamiento. Ahora tendrá tiempo dedicado cada día para concentrarse en esta tarea y sus esfuerzos ahora son medibles.

Un mal gerente te dirá que has perdido el tiempo, te dirá que te detengas y yo tomaría esto como una señal de que las cosas en esta empresa no cambiarán.
Un buen gerente identificará que has hecho algo que vale la pena.
Un gran gerente lo ayudará a desarrollar la idea y resolver el proceso (¡y recuerde darle crédito!)

Me cuesta ver cómo se puede dedicar tanto tiempo de su jornada laboral a la corrección de errores. Usted habla de front-end y back-end, lo que me parece indicar una pila web de algún tipo, pero ¿cómo puede ser que la corrección de errores sea un problema tan grande que equipos enteros estén eludiendo el problema y tratando de evitar asumir la responsabilidad?

Si está desarrollando aplicaciones web, la parte de investigación del proceso de diseño debe aclarar los requisitos de la aplicación. Cada desarrollador debe tener claridad sobre lo que se espera del producto.

Lo que sospecho que está sucediendo es que se espera que muchos desarrolladores junior trabajen en tecnologías a un nivel más avanzado de lo que son capaces. ¿Quién quiere contratar a un desarrollador sénior cuando puede obligar a un montón de novatos a trabajar por una fracción del precio?

Estas personas, en lugar de tomar posesión de su trabajo, están pasando la pelota simplemente porque no saben cómo solucionar el problema. A menudo es difícil admitir que no puedes resolver un problema. Especialmente si le tienes cariño a tu empleador y crees que no poder hacer algo por él es decepcionarlo.

Realmente no veo cómo si un problema es front-end o back-end debería impedir que alguien solucione un problema. Sí, tengo la intención de trabajar como desarrollador front-end, pero si la aplicación Angular necesita interactuar con una base de datos MySQL, mi trabajo es hacerlo.

No puedo tirar las manos al cansancio y dejar de trabajar simplemente porque de repente trabajo con algo que técnicamente no está orientado hacia adelante. Parece haber una desconexión en la forma en que operan estos equipos, deberían ser dos partes de una unidad cohesiva. Esta mentalidad de nosotros y ellos no conduce a un buen desarrollo de software.

Como se sugiere en un comentario, realice la debida diligencia, realice sus pruebas y, si no encuentra ningún error en el backend, simplemente cierre el ticket como "no es un error".

Frontend le envió el ticket y, como colega, debe esperar que lo hayan hecho de manera profesional y por una razón: después de un tiempo, tal vez alguien notará una tendencia y decidirá investigar.

¿Suena mezquino? Porque es...

¿Arriesgado? Tal vez; solo tu puedes decir cuanto...

Si la métrica es "número de tickets cerrados", creo que el frontend notará rápidamente el nuevo enfoque en la gestión de tickets del backend.

¿Cómo decirle al front-end que deje de pasar errores de forma predeterminada?

Reúna a todas las personas relevantes para una reunión rápida y dígales:

Estoy frustrado porque estoy haciendo RCA en cosas por las que no obtengo crédito o, en otras palabras, estoy perdiendo el tiempo haciendo cosas que no deberían ser mi trabajo. Al final de nuestros sprints, estoy atrasado en el conteo de errores y parece que mi desempeño es muy bajo.

Pregúnteles cómo creen que debería abordarse esto. Haga que su gerente esté presente. Escucha primero.

En primer lugar, cuando tiene un equipo trabajando en el front-end y otro equipo trabajando en el back-end, es una buena idea diseñar los sistemas de manera que los errores del front-end generen mensajes de error y otros mensajes que claramente implican al front-end. y lo mismo para el back-end. Los problemas en el front-end no deberían resultar en errores de back-end que hagan parecer que el back-end es el problema, y ​​luego requiere mucho RCA para determinar que no lo es. Si hubieran estado todos en un equipo, podrían salirse con la suya con este tipo de ida y vuelta. Pero dado que son equipos separados con sprints separados, el pasar la pelota hará que las cosas sean muy ineficientes, como ha descubierto. Así que claramente tienes un problema de sistemas aquí.

Por supuesto, el problema es probablemente algo que tomaría mucho tiempo y esfuerzo para resolver (por ejemplo, ¿cuántos errores tendrían que ser refactorizados?) y está buscando un encantamiento mágico rápido que pueda decirles que resolverá el problema. irse. Ese conjuro es:

Hola, chicos de front-end: me he dado cuenta de que tenemos muchos errores que al principio parecen ser errores de front-end, pero luego resultan ser errores de back-end, o viceversa. Por ejemplo, el mes pasado el equipo de back-end recibió X errores de los cuales Y resultaron ser errores de front-end. Siento que podría hacer nuestras vidas mucho más fáciles y ahorrarnos mucho tiempo si redujéramos esto de un lado a otro. ¿Podemos tener una reunión para acordar mejores criterios para clasificar los errores y archivarlos como front-end o back-end? Tengo algunas ideas que puedo compartir si quieres.

Lo que me extraña es que indiques que tu motivación es no querer trabajar en tantos errores. ¿No es arreglar errores tu trabajo? Si es así, ¿por qué te quejas? Simplemente siga arreglando los errores, marque los boletos como hechos y, al final del trimestre, dígale a su jefe cómo arregló tantos errores y debería obtener un aumento. O si no es tu trabajo, bueno, ¿no lo hagas? ¿No debería tener un gerente que le diga en qué tickets debe trabajar, en lugar de que otro equipo le descargue los tickets? Normalmente, se supone que los tickets van primero a su scrum master, para que pueda asignarlos a las personas en la próxima reunión de sprint .

Comience a asignar cada error al front-end sin mirarlo. El problema con el equipo de front-end (y su gerente) se resolverá naturalmente en unos pocos días.

Mientras sean recompensados ​​por sus acciones luciendo bien frente a los gerentes, y usted sea el que tenga que presentar informes sobre el desempeño deficiente, el equipo de front-end no tiene motivos para detener su comportamiento; y no lo harán. Tampoco a los gerentes parece importarles lo suficiente como para hacer algo al respecto, si las cosas continúan como están, te llevarás la culpa mucho antes de que el equipo de la parte delantera enfrente un retroceso.