La intención del cliente en el desarrollo de software es mucho más que una idea inicial o una conversación de arranque: es la referencia que debería gobernar requisitos, arquitectura, backlog, validación y cambio. Cuando esa intención se interpreta mal, se rellena con suposiciones o se diluye entre prisas y actividad, el equipo puede avanzar mucho y aun así construir el sistema equivocado.
Construir productos ajustados a la intención con la que un cliente inicia un proyecto parece obvio. Sin embargo, en muchos equipos esa intención se diluye en cuanto empieza la presión real: fechas comprometidas, tareas abiertas, expectativas internas, conversaciones incompletas y decisiones tomadas demasiado pronto.
Todos los miembros de un equipo y todos los roles involucrados en el desarrollo de software deberían tener claro que el objetivo no es cerrar tareas o historias en Jira, enseñar pantallas ni proteger una fecha prometida a destiempo. El objetivo es conseguir que el cliente reconozca en el producto construido la intención que quería materializar.
Yo parto de ahí porque, si no lo hago, todo lo demás se vuelve decorativo. Puedes tener buen código, despliegues limpios, pruebas automatizadas y una arquitectura aparentemente seria, y aun así entregar algo equivocado. En ese punto no has tenido un accidente técnico: has fallado en la traducción del problema.
Mi lectura es esta: en software, la mayor parte del deterioro no aparece cuando escribimos código, sino mucho antes, cuando empezamos a tratar como verdad una interpretación incompleta, cómoda o políticamente útil de lo que el cliente quería. Por eso conviene fijar pronto la tesis del proyecto, su alcance útil, sus límites y la evidencia que permitirá saber si seguimos construyendo en la dirección correcta.
La primera idea: el proyecto fracasa cuando la intención se deforma, aunque el código funcione
La ingeniería de requisitos existe por una razón bastante menos burocrática de lo que a veces se dice: evitar que el sistema implementado sea una versión incorrecta, parcial o inventada del sistema que se pretendía construir. Ese es el trabajo de fondo. No llenar documentos. No producir ceremonias. Proteger significado.
Aquí conviene ser preciso. El cliente casi nunca entrega su intención en una forma pura, estable y perfectamente articulada. La expresa mediante conversaciones, restricciones, urgencias, ejemplos, miedos, decisiones heredadas y, muchas veces, soluciones prematuras disfrazadas de necesidad. El equipo recibe todo eso y empieza a reconstruir una imagen mental del producto. Ahí empieza el riesgo.
Cuando esa reconstrucción sale mal, el proyecto puede parecer sano durante meses. Hay avance visible, hay demo y hay sensación de movimiento. Pero lo que se está moviendo quizá no va donde debía. Ese es exactamente el peligro: no siempre se nota pronto que estamos construyendo una versión muy pulida de la idea equivocada.
Por eso me interesa mucho menos la falsa separación entre “negocio” y “técnica” que la continuidad entre intención, especificación y construcción. Si en origen se entiende mal el problema y la intención, el resto del sistema solo hereda esa deformación. No buscamos pureza metodológica; buscamos sostenibilidad en la traducción de la intención a un resultado defendible.
¿Para qué sirve entender esto? Para dejar de medir el proyecto por la actividad y empezar a medirlo por la fidelidad. Un equipo muy ocupado puede estar alejándose del objetivo a gran velocidad.
La segunda idea: el cliente decide la intención, pero nosotros debemos hacerla más nítida y más gobernable
Aquí suele aparecer una confusión dañina. Como equipo, muchas veces vemos que la solución que propone el cliente no es la mejor. Eso pasa con frecuencia. El problema empieza cuando convertimos esa observación en una licencia para sustituir su intención por la nuestra.
No creo que nuestro trabajo consista en obedecer sin pensar, pero tampoco en tutelar al cliente como si no tuviera derecho a decidir sobre su producto. Nuestro trabajo serio está en otro sitio: aclarar, tensionar, explicar consecuencias, proponer alternativas y ayudar a que la intención se exprese con más precisión de la que traía al entrar.
Eso cambia bastante la postura profesional. Ya no actuamos como un simple canal de transmisión, pero tampoco como una élite técnica que corrige en silencio lo que considera una mala decisión. Actuamos como responsables de una traducción. Y una traducción rigurosa exige varias cosas.
La primera es distinguir observación de decisión. No todo lo que se oye en una reunión debe convertirse en verdad operativa. A veces estamos recogiendo contexto. Otras estamos capturando hipótesis. A veces estamos ante una preferencia provisional. Mezclar esas capas es una de las formas más rápidas de introducir ruido.
La segunda es no inferir silenciosamente. Cuando falta definición, la respuesta profesional no es rellenar huecos “como seguramente querían decir”. La respuesta profesional es hacer visible la incertidumbre y decidir qué impacto tiene. En algunos casos podremos avanzar porque la duda no compromete la siguiente decisión. En otros, continuar sería construir sobre una ficción.
La tercera es trabajar con una referencia viva de verdad del sistema. No con memoria de pasillo ni con un “yo entendí que…”. No con una cadena de correos donde cada uno recuerda una parte. Me refiero a una base explícita de qué se sabe, qué está confirmado, qué queda fuera y qué sigue abierto. Sin esa referencia, los cambios no se gobiernan: se absorben como se puede.
Esto sirve para evitar que cada conversación reinvente el proyecto, para que el equipo tenga una fuente de precedencia cuando aparecen contradicciones y para que el cliente pueda decidir con conocimiento, no sobre una nube de interpretaciones.
Un ejemplo mínimo
Imaginemos una aplicación sencilla de gestión personal al estilo GTD, que es el caso ligero que uso por defecto cuando no necesito otro dominio. El cliente dice: “Necesito una bandeja de entrada para capturar tareas rápido y luego convertirlas en proyectos o siguientes acciones”.
Parece claro, pero todavía no lo es. ¿Captura rápida significa una sola caja de texto? ¿Permite adjuntos? ¿Se puede clasificar más tarde sin perder contexto? ¿Una entrada puede generar varias acciones? ¿Quién usa esto: una persona sola o un equipo? ¿Hay revisión semanal? ¿Qué ocurre con elementos sin clasificar?
Si el equipo oye “bandeja de entrada” y salta directamente a implementar una pantalla con formulario, ya ha tomado decisiones de producto que nadie ha validado todavía. No porque el formulario esté mal, sino porque ha empezado a convertir una intención borrosa en una solución concreta sin pasar por una capa suficiente de aclaración.
En cambio, si primero separa lo observado, consolida significado, formaliza reglas y solo entonces registra trabajo ejecutable, el proyecto no se vuelve más lento por definición. Se vuelve menos arbitrario. Esta es una diferencia importante.
La tercera idea: requisitos, arquitectura y cambio forman una única cadena de responsabilidad
Una de las trampas más persistentes en nuestro sector es pensar que primero se “descubre”, luego se “diseña” y al final se “programa”, como si esas fases vivieran aisladas y solo se tocaran por cortesía. No funciona así. La intención atraviesa todas las capas, y en cada una puede reforzarse o degradarse.
La arquitectura, por ejemplo, no es una conversación separada del problema. Cuando definimos límites, componentes, interacciones, persistencia, validaciones o mecanismos de integración, estamos fijando qué partes de la intención serán fáciles de sostener y cuáles quedarán penalizadas desde el diseño. Decir que la arquitectura es “solo técnica” suele ser una forma elegante de ocultar decisiones de producto con vocabulario de ingeniería.
Por eso me parece más útil pensar el desarrollo como una cadena disciplinada de transformación:
- Primero observo.
- Después consolido semánticamente.
- Luego especifico con suficiente precisión.
- Después modelo técnicamente.
- Más tarde registro trabajo ejecutable.
- Finalmente implemento, produzco evidencia y valido frente a la verdad vigente.
El valor de esa cadena no está en sonar ordenado, sino en impedir mezclas peligrosas. Si convierto el backlog en sustituto de la especificación, el equipo redescubre la verdad mientras implementa. Si uso el código para decidir lo que no estaba resuelto, dejo de construir y empiezo a improvisar con apariencia de progreso. Y si valoro una entrega solo porque “funciona”, pero no puedo demostrar que funciona como debía, todavía no he validado nada relevante.
Esta forma de verlo sirve para que el proyecto no dependa del desarrollador que más recuerda, del analista con más ascendencia o del cliente que más presiona esa semana.
Cuando la intención no existe todavía con nitidez
Hay otra cuestión que suele tratarse mal: los proyectos donde la intención todavía no está madura. Esto no ocurre porque el cliente sea torpe o perezoso. Ocurre porque hay problemas que solo se entienden de verdad cuando empiezan a hacerse visibles.
En esos escenarios, exigir una definición exhaustiva desde el día uno no es ser riguroso. Es fingir control. Lo correcto es reconocer que estamos en un tramo de descubrimiento y que, por tanto, ciertas piezas del sistema todavía no pueden tratarse como definitivas.
Eso no autoriza a improvisar. Autoriza a cambiar el tipo de trabajo. Un prototipo, una maqueta navegable o una primera implementación parcial dejan de ser “algo rápido para enseñar” y pasan a ser instrumentos para reducir incertidumbre. Pero para que eso no derive en caos, cada iteración debe cerrar algo concreto: qué hipótesis se confirma, qué interpretación se descarta, qué parte entra ya en terreno estable y qué sigue abierta.
Dicho de otro modo, no todo descubrimiento merece continuidad. Si una demo no produce aprendizaje verificable, solo está comprando tiempo emocional.
Implicaciones para el equipo
En un proyecto de descubrimiento, el equipo necesita permiso metodológico para decir tres cosas sin culpa:
- esto aún no es verdad estable;
- esto ya puede tratarse como decisión;
- y esto no deberíamos ejecutarlo todavía.
Sin esa separación, el trabajo temprano entra demasiado pronto en modo producción y luego nadie sabe qué partes eran exploración y cuáles compromiso real.
El cambio es algo normal; lo peligroso es absorberlo sin gobernanza
Incluso cuando la intención estaba razonablemente clara al principio, puede cambiar. Y a veces cambia en el núcleo. No hablo de retoques cosméticos. Hablo de cambiar una regla central, un actor principal, una restricción operativa, un criterio de cálculo o una frontera del producto.
Cuando eso pasa, el peor reflejo posible es tratarlo como una historia más del backlog. Si el cambio altera finalidad, reglas, contratos, validaciones o arquitectura, no estás ante un ajuste menor. Estás ante un cambio de intención o, como mínimo, ante una reinterpretación dominante de esa intención.
Aquí es donde más se nota si el proyecto estaba gobernado o solo coordinado. Si existe trazabilidad entre intención, especificación, modelo técnico, trabajo y evidencia, puedes analizar impacto. Sabes qué piezas se tocan, qué validaciones dejan de valer, qué compromisos de alcance caen y qué nuevas decisiones hay que formalizar. Si no existe esa trazabilidad, el cambio entra por abajo y se manifiesta en forma de parches.
No conviene dramatizar el cambio, pero sí profesionalizarlo. Cambiar de idea no es una traición al proyecto. Es una realidad normal en software. Lo que sí rompe proyectos es pretender que un cambio nuclear cabe gratis dentro de una planificación pensada para otra cosa.
Decisiones tomadas
- Tratar como cambio mayor cualquier modificación que altere finalidad, reglas centrales, actores o criterios de validación.
- Reabrir la capa de requisitos antes de tocar código cuando el cambio afecte al significado del sistema.
- Exigir análisis de impacto sobre alcance, coste, plazo, pruebas y arquitectura antes de absorber el cambio.
- Formalizar una nueva referencia válida del proyecto cuando cambie el objetivo operativo.
Pendiente decidir
- Qué nivel de formalidad necesita el circuito de cambio según tamaño y criticidad del proyecto.
- Qué artefactos mínimos deben actualizarse siempre antes de ejecutar.
- Cuándo una incertidumbre puede convivir con avance y cuándo debe bloquear continuidad.
Esta disciplina sirve para que el equipo no viva en una negociación implícita permanente y para que el cliente no descubra demasiado tarde que llevaba semanas financiando otra cosa.
Fechas fijas y cambios nucleares: la conversación que nadie quiere tener
Aquí conviene dejarse de eufemismos. Cuando cambia la intención en el núcleo del producto, algo tiene que moverse: alcance, plazo, esfuerzo o nivel de riesgo asumido. No conozco ningún mecanismo serio que elimine ese hecho. Lo demás suelen ser disfraces: deuda, compresión artificial de pruebas, documentación inconsistente y cansancio convertido en cultura de compromiso.
Mi hipótesis, basada en bastante observación de proyecto, es que muchas crisis no nacen del cambio en sí, sino de la negativa a nombrar su coste estructural. A veces da miedo parecer poco colaborativo y el equipo intenta absorberlo en silencio. Otras da miedo reconocer que la planificación ya no aplica y se mantiene la misma fecha. En ocasiones da miedo reabrir la conversación con el cliente y el cambio se traduce a una sucesión de tareas pequeñas para que parezca inocuo. Entonces el proyecto se rompe por acumulación de autoengaños.
Ser profesional aquí significa decir algo muy concreto: “Esto se puede hacer, pero ya no estamos hablando del mismo sistema en los mismos términos”. Esa frase no bloquea el proyecto. Lo vuelve gobernable.
Documentar no es producir papeles: es proteger el producto
A estas alturas ya debería estar claro que no defiendo documentación por apego al documento. Defiendo artefactos útiles porque sin ellos la intención no sobrevive al tránsito entre personas, roles y fases. Cuando no queda referencia explícita, el proyecto depende de memoria informal, jerarquía tácita y reconstrucciones a posteriori.
Y eso tiene dos costes:
- uno evidente: aparecen desviaciones;
- otro más sutil: se pierde capacidad para discutir con rigor.
Sin una verdad explícita del sistema, cualquier conflicto se vuelve una batalla entre recuerdos e interpretaciones. Con una base trazable, en cambio, puedes revisar qué se observó, qué se consolidó, qué se decidió, qué se modeló y qué evidencia existe de que el resultado cumple.
La documentación útil, por tanto, no reemplaza la conversación; le da persistencia. Y en entornos con varias áreas, proveedores o equipos, esa persistencia deja de ser deseable para convertirse en condición de supervivencia.
Qué hacer ahora
Para llevar esta idea a un proyecto real, no hace falta empezar con una metodología pesada. Basta con introducir unas pocas prácticas de control que obliguen a distinguir intención, interpretación, decisión y ejecución.
- Escribe en una sola página cuál es la intención validada que hoy gobierna el producto.
- Separa explícitamente qué está confirmado, qué queda fuera y qué puntos siguen en zona gris.
- Verifica que cada bloque de trabajo relevante deriva de una referencia funcional y no solo de una conversación o de memoria.
- Define un circuito mínimo de cambio: petición, análisis de impacto, decisión y nueva referencia válida.
- Revisa si la arquitectura actual sostiene la intención dominante o solo sostiene la solución que salió primero.
- Acuerda qué evidencias demostrarán que lo construido responde a la intención validada, no solo que funciona técnicamente.
La clave está en no permitir que el proyecto avance con verdades implícitas. Lo que gobierna el producto debe poder verse, discutirse, corregirse y validarse.
Cierre
No creo que el norte de un proyecto sea “avanzar por avanzar”. Debemos intentar aportar valor, pero mantener el norte exige conservar la fidelidad entre intención y resultado mientras el conocimiento madura, el sistema se concreta y el contexto cambia. Esa es la responsabilidad real.
Por eso, cuando hablo de requisitos, no hablo de una fase previa al desarrollo. Hablo del mecanismo que evita que el desarrollo se convierta en una traducción defectuosa. Cuando hablo de arquitectura, no hablo de sofisticación técnica. Hablo de la forma que adopta una intención para poder sostenerse. Y cuando hablo de cambio, no hablo de una molestia inevitable. Hablo del momento en que más se pone a prueba si el proyecto estaba gobernado o solo iba tirando.
Si tuviera que resumirlo en una sola idea, sería esta:
No construyo lo que me parece razonable por intuición técnica; construyo la mejor materialización posible de una intención validada, visible y gobernable. Cuando esa intención todavía no está clara, ayudo a descubrirla. Cuando cambia, ayudo a reordenar el proyecto sin fingir que nada importante ha pasado.
Esa, al menos, es la diferencia entre desarrollar software y simplemente producir movimiento.