Cómo administrar errores y problemas de UX en tu aplicación

Utilizamos el conjunto de herramientas Atlassian, con Jira específicamente para el seguimiento de defectos. Usamos el conjunto de herramientas Agile dentro de eso, y creamos tableros Kanban o Sprint dependiendo de la naturaleza del trabajo y cuál es la mejor opción para la gestión de proyectos.

Realizamos sesiones de preparación periódicas en el trabajo atrasado para determinar qué desarrollo hacer a continuación y priorizar errores y problemas de UX y mejoras y nuevas características y todo lo demás juntos. Dependiendo del tamaño del proyecto y la forma en que se organizan las partes interesadas, podemos:

1. Haga una gran reserva y prepare todo
2. Cree sub-tableros separados para mantenimiento versus nuevas historias de usuarios versus infraestructura (refactorización por calidad y tecnología actual)

Si hay una sola parte interesada que posee todo hasta los detalles, entonces es un gran retraso. Si hay varias partes interesadas (por ejemplo, una persona en el servicio de atención al cliente que posee mantenimiento, alguien que es más un gerente de producto que posee nuevas historias y un arquitecto técnico que posee mejoras en la infraestructura), crearemos sub-tableros separados que permitan el mantenimiento persona para arreglar sus problemas de mantenimiento y las nuevas historias persona para arreglar sus problemas. Establecemos un entendimiento tácito de que cada sprint contendrá GENERALMENTE X% de mantenimiento e Y% de nuevas historias y Z% de infraestructura.

Durante la planificación del sprint, tomaremos los principales problemas de cada pila y los combinaremos en un tablero de sprint maestro que contiene lo que realmente trabajaremos. Le cobramos al gerente de producto que sea el propietario de esa junta y tome las decisiones finales sobre la preparación y si debe dejar el porcentaje XYZ dividido solo para ese sprint, o ir más pesado o más liviano en alguna área. Lo que hacen nuestros sub-tableros separados es permitir que el gerente de producto delegue la priorización de las piezas de mantenimiento e infraestructura a las personas que conocen mejor esos dominios, mientras aún toma decisiones finales sobre cómo invertir recursos a un nivel de imagen más amplio.

Durante la ejecución del sprint creamos carriles de natación en el tablero y ponemos mantenimiento y control de calidad en la parte superior. La razón de esto es que queremos generar una mentalidad de “calidad primero” cuando escribimos código. Es importante resolver primero los problemas en el software y no solo dejar que los problemas de mantenimiento se eliminen de los sprints porque vuela por debajo del radar frente a nuevas historias. Por supuesto, eso no necesariamente hace que la calidad sea lo primero, ya que si establece un% de mantenimiento o tiempo de infraestructura que es lamentablemente inadecuado, se retrasará y tendrá basura con errores con el tiempo. Pero el objetivo es establecer el XYZ% con una mentalidad de calidad y definir el tamaño del equipo para asegurarse de que se mantendrá en el camino.

En Kanban, el flujo es diferente porque hay un momento natural (planificación de sprint) para combinar diversas prioridades en una decisión final sobre en qué trabajaremos. Allí el flujo es más continuo, pero la razón es similar. Creamos carriles para nadar en el tablero de Kanban con un acelerado en la parte superior, seguido de mantenimiento y luego nuevas historias. También hacemos que la primera columna en el tablero sea la cartera de pedidos, y la segunda columna “Seleccionado para Dev”. Todavía los hacemos en orden de arriba a abajo como lo mantienen los carriles para terminar y arreglar las cosas como primera prioridad, pero el propietario del producto necesita arreglarse más continuamente.

La naturaleza de esta pregunta fue bastante general, por lo que me detendré aquí. Estoy dejando de lado algunos detalles para manejar situaciones específicas (estimaciones, etc.), pero esto puede haber ido lo suficientemente lejos como para responder la pregunta ya.

Existen varias herramientas de informe de fallos / seguimiento de errores que puede utilizar para gestionar errores. Sin embargo, ninguno de ellos puede proporcionar el contexto completo para ayudarlo a replicar problemas. Los errores de registro y los seguimientos de pila no siempre le brindan suficientes detalles para comprender los problemas que ocurrieron y reproducirlos.

Saber qué pasos tomó el usuario para obtener el error realmente ayudaría a construir la imagen completa.

SessionStack puede ayudarlo a llenar los vacíos y acelerar las correcciones de errores. Registra continuamente el comportamiento del usuario en segundo plano mientras se ejecuta su aplicación web. Cuando su aplicación falla, SessionStack le notificará de inmediato. Junto con los seguimientos de errores de JavaScript, detalles de solicitudes de red fallidas y mensajes de depuración, obtendrá una grabación de la sesión del usuario que condujo al error.

