El producto de software y el proceso de software

El producto de software y el proceso de software: dos cosas relacionadas pero distintas

Cuando se habla del producto de software y del proceso de software, se habla de dos cosas diferentes. El producto es lo que las personas reciben realmente: el código en ejecución, la interfaz, los datos almacenados, la configuración, la documentación y el material de soporte. El proceso es el conjunto de actividades y decisiones que producen y mantienen ese producto. Incluye el descubrimiento, el diseño, la construcción, las pruebas, la publicación, la monitorización y la retirada de funcionalidades. Un producto se puede inspeccionar directamente. Un proceso, en cambio, normalmente solo se ve a través de sus efectos.

Separar ambos conceptos es importante antes de actuar. Un equipo descontento con su software podría cambiar el proceso cuando el verdadero problema está en el producto, o al revés. Un nuevo flujo de trabajo no puede arreglar una funcionalidad que nadie necesita. Y una idea de funcionalidad clara seguirá decepcionando si se lanza sin cuidado.

Este artículo está escrito desde la perspectiva de IVRYN, un estudio de producto independiente con sede en París. Los consejos reflejan cómo el estudio documenta su propio enfoque. No se basan en ningún estudio, encuesta ni resultado medido.

Cómo se refleja el proceso en el producto

Las decisiones de proceso dejan huella en el producto. Si las pruebas se hacen solo al final, los defectos llegan a los usuarios en bloque. Si las decisiones de diseño nunca se ponen por escrito, la interfaz se desvía y se vuelve incoherente. Si los lanzamientos son grandes y poco frecuentes, resulta difícil saber qué cambio provocó qué efecto. Visto así, muchas cualidades del producto, como la fiabilidad, la coherencia y la claridad, son en parte resultados del proceso.

Sin embargo, esta relación tiene límites. Un proceso disciplinado puede producir algo que nadie necesita, porque la calidad del proceso no demuestra la utilidad. Un proceso poco riguroso puede producir de vez en cuando una herramienta útil, aunque sea difícil de repetir o mantener. Por eso conviene tratar el proceso como algo que hace que los buenos resultados sean más probables y más fáciles de comprobar. No los garantiza.

Empieza por la claridad del problema antes de elegir un método

El primer paso más útil es poner el problema por escrito con precisión. Indica quién lo tiene, en qué situación, qué hace hoy y qué contaría como una mejora. Si no puedes responder a eso, debatir Scrum frente a Kanban, o monorepos frente a microservicios, es prematuro. La definición del problema decide qué preguntas sobre el proceso merece la pena plantear.

La claridad del problema también indica qué tipo de artefacto construir primero. La guía de IVRYN sobre prototipos, MVP y pruebas de concepto los distingue según la pregunta que responde cada uno. Una prueba de concepto comprueba si algo es técnicamente viable. Un prototipo comprueba si la forma y el flujo tienen sentido para las personas. Un producto mínimo viable comprueba si usuarios reales obtienen valor de una versión funcional, aunque limitada. Confundirlos es una forma habitual en que el proceso perjudica al producto. Por ejemplo, un equipo puede lanzar una demo como si fuera un MVP y luego interpretar el silencio como un rechazo.

Lanzamientos pequeños y verificables e interfaces accesibles

Los lanzamientos pequeños son la conexión más directa entre proceso y producto. Cada lanzamiento debería cambiar una sola cosa que puedas describir y observar. Así, cuando algo mejora o falla, puedes rastrear la causa. Los lanzamientos pequeños también reducen el coste de equivocarse, algo que importa sobre todo al principio, cuando la evidencia es escasa.

La accesibilidad muestra por qué algunas cualidades del producto deben integrarse en el proceso en lugar de añadirse al final. La navegación con teclado, un contraste legible, etiquetas con sentido y mensajes de error claros son propiedades del producto. Solo llegan de forma fiable cuando forman parte de cómo se diseña y se revisa el trabajo. Estándares como las Pautas de Accesibilidad para el Contenido Web del W3C son una referencia práctica, aunque cumplir una checklist no equivale a ser utilizable por todo el mundo. Seguir un estándar es un mínimo, no una meta final.

Medir los resultados del producto sin exagerar

Las métricas de proceso, como tickets cerrados, frecuencia de despliegue o puntos de historia, describen actividad. Los resultados de producto describen si la situación de los usuarios ha cambiado: una tarea completada más rápido, menos errores, un flujo de trabajo abandonado con menos frecuencia. Ambos son útiles, pero solo los resultados te dicen si el producto cumple su función. Elige una o dos medidas de resultado vinculadas a la definición del problema antes de construir, no después.

Ten cuidado con lo que los números pueden respaldar. Grupos de usuarios pequeños, periodos cortos y cambios que se solapan hacen que las conclusiones contundentes no sean fiables. La metodología pública de IVRYN refleja esta prudencia. El estudio prefiere un alcance acotado, una utilidad que se pueda comprobar y una automatización que siga siendo responsable, y evita afirmaciones que vayan más allá de la evidencia. La automatización del proceso, como las pruebas, los pipelines de despliegue o el contenido generado, debe seguir teniendo a una persona responsable de lo que llega a los usuarios.

Ejemplo: una checklist de decisión para un equipo de tres personas

Ejemplo (hipotético): un equipo de tres personas ha creado una herramienta interna de planificación. Los usuarios dicen que es "engorrosa", y el equipo se plantea reescribirla por completo con un nuevo flujo de desarrollo. Antes de decidir, repasan la checklist siguiente. Les ayuda a ver si el problema está en el producto, en el proceso o en ambos.

En este caso hipotético, las respuestas indican que el problema del producto es un paso de reserva confuso. El problema del proceso es que los lanzamientos agrupan muchos cambios, lo que oculta la relación entre causa y efecto. El siguiente paso razonable es un lanzamiento pequeño que corrija el paso de reserva, junto con el compromiso de lanzar un cambio cada vez. Es más barato que una reescritura y más fácil de evaluar.

• ¿Podemos describir el problema del usuario en una frase, indicando quién lo tiene y cuándo?
• ¿Sabemos qué artefacto necesitamos ahora: prueba de concepto, prototipo o MVP?
• ¿Se puede describir el próximo lanzamiento como un único cambio observable?
• ¿Hemos elegido una medida de resultado vinculada al problema y no a la actividad del equipo?
• ¿La accesibilidad forma parte de la revisión de diseño o solo se comprueba antes del lanzamiento?
• ¿Cada paso automatizado tiene una persona designada como responsable de su resultado?
• ¿Nuestra evidencia respaldaría la afirmación que pensamos hacer sobre el resultado?