¿Por qué no hacer el propósito de Año Nuevo de mejorar su flujo de trabajo de defectos? En este artículo, basado en años de experiencia de primera mano, comparto una mejora del proceso que le permitirá prestar un mejor servicio a sus clientes, desarrolladores y partes interesadas de la empresa.
Cuando los errores se acumulan
Muchas organizaciones utilizan informes de errores para capturar todos los problemas que surgen como parte de un producto, servicio o proceso empresarial. Mientras que una amplia gama de problemas se capturan como errores - y aquí usamos el término "error" en sentido amplio, independientemente de la herramienta específica que se utiliza para realizar un seguimiento de esta información - sus desarrolladores están utilizando esto para realizar un seguimiento de las solicitudes de características o defectos que necesitan ser remediados.
Los desarrolladores acaban dedicando una cantidad de tiempo considerable a revisar y clasificar repetidamente los errores. Los errores obsoletos, que a menudo no se eliminan por miedo a perder información o se guardan "por si acaso", atascan el proceso de gestión del proyecto y requieren tiempo para revisarlos, y volver a revisarlos, para volver a dejarlos para más adelante. Los errores mal definidos se convierten en deudas técnicas que el equipo debe gestionar y comprender.
La acumulación de errores obsoletos alcanza un punto de inflexión cuando te ves desbordado por un esfuerzo de gestión de defectos que no hace avanzar tu negocio. Una empresa de productos en la que trabajé hablaba de haber llegado a la bancarrota de los bugs. Y un día, los líderes decidieron llevar a cabo esa charla. Se borraron todos los errores para empezar de cero con nuevos informes de errores. La intención era clasificar y corregir activamente los nuevos errores a medida que iban llegando.
¿Y qué? Un año después, los fallos se acumulaban. Otro año después, se volvió a hablar de declarar la bancarrota de los bugs. ¿Cómo es esto sostenible? ¿Cómo ayuda a la empresa a avanzar de forma productiva?
¿Qué problema intentamos resolver con la gestión de defectos?
Un cliente informa de un problema. Tu equipo de soporte recopila información, confirma que hay un comportamiento anómalo y archiva un fallo.
Su equipo de control de calidad realiza una prueba más de su producto. Observan un comportamiento inesperado y archivan los errores.
Tu equipo de éxito de clientes está hablando con un cliente potencial que pregunta si tu producto tiene ciertas características. Con la esperanza de cerrar el trato, su equipo presenta errores para las características que creen que faltan.
En todos estos casos, los errores adoptan distintas formas. Algunos son preguntas sobre por qué se han observado determinados comportamientos, a menudo porque faltaba documentación o las expectativas estaban mal alineadas.
Otros son problemas conocidos que se resuelven por medios alternativos: documentación, flujos de trabajo diferentes y soluciones provisionales. En la mezcla puede haber defectos legítimos que deben abordarse, aunque todavía no se les ha dado prioridad ni se conoce el impacto total del defecto.
Si damos un paso atrás y consideramos las partes interesadas en el ciclo de vida del desarrollo de software, las diferentes necesidades se hacen más evidentes.
Los usuarios empresariales quieren análisis de defectos sobre índices de incidencia, problemas notificados por los clientes y áreas de preocupación del producto. Los equipos de gestión de productos están interesados en conocer los defectos de los productos y las solicitudes de características para desarrollar una hoja de ruta de productos más sólida. El equipo de desarrollo utiliza el sistema de gestión de incidencias para definir los elementos de trabajo y mantener a todo el mundo al día.
Propuesta de un proceso de gestión de defectos más sostenible
Aquí proponemos un nuevo enfoque para su proceso de gestión de defectos basado en un flujo de trabajo sostenible, flexible e informativo.
En primer lugar, aclararemos las definiciones de algunos términos.
Un incidencia o observación representa la aparición de un comportamiento, ya sea esperado o inesperado. Específicamente, no implica ninguna acción o resolución requerida. Simplemente representa un punto de datos empíricos sobre un comportamiento observable con un contexto sobre cuándo, dónde y cómo ocurrió.
A problema representa un conjunto de incidentes similares que deben investigarse. Un problema puede ser un defecto si representa un comportamiento anómalo que debe corregirse.
A error es un elemento de trabajo procesable y centrado en el desarrollador para resolver un problema o defecto.
Teniendo en cuenta estas definiciones, proponemos el siguiente proceso:
1. 1. Crear una base de datos que contenga todas las incidencias y observaciones
Esto a menudo se puede crear como un proyecto independiente dentro de un sistema de gestión de incidencias existente. Los incidentes entrantes se registran con toda la información de apoyo que pueda recopilarse.
Los incidentes existentes no No se hace referencia a los incidentes existentes ni se intenta evitar la duplicación de incidentes. Cada vez que se hace una observación, por frecuente que sea, debe registrarse como una entrada independiente. La categorización, como el área de producto, puede añadirse al incidente.
2. Establezca un proceso diario para revisar los nuevos incidentes
El equipo de negocio, como los gestores de producto y los analistas de negocio, deben considerar cada incidente por separado. Si hay un problema existente que cubra ese tema, el incidente debería asignarse a ese problema. Los incidentes que no estén representados por problemas existentes deben dejarse como están.
3. Establecer un proceso semanal para revisar patrones de incidentes aún no asignados a problemas
Deben utilizarse análisis de datos para agrupar los incidentes en comportamientos similares. El equipo de negocio define problemas para cualquier grupo de incidentes que necesiten más investigación y puedan requerir algún tipo de resolución.
4. Tras la agrupación semanal de incidentes, revise todos los problemas en los que se han asignado nuevos incidentes
Querrá establecer la gravedad, probabilidad e impacto del problema para determinar si es un defecto y necesita remediación. Involucre al equipo de desarrollo para comprender el alcance del problema e identificar posibles soluciones.
5. En el caso de problemas que requieran solución, cree una solicitud de fallo o función en la lista de tareas pendientes de desarrollo del producto,
Incluya una solicitud específica y procesable para el equipo de desarrollo. El informe de errores también debe incluir la prioridad en relación con otros trabajos, los criterios de finalización, las métricas de éxito y cualquier otra información para cumplir con la definición de su organización de "listo para el desarrollo". Cualquier problema que no se pretenda resolver a corto plazo debería no dar lugar a un informe de error.
6. Ejecución
Incluya los bugs en el backlog de desarrollo con categorización, valor identificado y prioridad. Los errores sólo seguirán siendo una lista creciente a menos que se traten como elementos de primera clase y exista un plan para actuar sobre ellos.
Con el proceso descrito anteriormente, tanto el equipo de desarrollo como el de negocio comprenden la importancia de los fallos identificados y se asegurarán de que se mantiene su prioridad, en relación con otros trabajos. A medida que el equipo de desarrollo trabaje en su backlog, la atención se centrará en el valor que sus clientes necesitan, las nuevas funciones y una mayor calidad.
A continuación, ofrecemos un resumen visual del flujo de trabajo de la gestión de defectos.
La aplicación de este proceso le proporciona un flujo constante y predecible de incidentes, problemas y defectos procesables. Las funciones y expectativas quedan más claras, lo que aumenta la eficacia de los equipos.
Sólo el principio de un proceso de gestión de defectos nuevo y mejorado...
Con el proceso de gestión de defectos que acabamos de describir, puede considerar los incidentes entrantes como un flujo de eventos, al igual que las lecturas de los sensores, las páginas vistas y los cambios en la base de datos. Usted podría almacenar los incidentes, o mensajes de eventos derivados de ellos, en un lago de datos u otro almacenamiento adecuado.
Como ya se comentó en un artículo anterior Desbloquee sus datospuede realizar análisis de datos en el flujo de eventos de incidentes, supervisar la tasa de incidentes, explorar tendencias para el origen de los incidentes, predecir áreas problemáticas e implementar la supervisión y las alertas en su sistema.
Las empresas con más éxito saben cómo ajustar sus procesos y aprovechar el análisis de datos.Póngase en contactoa nuestro equipo de Improving para obtener asesoramiento estratégico y ejecución de proyectos.
