¿Hay un beneficio claro en separar los "problemas" de las "tareas" cuando se trabaja en equipos más grandes?

Antes de entrar en un sistema que ofrece la segregación entre una tarea y un problema, quisiera asegurarse de que los usuarios se sientan muy cómodos con la terminología y, más específicamente, con el uso de uno u otro.

Como señaló, los sistemas suelen utilizar la misma nomenclatura para identificar algo sobresaliente. Creo que eso se debe principalmente a que a los usuarios no les importa cómo lo llamará TI. Por lo tanto, siempre que los usuarios del sistema sepan claramente cuándo identificar algo como una tarea o un problema, tendrá problemas más adelante.

Otro escenario posible es que las entradas sean enviadas en su mayoría por personas que conocen claramente la diferencia. En este caso, ¿por qué no utilizar un dato para diferenciar los billetes? En nuestro caso, acordamos que cuando se completa el campo "fecha de vencimiento", significa que es una tarea que se está produciendo, para segregar a otros tickets que aún no se han priorizado.

Tal vez, los esfuerzos para cambiar el sistema actual a otro que ofrezca la segregación entre tareas y problemas no den resultado. Tenga en cuenta que siempre existe la curva de aprendizaje para cualquier sistema nuevo y si tiene a su cliente ingresando tickets, puede que no sea bueno cargarlos en un nuevo sistema "solo para facilitarle las cosas a TI".

En su caso, puede elegir cualquier campo que su equipo no esté muy acostumbrado a usar y aceptar que ese campo será el "identificador de la tarea" (un campo que solo puede ver el departamento de TI, preferiblemente).

Volviendo a la pregunta del sistema: Jira podría satisfacer su necesidad. Pero tenga en cuenta que tal diferenciación es más cultural que sistemática.

Creo que estamos tratando de resolver el mismo problema, que es el desafío de priorizar diferentes tipos de trabajo categorizándolos en la fase de entrada o al menos poco después de la entrada.

He trabajado con sistemas que han tenido un solo tipo de problema ("error") en una implementación actual de Jira con tres ("entregables", "tarea" y "error"). El sistema de tipo único resultó en muchas etiquetas extrañas y estándares de documentación para distinguir "errores" (trabajo no planificado, excepto en el sentido general) y "trabajo planificado". El sistema de tres tipos de problemas ha evolucionado durante cinco años y se adapta a las necesidades de mi organización.

Entregable: Trabajo formal del proyecto, es estimado, detallado, tiene pruebas de finalización y un paso formal de revisión/aceptación. Por lo general, se acumula en algún tipo de obligación contractual.

Tarea: Menos formal, sin paso de revisión. Básicamente, los elementos "para hacer" a menudo ingresados ​​​​por los propios desarrolladores. Existe debido al deseo de capturar trabajo desconocido en forma de listas de notas, tareas de Outlook, etc.

Error: generalmente ingresado por evaluadores de control de calidad. Revisado (lo llamamos triaje) y priorizado para la acción en relación con su gravedad. Un error grave puede tener prioridad sobre un entregable, un error muy pequeño podría esperar en la cartera de pedidos durante mucho tiempo. El reportero verifica una corrección de errores.

Tenga en cuenta que tanto los entregables como los errores tienen pasos de revisión/verificación. La diferencia entre un entregable y un error es que los entregables aún no están rotos.

La idea es que la mayoría de las consultas/solicitudes de terceros se ingresen como un problema y luego se migren a una tarea y, posteriormente, el administrador del proyecto las programe y asigne.

A lo que te refieres aquí es a un cambio de estado, no a un elemento separado. Necesita una forma de capturar el estado inicial del elemento como un problema y luego una forma de cambiar ese estado para indicar que ha sido visto y aprobado por los PM y está listo (o ha sido) programado.

En TFS, esto es simple, cuando los nuevos elementos de trabajo de tipo base (el nombre varía según la plantilla), el estado es algo así como "propuesto" o "pendiente". Una vez que ha sido aprobado, el estado cambia a "aprobado".

Este método garantiza informes transparentes y también que los elementos de trabajo no se pierdan. Si usó dos elementos de trabajo completamente separados, podría encontrarse fácilmente con problemas en los que el elemento no pudo migrar correctamente. Cada estado tiene su propio método de cierre, por lo que un elemento de trabajo que no ha sido aprobado puede rechazarse, pero un elemento de trabajo que ha sido aprobado puede completarse o cancelarse.

Creo que esta es una gran pregunta, y aprecio el contexto detallado. Estoy de acuerdo con @aclear16 en que esto es más un cambio de estado que dos entidades rastreables separadas. Creo que realmente estás lidiando con un control de cambios fundamental.

