¿Qué significa esto para los desarrolladores, diseñadores y directores de proyectos?

Creo que es un gradiente, dependiendo del equipo. Y lo que más estamos viendo en Webflow es eso para los desarrolladores, a pesar de que conceptualmente mucha gente piensa que estamos tratando de sacar a los desarrolladores de un trabajo, ¿verdad? Pero en realidad, lo que está sucediendo es que estamos tratando de automatizar las cosas que son más propensas a la automatización, por lo que los desarrolladores están eufóricos porque ahora pueden trabajar en las cosas difíciles en los problemas realmente interesantes.

Para los diseñadores, los convierte en héroes. Es un superpoder, ¿verdad? Porque ahora están haciendo el trabajo de dos personas. ¡Y se sienten más creativos!

En el caso de los PM, también pueden moverse más rápido. Pueden validar las ideas antes. Pueden probar las cosas con vapor más rápido. Pueden confiar en sus diseñadores y en la fase de investigación, mucho más en lugar de la espera que ocurre con la clásica cascada en la que diseñas algo y luego tienes que esperar a que el desarrollo vaya a implementarlo, o tienes que prototiparlo en código y luego presentarlo de alguna manera a los usuarios.

Muchas veces comienza desde el lado de la operación de la casa. Son estas personas las que, tal vez, tienen un montón de ingenieros que son contratados, pero esos ingenieros a menudo se despliegan contra el producto principal que están construyendo. Es como: "Oye, nuestro trabajo es construir este x de clase mundial. Y esa x es realmente en lo que queremos pasar todo nuestro tiempo". Sin embargo, para dirigir el negocio, necesitamos todas estas otras cosas. Necesitamos un CRM. Necesitamos una herramienta de facturación. Necesitamos email marketing. Necesitamos la gestión de proyectos. Necesitamos todas estas otras cosas, y nuestros ingenieros no suelen ayudar a que esas cosas funcionen mejor juntas.

Los ingenieros se centran en el problema realmente difícil de entregar un producto a los clientes finales. Y así, el funcionamiento del lado comercial de las cosas a menudo es donde la gente de operaciones comienza a entrar y desplegar una pila sin código y hacer que las cosas sean más eficientes, hacer que cada vendedor sea un poco mejor en su trabajo, hacer que esto que solía tomar todo el día o toda la semana suceda instantáneamente.

Los diseñadores de UX tienen la mayor oportunidad, porque son capaces de cerrar esta brecha de: yo lo diseñé, pero ahora tienes que ir a enviar a alguien más para que lo construya o enviar este diseño a otra persona para que lo construya. Son capaces de cerrar ese círculo y casi iniciar negocios de diseño o prácticas de diseño más completos al tener acceso a estas herramientas sin código. Hay tanta similitud entre cómo funciona una herramienta de software sin código y cómo funcionan las herramientas de software de diseño que encuentro que los diseñadores lo aprenden muy rápido.

Para los desarrolladores, creo que es algo genial para ellos. No perderán el tiempo en proyectos que no funcionan. Las personas deberían tener más convicción sobre lo que están tratando de construir antes de hablar con el desarrollador. Además, el 25% de nuestra comunidad son desarrolladores que ven el no-code como una forma de lanzar y validar rápidamente sus propias ideas.

Para los diseñadores, pueden construir cosas en lugar de simplemente decir cómo deberían verse. Ya no tienen que convencer a los desarrolladores para que construyan cosas.

Para los desarrolladores, creo que les va a permitir centrarse en la creación de tecnología central que mueva la aguja y se liberen a sí mismos. Muchas veces, cuando era ingeniero, quería crear productos o sabía que el dueño del negocio tendría que volver. Entonces, para hacer eso, los desarrolladores tienen que pensar en problemas mucho más grandes o en una escala mayor con una mejor granularidad. Creo que hará que el software que crean sea mucho mejor.

Para los diseñadores, creo que va a permitir que los diseñadores se centren más en el contenido en sí que en la estética y el diseño. Entonces, en lugar de tratar de descubrir cómo mezclar y combinar las piezas del rompecabezas, estoy más interesado ahora, como diseñador, en crear cómo se ve el rompecabezas real en lugar de tratar de hacer que todo encaje dentro de las limitaciones de la plataforma.

Creo que los gerentes de proyectos y los propietarios de productos son siempre la persona que hace malabarismos con las prioridades, descubriendo cómo asignar recursos para que la mayor parte de las plataformas principales se realicen de una manera sin código que les permita concentrarse en priorizar las características y compilaciones que ayudan a mover la línea superior y la línea inferior, no solo el tipo de "Oye, tenemos que mantenernos a flote con el tipo de iniciativas".

Creo que lo que siempre he hablado con los desarrolladores es que a los desarrolladores les gusta mucho crear funcionalidades que sean reutilizables, de propósito general y que se puedan usar para muchas cosas diferentes. Así que la mayoría de los desarrolladores que conozco que son realmente hábiles, preferirían escribir un componente de propósito general que pueda ser reutilizado en algún lugar, o una biblioteca de código abierto o algo así, en lugar de escribir esto que solo se usará aquí una vez. Creo que realmente aprovechar los conjuntos de habilidades de los desarrolladores para crear una funcionalidad reutilizable que luego se pueda conectar y aplicar sobre algo como Adalo, que proporciona la funcionalidad estándar básica, es realmente lo mejor de ambos mundos.

