Transforma los prototipos basados en la intuición en herramientas que tu empresa realmente pueda usar

De HBR.org

La IA generativa ha hecho que el desarrollo de un software parezca casi gratis. Una gerente de producto describe lo que quiere, un modelo de IA escribe el código y en una tarde, aparece una herramienta que funciona, impresionando a todos los que la ven.

Como resultado, las empresas y los equipos que antes compraban software a proveedores externos ahora suelen optar por desarrollarlo ellos mismos, atraídos por la rapidez y el bajo costo inicial.

Sin embargo, desarrollar un prototipo funcional es una cosa; convertirlo en una solución confiable que se pueda utilizar en las operaciones cotidianas es otra muy distinta. Pueden surgir problemas que incluso a los expertos les cuesta resolver y los costos continuos de mantenimiento de la herramienta pueden, en última instancia, superar lo que la empresa habría pagado por una solución lista para usar.

Hemos dedicado los últimos dos años a estudiar cómo las organizaciones que optan por desarrollar sus propias soluciones de software enfrentan este desafío, trabajando en estrecha colaboración con 11 empresas de las ciencias de la vida, banca y finanzas, productos de consumo y software, en Estados Unidos y Europa.

Estas empresas siguen tres pasos. Primero, antes de comenzar el desarrollo, evitan la miopía analizando qué partes de la solución puede desarrollar por su cuenta una persona sin conocimientos técnicos y en qué aspectos deben intervenir los expertos. Segundo, para gestionar las dependencias, evitan integrar de manera rígida la nueva solución con otros sistemas centrales. Y tercero, para limitar el alcance, son estrictos en cuanto al número de casos de uso adicionales que aceptan.

Miopía: saber lo que el equipo no puede ver

La IA generativa permite a un experto en el tema crear una solución de software funcional --no solo un prototipo-- al encargarse de las decisiones sobre cómo se estructura la solución.

Si bien esto puede acelerar el proceso de desarrollo y requerir menos experiencia en ingeniería, también crea un punto ciego. Es posible que el equipo que desarrolla la herramienta no sepa cómo está estructurada realmente, cuál será el costo de implementarla ni qué implicará el mantenimiento una vez implementada.

Las herramientas que se ven bien y ofrecen una funcionalidad impresionante son diferentes de una solución que sea extensible y funcione para cada caso de uso. El problema surge cuando la solución debe actualizarse, ya sea para manejar un caso extremo o para evolucionar de alguna otra manera. Debido a que las personas que la crearon nunca aprendieron cómo se armó, no saben qué elementos de la arquitectura deben corregir. Además, los costos aumentan a medida que la solución se expande, se integra con otros sistemas y requiere mantenimiento a medida que cambian los modelos subyacentes, las API y las estructuras de precios.

Los ingenieros expertos están mejor preparados para detectar lo que se les escapa a los desarrolladores sin experiencia. Esto no significa que los equipos sin conocimientos técnicos deban evitar usar la IA para desarrollar; significa colaborar con los ingenieros de software desde el principio --incluso cuando se está programando de manera intuitiva-- para anticipar adecuadamente la verdadera complejidad de la solución que se debe desarrollar. Asegúrate de que participen lo suficiente como para comprender la arquitectura de la solución y de que evalúen el costo real de lo que se necesitará para implementarla a gran escala, antes de que el equipo se comprometa a producirla.

Dependencia: Mantén pocas conexiones

Cada enlace entre la nueva solución y el resto de la empresa genera una obligación. Cada fuente de datos, cada integración, cada proceso posterior que llega a depender de la herramienta es algo que se rompe cuando la herramienta cambia. Cuanto más conectada esté la solución, más costoso será repararla, reemplazarla o retirarla.

Las empresas que desarrollan soluciones de manera eficiente mantienen al mínimo el número de conexiones con otros sistemas. No hay un número correcto o incorrecto en este caso, pero pregúntate cuál es el valor real para la solución de cada conector adicional y si de manera realista supera la complejidad de los requisitos que esa conexión agregaría.

Alcance: cuando las funcionalidades se amplían, los riesgos aumentan

La tentación después de una prueba piloto exitosa de software desarrollado internamente es implementarlo en todas partes: más equipos, más regiones, más casos de uso. Cuando surgen fallas, los nuevos equipos no saben cómo diagnosticarlas ni solucionarlas.

Las empresas (y los equipos) que desarrollan sus propias soluciones deben ser disciplinados en cuanto a quiénes son los usuarios principales y evitar la expansión del alcance. El principio consiste en definir a qué usuarios y necesidades servirá una solución antes de que la prueba piloto tenga éxito y después mantener ese límite cuando una herramienta que funciona tiente a todos a ampliarlo.

Sin embargo, eso no significa que los beneficios deban limitarse a un solo equipo. En lugar de expandir una solución exitosa para atender a más usuarios y propósitos, las empresas pueden usarla como modelo para que otros equipos desarrollen soluciones de alcance limitado para los problemas que ellos mismos enfrentan. En otras palabras, escalen el enfoque, no la solución.