es
Gestión de proyectos, Herramientas
Gestión de proyectos de IA: Por qué crear agentes de IA es un proyecto informático más
Unos meses después de que la IA generativa fuera lo suficientemente práctica como para construir con ella, empezó a ocurrir algo interesante en nuestro lado de FlexiProject: el equipo empresarial, no el de ingeniería. Sin escribir ningún código, de repente teníamos agentes que ejecutaban silenciosamente partes de nuestro trabajo diario: preparar ofertas a los clientes, rellenar los datos de los contratos, extraer Informes de Search Console, actualizar nuestra cartera de productos tras las reuniones con los clientes, ayudarnos a gestionar el sitio web. Construirlos resultó ser la parte fácil. Lo que no esperábamos era que la gestión de proyectos de IA, tratando a cada agente como un verdadero proyecto de software, con un plan, una rama compartida, pruebas y un paso de entrega, importaría tanto como cualquier cosa que nuestros ingenieros hubieran enviado. Esta es la historia de lo que aprendimos, en el orden en que lo aprendimos.
En este artículo aprenderás:
|
Cómo un equipo empresarial empezó a crear agentes de IA
Construir agentes de IA aunque no seamos informáticos
El giro interesante de los dos últimos años es que ya no se necesita un equipo de desarrollo para lanzar una IA que funcione. Una persona de negocios que pueda describir lo que debería ocurrir y copiar algunas entradas de ejemplo, puede construir un agente que haga un trabajo real. No planeamos convertirnos en constructores. Nos encontrábamos con tareas en las que la respuesta era obviamente «esto lo puede hacer un agente», así que empezamos a construir. La primera nos llevó una tarde. La segunda nos llevó una tarde. Entonces empezaron los problemas, no con el edificio, sino con todo lo que lo rodeaba.
Los agentes que construimos
La lista creció más rápido de lo que esperábamos. Tenemos un agente que rellena automáticamente los datos del cliente en nuestros contratos Estándar. Un agente que prepara primeros borradores de ofertas basándose en el resumen de una conversación de ventas. Un integrador que importa la lista de proyectos Excel de un cliente directamente a su entorno FlexiProject. Un asistente que nos ayuda a gestionar partes de nuestro sitio web. Un agente que extrae datos de Google Search Console para nuestro dominio y los convierte en un resumen semanal legible. Un agente que, tras las reuniones con los clientes, actualiza nuestra cartera de productos con lo que determinadas empresas consideran que falta, para que las ideas sobre funciones no se pierdan entre una llamada y la siguiente sesión de planificación. Y docenas de otros más pequeños, ayudantes de una sola tarea que alguien construyó para sí mismo, siguió mejorando y finalmente compartió con el equipo.
Cuando el mismo agente se extendía en paralelo
La fricción no vino de los agentes que construimos una vez y de los que nos olvidamos. Venía de los agentes que realmente importaban. Dos personas cogían un agente útil, cada una tenía una idea distinta de cómo mejorarlo, y empezaban a ampliarlo independientemente. Una semana más tarde, teníamos dos versiones: avisos diferentes, herramientas diferentes conectadas, casos extremos diferentes detectados… y ninguna forma limpia de fusionarlos. Era el mismo problema que los desarrolladores resolvieron hace décadas con Git: no puedes tener a dos personas trabajando a partir de un punto de partida compartido y mejorándolo en distintas direcciones sin un modelo de bifurcación. Simplemente pensábamos que no necesitábamos uno. Los agentes eran «fáciles». La expresión gestión de proyectos de IA aún no había entrado en nuestro vocabulario.
Por qué el desarrollo de agentes de IA es, fundamentalmente, gestión de proyectos informáticos
Construir agentes es trivialmente fácil
La primera lección es la más incómoda: crear un agente es realmente fácil. Cualquiera que lea esto podría abrir un modelo y tener algo funcionando en una hora. La demo parecerá mágica. A los tres primeros usuarios les encantará. Y ése es exactamente el momento en que el proyecto se vuelve difícil, porque enviar una demo no es enviar una herramienta en la que la empresa pueda confiar. La diferencia entre «funciona con los datos que yo he probado» y «funciona con los datos que le envía toda la empresa» es enorme, y el modelo en sí no hace nada por salvarla. Para salvarla está la gestión de proyectos de IA.
Un equipo empresarial que construye agentes de IA tiene que aprender gestión de proyectos informáticos
Cuando un equipo no informático empieza a construir software, y un agente es software, hereda todos los problemas que los equipos de ingeniería han pasado cincuenta años aprendiendo a manejar. Hay que escribir los requisitos. Hay que diseñar la arquitectura. El código, las instrucciones o las definiciones de las herramientas tienen que vivir en algún lugar compartido. Tienen que existir pruebas. Hay que revisar los cambios antes de ponerlos en marcha. Omitir cualquiera de estas cosas no las hace desaparecer; sólo adelanta el coste en el tiempo. La buena noticia es que el libro de jugadas ya existe. Las disciplinas que hacen que los proyectos informáticos tengan éxito se aplican sin cambios cuando un equipo empresarial crea agentes. El único ingrediente nuevo es la evaluación, la versión específica de la IA de las pruebas.
¡Prueba FlexiProject!
El ciclo de vida de un proyecto de agente de IA
1. Análisis inicial: ¿qué problema estamos resolviendo realmente?
Todo agente que merezca la pena construir comienza con una fase de análisis que no tiene nada que ver con la IA. ¿Quién va a utilizar esto? ¿Qué hacen hoy, paso a paso? ¿Cuál de esos pasos duele realmente? ¿Qué aspecto tiene «hacerlo bien», de forma mensurable? Antes de construir el agente de preparación de ofertas, escribimos la secuencia manual exacta que seguía el equipo de ventas, marcamos qué pasos eran repetitivos y cuáles requerían juicio, y sólo entonces decidimos lo que el agente debía y no debía hacer. El análisis llevó más tiempo que la construcción. Esa proporción es normal.
2. Planificación – alcance, integraciones, rama compartida
La planificación es donde decides tres cosas: entradas y salidas, las integraciones que tocará el agente y, lo más importante, dónde vive el trabajo. Si dos personas van a contribuir, necesitan una definición compartida de «principal». Puede ser un documento único con las indicaciones canónicas y las definiciones de las herramientas, un repositorio, una carpeta de habilidades: el formato importa menos que el acuerdo. Elígelo el primer día. Decide lo que el agente no hará, escríbelo y cíñete a ello; el scope creep es la razón más común por la que los agentes se vuelven imposibles de mantener.
3. Desarrollo: la parte engañosamente fácil
La construcción en sí es rápida. Ésa es la trampa. Escribirás las instrucciones, conectarás las herramientas, ejecutarás algunos ejemplos y te sentirás realizado en un 80%. Más bien estás al 30%. El 70% restante es todo lo que aún no has probado: las entradas raras, las entradas largas, las entradas en otro idioma, los casos en que una herramienta devuelve un resultado vacío, los casos en que el usuario cambia de opinión a mitad de la conversación. Nada de esto es visible desde el interior de la construcción.
4. Probar y volver a probar
Aquí es donde los agentes difieren más del software clásico, y donde la mayoría de los equipos toman atajos. Un agente pasa una prueba hoy y puede fallar la misma prueba mañana porque has cambiado una sola línea en el prompt o porque se ha actualizado el modelo subyacente. La disciplina que necesitas es la evaluación de regresión: un conjunto guardado de entradas con comportamientos esperados, ejecutado automáticamente, o al menos sistemáticamente, después de cada cambio. Sin esto, sólo te enteras de las regresiones cuando un usuario tropieza con ellas.
5. Entrega y traspaso
Un agente que nunca se entrega oficialmente es un agente que se convierte en heredado el primer día. La entrega implica escribir la documentación de cara al usuario, definir qué aspecto tiene el éxito en la producción y establecer una forma de controlar si el agente sigue siendo útil tres meses después. Esto lo aprendimos a fuego lento: véase la sección siguiente.
MVP, Agile y Scrum en proyectos de IA
MVP primero – empieza con el agente útil más pequeño
Cada agente que construimos y que tuvo éxito empezó como la versión útil más pequeña de sí mismo. Una tarea. Una entrada. Una salida. Resistimos la tentación de añadir el segundo caso de uso hasta que vimos que el primero sobrevivía al contacto con usuarios reales. Los agentes que tuvieron problemas fueron todo lo contrario: ambiciosos desde el primer día, con tres capacidades ninguna de las cuales funcionó hasta el final. Los agentes big-bang fracasan exactamente por las mismas razones por las que fracasan los proyectos de software big-bang: el factor de forma no cambia las matemáticas. Si sólo te quedas con una regla de este artículo, quédate con ésta: un MVP para un agente de IA es lo suficientemente pequeño como para que una persona pueda describirlo en tres frases y ejecutarlo de principio a fin en un ejemplo real al final de un día. Todo lo demás es iteración.
Por qué Agile encaja de forma natural con los agentes de IA
Los agentes son excepcionalmente adecuados para el trabajo ágil porque son excepcionalmente impredecibles. No puedes especificar completamente un agente por adelantado del mismo modo que especificas un formulario de pago o un informe. Haces una versión pequeña, observas cómo funciona en el mundo real, ves dónde falla y arreglas lo siguiente. Intentar diseñar el agente perfecto sobre el papel antes de construirlo es la forma más rápida de construir el agente equivocado. La iteración no es una preferencia de gestión de proyectos para la IA; es un requisito estructural: el mismo ritmo de Planificar, Hacer, Comprobar, Actuar que Deming describió hace décadas para cualquier proceso que necesite seguir mejorando, sólo que aplicado a agentes cuyo comportamiento no puedes predecir totalmente.
Ejecutar el trabajo de agente en sprints Scrum
Tratamos cada agente significativo como un pequeño flujo de trabajo al estilo Scrum. Hay un backlog de capacidades que el agente podría tener. Cada sprint elige un pequeño número de ellas. La demo del sprint es el propio agente, ejecutado con entradas reales del equipo que lo utilizará. Si la demo no convence, el trabajo continúa; la cadencia fuerza una conversación real entre el constructor y los usuarios, en lugar de una construcción silenciosa de meses de duración.
Errores que cometimos
Construir antes de analizar
Como la construcción es tan rápida, parece eficiente pasar directamente a ella. Pero no lo es. Los agentes que construimos sin un análisis claro acabaron funcionando técnicamente, pero resolviendo el problema equivocado; el equipo que los utilizó fue educado al respecto durante un tiempo y luego volvió tranquilamente a hacer el trabajo manualmente. Una tarde de análisis habría ahorrado una semana de construcción.
Confiar en el modelo para resolverlo
Éste fue nuestro error más constante y el más difícil de desaprender. Suponíamos que si le dábamos al modelo la tarea en lenguaje sencillo, diseñaría una buena solución. A menudo no lo hacía, no porque el modelo fuera débil, sino porque nosotros mismos no habíamos hecho el trabajo de diseño. El modelo no tiene una visión del contexto de tu empresa, de tus datos existentes, de tus convenciones no escritas, del sistema que rodea a la tarea. Cuanto más de eso le des, un análisis real, una arquitectura real, la estructura que quieres que siga, mejor será el resultado. El modelo es excelente en la ejecución. No es tu arquitecto.
Ir a lo grande en lugar de empezar con un MVP
Cada vez que intentábamos lanzar un agente con todas las funciones el primer día, el resultado tardaba más en construirse, era más difícil de depurar y se abandonaba con más frecuencia que las pequeñas versiones que habíamos cultivado deliberadamente. Big-bang parecía más rápido. Pero no lo era.
Dos personas desarrollando el mismo agente en paralelo
Éste fue el momento Git. Dos personas, el mismo agente, ideas diferentes, ramas diferentes en sus cabezas, ningún «principal» compartido. Una semana después, dos versiones que no se reconciliaban. Ahora tratamos cada agente significativo de la misma forma que los desarrolladores tratan el código: una versión canónica, un modelo de ramificación explícito cuando más de una persona trabaja en él, y un paso de fusión explícito. O, si las ideas son realmente divergentes, una decisión deliberada de dividirse en dos agentes separados en lugar de fingir que siguen siendo uno.
Sin documentación inicial – los usuarios no sabían lo que hacía el agente
Los primeros usuarios internos de nuestras habilidades no dejaban de hacer las mismas preguntas: qué hace realmente esta cosa, qué tengo que introducir, qué aspecto tiene la salida, cuándo debo utilizarla frente a la versión anterior. Pensábamos que el agente se explicaba por sí mismo. No lo era. Ahora escribimos una breve descripción orientada al usuario para cada agente en el momento de la entrega: qué hace, con qué hay que alimentarlo, qué esperar, qué no hace. Cuesta diez minutos y evita semanas de uso confuso.
¡Prueba FlexiProject!
Preguntas frecuentes sobre la gestión de proyectos de IA
¿Es la gestión de proyectos de IA diferente de la gestión habitual de proyectos de TI?
Las disciplinas son las mismas: análisis, planificación, construcción, prueba, entrega, iteración. Las diferencias radican en las fases de construcción y prueba: los resultados no son deterministas, el comportamiento puede desviarse cuando cambian el modelo o las instrucciones, y «probar» se convierte en «evaluar un conjunto de casos guardados». Todo lo que rodea a esas fases se parece a un proyecto informático normal.
¿Necesito una herramienta de gestión de proyectos para gestionar el desarrollo de agentes de IA?
Necesitas un lugar donde cada agente viva como un proyecto: con un plan, una versión actual, un propietario y un estado de entrega. Que ese lugar sea un sistema de gestión de proyectos, una wiki o una estructura de carpetas importa menos que tener uno. Para los equipos que ejecutan muchos agentes en paralelo, un verdadero sistema de gestión de proyectos se amortiza rápidamente.
¿Qué tamaño debe tener un agente MVP?
Lo suficientemente pequeño como para que una persona pueda describirlo en tres frases y ejecutarlo de principio a fin en un ejemplo real al cabo de un día. Si no puedes, el alcance es demasiado grande y el MVP es algo más estrecho dentro de él.
¿Cómo evitar que dos personas construyan el mismo agente en paralelo?
No impides que dos personas contribuyan: haces explícito dónde vive la versión canónica, a quién pertenece la fusión y cuándo las ideas divergentes deben convertirse en una bifurcación deliberada en dos agentes separados. La lección de la ingeniería del software se aplica uno a uno: una rama compartida, con un proceso de fusión acordado.
¿Cuándo se convierte en legado un agente?
En el momento en que nadie se encarga de evaluar si sigue siendo útil. Un agente que nadie controla se degrada silenciosamente, el mundo que lo rodea cambia, las entradas evolucionan, el modelo subyacente se sustituye, y un día se equivoca y nadie se da cuenta. El legado no es una edad, es un estado de abandono.
Conclusión
La parte emocionante de construir agentes de IA, el modelo, las indicaciones, el momento en que una demo funciona por primera vez, es la fracción más pequeña del trabajo. Las partes no emocionantes son las que convierten una demo en una herramienta en la que puede confiar toda la empresa: un análisis claro, un plan real, una rama compartida, pruebas de regresión, documentación y un ritmo de iteración que mantenga la utilidad del agente mucho después del envío de la primera versión. Nada de esto es exótico. Es exactamente la disciplina que lleva décadas haciendo que los proyectos informáticos tengan éxito, aplicada sin diluirse a un tipo de software ligeramente más nuevo. Los equipos que adoptan pronto esa disciplina acaban teniendo agentes en los que confían. Los equipos que se la saltan acaban reconstruyendo el mismo agente dos veces. Tratar cada agente como un proyecto real, con un plan que puedes trazar, revisar y mejorar, es lo que significa en la práctica la gestión de proyectos de IA. Lo hacemos en FlexiProject, donde cada agente tiene su propio registro de proyecto con un plan de acción claramente escrito; sea cual sea el sistema que elijas, trata a cada agente como un proyecto, no como un experimento.
AUTOR
Dominik Wrzosek
General Manager at FlexiProject
![¿Qué es un diagrama de Gantt y cómo crearlo? [EJEMPLO]](https://flexi-project.com/wp-content/uploads/2024/04/What-is-Gantt-chart-e1714048900401.png)
