¿Cómo evitar que uno mismo y el ex empleado se vean mal al informar sobre arreglar el trabajo del ex empleado?

Un ex empleado con buena reputación ha cambiado de trabajo. Desafortunadamente, mucho de su trabajo justo antes de irse no satisfizo algunos criterios de aceptación encontrados por el control de calidad y tenía otros errores. Estoy tomando el relevo en la fijación de ellos. Espero que algo de esto no sea trivial para mí para comenzar a arreglar (debido a que mi habilidad/conocimiento es menor), y tener que trabajar en esto por un tiempo, y cuál es la mejor manera en que debo hablar sobre esto durante el soporte diario. ¿UPS?

mis objetivos son

  1. para que no parezca que estoy hablando mal del código o del ex empleado que se fue, cuyo trabajo estoy arreglando.
  2. para tratar de no hacerme quedar mal, ya que estaré ocupado arreglando algo que no pasó la prueba (creo que se ve mal cuando empujas cosas que tienen problemas cuando se prueban), durante al menos un solo sprint , en el que es posible que no contribuya tanto al nuevo trabajo que hemos realizado.
    • no quiero sonar como si estuviera tratando de desviar la responsabilidad de arreglarlo, pero ciertamente no me gustaría ser confundido con la fuente de estos problemas.

Editar: para aclarar, los tickets rebotaron en nuestro proceso de control de calidad porque no cumplían con todos los criterios de aceptación dentro de ellos y se encontraron algunos otros errores, por lo que quizás decir que solo tenían errores no es preciso. (Sin embargo, el código ya se fusionó detrás de un indicador de función).

¿Tienes alguna idea de por qué gran parte de su código justo antes de irse tenía errores? Las "explicaciones razonables" pueden ayudar mucho aquí. Por ejemplo, si estuvieran apurados para tratar de terminar una gran parte del trabajo antes de partir, eso proporcionaría una buena explicación.
@BenBarden apresurarse a terminar antes de partir es una suposición justa, aunque no estuve tan atento a su progreso
¿Se le asignó corregir los errores/la calidad general, o se está encargando de eso? Si fue asignado, presumiblemente su gerente (que es realmente la única persona que importa) ya sabe de dónde provienen los errores y por qué está trabajando en ellos.
@GreySage Supuse que me ocuparía de eso, ya que tenemos equipos pequeños.

Respuestas (5)

No te preocupas por nada. El software tiene errores, eso es inevitable, y todo el mundo lo sabe. El control de calidad encuentra errores, con suerte los coloca en un sistema de seguimiento de errores, y usted toma un error del rastreador de errores, lo corrige, luego el siguiente y así sucesivamente hasta que haya terminado.

No hay necesidad de mencionar de dónde viene este error. A nadie le importa. Si alguien te pregunta por qué hay tantos errores, respondes “porque QA está haciendo un buen trabajo”. Si alguien realmente se queja, pregunte aquí nuevamente y cuéntenos sobre su queja.

