Del proceso al producto: qué definir antes de escribir código

En nuestra experiencia, la mayor parte del costo de un proyecto de software se decide antes de escribir la primera línea de código: en lo que se definió, en lo que se supuso y en lo que nadie preguntó. Un proceso de negocio no se convierte en producto por describirlo; se convierte cuando alguien decide qué problema resuelve, para quién, con qué reglas, con qué datos y qué queda fuera. Esta guía recorre las diez definiciones que hacen esa conversión posible.

Definir no es escribir un documento de requerimientos

Una lista de funcionalidades responde «¿qué debe hacer el sistema?». Es una pregunta necesaria, pero llega tarde: presupone que ya se sabe qué problema se resuelve, cómo funciona hoy el trabajo y qué no se va a tocar. Cuando esas respuestas faltan, la lista crece sin criterio y cada funcionalidad parece igual de importante.

Definir es otra cosa: es tomar las decisiones que permiten que una lista de funcionalidades tenga sentido. Y casi todas se toman mirando el proceso, no la pantalla.

Entender: el problema, el éxito y las personas

1. El problema, sin la solución

Escriba el problema en dos frases sin mencionar software. «Necesitamos un portal de proveedores» es una solución; «las órdenes de compra tardan cinco días en aprobarse y nadie sabe en qué paso están» es un problema. La trampa: describir el sistema que se imagina y llamarlo problema.

2. Cómo se sabrá que funcionó

Una métrica, con su valor actual y uno objetivo. Si nadie puede decir qué número cambiaría, el proyecto no tiene forma de terminar bien: solo de terminar. La trampa: medir la entrega («el sistema está en producción») en lugar del resultado.

3. Quiénes participan

Quién usa el sistema, quién lo alimenta, quién depende de lo que produce y quién es dueño del resultado. Cada actor necesita hacer algo distinto. La trampa: diseñar solo para quien pidió el sistema y descubrir en la primera semana de uso a quienes no fueron consultados.

Mapear: el proceso, sus reglas y sus excepciones

4. El proceso tal como funciona hoy

No el proceso del manual: el que ocurre. Incluya los atajos informales, las hojas de cálculo que alguien mantiene por su cuenta y los mensajes que reemplazan a un paso del sistema. La trampa: mapear con quienes dirigen el proceso y no con quienes lo ejecutan.

5. Las reglas de negocio

Quién aprueba qué, con qué límites, en qué orden, según qué criterio. Cada regla con su fuente —política, normativa o costumbre— y su dueño. La trampa: convertir en código una costumbre que nadie decidió conservar.

6. Las excepciones

El caso que «casi nunca pasa» y que ocurre cada semana. Las excepciones definen la complejidad real de un sistema mucho más que el flujo normal. La trampa: construir el caso feliz y resolver las excepciones a mano, para siempre.

Conectar: los datos y las integraciones

7. Los datos

Qué información entra, qué sale, qué se guarda y quién puede verla. Señale los datos personales, financieros o regulados desde el principio. La trampa: suponer que los datos existen y son confiables porque «están en el sistema».

8. Las integraciones

Con qué sistemas tiene que hablar el producto, en qué dirección —leer, escribir o ambas— y quién es dueño del otro lado. La trampa: tratar cada integración como un detalle técnico, cuando suele ser la parte más incierta del costo y del plazo.

Acotar: las restricciones y el alcance

9. Las restricciones

Lo que no se puede mover: plazos, presupuesto, normativa, tecnología existente, personas disponibles. Escritas, para que nadie las descubra en una reunión de seguimiento. La trampa: dejar implícita la restricción que todos conocen, hasta que alguien nuevo no la conoce.

10. Lo que no se construye todavía

La definición más valiosa y la que menos se escribe. Cada idea aplazada, con su razón y con la condición que la traería de vuelta.

Por qué «lo que no se construye todavía» merece su propio capítulo

Todo proyecto acumula ideas razonables: un reporte más, una integración más, una aplicación móvil «ya que estamos». Ninguna es mala. Juntas, convierten una primera versión de pocas semanas en un proyecto que nunca termina de salir.

Escribir lo que queda fuera tiene tres efectos. El alcance deja de crecer por acumulación. Las ideas no se pierden: quedan registradas con la condición que las activaría. Y la conversación cambia de «¿por qué no incluimos esto?» a «¿ya se cumplió la condición para incluirlo?».

Una buena primera versión no es la que tiene más funcionalidades. Es la que resuelve el problema definido en el punto 1 y mueve la métrica del punto 2.

Un ejemplo ilustrativo

Una distribuidora (ejemplo ilustrativo, no un cliente) quiere «digitalizar las órdenes de compra». Al definir, aparecen tres cosas que no estaban en la idea original:

• Una excepción: las compras urgentes se aprueban por teléfono y se registran después. Si el sistema no la contempla, la gente seguirá usando el teléfono y el sistema quedará incompleto.
• Una regla sin dueño: el límite de aprobación por monto no está escrito en ninguna política; lo aplica de memoria el gerente de compras.
• Una integración incierta: el sistema contable admite lectura de proveedores, pero no escritura de órdenes. Eso cambia el diseño y el costo.

Y una decisión de alcance: el portal para que los proveedores consulten sus pagos queda fuera de la primera versión, con una condición escrita para volver a evaluarlo —cuando las órdenes lleven tres meses en el sistema nuevo—. Ninguna de estas definiciones requería escribir código. Todas habrían cambiado el proyecto si se descubrían a mitad de camino.

Errores comunes

• Empezar por las pantallas antes de entender el proceso que van a sostener.
• Pedir una cotización sobre una idea, sin problema, métrica ni alcance escritos.
• Mapear el proceso ideal en lugar del que ocurre.
• Dejar las excepciones «para después».
• Subestimar las integraciones porque «el otro sistema tiene una API».
• No nombrar un dueño del resultado, o nombrar a alguien sin tiempo para decidir.
• No escribir lo que queda fuera, y descubrir el alcance real en la última reunión.