saber que buen software parece.
Se abre el nuevo sistema y todas las funciones están presentes. Pero, ¿puede tu equipo completar un día de trabajo ajetreado sin demoras, correcciones o llamadas de ayuda?
De acuerdo en lo que significa un buen resultado.
La calidad del software comienza con una tarea comercial y la evidencia de que el sistema puede respaldarla. Acuerda el comportamiento esperado, revíselo durante la entrega y sigue revisando las partes importantes después del lanzamiento.
Para un proveedor comercial ilustrativo, “los clientes pueden realizar pedidos” deja muchas cosas abiertas. ¿Puede un cliente encontrar el producto correcto, ver el precio acordado, enviarlo una vez y recibir una confirmación clara? ¿Qué pasa si cambia el inventario o la conexión contable deja de responder?
Esas preguntas se convierten en controles de aceptación. Cybercube ofrece precios fijos para un alcance acordado, por lo que el comportamiento requerido, las condiciones de operación y las comprobaciones deben ser parte de ese alcance. Las características adicionales y los requisitos más estrictos necesitan una decisión explícita sobre el precio y el momento. Un defecto frente al comportamiento acordado es una conversación diferente.
KPI de calidad del software que vale la pena discutir
Un indicador clave de desempeño debería ayudar a alguien a tomar una decisión. Elige medidas que coincidan con la aplicación y registra cómo se recopila cada una. Las cinco áreas siguientes proporcionan un punto de partida práctico; los ejemplos son sugerencias, no resultados de los clientes de Cybercube ni garantías de servicio universal.
Usabilidad: ¿pueden las personas completar la tarea?
Las medidas útiles incluyen la tasa de finalización de tareas, el tiempo de finalización, los errores del usuario, la adopción y el tiempo de capacitación.
Para el portal de pedidos del proveedor, cuente los pedidos exitosos frente a los intentos de pedido genuinos. Decide cómo manejar las sesiones abandonadas, las cuentas de prueba y los clientes que solo estaban navegando. Observa dónde la gente pide ayuda. Un proceso de pago más rápido no es una mejora si el personal debe corregir más pedidos posteriormente.
Disponibilidad: ¿puede la gente confiar en ella cuando sea necesario?
Realiza un seguimiento de la disponibilidad exitosa durante las horas de operación acordadas, la frecuencia de incidentes, el tiempo para detectar una falla y el tiempo para restaurar el servicio. El tiempo medio entre fallas puede ayudar a revelar tendencias de confiabilidad cuando se han registrado suficientes incidentes.
Verifica una acción importante de un extremo a otro, no solo si la página de inicio responde. Si los clientes pueden iniciar sesión pero no pueden enviar un pedido, su flujo de trabajo no está disponible. Define cómo el mantenimiento planificado y las fallas parciales entran en la medida y mantén visibles las duraciones de los incidentes individuales junto con los promedios.
Rendimiento: ¿responde bajo una demanda realista?
Mide el tiempo de respuesta, las operaciones completadas por segundo y la capacidad bajo una carga de trabajo acordada. Registra las experiencias más lentas, así como el promedio: un tiempo de respuesta del percentil 95 describe el tiempo dentro del cual finalizan el 95 % de las respuestas medidas.
Para una búsqueda de stock, especifica el tamaño del catálogo, los usuarios simultáneos y las condiciones de conexión. Compara los resultados utilizando la misma configuración. Una base de datos de demostración vacía dice poco sobre el lunes por la mañana con años de historial de pedidos cargados.
Seguridad: ¿se están abordando las debilidades?
Los indicadores útiles incluyen vulnerabilidades no resueltas por gravedad y antigüedad, tiempo para remediar hallazgos verificados e incidentes de seguridad. Los resultados de la prueba necesitan un propietario designado y un registro de si se verificó la solución.
Un pequeño recuento de incidentes por sí solo no puede demostrar protección; también puede reflejar una detección limitada. Para el portal de ejemplo, verifica que la cuenta de un cliente no pueda recuperar los precios o el historial de pedidos de otro cliente. Mantén la evidencia de esa verificación separada del total general del incidente.
Calidad del código: ¿se puede cambiar el software de forma segura?
Las medidas de ingeniería como la complejidad, el acoplamiento entre componentes y las puntuaciones de mantenibilidad pueden identificar áreas que vale la pena revisar. Revisar los hallazgos y defectos que se repiten después de los cambios agrega contexto útil.
Pídele al equipo que explique las implicaciones comerciales. Si cambiar una regla de precios incumple repetidamente las facturas, esa dependencia merece atención. Las líneas de código o una única puntuación de mantenibilidad no deberían convertirse en un objetivo de productividad ni en una promesa de que los cambios futuros serán fáciles.
Dale a cada medida una definición y un dueño
Antes de agregar un KPI a un informe, escriba:
- Flujo de trabajo: la acción y los usuarios que cubre.
- Método: la fuente de datos, el cálculo y las exclusiones.
- Base: el resultado actual durante un período representativo.
- Objetivo: el resultado acordado y las condiciones bajo las cuales se aplica.
- Respuesta: quién investiga un objetivo perdido y qué sucede después.
Por ejemplo, una verificación de aceptación ilustrativa podría requerir que un usuario de la oficina de representación envíe un pedido válido sin ayuda y sin crear registros duplicados. Una verificación de rendimiento especificaría por separado un objetivo de tiempo de respuesta bajo una carga de trabajo definida. Mantén estas comprobaciones distintas para que una respuesta rápida no pueda ocultar un resultado incorrecto.
Evita llenar un informe con medidas que nadie utiliza. Comienza con las fallas más importantes del flujo de trabajo y luego agregue detalles cuando ayuden a explicar un problema.
Comprobar la calidad durante la entrega
Revisar requisitos y diseños antes de construir. Durante el desarrollo, combine la revisión de código y comprobaciones automatizadas con pruebas prácticas de flujos de trabajo reales. Antes del lanzamiento, solicita a los usuarios comerciales que verifiquen los escenarios de aceptación acordados y registren cualquier problema no resuelto con su impacto y propietario.
La entrega debe incluir la evidencia necesaria para operar la aplicación: resultados de las pruebas, limitaciones conocidas, orientación para el usuario y responsabilidades de soporte. Después del lanzamiento, revisa los KPI seleccionados y prueba los flujos de trabajo afectados cuando se realicen cambios.
Las medidas de entrega, como el progreso del cronograma, el presupuesto y las funciones completadas, responden a una pregunta aparte: cómo avanza el proyecto. Manténgalos visibles junto con las medidas de calidad. Un proyecto puede finalizar a tiempo y dejar frustrante el flujo de trabajo diario.
Del alcance acordado al uso diario Explica las etapas de entrega. Mantener el software útil después del lanzamiento cubre la atención continua. Inicie tu propia discusión sobre calidad con una tarea esencial, tus posibles puntos de falla y la evidencia que necesitaría para aprobarla.