¿Cómo sabes que estás "terminado"?
@Gherman, ha terminado cuando el control de calidad no encuentra ningún error (raro) o cuando los errores que encuentran no son lo suficientemente urgentes o grandes como para justificar la reparación "ahora". Listo generalmente significa que el software cumple con todos los requisitos y es lo suficientemente funcional como para pasar algún nivel de prueba de calidad (el nivel de calidad depende de la audiencia objetivo, el tipo de software, etc.).
> no es necesario mencionar de dónde viene este error. A nadie le importa. La organización con la que trabajo se preocupa por esto más que cualquier otra cosa: ¿por qué existen errores en primer lugar (falta de definición de funciones, falta de comprensión del dominio, falta de pruebas exploratorias, etc.) Simplemente sentí que valía la pena mencionar que depende de la organización: algunas organizaciones se preocupan mucho de dónde provienen los errores (a veces más de lo que era el error en sí).
@Gherman Cuando deje el trabajo o el producto llegue al final de su vida útil. Pero luego estás comenzando de nuevo con el siguiente.
@user2152081, esto camina por la delgada línea entre tratar de mejorar su proceso y simplemente buscar chivos expiatorios. Si dedica más tiempo a determinar el origen de los errores, le está quitando ese tiempo al desarrollo de nuevas funciones, lo que ayudará a su organización. más. Intentar ser perfecto causa problemas y suele ser más perjudicial que útil.
@ user2152081 ¿Se preocupan por esas cosas incluso para el desarrollo activo de nuevas funciones? Eso parece extremo, y posiblemente una cascada.
Si hay un empleado que crea muchos errores, puede estar degradando el proceso de desarrollo, y eso debe ser manejado por la gerencia. Pero si los errores son de un ex-empleado, no hay mucho que se pueda hacer al respecto aparte de tratar de solucionarlos.
Estoy algo en desacuerdo con esta respuesta. Si de vez en cuando dices "Sí, eso es difícil porque el código no es óptimo", podrían comenzar a pensar que ese es el resultado de los empleados actuales.
OP parece un poco preocupado porque no quiere que los demás piensen que es la persona que originó los errores. En ese sentido, creo que una respuesta que diga "Lo siento, ese código ya estaba presente cuando comencé a trabajar en él y todavía me estoy familiarizando con el código base" sería una respuesta razonable que puede ayudar a OP a notar que hay un subconjunto de esos errores que no fueron causados ​​​​por OP.
@computercarguy La organización sufre problemas de calidad bastante graves, lo que socava la confianza del cliente. De acuerdo, es un equilibrio, pero la corrección de errores no mejora significativamente la calidad a largo plazo: el proceso debe mejorarse para que los errores no existan en primer lugar. Las nuevas características de Buggy decepcionan a las personas, incluso si los errores finalmente se solucionan. Así que no, las nuevas funciones no ayudarán más a la organización en esta circunstancia si esas nuevas funciones frustran demasiado a los usuarios con sus errores. Solo quería señalar que esta respuesta no refleja mi experiencia con proyectos de grandes empresas.
@DavidRice ¿Le sorprende que sea interesante para una organización de donde provienen nuevos errores? Dicho de otra manera, si resuelve un error, corrige un error, si aborda la causa raíz, potencialmente corrige muchos errores. Sí, la organización (y yo mismo) nos preocupamos por la causa raíz de los errores introducidos por el nuevo trabajo. Analizar activamente los problemas y cambiar el proceso para evitar esos problemas suena como una cascada. Agile no significa "errores de envío", hay un lugar en ágil para MVP sólidos como una roca que tienen un alcance limitado pero no robustez.
@ user2152081, entonces sí, hay una diferencia entre "ya somos 99% perfectos, pero queremos ser 100%" y "necesitamos tener este monstruo bajo control". Si la Org. está tratando de ser perfeccionista, se aplica mi comentario, pero también he trabajado en lugares con un código heredado extremadamente defectuoso que tenía poco o ningún control de calidad anterior, funciones a medio completar y cosas peores. Llegar a la causa raíz de los errores en ese caso es definitivamente útil, pero aún puede perder un tiempo precioso arreglando las cosas si "necesita" encontrar la causa antes de que se solucione el error.
@user2152081 No enviaría errores, pero si estoy trabajando en una nueva función, la codifico y el control de calidad encuentra un error en el nuevo código, lo soluciono antes de que se lo demuestre al cliente, o si es un falla más fundamental con la función, lo discutimos con el cliente, pero me parece extraño preocuparme más por por qué hay un error en lugar de por qué hay un error.
@DavidRice definitivamente estaba siendo un poco hiperbólico, hay errores muy importantes. No tenemos esa separación entre desarrollo y control de calidad, trabajamos de la mano y, en general, el control de calidad está ahí para pruebas exploratorias/de regresión más que para la verificación de funciones. Los errores menores nunca desaparecen, pero generalmente apuntan en la dirección de, por ejemplo, falta de modelado de dominio, complejidad arquitectónica, etc. " en el ámbito relativamente pequeño que respalda el esfuerzo. Dev hace control de calidad.
@DavidRice Comprender por qué ocurrió un error es fundamental para reducir la tasa general de errores generados por una organización. Puede ser que la mayoría de los errores se creen debido a especificaciones incompletas o incorrectas. O tal vez es una base de código de baja calidad que necesita urgentemente una refactorización. Quizás haya un desarrollador en el equipo que sea incompetente. Una vez que se conocen las causas raíz, se pueden tomar medidas para reducir las tasas de errores, mejorar la calidad del código y reducir el tiempo de comercialización de nuevas funciones.

En el stand up , solo debe exponer los hechos:

  • Ayer, trabajé en el error n.º 532 acerca de que los widgets tenían el color incorrecto. Completó eso y está listo para la próxima implementación.
  • Hoy, voy a trabajar en el error n.º 536 sobre el bloqueo al intentar pedir más widgets.
  • Posiblemente bloqueado porque no entiendo las interacciones con el servicio de pedidos de back-end. ¿Con quién puedo hablar de eso?

Cualquier otra cosa está fuera del alcance del stand up. Más allá de eso, alguien (el líder de su equipo, su gerente, quienquiera que le asigne trabajo) le ha pedido que trabaje en estos problemas para que ya sepan de dónde provienen y por qué no está aportando nuevas funciones al sprint. Que se preocupen por eso.

