Tengo una idea de sistema. ¿Y ahora? El camino de la idea al software

Por qué empezar por la pantalla casi siempre es un error

Cuando alguien describe una idea, normalmente describe pantallas: 'hay un registro, un panel, un reporte'. Las pantallas son el resultado visible de un sistema, no su fundamento. Empezar por ellas es como elegir el revestimiento antes de saber cuántos pisos tendrá el edificio.

El fundamento es el problema. Quién lo sufre, con qué frecuencia, cuánto cuesta hoy convivir con ese problema y qué hace la persona actualmente para sortearlo. Mientras esas cuatro respuestas no existan por escrito, cualquier estimación de plazo y precio es ficción.

• Describe el problema en una frase, sin mencionar tecnología.
• Identifica quién paga la cuenta del problema, no siempre es quien usa el sistema.
• Mide el costo actual: horas perdidas, errores, retrabajo, ventas no realizadas.
• Lista la solución improvisada de hoy (hoja de cálculo, WhatsApp, cuaderno). Es tu competidor real.

Cómo validar una idea antes de invertir

Validar no es preguntar si a la gente le gustó. A todo el mundo le gustan las ideas ajenas en una conversación educada. Validar es buscar evidencia de comportamiento: ¿alguien ya gasta dinero, tiempo o atención intentando resolver ese problema hoy?

Existen formas baratas de obtener esa evidencia antes de escribir una línea de código: entrevistas con preguntas sobre el pasado (no sobre el futuro), una página que explique la propuesta y mida interés real, un prototipo clicable, o incluso la operación manual del servicio para los primeros diez clientes.

• Pregunta '¿cómo resolviste esto la última vez?' en vez de '¿usarías una app así?'.
• Prefiere señales con costo: agendar una conversación, dejar una tarjeta, pagar una preventa.
• Haz el servicio a mano antes de automatizar: así aprendes las reglas de negocio reales.
• Anota las objeciones. Se convierten en requisitos.

Qué viene antes: ¿prototipo, arquitectura o programación?

El orden sano es: comprensión del problema, prototipo de bajo costo, decisiones de arquitectura difíciles de revertir y, por último, implementación. Fred Brooks, en su reflexión clásica sobre proyectos de software, ya advertía que agregar personas a un proyecto atrasado lo atrasa aún más, lo que refuerza que planificar temprano cuesta menos que corregir tarde.

No toda decisión debe tomarse al inicio. La técnica consiste en separar decisiones reversibles (color de botón, biblioteca de gráficos) de decisiones caras de cambiar (modelo de datos, estrategia de autenticación, multi-tenant o no, integración fiscal). Las caras merecen tiempo; las baratas merecen velocidad.

Requisitos: el documento que evita el 80% de las peleas

Un requisito no es una lista de funcionalidades. Es la descripción de lo que el sistema necesita garantizar para que el negocio funcione: quién puede hacer qué, qué nunca puede pasar, qué números deben cuadrar a fin de mes, cuánto tiempo acepta esperar el usuario.

Ian Sommerville popularizó la distinción entre requisitos funcionales (lo que el sistema hace) y no funcionales (con qué calidad lo hace: desempeño, seguridad, disponibilidad). Los proyectos suelen morir en los no funcionales, precisamente porque nadie los escribió.

• Funcional: 'el gestor aprueba un pedido superior a R$ 5.000'.
• No funcional: 'la aprobación debe registrarse con autor, fecha e IP, y el historial es inmutable'.
• Regla de negocio: 'un pedido aprobado no puede editarse, solo cancelarse'.
• Criterio de aceptación: cómo saber, sin discusión, que eso está listo.

El MVP no es una versión coja del producto

El MVP es la versión más pequeña capaz de generar aprendizaje real con usuarios reales. La palabra que importa es 'viable': un MVP entrega valor completo en un camino estrecho, en vez de entregar medio camino en varios frentes.

Una analogía útil: si el objetivo es transporte, un skate funcional enseña más que un cuarto de auto. El error común es confundir el MVP con un producto mal hecho: el alcance es pequeño, pero la calidad de lo que existe debe ser real, incluso en seguridad y datos.

Cuánto cuesta y cuánto tiempo lleva

No existe un precio de tabla para software a medida, por la misma razón por la que no existe un precio de tabla para una obra: el costo es función del alcance, de las integraciones, del nivel de calidad exigido y del riesgo. Lo que sí existe es un método honesto de estimar.

Las estimaciones confiables nacen de un alcance dividido en entregas pequeñas, con rangos en vez de números exactos, y con revisión en cada ciclo. Quien promete un número cerrado antes de entender las reglas de negocio está asumiendo un riesgo que, tarde o temprano, aparece en la calidad.