¿Por qué es tan difícil hacer que los empleados actualicen el rastreador de problemas?

31

Siempre he tenido dificultades para lograr que la gente actualice sus problemas, tanto en mi empresa como en el trabajo. He tenido algunos casos en que las personas realmente lo hacen por la bondad de su corazón, pero ~ 70% del tiempo tengo que estar persiguiendo a las personas.

Siendo el que generalmente realiza alguna u otra forma de gestión (en primer lugar soy un desarrollador), la razón principal por la que trato de dar es que no quiero perseguir a las personas e interrumpirlas para consultar sobre el progreso, pero no lo hago ' Al final, piense que a la gente le importa que le pregunten mucho. En algunos casos raros y extremos termino actualizando sus tickets (cuando necesito crear informes).

Entonces, ¿te has encontrado con este problema ?, ¿cómo has animado a los desarrolladores a actualizar el rastreador de problemas con frecuencia ?, ¿qué grado de éxito has tenido?

dukeofgaming
fuente
21
Por experiencia personal, el problema radica en la mentalidad de que actualizar el rastreador de problemas y mantener la documentación adecuada en general no es tan importante como la codificación. Y si bien esta es una mentalidad algo natural para un desarrollador, no debería ser para la administración y la empresa en general. ¿Su empresa trata esa parte del trabajo tan importante como la codificación? De lo contrario, debe comenzar allí, los desarrolladores son inteligentes y adaptables, si sienten que la compañía realmente considera que esto es un gran problema (con elogios cuando se hace bien y las consecuencias cuando no), pronto comenzarán a hacerlo bien.
Yannis
@YannisRizos Este comentario es lo suficientemente bueno como para ser una respuesta
dukeofgaming
14
Ah! Ni siquiera puedo lograr que mi jefe use el rastreador de problemas. Él pasa, habla rápidamente sobre "cosas" y se va. A eso lo llamo "informes de errores de conducción". De hecho, me ridiculizan por usar el rastreador de problemas ... Siento cierta frustración en la Fuerza.
MetalMikester
3
OMI, la mayoría de los 'rastreadores de problemas' que he visto apestan bastante mal: los ui terminan siendo demasiado engorrosos (para que puedan manejar casos especiales). Entonces, si me preguntaran por qué no los uso, es por eso.
GrandmasterB
1
Efectivamente, asegúrese de tener una aplicación que funcione bien, sea fácil de usar, rápida y no requiera ingresar demasiada información. Además, los defectos deben clasificarse como qué hacer en la próxima versión y se debe utilizar la información ingresada. Por ejemplo, si un desarrollador explica todo correctamente, pero usted es demasiado vago para leerlo y, en su lugar, va a preguntarle, obviamente, uno perdería la motivación para usar el sistema, ya que es muy frustrante explicarle lo mismo dos veces.
Phil1970

Respuestas:

30

La razón es que no entienden por qué deberían actualizar el rastreador de problemas, aparte del hecho de que usted lo diga.

¿Porqué es eso? Supongo que actualizar el rastreador no afecta su trabajo de manera significativa, por lo que la solución probablemente sea implementar un sistema de rastreo que realmente los ayude a hacer mejor su trabajo.

Martin Wickman
fuente
"implementar un sistema de seguimiento que realmente los ayude a hacer mejor su trabajo". ¿Puede dar un ejemplo? De algo que les ayuda es un sistema de seguimiento específico.
Burhan Ali
2
@BurhanAli No, no estoy en condiciones de decirles lo que funciona para ellos. Necesitan resolver eso por sí mismos. Sin embargo, sugerencia: comience con algo simple y use comentarios semanales para mejorarlo.
Martin Wickman
Su equipo puede variar, pero como ejemplo, comencé a mejorar mucho más la actualización del rastreador de problemas cuando comencé a usarlo como un centro de comunicación para que no me interrumpieran con tanta frecuencia en el código.
Morgen
13

Es difícil, porque los empleados sienten claramente que actualizar el rastreador de problemas no es importante. Tienes que cambiar eso, pero hay una trampa. La comunicación es dificil. La comunicación efectiva es realmente difícil, mucho más difícil de lo que piensas. Tan difícil, que la comunicación generalmente falla, excepto por accidente .

Muestra, no digas. P.ej. no diga que usted (o su jefe) necesita los datos para un informe. Muestre desde el punto de vista de los empleados cómo el rastreador de problemas actualizado les afecta y les ayuda.

Predicar con el ejemplo.

Maglob
fuente
10

Soy desarrollador y me cuesta utilizar el rastreador de problemas que tenemos en el trabajo. Esto es lamentable porque estoy a favor de que ellos mantengan las cosas organizadas. Mi solución por el momento es usar una herramienta de seguimiento personal y hacer referencia a ella para hablar sobre el progreso en nuestros scrums diarios.