Esto es excelente, deja que el equipo/director saque sus propias conclusiones. No se refleja en usted porque entró después de que ya estaba 'codificado' y tiene que aumentar.

  • 1) No hagas que parezca que estoy hablando mal del código o del ex empleado que se fue, cuyo trabajo estoy arreglando.

    Bueno, hablas de los problemas en el código, sin mencionar el por qué (o quién), los errores están ahí y deben corregirse, eso es todo.

  • 2) Trato de no hacerme quedar mal, ya que voy a estar ocupado arreglando algo que no pasó la prueba (creo que se ve mal cuando empujas cosas que tienen problemas cuando se prueban), por lo menos una vez. sprint, en el que puede que no contribuya tanto al nuevo trabajo que hemos realizado.

    No es tu trabajo preocuparte por la tarea. Una vez que le asignan algo, lo único que debe preocuparle es si está completando (o al menos progresando) sus tareas como se esperaba o no. Por qué estás trabajando en algo, casi siempre está por encima de tu nivel de pago.

  • 2.5) No parece que esté tratando de desviar la responsabilidad de arreglarlo, pero ciertamente no me gustaría que me confundan con la fuente de estos problemas.

    ¿Por qué piensas de esta manera? El código está escrito por otra persona, el control de calidad lo ha realizado otra persona, tú eres el que lo arregla. Nadie pensará que usted es la fuente del problema aquí.

Entonces, finalmente, para responder:

¿Cuál es la mejor manera de hablar sobre esto durante las reuniones diarias?

De la misma manera si los errores se hubieran encontrado en el código de otra persona que todavía está trabajando en el equipo. Se encuentra un error, se le asigna corregirlo, indicar el progreso que hizo ayer y establecer el plan para hoy; también mencione si necesita ayuda del equipo para superar cualquier obstáculo que tenga. Estás listo.

Me gusta este, solo hable sobre el código y los errores, culpe al código "Descubrí que no hizo esto" "Estoy mejorando esto..."
"¿Por qué piensas de esta manera? El código está escrito por otra persona, el control de calidad lo ha hecho otra persona, eres tú quien lo arregla. Nadie pensará que eres la fuente del problema aquí". Si ahora son responsables de la función X y hay problemas con la función X, entonces la gente podría suponer con bastante facilidad que ellos son la razón por la que hay problemas con la función X. Es posible que no sepan, o no recuerden, que alguien más estuvo anteriormente responsable de la característica X, y es posible que no sepan cuándo se introdujeron los problemas en el código.
@AnthonyGrist Entonces, necesita un mejor gerente. Ciertamente no quiero que mi gerente "se olvide" de eso. También tenga en cuenta que esto en el contexto de una reunión de pie, por lo que el equipo (ágil) es pequeño (2 ~ 7, idealmente) y cohesionado.

Hay algunos conceptos subyacentes de Scrum que no se respetan de manera efectiva en la situación que describe y que generan la preocupación que tiene.

1) Todo el equipo está destinado a ser dueño de la finalización del trabajo. Una función en particular solo se realiza una vez que se implementa, prueba y se puede publicar según el estándar de la definición de hecho. Menciona el trabajo antiguo frente al trabajo recién comprometido, pero este es un trabajo comprometido que el equipo no ha terminado. Usted está ayudando al equipo a completar este trabajo. Esto definitivamente no debe reflejarse mal en usted ni debe verse como un trabajo antiguo.

2) El desarrollo en Scrum es adaptativo. Muchas veces necesitamos refactorizar o "arreglar" las cosas, no porque nos hayamos equivocado antes, sino porque las cosas han cambiado desde entonces. Esto es normal.

3) Somos seres humanos y el dominio perfecto de cualquier habilidad es imposible. Scrum requiere que nos esforcemos por ser un equipo que pueda identificar errores y mejorar la forma en que trabajamos sin que sea un ataque personal, no ser un equipo que evite esas conversaciones. Si tiene ganas de decir que está arreglando un error que alguien cometió y se considera malo, eso es realmente un desafío de seguridad psicológica profunda en el equipo que debe abordarse en gran medida.

No veo ninguna mención de Scrum específicamente en la pregunta. Sin embargo, los puntos que haga deben ser aplicables a cualquier proceso ágil. Y el #3 (no dispares al mensajero) es especialmente importante para cualquier organización/equipo/lo que sea que aspire a ser algo más que disfuncional.
no lo fue Simplemente se dedujo de las etiquetas.

Simplemente informe al rastreador de errores de la empresa y a su superior cuál es el estado actual del código diciendo la simple verdad y sin ocultar nada.

Cuando llene el rastreador de errores, intente evitar mencionar el nombre del desarrollador anterior tanto como sea posible y también evite los adjetivos (malo, pobre, de mierda...). Solo concéntrate en los hechos.

Reúnase con su superior o el equipo para explicarle la situación y los recursos necesarios para solucionar todo el problema: tal vez necesite unas semanas más, tal vez se necesite otro desarrollador, tal vez una capacitación para usted, etc. Su superior lo conoce y tus puntos fuertes, así que si un insecto necesita algún conocimiento que tú no tienes, no debería culparte.

¿Cómo evitar que uno mismo y el ex empleado se vean mal al informar sobre arreglar el trabajo del ex empleado?
RespuestasAquíPolítica de privacidad1y, 0v