Ha definido "Problema" como una entrada de un tercero que indica un deseo de cambio. Lógicamente, esa solicitud de cambio debe analizarse para descubrir qué impacto tiene en el alcance/programación/costo/calidad/etc. Con base en ese análisis, el PM desarrolla un paquete de trabajo para abordar el problema, lo que llama una "tarea".

Las tareas deben enviarse a las partes interesadas pertinentes (junta de control de cambios) para su priorización y asignación de recursos. (A veces, la CCB hace la validación y una entidad separada hace la priorización y la dotación de recursos). En ese momento, la programación se cambia para incluir la tarea.

TL;RD

No confunda las entradas del proyecto con compromisos de entregables. Este parece ser el problema subyacente de X/Y que está siendo abordado por la pregunta.

El problema

Tradicionalmente, todos los problemas se ingresan en un sistema de seguimiento exactamente como eso: un "Problema".

El problema, tal como lo veo, es que sus herramientas dictan el flujo de trabajo, y usted está tratando de diferenciar entre la entrada de procesos no controlados (problemas) y los entregables de procesos ordenados y controlados (tareas).

En la medida en que ya haya definido una distinción entre los dos, no hay ningún problema real. El problema, como tal, es que no ha modificado su flujo de trabajo en consecuencia y que, hasta cierto punto, está restringiendo su flujo de trabajo en función de su cadena de herramientas existente.

También parece que falta un paso del proceso. Específicamente, el proceso en el que los problemas se clasifican y asignan, priorizan y programan, o no, según lo dicten las necesidades de la organización.

Soluciones potenciales

No hay valor inherente en diferenciar entre "problemas" y "tareas". Lo que realmente necesita hacer es arreglar su proceso para diferenciar entre "cosas en las que queremos gastar tiempo y dinero" y "cosas que no nos importan".

Para ello, debe revisar su proceso de clasificación o crear uno si no existe. Alguien debería estar revisando los problemas a medida que surgen, evaluando el impacto comercial (si lo hay) e identificándolo como un entregable si amerita el esfuerzo y los recursos.

En Scrum, este sería el trabajo del propietario del producto. El PO prioriza el Product Backlog al identificar el valor comercial y coloca el trabajo en el backlog en un espacio determinado tanto por la importancia intrínseca como por las dependencias de otros elementos del backlog.

Aproveche su sistema de seguimiento de errores

Si insiste en permanecer limitado por su cadena de herramientas actual, todavía tiene un par de opciones.

1. Use un cubo diferente para el trabajo que no se ha clasificado.

   Básicamente, se trata de una pila de desechos, desde la cual el propietario del producto (o equivalente) puede seleccionar el trabajo que se transferirá a otra cubeta desde la cual se asigna realmente el trabajo. A excepción de la clasificación, ningún trabajo se realiza directamente desde el depósito de entrada no clasificado.

2. Use el mismo depósito, pero solo trabaje en problemas clasificados y etiquetados adecuadamente.

   La mayoría de los sistemas de seguimiento de errores permiten etiquetas, priorización y programación. Si su sistema de seguimiento de errores es realmente el grupo de entregables de su proyecto, entonces asegúrese de que las etiquetas de su proceso de clasificación funcionen para ignorarlas como "no arreglar" o similar, o asigne niveles de gravedad, fechas de vencimiento e hitos al trabajo que debe realizarse.

De cualquier manera, la solución es, en última instancia, la misma: dejar de tratar los problemas o las solicitudes de errores como un compromiso para entregas específicas. Independientemente del formato o la nomenclatura, su sistema de problemas simplemente proporciona información para su proceso. Depende de la organización evaluar el valor, y la responsabilidad del equipo del proyecto es estimar el esfuerzo y comprometerse con tareas e hitos específicos.

Una tarea es la ejecución de un paquete de trabajo. Fluye de una actividad de planificación de proyecto premeditada (ya sea una historia de usuario o un plan de proyecto de tipo cascada). Una tarea es una actividad planificada.

Un problema es un error, riesgo o desafío que surge durante la ejecución. Fluye del trabajo en curso. Un problema es una actividad no planificada.

El hecho de que un problema se convierta en una tarea está sujeto a su control de cambios y/o proceso de gestión de riesgos. Este proceso es donde decide cuándo un error se convierte en una tarea o si un riesgo positivo (una oportunidad), por ejemplo, se convierte en una característica. A partir de ahí, lo devolvería a una actividad planificada (como crear la función o abordar el riesgo).

Si el error surge durante las pruebas/control de calidad, es decir, durante el desarrollo del producto, debe decidir cuándo el software está "terminado" y, a partir de ahí, basar las decisiones para corregir el error.