Esto es lo que me haría usar el rastreador todo el tiempo:

  • Integración perfecta con el IDE y el control de origen. Usamos algunas aplicaciones web torpes porque ya se compraron licencias para ello. Se tarda una eternidad en crear / actualizar tareas, y tiene algunas características confusas de la interfaz de usuario. Desafortunadamente, usar esto está más allá del control de nuestro equipo.

  • Sencillez. Con esto me refiero a no tomar 10 campos rellenados manualmente solo para agregar una tarea. Estimaciones por hora versus tiempo de finalización, ingresando manualmente el proyecto / componente / etc. en varios campos, etc. solo aumente la cantidad de tiempo.

  • Solo uno. No estoy seguro de qué tan común es esto, pero la administración de proyectos usa una herramienta, el soporte usa otra y el desarrollo usa una tercera. Si uno no se actualiza, tres ciertamente no lo son y es poco probable que la sincronización entre ellos se automatice.

Críptico
fuente
8

En primer lugar: ¿qué quiere decir con "personas que actualizan su progreso"?

¿Se refiere a "desarrolladores que actualizan la estimación actual", o "desarrolladores que no resuelven un problema", o más bien "clientes / evaluadores que no cierran un problema resuelto", o todos juntos?

Desde la perspectiva del desarrollador, es una mezcla de mentalidad y cultura.

  • mentalidad: cuando configuras un problema para resolverlo, significa que has terminado y eres responsable si tiene errores
  • cultura: si toda la empresa no está muy interesada en usar tales herramientas, pero prefiere otras estrategias de organización

Mi experiencia es: necesitas la cultura para apuntar en la dirección correcta, al menos. Lo que ayuda a continuación es definir un DoD (definición de 'hecho'): si un desarrollador (también trabaja para otros roles) puede decir (s) que completó toda la lista, es un alivio marcar el problema resuelto y seguir adelante sin necesidad mirar atras.

Andy
fuente
5

Deje de preguntar sobre el progreso de la codificación (por lo general, es un porcentaje arbitrario extraído de la nada) hasta que se cierre el boleto, no otorgue crédito. Si lo principal que mide es el número de tickets cerrados, mejorará.

Sin embargo, tenga en cuenta que todas las métricas se pueden jugar y las métricas tienden a funcionar mejor cuando se combinan con métricas complementarias, por ejemplo, es probable que también desee ver los problemas que se vuelven a abrir, ya que esto implica que se están cerrando prematuramente

jk.
fuente
5

Como señalan algunas otras respuestas, la pregunta correcta aquí es probablemente: ¿por qué tiene un rastreador de problemas? Una buena respuesta a esta pregunta (no solo desde la perspectiva de la administración sino también desde la perspectiva del desarrollador) es imprescindible si desea que un sistema de seguimiento de problemas realmente funcione y se actualice regularmente.

En muchas empresas, el sistema de seguimiento de problemas se utiliza principalmente como herramienta de informes de gestión. Hacer que los programadores actualicen los problemas solo para que la administración pueda ejecutar un informe no funciona bien. Y obligar a los programadores a actualizar los problemas tampoco funciona: es posible que tenga problemas actualizados, pero debe cuestionar los datos.

En mi experiencia, la única forma de que los desarrolladores (y probadores, administradores, etc.) realmente utilicen un sistema de seguimiento de problemas es integrarlo en el proceso de desarrollo. Esto significa que la salida de una parte del proceso se convierte en la entrada a la siguiente parte del proceso.

Para dar autoridad al sistema de seguimiento de errores, sugeriría lo siguiente:

  • Los desarrolladores solo trabajan en errores / características registradas en el rastreador de problemas y no se realiza ningún trabajo fuera de él. Todas las ideas, proyectos de refactorización, nuevas características, herramientas personalizadas para ser desarrolladas, etc. también deben registrarse
  • Las cuestiones se trabajan en orden de prioridad. La prioridad debe estar determinada en parte por la administración, pero los desarrolladores definitivamente también deben tener voz en la determinación de prioridades. Esto es especialmente cierto cuando se trata de problemas de mantenimiento y refactorización.