Para los diseñadores, va a haber una especie de cambio en el que las líneas se difuminan entre las fases iniciales de diseño, como la fase de diseño hasta el prototipo, pasando por el desarrollo con los desarrolladores, hasta la producción. Si lo que estaba describiendo con los componentes realmente se convierte en realidad, entonces los sistemas de diseño combinados con herramientas sin código significarán que los diseñadores pueden construir el producto hasta cierto punto, y luego conectar las cosas que los desarrolladores están construyendo.

En el caso de los PM, ya no tendrán que pedir permiso, pueden ir a construir algo ellos mismos y luego decir, oye, diseñador, ayúdame a arreglar esto. En lugar de tener que pasar por el canal tradicional de: quiero crear un producto, necesito que un diseñador se suba a bordo, que se sume un desarrollador, que mi jefe autorice este proyecto. Pueden ir a construirlo ellos mismos en un fin de semana y luego mostrarlo. Eso va a transformar totalmente la rapidez con la que las organizaciones pueden moverse porque, a menudo, una de las cosas que más ralentiza a las personas son las dependencias dentro de una organización y la disponibilidad de recursos.

Sé que muchas personas en estos roles podrían comenzar preguntándose: "¿Voy a perder mi trabajo debido a estas plataformas?".  No lo creo, las plataformas sin código están surgiendo porque hay una gran escasez de ingenieros de software, diseñadores y gerentes de producto, y todo el mundo quiere construir. No creo que estos roles desaparezcan, creo que las personas en estos roles siempre serán necesarias para construir algo realmente grande, pero es posible que no sean necesarias para construir algo básico. El futuro del código cero está permitiendo a los desarrolladores y diseñadores centrarse en las cosas en las que son buenos y no preocuparse por las cosas que no valen la pena.

Además, lo que realmente se obtiene con el mundo sin código es una verdadera colaboración, lo que permite a los equipos omitir gran parte del trabajo de "hacer cola en el trabajo" y simplemente hacer el trabajo ellos mismos directamente. En la mayoría de las empresas de software, el 98% de las personas de la organización solo están haciendo cola para que los ingenieros completen el trabajo. Por ejemplo, si estás haciendo un trabajo de diseño, terminas creando historias y especificaciones, y simplemente va a un rastreador para que un ingeniero lo implemente. Eso es tan ineficiente, ¿por qué no implementar los cambios de diseño usted mismo? La verdadera colaboración significa construir juntos. Creo que las herramientas no-code y low-code nos permiten a todos trabajar juntos.

En términos de desarrolladores, creo que esto es como acelerar todo y el no-code, en muchos sentidos, es el arranque de tratar de hacer algo. No significa necesariamente que vaya a ser tu producto final lo que estés haciendo. Pero va a ser mucho más rápido sacar esa estructura que vas a ser capaz de tocar más, hacer más, y tal vez probar algo que de otro modo te habría llevado mucho tiempo aprender.

Con los diseñadores, creo que el no-code ha sido un movimiento increíblemente empoderador para ellos. Como, por ejemplo, yo mismo, vengo de un entorno de diseño y me encantó poder hacer estos diseños tan bonitos y completos en mi ordenador, pero no respiraban. Hay algo un poco especial en ver cómo se desarrollan esos movimientos, cómo se desarrollan las interacciones reales, y a veces apesta tener esto y no poder comunicarlo completamente o quedarse atrás cuando intentas que cobre vida. Así que creo que las herramientas sin código realmente han hecho que los diseñadores estén sobrealimentados cuando se trata de poder animar muchas de las cosas que están haciendo, hacerlas en vivo, crear sitios web, aplicaciones web, mercados; Son tantas las cosas que han hecho.

Con los PM, o miembros no técnicos en los equipos, se ha abierto totalmente no solo en más formas para que puedan dar vida a los MVP, ensuciarse las manos en las cosas, sino también generar empatía hacia otras personas de su equipo. Personalmente, encuentro que al sumergirme en las herramientas sin código, en realidad he aprendido más sobre la lógica, las expectativas y las complejidades detrás de lo que estoy pidiendo, lo que me ha hecho, creo, más empático como líder, pero también en términos de cómo gestiono o espero lo que se puede lograr en el alcance.

El PM que obviamente necesita algo del desarrollador o del diseñador podría marcar una serie de tareas pendientes por su cuenta. Cualquiera de las personas que técnicamente no se supone que estén haciendo esos cambios podría estar haciendo esos cambios.

[Ben] Creo que esto realmente depende del liderazgo de un espacio a otro. Creo que hay muchos desarrolladores que ven la ventaja ahí. [Escucharé cosas como]  "Solo quiero que sepas que encontré Webflow y, Dios mío, como lo que ha hecho por mí, en lugar de tener que pasar todo este tiempo trabajando en micro interacciones, puedo volver a lo que está sucediendo en el back-end y pasar más tiempo allí".

Lo mismo ocurre con los diseñadores y los gestores de proyectos. Para que un diseñador no solo te muestre una maqueta de Figma o Sketch, sino que te muestre realmente 'mira cómo se ve esta micro interacción' o 'mira cómo fluye esto', puedes hacer clic en esta aplicación y pasar por todo el flujo de la aplicación. Creo que va a ayudar a la gente de todo tipo de desarrolladores, diseñadores, PMs, creo que juega un papel muy importante. Ya puedo verlo haciendo eso. Y creo que solo va a seguir haciendo ese tipo de cosas.