Vea los detalles del error que obtuvo el usuario y reproduzca solo esa parte de la sesión de grabación del usuario para ver cómo sucedió en el navegador del usuario.

También puede usar la línea de tiempo SessionStack para reproducir acciones específicas del usuario y detectar problemas de UX desde el principio.

Elija un paso de la línea de tiempo para reproducir.

Hay un plan gratuito que otorga acceso a 50 sesiones de usuario / día que puede comenzar a usar de inmediato.

Descargo de responsabilidad: trabajo en SessionStack.

La solución de gestión de pruebas basada en la nube de Kualitee es una herramienta relativamente nueva, pero tiene algunas características excelentes que ofrecer. Puede gestionar sus defectos y problemas de UX con bastante facilidad y también puede compartirlos con el equipo de desarrollo.

Tiene diferentes análisis para representar diferentes resultados que puede filtrar según sus necesidades. Adjunte diferentes videos e imágenes en su informe de defectos.

Tiene integración JIRA a través de la cual puede sincronizar sus defectos. Puede crear informes de prueba y errores personalizados. Descargue y cargue diferentes informes en el formato que elija. Hay una jerarquía que se mantiene a medida que avanza en su proyecto.

El tablero de mandos es bastante interactivo y diferentes gráficos para la representación de datos y escenarios.

La mejor característica para mí hasta ahora es donde puede crear roles de trabajo personalizados y otorgar permisos a esos roles.

La herramienta también es gratuita para un pequeño equipo de 20 personas.

Precios y paquetes

Puedes consultar las características aquí:

Revisión de características potentes

Los rastreamos en los problemas de Git Hub. Cuando nos comprometemos desde la terminal, mencionamos los miembros del equipo y los problemas de referencia en GitHub.

Tenemos un menú de soporte accesible desde cualquier pantalla de nuestra aplicación que incluye teléfono / chat en vivo / y correo electrónico para que podamos acceder fácilmente. Además de eso, tenemos

Puede crear problemas manualmente utilizando la interfaz web de Git Hub.

Código de compromiso y problemas de cierre

Cada vez que desee hacer referencia a un problema en su confirmación, simplemente agregue un hashtag + número de problema:

  git commit -m "trabajando en el problema # 298, depurando la primera parte del problema".

Si desea cerrar un problema, esto registra automáticamente el compromiso y lo cierra una vez que el compromiso llega a la rama Master:

  git commit -m "corrige el problema # 298 donde el usuario obtuvo el error x en la pantalla y"

Cualquiera de estas variaciones en su mensaje de confirmación cerrará el problema: “Arreglos”, “Corregidos”, “Arreglos”, “Cierres”, “Cerrados” o “Cerrar”

Ver los problemas en GitHub

Puede ver las confirmaciones que hacen referencia a un problema en la página detallada del problema en GitHub. Esto le permite realizar un seguimiento de todos los que se están comprometiendo / comentando sobre el tema.
Puede comentar un problema dentro de GitHub, y verá los comentarios, así como los commits en una discusión en hilo / cronológica.

Trabajando en problemas con otras personas

Puede asignar problemas a un contribuyente particular. Y si necesita hacer ping a un colaborador, incluso puede hacerlo con una mención en su mensaje de confirmación, como este:

git commit -m "@frontendguy2, can you look at issue #298. The javascript is wrecking havoc with my CSS"

Seguimiento de la actividad general del equipo

Puede ver en qué tickets / problemas está trabajando su equipo mirando los últimos commits dentro del repositorio de github y el ‘Pulse’ del repositorio.

¿Eso responde a su pregunta? Puede obtener más información sobre la gestión de problemas de Git Hub aquí:
Problemas de masterización

Corregir errores y problemas de UX en tiempo real es una buena estrategia. Permítanme explicar esto con un ejemplo de una aplicación en vivo.

Supongamos que posee una startup que ofrece suscripciones de café personalizadas. Los clientes ordenan y administran sus mezclas favoritas utilizando su aplicación.

Problema 1: el sistema de seguimiento de pedidos bloquea la aplicación, por lo tanto, los usuarios están muy enojados. Necesitas tomar una acción inmediata.

Problema 2: Mañana es Navidad y de repente piensas que un tema de Navidad en tu aplicación deleitará a los usuarios. Pero no le queda tiempo para lanzar una nueva versión.

¿Cómo va a resolver estos problemas por la noche?

Es por eso que necesitamos integrar nuestras aplicaciones con las herramientas adecuadas. Utilizamos herramientas como Crashlytics y Hansel en nuestras aplicaciones.

Estos nos permiten resolver errores o problemas de UX en tiempo real.

Puede comprender los problemas con errores y sus soluciones en detalle leyendo este artículo http://blog.devathon.com/how-to- …