El mayor problema del diseño Agile (y cómo solucionarlo)

La variedad de decisiones y coordinación que se ve en el documental es casi indescriptible, desde planificar cuándo y dónde se filmará cada toma, hasta coordinar el vuelo en helicóptero de un títere animatrónico de 18 pies al lado de un acantilado, hasta revisar cada detalle de cada disfraz y criatura en una fiesta de casino masiva en lo que Rian describió como la toma más complicada en la historia de Star Wars.

Este es precisamente el lugar donde las herramientas modernas de desarrollo de aplicaciones han cambiado el juego para los equipos de software. Plataformas como Adalo, un constructor de aplicaciones sin código para aplicaciones web impulsadas por bases de datos y aplicaciones nativas de iOS y Android—una versión en las tres plataformas, publicadas en Apple App Store y Google Play, permiten a los equipos adoptar plenamente los principios del diseño Agile. A diferencia de los directores de cine o arquitectos que deben comprometerse con una única visión final, los constructores de aplicaciones pueden iterar rápidamente, probar y perfeccionar sus productos basándose en comentarios de usuarios reales.

Además de la cantidad de decisiones que Rian tuvo que tomar, no pude evitar estar impresionado por su confianza en su visión de la película. Antes de que The Last Jedi fuera lanzada, Mark Hamill, quien interpreta a Luke Skywalker, estaba completamente en contra del enfoque de Rian sobre su personaje, diciendo que "fundamentalmente está en desacuerdo con prácticamente todo lo escrito sobre Luke". Y esta tensión permea el documental. Pero a pesar de los intentos de Mark para cambiar su opinión, Rian se mantuvo firme. Su visión general de la película fue sólida como una roca.

¿Entonces qué tiene que ver el impresionante esfuerzo de Rian para hacer una película de Star Wars con el diseño Agile?

Bueno, después de ver todo el proceso de diseño de una película importante, quedó bastante evidente cuán diferente es ese proceso de lo que sucede en la mayoría de las empresas de tecnología hoy en día. En software, tienes la oportunidad de iterar con típicamente pocos plazos irrevocables y la oportunidad de decidir qué construir a continuación sobre la marcha. La mayoría de los equipos crean un producto mínimo viable y luego hacen mejoras basadas en comentarios. Esto es muy diferente de los equipos de diseño en una película importante trabajando hacia un único plazo final donde revelan el producto completo a todos al final, y con ese plazo, sin posibilidad de hacer cambios o actualizaciones posteriores.

Después de esta realización, estuve tentado a concluir que el proceso de diseño de películas simplemente está rezagado y que necesitan seguir un proceso de diseño más Agile; pero cuando pensé en mis experiencias previas como arquitecto, pude ver restricciones similares. Los arquitectos, al igual que los directores de cine, también tienen que diseñar hacia un único plazo. En arquitectura, no hemos llegado al punto donde sea lo suficientemente barato construir solo una pequeña porción del edificio, ver si a la gente le gusta, y luego construir el resto. Y en la industria cinematográfica, no es posible lanzar una película al público, ver qué piensan, y luego hacer mejoras. Una vez que la película está fuera, está fuera. Y una vez que el edificio está levantado, está levantado.

Esto me hizo pausar. Si consideramos películas excelentes y grandes obras de arquitectura como algunos de los mejores diseños de todos los tiempos, pero aún así no fueron creados con un proceso de diseño Agile, entonces tal vez hay algo que aprender de esto. Dicho de otra manera: ¿qué aspectos positivos del proceso de Rian no están presentes en la mayoría de los procesos de diseño Agile?

Mirando el proceso de Rian, la respuesta es bastante clara: Más a menudo que no, los equipos de software no tienen la visión inquebrantable del producto final, como vimos que tuvo Rian para The Last Jedi. Esta falta de pensamiento de panorama general—combinada con la capacidad de cambiar de dirección durante todo el proceso de diseño—es el mayor problema con el diseño Agile hoy en día. Estamos abrumados y desorganizados.

No solo tomes mi palabra. Ryan Singer, jefe de estrategia de producto en Basecamp, recientemente recibió mucho apoyo en Twitter por este tuit:

