los clientes y las partes interesadas no quieren sorpresas.
Lo que esperan es claridad, comunicación consistente y transparencia. Quieren resultados, pero también quieren que se mantenga en tierra y se alinee con los objetivos del proyecto como desarrollador o gerente de producto. Igual de importante, quieren una visibilidad total en el proceso.
En esta publicación de blog, compartiré principios y consejos prácticos para ayudar a mantener los proyectos de IA en camino. Estas ideas provienen de más de 15 años de administrar e implementar iniciativas de IA y es un seguimiento de mi publicación de blog “Consejos para establecer expectativas en proyectos de IA”.
Cuando se trabaja con proyectos de IA, la incertidumbre no es solo un efecto secundario, puede hacer o romper toda la iniciativa.
A lo largo de las secciones del blog, incluiré elementos prácticos que puede poner en acción de inmediato.
¡Vamos a sumergirnos!
Abu (siempre actualizar)
En las ventas, hay una regla famosa llamada ABC, siempre se está cerrando. La idea es simple: cada interacción debe acercar al cliente a un acuerdo. En proyectos de IA, tenemos otro lema: ABU (siempre actualizar).
Esta regla significa exactamente lo que dice: nunca deje a las partes interesadas en la oscuridad. Incluso cuando hay poco o ningún progreso, debe comunicarlo rápidamente. El silencio crea incertidumbre, y la incertidumbre mata la confianza.
Una forma directa de aplicar ABU es con un breve correo electrónico semanal a cada parte interesada. Manténgalo consistente, conciso y enfocado en cuatro puntos clave:
Avances en rendimiento o hitos clave logrados durante la semana; Problemas con entregables o cambios en el plan de la semana pasada y que afectan las expectativas de las partes interesadas; Actualizaciones sobre el equipo o recursos involucrados; Progreso actual en métricas de éxito acordadas;
Este ritmo mantiene a todos alineados sin abrumarlos con ruido. La idea clave es que las personas en realidad no odian las malas noticias, simplemente odian las malas sorpresas. Si se adhiere a ABU y gestiona las expectativas semana a semana, crea credibilidad y protege el proyecto cuando los desafíos inevitablemente surgen.
Poner el producto frente a los usuarios
En proyectos de IA, es fácil caer en la trampa de construir para usted en lugar de para las personas que realmente usarán el producto/solución que está construyendo.
Con demasiada frecuencia, he visto a los equipos entusiasmados con las características que les importan, pero significan poco para el usuario final.
Entonces, no asuma nada. Ponga el producto frente a los usuarios lo más temprano y con la mayor frecuencia posible. La retroalimentación real es insustituible.
Una forma práctica de hacerlo es a través de prototipos livianos o pilotos limitados. Incluso si el producto está lejos de terminar, mostrarlo a los usuarios lo ayuda a probar suposiciones y priorizar las características. Cuando comience el proyecto, comprométase a una fecha de prototipo lo antes posible.
No caigas en la trampa tecnológica
Los ingenieros aman la tecnología: es parte de la pasión por el papel. Pero en los proyectos de IA, la tecnología es solo un facilitador, nunca el objetivo final. El hecho de que algo sea técnicamente posible (o se ve impresionante en una demostración) no significa que resuelva los problemas reales de sus clientes o partes interesadas.
Por lo tanto, la guía es muy simple, pero difícil de seguir: no comience con la tecnología, comience con la necesidad. Cada función o código debe rastrear un problema de usuario claro.
Una forma práctica de aplicar este principio es validar los problemas antes de las soluciones. Pase tiempo con los clientes, asigne sus puntos débiles y pregunte: “Si esta tecnología funcionara perfectamente, ¿realmente les importaría?”
Las características geniales no guardarán un producto que no resuelva un problema. Pero cuando ancla la tecnología en necesidades reales, la adopción sigue naturalmente.
Los ingenieros a menudo se centran en optimizar la tecnología o la construcción de características frías. Pero los mejores ingenieros (10x ingenieros) combinan esa fuerza técnica con la rara capacidad de empatizar con las partes interesadas.
Métricas comerciales sobre métricas técnicas
Es fácil perderse en métricas técnicas: precisión, puntaje F1, ROC-AUC, precisión, retiro. A los clientes y las partes interesadas normalmente no les importa si su modelo es 0.5% más preciso, les importa si reduce la rotación, aumenta los ingresos o ahorra tiempo y costos. La peor parte es que los clientes y las partes interesadas a menudo creen que las métricas técnicas son lo que importa, cuando en un contexto comercial rara vez lo están. Y depende de ti convencerlos de otra manera.
Si su modelo de predicción de rotación alcanza la precisión del 92%, pero el equipo de marketing no puede diseñar campañas efectivas de sus resultados, la métrica no significa nada. Por otro lado, si un modelo “menos preciso” ayuda a reducir la rotación de clientes en un 10% porque es explicable, eso es un éxito.
Una forma práctica de aplicar esto es definir las métricas comerciales al comienzo del proyecto – Pregunte:
¿Cuál es el objetivo financiero u operativo? (Ejemplo: reduzca el tiempo de manejo del centro de llamadas en un 20%) ¿Qué métricas técnicas se correlacionan mejor con ese resultado? ¿Cómo comunicaremos los resultados a las partes interesadas no técnicas?
A veces, la métrica correcta no es una precisión en absoluto. Por ejemplo, en la detección de fraude, atrapar el 70% de los casos de fraude con falsos positivos mínimos podría ser más valioso que un modelo que exprime el 90% pero bloquea miles de transacciones legítimas.
Propiedad y entrega
¿Quién es el dueño de la solución una vez que sale en vivo? En caso de éxito, ¿tendrá el cliente acceso confiable en todo momento? ¿Qué sucede cuando su equipo ya no está trabajando en el proyecto?
Estas preguntas a menudo se transmiten, pero definen el impacto a largo plazo de su trabajo. Debe planificar la entrega desde el primer día. Eso significa documentar procesos, transferir conocimiento y garantizar que el equipo del cliente pueda mantener y operar el modelo sin su participación constante.
La entrega de un modelo de ML es solo la mitad del trabajo: la posterior desplegación es a menudo una fase importante que se pierde en la traducción entre negocios y tecnología.
Visibilidad de costo y presupuesto
¿Cuánto costará la solución? ¿Está utilizando la infraestructura de la nube, LLM u otras técnicas que conllevan gastos variables que el cliente debe comprender?
Desde el principio, debe dar a los interesados la visibilidad total de los conductores de costos. Esto significa desglosar los costos de infraestructura, las tarifas de licencia y, especialmente con Genai, los gastos de uso como el consumo de tokens.
Una forma práctica de administrar esto es configurar los paneles o alertas de seguimiento de costos claro y revisarlos regularmente con el cliente. Para los LLM, estimar el uso de token esperado en diferentes escenarios (consulta promedio versus uso pesado), por lo que no hay sorpresas más adelante.
Los clientes pueden aceptar costos, pero no aceptarán costos ocultos o multiCalables. La transparencia en el presupuesto permite a los clientes planificar de manera realista para escalar la solución.
Escala
Hablando de escala ..
La escala es un juego completamente diferente. Es la etapa en la que una solución de IA puede ofrecer el mayor valor comercial, pero también donde la mayoría de los proyectos fallan. Construir un modelo en un cuaderno es una cosa, pero implementarlo para manejar el tráfico del mundo real, los datos y las demandas de los usuarios es otra.
Así que tenga claro cómo escalará su solución. Aquí es donde vienen la ingeniería de datos y los MLOP. Abordar los temas relacionados con garantizar que toda la tubería (ingestión de datos, capacitación modelo, implementación, monitoreo) pueda crecer con demanda mientras se mantiene confiable y rentable.
Algunas áreas críticas a considerar al comunicar la escala son:
Prácticas de ingeniería de software: control de versiones, tuberías de CI/CD, contenedores y pruebas automatizadas para garantizar que su solución pueda evolucionar sin romperse. Capacidades de MLOPS: reentrenamiento automatizado, monitoreo de la deriva de datos y la deriva de conceptos, y los sistemas de alerta que mantienen el modelo preciso con el tiempo. Opciones de infraestructura: Cloud versus local, escalado horizontal, controles de costos y si necesita hardware especializado.
Una solución / proyecto de IA que funciona bien de forma aislada no es suficiente. El valor real se produce cuando la solución puede escalar a miles de usuarios, adaptarse a nuevos datos y continuar ofreciendo impacto comercial mucho después de la implementación inicial.
Aquí están los consejos prácticos que hemos visto en esta publicación:
Envíe un breve correo electrónico semanal a todos los interesados con avances, problemas, actualizaciones de equipo y progreso en métricas. Comprometerse con un prototipo o piloto temprano para probar suposiciones con los usuarios finales. Validar los problemas primero: no comience con la tecnología, comience con las necesidades del usuario. Las entrevistas de los usuarios son una excelente manera de hacer esto (si es posible, salga de su escritorio y únase a los usuarios en cualquier trabajo que estén haciendo durante un día). Defina las métricas comerciales por adelantado y vincule el progreso técnico a ellas. Planifique la entrega del primer día: documente, capacite al equipo del cliente y asegúrese de que la propiedad sea clara. Configure un tablero o alertas para rastrear los costos (especialmente para las soluciones Genai basadas en la nube y el token). Construya con escalabilidad en mente: CI/CD, monitoreo de la deriva, tuberías modulares e infraestructura que pueden crecer.
¿Algún otro consejo que encuentre relevante para compartir? ¡Escribirlo en los comentarios o no dude en contactarme a través de LinkedIn!