Proyecto y producto de software

Proyecto y producto de software: dos compromisos distintos

Quien busca proyecto y producto de software suele intentar separar dos palabras que se usan como si fueran sinónimos. Un proyecto de software es un trabajo acotado: tiene un alcance, una fecha límite, un presupuesto y un momento en el que se da por terminado. Un producto de software es algo que la gente sigue usando, así que no tiene un final natural. Se juzga por si sigue resolviendo un problema para un público definido.

Ambos son legítimos. Una migración interna, una integración puntual o la web de una campaña suelen gestionarse mejor como proyecto. Una herramienta a la que los clientes vuelven cada semana es un producto, aunque empezara siendo un proyecto. Los problemas aparecen cuando un equipo trata uno como si fuera el otro: lanzar un producto con hábitos de proyecto, o enterrar un trabajo corto bajo rituales de producto que no necesita.

Qué cambia cuando lo llamas producto

La etiqueta decide qué significa 'terminado'. En un proyecto, terminado es entregar lo acordado en la especificación. En un producto, la entrega es el inicio de la evidencia: descubres si el problema era real, si la interfaz es usable y si la gente vuelve. Por eso los elementos de la hoja de ruta pasan a ser hipótesis y no promesas.

También cambian la responsabilidad y el coste. Un producto necesita a alguien responsable después del lanzamiento para el soporte, las correcciones de accesibilidad, las actualizaciones de seguridad y las pequeñas mejoras. Si nadie va a asumir ese trabajo, es más honesto plantear el esfuerzo como un proyecto con una fecha clara de traspaso o retirada que llamarlo producto y dejar que se deteriore.

• Proyecto: el éxito es entregar el alcance acordado a tiempo y dentro del presupuesto
• Producto: el éxito es un cambio medible para un público concreto, mantenido en el tiempo
• Ambos: una descripción escrita del problema y de quién lo tiene

Empieza por la claridad del problema y luego lanza en pasos pequeños y comprobables

Lo llames como lo llames, el primer artefacto debería ser una descripción del problema breve y refutable: quién tiene dificultades, con qué, cómo se las arregla hoy y qué mejoraría de forma visible. Si no puede escribirse en unas pocas frases, el alcance todavía no es lo bastante claro para estimar un proyecto ni para justificar un producto.

Después, adapta lo que construyes a la pregunta que necesitas responder. La guía de IVRYN sobre prototipos, MVP y pruebas de concepto los distingue por su propósito: un prototipo explora la experiencia y si la gente la entiende, una prueba de concepto pone a prueba una única hipótesis de viabilidad técnica, y un MVP es un lanzamiento acotado en el mundo real que genera evidencia. La guía deja claro que un MVP desplegado no demuestra por sí solo adopción, ingresos ni encaje producto-mercado. Elegir el artefacto equivocado desperdicia esfuerzo, por ejemplo pulir un MVP cuando la pregunta abierta es si se puede acceder siquiera a una fuente de datos.

Los lanzamientos pequeños mantienen honestos tanto los proyectos como los productos. Cada lanzamiento debería cambiar una sola cosa observable, de modo que un resultado decepcionante apunte a una causa y no a un montón de cambios simultáneos. 'Mínimo' nunca significa desprotegido: la guía señala que un MVP sigue necesitando autenticación, privacidad, accesibilidad, gestión de errores, monitorización y recuperación siempre que su contexto lo exija.

La accesibilidad y los resultados forman parte de la definición

Un producto que algunas personas no pueden usar tiene un público más pequeño del que supone su hoja de ruta. El acceso por teclado, un contraste legible, etiquetas claras y formularios que explican los errores merecen planificarse desde el primer lanzamiento; como orientación general y no como dato medido, añadirlos más tarde suele afectar a una parte mayor de la interfaz. WCAG 2.2, que la guía de IVRYN incluye entre sus fuentes principales, ofrece una referencia reconocida para estas comprobaciones. Trátalas como criterios de lanzamiento junto a las pruebas funcionales.

Los resultados medibles completan el cuadro. Elige una o dos señales ligadas a la descripción del problema, como las tareas completadas sin ayuda o la proporción de usuarios que vuelven para la misma tarea, y decide de antemano qué resultado significa continuar, cambiar de rumbo o parar. Los totales como los registros rara vez muestran si el problema se está resolviendo.

Ejemplo: ¿esta herramienta de reservas es un proyecto o un producto?

Este es un ejemplo hipotético, no un caso en el que IVRYN haya trabajado. Un equipo de tres personas de una pequeña red de clínicas quiere un software que evite que las salas se reserven dos veces. La persona fundadora ve un producto que vender a otras clínicas; la responsable de operaciones ve un proyecto interno.

Al recorrer la checklist de abajo, el equipo descubre que el problema está claro en sus propios centros pero no verificado en otros. Un camino sensato es desarrollar la versión interna como un proyecto de alcance cerrado, y tratar la demanda externa como una hipótesis de producto que se explora con un prototipo mostrado a unas pocas clínicas más. Solo si estas describen el mismo problema, y alguien está dispuesto a responsabilizarse de la herramienta a largo plazo, pasa a ser un MVP: un único recorrido de reserva acotado, lanzado a usuarios reales, con la autenticación, la privacidad, la accesibilidad, la gestión de errores, la monitorización y la recuperación que exige una gestión de citas vinculada a pacientes, y una decisión concreta que la evidencia ayudará a tomar.

• ¿Podemos describir el problema, el público y la solución provisional actual en tres frases?
• ¿Hay una fecha de fin natural o la gente dependerá de esto de forma indefinida?
• ¿Quién se encarga del mantenimiento, el soporte y la accesibilidad después del primer lanzamiento?
• ¿Qué es lo más barato que podemos construir para responder a nuestra pregunta actual: prueba de concepto, prototipo o MVP?
• ¿Qué una o dos medidas mostrarán que ha funcionado y qué resultado significa parar?

Límites de este consejo y cómo lo plantea IVRYN

IVRYN, un estudio de París que funciona de forma independiente, gestiona cada uno de sus productos como una oferta distinta, con su propio dominio, sus propios usuarios previstos y su propia página. Su metodología pública describe cómo construye, verifica, opera y explica los productos, y fija el estándar de evidencia que deben cumplir sus notas de caso, con preferencia por un alcance ajustado y una automatización que siga siendo responsable. Este artículo se basa en esa postura y en la guía citada; no presenta estudios, trabajos para clientes ni resultados medidos, porque aquí no se afirma ninguno.

La orientación es deliberadamente general. Los sectores regulados, las condiciones contractuales de entrega, las normas de contratación y el software crítico para la seguridad pueden imponer requisitos que prevalecen sobre cualquier planteamiento de proyecto o producto, y esas cuestiones corresponden a asesores cualificados. Usa la checklist para estructurar una conversación, no para sustituir una revisión especializada.