Hace casi tres meses, con Jean-Francis Ochs , hicimos una simple observación: en muchas misiones, el problema no proviene inmediatamente de la solución técnica. Comienza mucho antes, cuando la necesidad debe ser comprendida, cuestionada y formalizada.
01Un problema encontrado en muchas misiones
Con cada nueva misión, nos topamos a menudo con las mismas dificultades: una expresión de necesidad demasiado general, documentos insuficientemente detallados o decisiones importantes que nunca han sido realmente formuladas.
El cliente generalmente conoce su negocio y sabe qué problema quiere solucionar. Por otro lado, no siempre identifica todas las consecuencias de su solicitud: excepciones, roles de usuario, datos necesarios, reglas de gestión, dependencias con las herramientas existentes o incluso los criterios que permitirán que el proyecto se considere exitoso.
En algunos casos, una mejor formulación habría permitido reducir el coste de la misión. También habría evitado parte de la frustración que se siente cuando el equipo descubre demasiado tarde que una solicitud estaba mal redactada, incompleta o interpretable de varias maneras.
Esto no es necesariamente culpa del cliente, de la AMOA o del desarrollador. La necesidad evoluciona naturalmente a lo largo de las discusiones. El problema aparece cuando este desarrollo no está suficientemente estructurado y las zonas grises no se identifican antes del inicio de la producción.
02La búsqueda de una solución
Una vez realizada esta observación, partimos a la búsqueda de una solución capaz de ayudar a los responsables de recolectar y formalizar la necesidad.
Nuestro objetivo no era reemplazar al AMOA, al analista funcional o al director de proyecto. Al contrario, queríamos brindarles una herramienta capaz de fortalecer su trabajo: ayudarlos a hacer las preguntas correctas, identificar la información faltante y profundizar en temas que parecen obvios a primera vista.
Naturalmente, recurrimos a la inteligencia artificial. Un modelo conversacional es particularmente adecuado para este tipo de situación: puede analizar una formulación inicial, solicitar detalles, cuestionar ciertos supuestos y ayudar a estructurar gradualmente la necesidad.
03Un asistente de la AMOA y el analista
La idea de AskLeopold es simple: convertirse en el acompañante de la AMOA o el analista durante toda la fase de alcance.
La herramienta debe utilizarse desde los primeros intercambios, cuando la necesidad aún no está bien definida. Su función es formular preguntas útiles, incluidas aquellas que puedan parecer inquietantes o prematuras:
- ¿Qué problema estamos realmente tratando de resolver?
- ¿Qué usuarios se verán afectados?
- ¿Cuáles son las excepciones a la operación nominal?
- ¿Qué datos se necesitan y quién es responsable de ellos?
- ¿Qué limitaciones técnicas o reglamentarias deben respetarse?
- ¿Cómo mediremos el éxito del proyecto?
Estas preguntas pueden parecer simples. Sin embargo, su ausencia es a menudo la causa de los malentendidos más costosos.
04¿Por qué crear una herramienta real?
Al inicio del proyecto, teníamos dos posibilidades disponibles. La primera consistió en elaborar una guía de buenas prácticas: un método, una lista de preguntas y algunos documentos modelo destinados a los responsables del encuadre.
Este enfoque habría sido más simple y rápido. Sin embargo, tenía una limitación importante: una guía sigue siendo un documento estático. Puede olvidarse, aplicarse parcialmente o no adaptarse al contexto particular de una misión.
La segunda posibilidad era más ambiciosa: desarrollar una herramienta capaz de apoyar verdaderamente al usuario, adaptándose a las respuestas obtenidas y haciendo evolucionar sus preguntas a lo largo del debate.
Como suele ocurrir en nuestros proyectos conjuntos, elegimos el camino más complejo: construir nosotros mismos el producto que nos hubiera gustado utilizar.
05¿Por qué vibe coding?
Desde hace varios años, Jean-Francis y yo realizamos lo que llamamos nuestros proyectos nocturnos y de fin de semana. Se trata de proyectos desarrollados para nosotros o para algunos de nuestros clientes, fuera de los formatos habituales de los grandes proyectos TI.
Su escala rara vez interesa a las grandes ESN. Sin embargo, estas aplicaciones pueden aportar un fuerte valor añadido a las empresas que las utilizan. Suelen responder a una necesidad concreta, con un presupuesto limitado y una fuerte expectativa de rapidez.
AskLeopold Sin embargo, no es un proyecto pequeño. Sin el apoyo de herramientas de desarrollo asistidas por IA, no habríamos tenido la capacidad de producir una aplicación de esta escala solo por las noches y los fines de semana. El proyecto probablemente habría requerido mucho más tiempo, hasta el punto de resultar difícilmente compatible con nuestras otras actividades profesionales.
El vibe coding nos permitió acelerar la producción manteniendo el control del diseño. Pudimos definir la arquitectura, formalizar las reglas de desarrollo, controlar las elecciones técnicas y orientar a los agentes hacia el producto que teníamos en mente.
El punto importante es este: no le pedimos a una IA que decidiera por sí sola en qué debería convertirse AskLeopold. Le dimos un marco, requisitos, una visión de producto y un método de trabajo.
06Tres meses para hacer realidad la idea
En tres meses pasamos de una observación compartida a una aplicación disponible online. Tuvimos que transformar una idea general en un viaje de usuario, organizar el funcionamiento del asistente, estructurar el proyecto y construir una interfaz lo suficientemente simple como para no agregar complejidad a una fase de encuadre que a veces ya es mucha.
El desarrollo asistido por IA nos ha permitido reducir significativamente el tiempo necesario para la implementación. También nos dio la oportunidad de iterar rápidamente: probar un enfoque, evaluarlo, cuestionarlo y luego mejorarlo sin esperar varias semanas entre cada versión.
Estamos orgullosos de haber llevado este proyecto a una primera versión utilizable en solo tres meses. Esto no significa que el trabajo esté hecho. Un producto continúa evolucionando a través del contacto con sus usuarios, sus prácticas y su retroalimentación.
Sin embargo, estamos convencidos de que una herramienta como AskLeopold puede cambiar la forma en que ciertos equipos abordan sus proyectos. No porque reemplazaría su experiencia, sino porque les ayuda a dedicar más tiempo a las preguntas correctas antes de que las respuestas incorrectas se vuelvan costosas.
07¿Y ahora?
El siguiente paso es confrontar AskLeopold con más situaciones de la vida real, escuchar a los usuarios y mejorar gradualmente su soporte.
Queremos que la herramienta siga siendo sencilla de utilizar, exigente en su cuestionamiento y útil tanto para profesionales experimentados como para personas que ocasionalmente tienen que formalizar una necesidad.
El punto de partida sigue siendo el mismo: unas cuantas buenas preguntas formuladas en el momento adecuado pueden evitar semanas de desarrollo innecesario.
Comentarios
0 comentariosTodavía no hay comentarios publicados. Sé el primero en participar.