Empresa típica de software: 1. Atraso de cosas que alguien decidió que el equipo debería hacer -> 2. Rol de "Producto" que es realmente solo un gerente de proyecto -> 3. Diseñadores y programadores sobrecargados con trabajo mal definido a los que se les pide trabajar más rápido y más rápido en lugar de de manera más inteligente. - @rjs

Lo que Ryan está describiendo es el proceso de diseño demasiado familiar donde escuchamos cualquier comentario que oigamos e intentamos resolver cada problema. Un cliente importante tiene una solicitud de función, así que la agregamos al atraso. Alguien del equipo de ventas piensa que necesitamos otra función para competir con un competidor, así que la agregamos al atraso. Nos damos cuenta de que hay un problema de usabilidad con una función anterior que desarrollamos, así que… la agregamos al atraso. Y lo aterrador es que todas estas funciones están en diferentes partes del producto, lo que lleva a funciones apresuradas e insatisfactorias en muchas direcciones diferentes.

Ahora puedo escuchar a los defensores de lean por ahí: "¡Pero ese es el punto! Somos capaces de dar a nuestros usuarios exactamente lo que quieren, porque desarrollamos un poco, vemos si 'funciona', y luego desarrollamos un poco más". Y eso es exactamente correcto. Yo también soy un gran defensor de este tipo de pensamiento. Pero el problema es cómo definimos la palabra 'funciona'. 'Funciona' no debería simplemente significar que cumplimos con la solicitud. Necesita ser: ¿nos estamos moviendo en la dirección correcta? Mi punto es que este proceso a menudo carece de una visión general, creando software de Frankenstein en lugar de un producto final cohesivo y pulido.

Es hora de que reconozcamos los inconvenientes de cambiar continuamente de dirección mientras trabajamos a velocidades vertiginosas.

El dilema: ¿es posible tener lo mejor de ambos mundos?

¿Hay una manera para que los procesos de diseño de películas y arquitectura incorporen algunas de las metodologías Agile para obtener comentarios más precisos antes de su lanzamiento final? ¿Y es posible que las empresas de software Agile creen un diseño cohesivo donde todos los detalles apunten a una única visión?

MVP Película y Arquitectura Agile

Mirando los avances en tecnología, no solo es posible, sino que ya estamos comenzando a ver indicios de que suceda en las industrias de cine y arquitectura. Estos equipos de diseño están comenzando a incorporar metodologías Agile para obtener comentarios mejores. Para películas importantes, algunos equipos están comenzando a animar porciones de la película antes de filmar la toma real; y pronto este concepto se llevará más lejos. Podrán animar rápidamente la película completa—con voces en off y todo—para ver qué tomas necesitan y qué tomas podrían cortarse antes de que se construyan siquiera los decorados.

Y en arquitectura, la realidad virtual ahora permite a los arquitectos crear renderizaciones para mostrar diseños desde todos los ángulos. Y pronto esto progresará al punto donde los arquitectos crearán el edificio completo en RV para que los clientes puedan subirse a una cinta de correr omnidireccional, caminar alrededor de todo el edificio e interactuar con todos los demás en el espacio.

Software de Panorama General

Para software, nuestro problema es lo opuesto. Durante décadas, hemos sido capaces de cambiar direcciones rápidamente, pero esto ha estancado el pensamiento sobre el producto desde una perspectiva de panorama general. Afortunadamente, está completamente en nuestro poder cambiar eso.

Ada, el constructor de IA de Adalo, te permite describir lo que deseas y genera tu app. Magic Start crea fundaciones de aplicaciones completas a partir de una descripción, mientras que Magic Add agrega funciones mediante lenguaje natural.

Las plataformas modernas asistidas por IA están ayudando a cerrar esta brecha. Magic Start, por ejemplo, genera fundaciones de aplicaciones completas a partir de una descripción simple—dile que necesitas una aplicación de reserva para un negocio de aseo de perros, y crea tu estructura de base de datos, pantallas y flujos de usuario automáticamente. Lo que solía tomar días de planificación ocurre en minutos, liberando a los equipos para enfocarse en su visión general en lugar de perderse en detalles de implementación.

