Antes de escribir historias de usuario, diseñar pantallas o discutir arquitectura, necesito poder explicar tres cosas: cómo funciona hoy la realidad del cliente, qué problema merece ser resuelto y qué estado futuro justificaría construir software. El análisis AS-IS y TO-BE en proyectos de software sirve precisamente para eso: evitar que el equipo salte demasiado pronto de una petición inicial a una solución aparentemente razonable, pero todavía mal fundada.
Mi lectura es que muchos errores serios de producto empiezan aquí: no en el código, sino en la prisa por convertir una petición en solución sin haber consolidado todavía el problema. Sin esa base, el proyecto puede avanzar, sí, pero lo hará sobre supuestos frágiles, decisiones prematuras y una comprensión pobre que después acaba pagando todo el SDLC.
Voy a defender tres ideas muy concretas. La primera: el problema existe antes que el producto y no se deja reducir a una petición. La segunda: entender el estado actual exige documentar cómo se trabaja hoy, qué resultados se obtienen y qué impedimentos reales aparecen. La tercera: sin una imagen del estado futuro que merezca la pena, tampoco puedo decidir bien visión, alcance ni solución.
Primera idea: el problema existe antes que la solución y no cabe entero en una petición
Uno de los errores más frecuentes en proyectos de software consiste en tratar la petición inicial como si ya contuviera el problema bien comprendido. El cliente dice que necesita una aplicación, un portal, una integración o una automatización, y el equipo empieza a discutir pantallas, módulos, plazos y costes. Parece una reacción profesional. En realidad, muchas veces es una aceleración prematura.
Una petición no es todavía comprensión. Como mucho, es una formulación parcial de una necesidad. A veces describe un síntoma. Otras veces arrastra una solución heredada. En muchos casos expresa una intuición legítima, pero todavía no separa con claridad qué duele, a quién le duele, en qué contexto ocurre, cómo se está sobreviviendo hoy a ello y qué cambio justificaría el esfuerzo de construir software.
¿Para qué me sirve reconocer esto? Para no dejar que el proyecto nazca ya mezclando niveles distintos. Si trato una petición como verdad cerrada, confundo observación con decisión, necesidad con implementación y deseo con requisito. A partir de ahí, todo se vuelve más frágil: la visión se redacta sobre una comprensión pobre, el backlog absorbe interpretación no discutida y la arquitectura empieza a pagar decisiones que nadie formuló explícitamente.
Por eso, antes de hablar en serio de producto, yo necesito responder unas pocas preguntas incómodas.
- Situación actual: qué realidad origina la necesidad.
- Actores: quién participa de verdad.
- Consecuencias: qué impacto operativo, económico o de control produce el problema.
- Restricciones: qué límites del negocio, del proceso o del entorno no puedo ignorar.
- Resultado futuro: qué cambio sería valioso de forma observable.
No busco pureza metodológica. Busco sostenibilidad en la cadena que va desde la necesidad hasta el sistema implementado.
Aquí aparece un matiz importante. Entender el problema no implica congelarlo todo ni exigir una completitud imposible antes de empezar. Lo que implica es no inventar conocimiento que todavía no tengo. Cuando hay lagunas, conviene tratarlas como lagunas. Cuando hay conflicto entre versiones, conviene hacerlo visible. Y cuando una parte del problema sigue gris, conviene no vestirla de certeza solo para poder correr.
Mi hipótesis, basada en bastante trabajo de proyecto, es que muchos equipos no fallan tanto por incapacidad técnica como por haber normalizado este salto: del “necesitamos algo” al “ya sabemos qué hacer”. En ese salto se pierden justo las preguntas que más condicionan el valor del producto.
Segunda idea: qué es el análisis AS-IS y por qué exige documentar el estado actual
Una vez acepto que la petición inicial no basta, la conversación correcta cambia mucho. Ya no empiezo preguntando qué pantallas quiere el cliente, sino cómo está operando hoy, qué intenta conseguir, qué resultados obtiene y dónde aparecen los impedimentos. Dicho de otra forma: necesito una visión seria del AS-IS antes de jugar a diseñar el TO-BE.
Esto no es burocracia. Es una forma de separar lo observado de lo imaginado. Cuando documento la situación actual, lo que persigo es entender cómo se está resolviendo hoy el problema, aunque sea de manera manual, torpe, costosa o improvisada. Ahí suelen aparecer dependencias que nadie había verbalizado, excepciones que parecían anecdóticas y reglas de negocio que no estaban en ningún documento, pero sí mandaban sobre el proceso real.
¿Para qué me sirve hacerlo así? Para no construir un producto idealizado sobre una organización inventada. El estado actual me da límites, vocabulario, secuencia operativa y fricción real. También me enseña algo más importante de lo que parece: qué parte del dolor es estructural y qué parte es simplemente ruido o costumbre. Esa distinción vale oro, porque evita sobrediseñar problemas que no merecen una solución compleja.
Cuando trabajo este análisis, suelo necesitar al menos cinco bloques de información.
- Forma de trabajo actual: procesos, herramientas, pasos, actores y dependencias.
- Resultados actuales: tiempos, errores, retrabajos, pérdidas o bloqueos.
- Impedimentos: cuellos de botella, tareas manuales, falta de información, controles deficientes o duplicidades.
- Intentos previos: qué se probó y qué aprendí de ello.
- Lenguaje del dominio: qué términos usa el cliente para nombrar su realidad.
Este último punto, el lenguaje, suele infravalorarse mucho. En cuanto entro de verdad en los procesos del cliente, dejo de trabajar solo con categorías técnicas y empiezo a trabajar con términos del dominio. Si el equipo no captura un glosario vivo, aparecen malentendidos muy baratos al principio y muy caros después. Dos personas pueden usar la misma palabra para cosas distintas o palabras distintas para el mismo objeto relevante. Y cuando eso ocurre, el error no parece grave al principio porque todavía está en conversación; más tarde se vuelve requisito ambiguo, modelo defectuoso o implementación incoherente.
Un ejemplo mínimo
Imaginemos una aplicación personal de gestión al estilo GTD. El usuario dice: “Necesito capturar tareas rápido y luego organizarlas”. Si yo me quedo ahí, lo más probable es que acabe proponiendo una bandeja de entrada, un botón para guardar y una lista para clasificar después. Parece razonable, pero todavía no sé casi nada.
Si estudio el estado actual, quizá descubro que hoy el usuario captura ideas en el móvil, en notas sueltas y en correos que se reenvía a sí mismo. Olvida revisar lo capturado, confunde compromisos con ocurrencias y, en realidad, no necesita solo guardar rápido: necesita vaciar la cabeza sin perder contexto. También puedo descubrir que lo que más le rompe el sistema no es la captura, sino el momento posterior de decidir si algo es proyecto, siguiente acción o simple referencia.
¿Para qué me sirve este ejemplo? Para ver con claridad que la funcionalidad aparente y el problema real no son necesariamente lo mismo. La solución superficial sería una caja de texto. La comprensión útil empieza cuando veo cómo se comporta hoy la persona, qué le falla del flujo actual y qué resultado futuro tendría valor para ella.
Una observación más: documentar el estado actual no significa producir una enciclopedia. Significa producir conocimiento utilizable. Lo suficiente para que el equipo no dependa de memoria informal, intuiciones dispersas o conversación oral para seguir tomando decisiones. Si el material no ayuda a entender, alinear y decidir, entonces no está cumpliendo su función.
Tercera idea: qué es el análisis TO-BE y por qué puede ser un entregable propio
Analizar el presente es imprescindible, pero no suficiente. Si me quedo solo en el AS-IS, puedo describir muy bien el dolor actual y, aun así, no tener criterio bastante para orientar una mejora seria. Necesito también una representación razonable del TO-BE: no una especificación detallada todavía, sino una imagen operativa de cómo debería cambiar la realidad si la organización decidiera intervenir sobre ese problema.
Aquí conviene romper una simplificación bastante dañina. Mucha gente sigue pensando que el análisis del problema, el AS-IS y el TO-BE son solo un paso previo a “lo importante”, que sería implementar. Yo no lo veo así. Hay proyectos enteros de consultoría cuyo cometido no es construir un sistema, sino entender con profundidad una situación, descubrir el estado actual con rigor y formular un estado futuro defendible. Y su entregable final no es una aplicación, ni un backlog, ni una integración. Es precisamente ese TO-BE.
¿Para qué me sirve asumir esto? Para darle a esta fase el peso que merece. En este tipo de proyectos, el cliente no siempre está comprando implementación. A veces está comprando claridad: entender por qué su operación produce ciertos resultados, qué parte del problema es procesal, qué parte es tecnológica, qué parte depende de incentivos, controles o datos, y qué escenario futuro tendría sentido perseguir.
Después de eso, ya decidirá si ejecuta el cambio, si lo aplaza, si lo reduce, si lo reparte por fases o si concluye que no debe hacerlo. Pero esa decisión mejora mucho cuando el TO-BE está bien pensado.
Esto no convierte el TO-BE en literatura estratégica. Lo convierte en un artefacto de decisión. Si está bien hecho, permite evaluar viabilidad, impacto, coste probable, dependencias, riesgos y orden razonable de transformación. Y si está especialmente bien hecho, además sirve como base para una posible implementación futura sin obligar todavía a asumirla.
Aquí es donde el artículo anterior sobre la visión de producto encuentra su sitio natural. La visión no aparece de la nada. Se alimenta de una comprensión consolidada del problema y de una imagen suficientemente clara del cambio perseguido. Si no tengo esas dos piezas, la visión corre el riesgo de sonar bien y gobernar poco.
Artículo relacionado: La visión de producto en software: la guía requisitos, prioridades y arquitectura que documenta la intención del producto.
Un caso real de consultoría sin implementación inmediata
Participé en un proyecto de este tipo para una gran aseguradora. La necesidad no venía formulada como “construidme esta aplicación” ni “quiero este portal con estas pantallas”. El problema de partida era otro: la organización quería mitigar la cantidad de clientes que se daban de baja o no renovaban sus pólizas.
Tenían ya bastante contexto sobre la situación actual. Conocían parte de los escenarios por los que los clientes abandonaban, tenían información operativa relevante y eran conscientes de que la retención necesitaba mejorar. Pero eso no significaba que el problema estuviera suficientemente entendido. Lo que pedían, de hecho, era un análisis más exhaustivo del AS-IS y la definición del TO-BE del sistema que podría ayudarles a mejorar la retención de clientes.
¿Para qué sirve mirar este ejemplo? Para entender que incluso cuando el cliente llega con bastante información, todavía puede faltar la parte más delicada del trabajo: consolidar el problema, separar síntomas de causas, ordenar escenarios, descubrir fricciones reales y formular un futuro defendible. En ese proyecto, el valor no estaba en prometer una solución rápida, sino en producir una lectura más completa del contexto actual y diseñar un estado futuro suficientemente sólido como para permitir una decisión seria.
Eso incluía entender mejor el recorrido del cliente, los puntos en los que se perdía valor, los momentos de fricción en renovación o baja, la información disponible para anticipar riesgo de abandono y las capacidades que debería tener un sistema futuro para intervenir con más criterio sobre ese proceso. El entregable no era todavía el sistema. Era la representación del cambio deseable y posible.
Y aquí hay una lección importante. El hecho de que un proyecto termine en un TO-BE y no en implementación no lo convierte en algo menor o incompleto. En muchos casos es exactamente el nivel de intervención correcto: obliga a entender antes de gastar, a decidir antes de construir y a separar una aspiración genérica de una propuesta de cambio que pueda defenderse con criterio.
Me interesa mucho insistir en una idea: el estado futuro no debe describirse como una promesa abstracta. Debe poder leerse como una hipótesis operativa: si el sistema existiera, qué dejaría de hacerse como ahora.
- Pasos: qué pasos serían distintos.
- Decisiones: qué decisiones ganarían autonomía.
- Dependencias: qué actor dejaría de depender de otro.
- Control: qué control aparecería donde hoy hay opacidad.
Cuanto más concreta sea esa imagen, más útil será después para decidir si debe llevarse a término o quedarse, por el momento, como futurible.
También aquí hay incertidumbre legítima. No siempre puedo proyectar con precisión todo el futuro al inicio del trabajo. Pero incluso cuando el proyecto termina en consultoría y no en ejecución, necesito una dirección explícita. Sin ella, el TO-BE se convierte en deseo vago. No busco adivinar el futuro con exactitud. Busco formular un estado futuro lo bastante claro como para que la organización pueda tomar una decisión informada sobre su siguiente paso.
Cómo usar AS-IS y TO-BE antes del backlog
La consecuencia práctica de todo esto es sencilla: no debería derivar backlog antes de poder explicar el AS-IS y el TO-BE con suficiente claridad. El backlog no es el lugar donde descubro el problema desde cero, sino donde traduzco una comprensión ya trabajada en decisiones, cortes de alcance y trabajo ejecutable.
Cuando esa comprensión falta, las historias de usuario suelen absorber ambigüedad que no les corresponde. Parecen unidades manejables de trabajo, pero en realidad arrastran decisiones de negocio, hipótesis de proceso y supuestos técnicos que nadie ha validado todavía.
Para el equipo
Todo esto tiene implicaciones prácticas muy directas. Comprender el problema no es una tarea decorativa del análisis ni una fase que negocio pueda liquidar y entregar ya masticada al resto. Afecta a cómo trabaja todo el equipo.
- Gestión: da una base más seria para estimar, negociar y detectar cambios de impacto real.
- Análisis: obliga a separar hechos observados de interpretaciones prematuras.
- Diseño: evita proponer experiencias limpias sobre procesos que todavía no entiende.
- Desarrollo: da contexto para no implementar funcionalidades desancladas del porqué.
- Validación: permite comprobar no solo que algo funciona, sino que funciona en la dirección correcta.
¿Para qué me sirve mirarlo así? Para evitar la fragmentación clásica del proyecto, esa en la que cada rol optimiza lo suyo y nadie custodia ya el sentido completo del sistema. Cuando el problema, el estado actual y el estado futuro están razonablemente claros, las conversaciones bajan de ruido y suben de criterio.
Decisiones tomadas
- Tratar la comprensión del problema como base de verdad previa a visión, requisitos, backlog y diseño técnico.
- Exigir una lectura explícita del estado actual antes de legitimar discusiones serias de solución.
- Usar el estado futuro como hipótesis operativa de cambio y no como escaparate funcional prematuro.
- Mantener visible el lenguaje del dominio mediante un glosario que evite interpretaciones silenciosas.
Pendiente decidir
- Qué nivel de formalidad necesita la documentación del AS-IS y del TO-BE según criticidad, tamaño y contexto del proyecto.
- Cuándo basta una representación ligera del proceso actual y cuándo necesito modelado más exhaustivo.
- Qué señales mínimas deberían permitirme afirmar que la imagen del estado futuro es suficiente para empezar a derivar requisitos.
- Cómo gobernar mejor los casos en los que el cliente expresa una solución cerrada antes de haber explicado bien el problema.
Qué hacer ahora
- Revisar el proyecto activo y escribir en una página cuál es hoy la situación actual observada, sin mezclarla todavía con solución.
- Identificar qué resultados se obtienen ahora, qué impedimentos bloquean el cambio y qué lenguaje del dominio falta por fijar.
- Dibujar un estado futuro mínimo que describa cómo debería cambiar el trabajo real si el producto cumpliera su propósito.
- Comprobar si la visión, el backlog o las decisiones técnicas actuales pueden justificarse desde esa lectura y no solo desde peticiones aisladas.
Cierre
Yo no veo la comprensión del problema como un calentamiento previo al trabajo serio. La veo como el primer trabajo serio del proyecto. Ahí decido, aunque todavía no lo parezca, si voy a construir sobre una base defendible o sobre una cadena de suposiciones cómodas.
Por eso me parece un error empezar por la solución. No porque hablar de solución esté mal, sino porque hacerlo antes de tiempo degrada todo lo que viene después: la visión pierde capacidad de gobierno, los requisitos nacen mezclados con interpretación, el backlog absorbe trabajo que todavía no debería existir y la arquitectura acaba sosteniendo decisiones de negocio que nadie formuló de forma explícita.
Mi lectura es bastante simple. Primero necesito entender qué está ocurriendo hoy. Después necesito distinguir qué parte de esa realidad merece cambiar y por qué. Luego necesito proyectar un estado futuro que me permita evaluar si el producto tendría sentido y en qué términos. Solo entonces empieza a ser responsable hablar de solución.
Ese orden no me garantiza el éxito, pero me evita uno de los fallos más caros y más repetidos del sector: construir con aparente diligencia sobre un problema mal comprendido. Y cuando eso ocurre, lo normal no es que el proyecto explote de golpe. Lo normal es algo peor: que avance, entregue cosas y tarde demasiado en admitir que estaba empujando en una dirección equivocada.