En cuanto al proceso, puede usar algo como lo siguiente:

  • El estado 'nuevo' indica que un desarrollador aún no ha resuelto un problema y todavía está en la cola de problemas priorizados
  • El estado 'asignado' indica que se ha asignado a un desarrollador. Esto podría hacerlo el desarrollador u otra persona, como el líder del equipo. Creo que funciona bien tener algunos problemas asignados a cada desarrollador y, por lo general, una combinación de 'trabajo pesado', como nuevas características y selecciones fáciles, como errores simples o algún trabajo de mantenimiento simple. Esto permite a los desarrolladores elegir el trabajo en función de su estado de ánimo.
  • El estado 'en progreso' significa que un desarrollador está trabajando en un problema. Solo uno o dos problemas por desarrollador deben estar 'en progreso' en cualquier momento.
  • Una vez que se ha resuelto un problema, el desarrollador puede cambiar el estado del problema a "necesidades de prueba" y cambiar el propietario al probador. Este es un paso importante, ya que también es la cola de trabajo de los evaluadores.
  • los evaluadores pueden cambiar el estado a 'prueba fallida' y cambiar la propiedad al desarrollador, lo que significa que va a la parte superior de la cola para el desarrollador, o pueden cambiar el estado a 'listo para implementar'.
  • los problemas con el estado de 'listo para implementar' pueden fusionarse y liberarse de acuerdo con el ciclo de lanzamiento por quien sea responsable de los lanzamientos.

En resumen: haga que el sistema de seguimiento de problemas sea una parte esencial del proceso de desarrollo y no tendrá que preocuparse por problemas que no se actualicen.

Mauritz Hansen
fuente
3

Quizás consideren que es demasiado trabajo abrir un navegador, iniciar sesión, encontrar el ticket y llenarlo. Quizás puedas intentar animarlos con ganchos . Hoy en día es una característica común que en el mensaje git / hg [supongo que usas uno de estos] puedes escribir algo como FIJO # 123, y el ticket cambiará automáticamente una vez que presiones tu confirmación. De esa manera, casi no es trabajo para el desarrollador [si trabaja en cada tema en una rama separada, ya tiene la identificación del ticket] y lo más probable es que agregue esos dos caracteres en el mensaje de confirmación. Si esta solución no es suficiente, ¿tal vez significa que el alcance de los boletos es demasiado grande y debería dividirse en muchos boletos más pequeños?

mkk
fuente
3

Esto suena como un problema de cultura de empresa más que cualquier otra cosa. ¿Quién instituyó la necesidad de usar el rastreador? Si esto es algo que una persona o grupo lanzó, y espera que todos los demás lo acepten y lo usen, buena suerte. A menos que las personas entiendan lo que es, sepan cómo usarlo y acepten que en realidad les hace la vida más fácil (sus vidas, NO la suya), no lo usarán a menos que la gerencia lo obligue. Dicho esto, si el uso del rastreador es una decisión de la compañía, entonces debería estar en manos de la gerencia aplicarlo. A menos que su rol incluya la responsabilidad y la autoridad para obtener / hacer que las personas usen el rastreador (suena como no, como indicó que es un desarrollador), no va a llegar muy lejos, independientemente de lo que haga (de manera realista, en mi humilde opinión )

cazador
fuente
2

Esto es probablemente similar a por qué es tan difícil lograr que las personas ingresen a su tiempo regularmente. Es un trabajo tedioso ...

Muchos rastreadores de problemas se integran con el IDE. Por ejemplo, el Rastreador de elementos de trabajo TFS le permite marcar una tarea como resuelta cuando realiza un check-in. Incluso hay una opción para exigir que un check-in esté asociado con una tarea. Hacer que la actualización de un elemento de trabajo forme parte del proceso de registro simplifica las cosas. La alternativa es abrir el rastreador de problemas en una interfaz separada para realizar el cambio.

Otra opción es tener una reunión de estado (o durante el standup diario) donde alguien abre el rastreador y actualiza las tareas a medida que las personas proporcionan el estado.

Michael Brown
fuente
0

Una cosa a tener en cuenta es que la GUI misma es un impedimento. Por ejemplo, algunos obstáculos pueden incluir:

  • Demasiados clics
  • Servidor de aplicaciones de seguimiento de problemas sin optimizar o con poca potencia
  • Mala usabilidad o accesibilidad

Exponer una API permitirá que el rastreador de problemas se actualice mediante secuencias de comandos, lo mismo que los artefactos técnicos (cobertura de código, informes de prueba de unidad, estado de compilación, etc.).

Referencias

Paul Sweatte
fuente
En uno de mis lugares de trabajo usamos Jira y el primer año y medio fue la razón por la que aprendí a odiarlo: fue lento, estaba hinchado, el proceso estaba mal definido, tuve que marcar el tiempo que pasé en Jira, en mi propio software de seguimiento de tiempo personal y en el software propietario que no ayudó. Si la pista de error tarda más de un segundo en actualizarse entre clics, es demasiado larga. Finalmente, aprendí a que me gustara Jira cuando se le lanzó un mejor hardware y se finalizó el proceso.
Maurycy