De manera similar, Magic Add te permite añadir funciones a través de solicitudes en lenguaje natural, mientras que X-Ray identifica problemas de rendimiento antes de que afecten a los usuarios. Estas capacidades de IA ayudan a mantener el impulso sin sacrificar el pensamiento de panorama general que separa los grandes productos del software de Frankenstein.

Para arreglar el problema de visión, los equipos de diseño Agile deben:

• Comprometerse con una dirección (¡e incluso tal vez fechas de destino a largo plazo!). Necesitamos objetivos de seis meses, objetivos de un año y un plan de cinco años. Estas visiones generales deben ser compartidas por todos en la empresa. No podemos tener desarrolladores que no entiendan por qué estamos haciendo algo, y no podemos tener miembros del equipo de ventas comprometiéndose con funciones que no forman parte de esa visión futura compartida. Todos necesitan creer en el plan y comprometerse con él.
• Deja de perseguir todos y cada uno de los unicornios dorados que pasan volando. El siguiente paso es realmente seguir ese compromiso. Solo porque hay otra oportunidad que podría ser valiosa no significa que debamos ir por ese camino. Si todos en la empresa están realmente alineados con los objetivos a largo plazo, entonces debería estar claro qué funciones son parte de ese plan y qué funciones son distracciones.
• Crea un proceso para determinar si debes cambiar de dirección. Lo mejor del desarrollo Agile es que si nuestros usuarios no están obteniendo valor de lo que estamos creando, podemos cambiar de dirección. Así que no deberíamos estar creando estos planes a largo plazo sin la capacidad de cambiar de dirección. Esto significa que todos necesitan idear y acordar los criterios para cambiar de dirección. Solo porque algunos clientes importantes quieren algo no significa que debamos hacerlo. Mira la constitución. Su visión general no ha cambiado demasiado, pero hay un plan claro en su lugar para hacer enmiendas.
• Termina los detalles importantes antes de pasar a lo siguiente. Una de las razones por las que películas importantes y grandes obras de arquitectura son grandes diseños es porque sus pequeños detalles sirven a la visión general. En el diseño Agile, estos detalles normalmente se dejan de lado para la siguiente función importante. Pero si nos comprometemos con planes a largo plazo, podemos acertar estos detalles antes de pasar a lo siguiente.
• Celebra los grandes logros. Cuando logramos uno de estos objetivos a largo plazo a tiempo, todos necesitamos celebrar juntos. Ver a todo el elenco de The Last Jedi reunirse para una sesión de fotos final fue increíble. La sensación de orgullo y alegría fue contagiosa e inspiradora. Si no nos tomamos el tiempo para celebrar nuestros logros, entonces corremos el riesgo de caer en una marcha de funciones de la muerte.

Por qué los constructores de aplicaciones modernas permiten un mejor diseño Agile

El proceso de diseño Agile tiene mucho a su favor. La velocidad a la que somos capaces de desarrollar soluciones reales que resuelven problemas reales para personas reales es asombrosa. Pero solo porque estemos siguiendo el proceso de diseño Agile no significa que vayamos a tener éxito. Tenemos que dar un paso atrás y asegurarnos de que nos estamos moviendo en la dirección correcta.

Aquí es donde las herramientas adecuadas marcan una diferencia significativa. Con más de 3 millones de aplicaciones creadas en Adalo y un constructor visual descrito como "tan fácil como PowerPoint", los equipos pueden mantener su visión mientras aún iteran rápidamente. La infraestructura modular de la plataforma se escala para servir aplicaciones con millones de usuarios activos mensuales, sin límite superior, lo que significa que puede comprometerse con una visión a largo plazo sin preocuparse por superar sus herramientas.

A diferencia de las plataformas que cobran según el uso (creando costos impredecibles que pueden descarrilar la planificación a largo plazo), los planes pagos de Adalo incluyen uso ilimitado sin sorpresas en la factura. Esta previsibilidad respalda el tipo de pensamiento comprometido a largo plazo que separa los grandes productos de los dispersos. Cuando sabe que los costos de su infraestructura no aumentarán inesperadamente, puede enfocarse en ejecutar su visión en lugar de reevaluar constantemente sus opciones técnicas.

Los mayores innovadores de todos los tiempos tenían visiones más grandes que cualquier persona para la que estaban diseñando. Es hora de comprometerse con una visión grande y mantenerla, aunque eso signifique decirle a Luke Skywalker que se equivoca.

