Prototipos de software y estudios de viabilidad con IA
EL COSTE DE EXPERIMENTAR SE DESPLOMA
NO SIMPLEMENTE LO MISMO, MÁS RÁPIDO
Durante décadas, el desarrollo de software estuvo marcado por un umbral de entrada alto. Antes incluso de que un producto pudiera juzgarse de verdad, había que estructurar requisitos, preparar decisiones técnicas, diseñar interfaces, levantar arquitecturas y comprometer recursos de desarrollo considerables.
Ese coste actuaba como un filtro. Solo una parte limitada de las ideas de producto imaginables alcanzaba un estado de desarrollo que permitiera un juicio sólido.
El desarrollo asistido por IA modifica ese filtro. No elimina ni la complejidad técnica ni la necesidad de una buena arquitectura. Pero puede acelerar considerablemente la implementación, la generación de variantes, la investigación técnica y la iteración.
Un estado de desarrollo funcional y coherente puede así aparecer bastante antes.
El efecto decisivo no está, por tanto, solo en realizar más rápido los proyectos existentes. Lo que baja es el umbral económico a partir del cual una nueva idea de software o de producto puede estudiarse en serio.
Quien usa la programación con IA solo para programar más rápido aprovecha la parte menor.
La mirada inmediata sobre la programación con IA dice: los proyectos de software existentes van más rápido. Es cierto, pero describe solo una parte del cambio.
Más importante estratégicamente es que aumenta el conjunto de ideas económicamente examinables.
Una nueva aplicación ya no tiene que describirse durante meses únicamente como concepto. Un sistema especializado, un entorno de simulación, un sistema de planificación visual o una nueva idea de producto digital puede tomar forma mucho antes como software coherente.
No se trata, pues, de despachar más rápido la cartera de proyectos existente. Entran en desarrollo ideas que antes no habrían superado el umbral económico de un proyecto informático clásico.
El cambio relevante no está, por tanto, solo en la productividad. Está en un espacio de búsqueda empresarial más amplio.
DE LA DECISIÓN TEMPRANA AL CONOCIMIENTO TEMPRANO
Los modelos de desarrollo clásicos obligan a las empresas a seleccionar pronto. Solo unas pocas ideas reciben presupuesto. Esas ideas se persiguen después bastante lejos, porque ya se han comprometido recursos considerables.
Cuando baja el coste de un desarrollo técnico temprano, ese orden puede invertirse en parte. Más ideas de producto pueden llevarse primero a un nivel técnico real. Solo después hay que decidir qué planteamientos justifican más inversión.
El desarrollo de producto pasa así de una lógica de decisión temprana a una lógica de conocimiento temprano.
Eso no significa producir el mayor número posible de experimentos. Lo decisivo es más bien reducir la incertidumbre allí donde influye realmente en las decisiones empresariales.
Probar más. Aprender antes. Descartar antes los planteamientos débiles. Desarrollar con más tino los fuertes.
En productos nuevos, el pliego de especificaciones es una forma laboriosa de adivinar.
Tradicionalmente, el desarrollo de software se entiende a menudo como la ejecución de una decisión ya tomada. Primero se define qué debe surgir. Después se desarrolla.
En productos nuevos esa separación solo tiene un sentido limitado. Parte del conocimiento decisivo solo surge durante el desarrollo.
Solo una interfaz real muestra si una idea de manejo funciona. Solo datos reales hacen visible si un modelo de datos es adecuado. Solo un núcleo de sistema que funcione muestra si arquitectura, rendimiento y lógica de producto encajan. Solo un sistema utilizable permite estimar de forma realista en qué puede convertirse de verdad una idea de producto.
El desarrollo no produce, por tanto, solo software. Produce información sobre el producto futuro.
En una fase temprana de producto, un estado de desarrollo sólido puede generar más conocimiento que otra ronda de especificación abstracta.
Un prototipo de clics muestra cómo podría verse un producto. Si funciona, no lo muestra.
El carácter experimental de este planteamiento no significa que solo surja software pequeño o provisional.
Lo experimental es la apertura del proceso de conocimiento.
También una aplicación de escritorio técnicamente exigente puede desarrollarse de forma experimental si su propósito es, en primer lugar, poner a prueba de verdad una idea de producto y afinar su dirección durante el desarrollo.
Un estado de desarrollo temprano puede constar ya de varios elementos enlazados: una interfaz real, lógica de negocio, gestión de datos, visualización, persistencia, funciones de importación y exportación, comunicación con sistemas externos o un núcleo técnico sólido.
Con ello el trabajo va bastante más allá de un prototipo visual de clics.
El objetivo es obtener la mayor cantidad posible de realidad de producto sólida en el menor tiempo de desarrollo posible.
Un proyecto que se detiene tras una semana puede ser el más exitoso del año.
No toda idea de producto debería desarrollarse.
Un estado de desarrollo temprano puede mostrar que una idea no se sostiene técnicamente, que se subestimó su complejidad o que el beneficio esperado no justifica el esfuerzo.
Igualmente puede hacerse visible que la solución prevista al principio es innecesariamente complicada, que la vía técnica puede simplificarse o que otra parte de la idea tiene mucho más potencial.
Esos resultados no son un fracaso del desarrollo. Forman parte de su valor económico.
Una decisión temprana y sólida en contra de una idea puede ser mucho más sensata que una corrección tardía tras inversiones cuantiosas.
El valor del desarrollo temprano no está, por tanto, solo en generar nuevos productos, sino también en la calidad de las decisiones que se toman sobre ellos.
Más en vídeo
-
Experiencia × programación con IA →
Quien usa la programación con IA solo para programar más rápido aprovecha la parte menor. -
40 años como palanca →
Productos fotográficos para el consumidor final, como producto en caja. -
Caso · Impact4Sculpt →
Luz, material, movimiento complejo: calculados de antemano con calidad offline. -
Aprender pronto en lugar de fijar pronto →
Muchas ideas de producto nunca fracasaron. -
Caso · IMPACT4IMMERSIVE Runtime →
El mapping sobre cinco proyectores tiene sus propios retos.
Proyectos de ejemplo
3Preguntar sobre esto
EL COSTE DE EXPERIMENTAR SE DESPLOMA