Revisar software en funcionamiento

La revisión de software en funcionamiento permite a las partes interesadas del negocio evaluar el comportamiento que realmente utilizarán. Puede revelar malentendidos antes y con mayor claridad que una descripción larga de interacciones hipotéticas. El Product Engineer traduce los comentarios en decisiones acordadas y mantiene el conjunto de especificaciones en consecuencia.

Rol responsable: Product Engineer.
Participantes: Partes interesadas del negocio, usuarios previstos, diseñador de UX cuando corresponda; agente de programación para los cambios posteriores.
Entradas: Incremento funcional del producto, especificaciones de funcionalidades relacionadas, objetivos, limitaciones conocidas, escenarios representativos.
Resultados: Comportamientos confirmados, defectos y problemas de usabilidad registrados, cambios de especificaciones acordados y trabajo de seguimiento priorizado.

1. Elegir escenarios significativos. Pida a las partes interesadas que intenten realizar tareas reales en lugar de limitarse a comentar la apariencia de la interfaz. Incluya flujos habituales y excepciones importantes.

2. Declarar el límite actual. Explique qué funcionalidad está preparada, qué decisiones siguen pendientes y qué queda explícitamente fuera del alcance de la revisión. No presente una implementación inacabada como completa.

3. Observar antes de interpretar. Observe dónde dudan los usuarios, eligen un camino inesperado o encuentran un error. Pregunte qué resultado esperaban. Una queja puede revelar un requisito ausente, un problema de usabilidad o un defecto de implementación.

4. Clasificar los comentarios. Distinga entre (a) comportamiento que contradice la especificación actual, (b) una regla empresarial no expresada previamente, (c) una mejora de usabilidad, (d) una funcionalidad nueva solicitada y (e) un defecto fuera del alcance revisado.

5. Confirmar las decisiones. Obtenga el acuerdo de las partes interesadas correspondientes sobre los cambios del comportamiento empresarial. Registre el cambio aceptado en la especificación pertinente. Consulte a UX o al arquitecto cuando el cambio afecte a patrones de experiencia o límites técnicos.

6. Implementar y volver a revisar. Indique al agente de programación que realice el cambio acordado, evalúe el resultado en funcionamiento y repita la revisión según sea necesario. Mantenga una relación clara de lo que está terminado y lo que aún requiere atención.

Las partes interesadas han evaluado flujos representativos en funcionamiento; los comentarios están clasificados y tratados; los cambios de comportamiento acordados aparecen en las especificaciones; y el producto está listo para pasar a la verificación independiente cuando las iteraciones hayan convergido suficientemente.

Tratar cada sugerencia como alcance inmediato; permitir que los problemas de UX se conviertan en requisitos empresariales contradictorios; editar código sin actualizar las especificaciones mantenidas; y sustituir los comentarios de las partes interesadas por resúmenes de confianza generados por agentes.