Preguntas frecuentes

¿Por qué elegir Adalo sobre otras soluciones de construcción de aplicaciones?

Adalo es un constructor de aplicaciones impulsado por IA que crea aplicaciones iOS y Android verdaderamente nativas a partir de una única base de código. A diferencia de los wrappers web, se compila en código nativo y se publica directamente en la App Store de Apple y Google Play Store. Con Magic Start generando bases de aplicaciones completas a partir de descripciones y registros de base de datos ilimitados en planes pagos, obtiene capacidad de nivel empresarial sin complejidad empresarial.

¿Cuál es la forma más rápida de construir y publicar una aplicación en la App Store?

La interfaz de arrastrar y soltar de Adalo y la construcción asistida por IA te permiten pasar de idea a aplicación publicada en días en lugar de meses. La plataforma maneja el complejo proceso de envío a App Store—certificados, perfiles de aprovisionamiento e indicaciones de tienda—para que puedas enfocarte en las características y experiencia de usuario de tu aplicación.

¿Puedo iterar y refinar fácilmente mi aplicación según los comentarios de los usuarios?

Sí, Adalo le permite probar, actualizar y mejorar rápidamente su producto en tiempo real. A diferencia de los directores de cine o arquitectos que deben comprometerse con una única visión final, puede iterar continuamente. Magic Add le permite agregar funciones a través de solicitudes en lenguaje natural, mientras que X-Ray identifica problemas de rendimiento antes de que afecten a los usuarios.

¿En qué se diferencia el diseño ágil de los procesos tradicionales de diseño de cine o arquitectura?

El diseño ágil permite que los equipos de software iteren rápidamente con pocos plazos irrevocables y la oportunidad de decidir qué construir a continuación sobre la marcha. A diferencia de los directores de cine y arquitectos que deben diseñar hacia un único plazo final sin posibilidad de cambios posteriores, los equipos ágiles pueden crear productos mínimos viables y hacer mejoras basadas en comentarios de usuarios reales.

¿Cuál es el mayor problema con los procesos de diseño ágil hoy en día?

El mayor problema del diseño ágil hoy es la falta de una visión inquebrantable del producto final. Los equipos de software a menudo persiguen cada solicitud de función y agregan elementos a un trabajo pendiente interminable sin un plan coherente a largo plazo, lo que resulta en "software de Frankenstein" en lugar de un producto pulido y unificado.

¿Cómo pueden mantener una visión coherente los equipos de software ágil mientras aún iteran?

Los equipos deben comprometerse con objetivos a largo plazo (planes de seis meses, un año y cinco años) compartidos en toda la empresa. Necesitan dejar de perseguir todas las oportunidades, crear criterios claros para cambiar de dirección, terminar detalles importantes antes de pasar adelante y celebrar logros importantes juntos.

¿Cuánto cuesta construir una aplicación con metodología ágil?

El constructor móvil web y verdaderamente nativo de Adalo comienza en $36/mes con uso ilimitado y publicación en la tienda de aplicaciones. Esto se compara favorablemente con alternativas como Bubble (comenzando en $69/mes con cargos basados en el uso y límites de registros) o FlutterFlow ($70/mes por usuario, más costos de base de datos separados). Los precios predecibles apoyan la planificación a largo plazo.

¿Pueden las herramientas de IA ayudar a equilibrar la iteración rápida con el pensamiento de la perspectiva general?

Sí. Las características de IA como Magic Start generan bases de aplicaciones completas a partir de descripciones, liberando a los equipos para enfocarse en la visión en lugar de detalles de implementación. Magic Add le permite agregar funciones a través del lenguaje natural, manteniendo el impulso sin perder de vista la dirección general del producto.

¿Se escalará mi aplicación si me comprometo con una visión a largo plazo?

La infraestructura modular de Adalo se escala para servir aplicaciones con millones de usuarios activos mensuales, sin límite superior. A diferencia de los wrappers de aplicaciones que alcanzan límites de rendimiento bajo carga, la arquitectura de propósito específico de Adalo mantiene el rendimiento a escala, de modo que puede comprometerse con objetivos ambiciosos a largo plazo sin superar su plataforma.