Colaboración eficiente: ciudadanos desarrolladores y líderes de negocio creando soluciones con plataformas de bajo código

En este episodio de Dynamic Developer, mi invitado no piensa que sea así, y nos explicará por qué. A continuación, encontrarás una transcripción de esta entrevista, editada para mayor claridad.

¡Bill Detwiler al habla!

Bill Detwiler: Soy tu anfitrión Bill Detwiler, y estoy acompañado por Malcolm Ross, Vicepresidente de Estrategia de Producto y Subdirector de Tecnología de Appian. Malcolm, gracias por unirte a nosotros.

Malcolm Ross: Gracias por el tiempo, Bill.

Escucha la versión de este podcast en SoundCloud

Malcolm Ross: Gracias por el tiempo, Bill.

Appian: una plataforma de desarrollo de bajo código

Bill Detwiler: Antes de comenzar a hablar sobre la automatización, el bajo código y el sin código, y el efecto que esto tiene en la industria del desarrollo de software en general, para aquellos que no conocen Appian, explícanos brevemente qué es Appian, qué hace y cuál es tu rol allí.

Aprende Python en 2022 con el paquete completo del programador de Python 2022.

Malcolm Ross: Claro. Appian es una plataforma de desarrollo de bajo código que se especializa en automatización, flujo de trabajo y RPA (automatización de procesos robóticos). Por lo tanto, si piensas en lo que eso significa, es un nuevo paradigma para construir aplicaciones utilizando herramientas visuales y declarativas de arrastrar y soltar para entregar rápidamente soluciones que los clientes esperan, y por supuesto, con una arquitectura moderna y nativa en la nube.

Llevo más de 16 años y medio en Appian. He tenido varios roles, pero mi rol actual es liderar la estrategia de producto, que es la dirección a largo plazo de la empresa. También he desempeñado roles de liderazgo en gestión de productos, marketing de productos y otras áreas de la empresa. Además, tengo más de 22 años de experiencia en el campo de la automatización de procesos antes de trabajar en Appian. Por lo tanto, tengo mucha experiencia en software empresarial y en la creación de flujos de trabajo y procesos de BPM para diversas compañías durante varias décadas.

El impacto en los empleos de los desarrolladores

Bill Detwiler: Creo que esta es una gran introducción a mi primera pregunta. Debido a tu amplia experiencia en automatización, uno de los temores que tienen los desarrolladores de software y los ingenieros frente a las herramientas de bajo código y sin código es que podrían limitar sus perspectivas laborales, ¿verdad? Podría ser que al facilitar que más personas desarrollen software empresarial sin tener la formación clásica de ingeniero de software, su necesidad disminuya. ¿Realmente esto significa que se generarán menos empleos para desarrolladores porque ya no se necesitarán para construir software?

Así que, basándote en tu experiencia en automatización, ¿qué les dirías a los que tienen estas preocupaciones? ¿Cómo las abordarías?

Malcolm Ross: Realmente hay muchas formas de abordar esto, y yo mismo soy uno de ellos: obtuve mi título en ciencias de la computación e informática hace algunas décadas y me considero un desarrollador. Sin embargo, hay que considerar la enorme cantidad de necesidades digitales acumuladas en todo el mundo. La realidad es que no hay suficiente personal para satisfacer la demanda de digitalizar todos estos negocios. Y eventos como la pandemia global solo han acelerado esa necesidad, ya que ahora necesitamos trabajar más a distancia, las tiendas minoristas necesitan hacer más compras en línea y recogida digital, la demanda simplemente no se detiene, sino que crece y crece. Por lo tanto, no hay temor de que los desarrolladores de software pierdan empleo, porque hablando desde una empresa de software, no podemos contratar suficiente personal con experiencia profesional en desarrollo de software.

Las herramientas de bajo código, sin embargo, son una respuesta directa a esta tendencia que hemos visto en los últimos 10 años, en la que se necesita desarrollo y crecimiento ágil. En la década de 2000, hubo un gran cambio del desarrollo tradicional cascada al desarrollo ágil, realizando ciclos rápidos de una o dos semanas y mostrando resultados rápidamente, utilizando metodologías de desarrollo ágil que se adaptan a los cambios en el negocio. A pesar de que las metodologías para construir software han cambiado, las herramientas en sí no lo han hecho y realmente no han permitido a las personas construir rápidamente y con agilidad debido a la experiencia de alto código y la cantidad de herramientas necesarias. Por ejemplo, si eres desarrollador de Java, es complejo tener que aprender varias herramientas para crear pruebas de unidad, integración y funcionales, asegurar la entrega continua, y también tener que construir la interfaz de usuario aprendiendo otros lenguajes como Angular o React. Es inmensamente complejo ser un desarrollador full-stack, ya que tienes que aprender muchas herramientas no solo para construir lo que deseas, sino también para llevarlo a través de una canalización ágil de entrega continua. Esto es complicado, difícil de enseñar y también difícil de hacer correctamente.

Entrevistas con Desarrolladores Dinámicos: Novedades

Las herramientas de bajo código no buscan reemplazar a los desarrolladores, sino facilitar ese proceso de manera más elegante. Cuando pensamos en bajo código, a menudo solo pensamos en la capa de composición, es decir, cómo declarar lo que queremos arrastrando y soltando en lugar de escribir código. Sin embargo, aquellos familiarizados con el desarrollo de software saben que eso solo representa el 20% o el 30% del proceso de desarrollo en sí. También hay desarrollo de pruebas, implementación, pruebas de integración, mantenimiento, etc. Todas estas etapas deben unirse para producir software de alta calidad.

Las herramientas de bajo código, como Appian, cubren todo el ciclo de vida de desarrollo. No se trata solo de la parte de composición, sino de facilitar todo el ciclo de vida ágil para construir, implementar, iterar y realizar cambios rápidamente.

Programas de desarrolladores ciudadanos

Bill Detwiler: Eso es lo que he escuchado de muchas personas, que hay tanto trabajo disponible que no se agotarán los empleos para desarrolladores full-stack en un futuro cercano; esto realmente se trata de ampliar esa base. Sé que uno de los métodos que utilizan las empresas para lograr esto es mediante programas de desarrolladores ciudadanos. Háblanos un poco sobre eso, cómo las organizaciones pueden utilizar estas herramientas de bajo código para involucrar a más personas dentro de su organización en el proceso de desarrollo.

Malcolm Ross: Sí, eso implica múltiples niveles, ya que ampliar el número de personas que pueden participar en el desarrollo de aplicaciones naturalmente será beneficioso. Esto se logra tanto contratando a más desarrolladores profesionales como simplificando el proceso de desarrollo utilizando el bajo código. Luego, esto nos lleva a la definición de quién es un desarrollador ciudadano y quién no lo es.

Cuando hablamos de desarrolladores ciudadanos, ya hemos tenido esto durante décadas. En realidad, hemos tenido estos desarrolladores ciudadanos durante 20 o 30 años, desde que se lanzó el paquete de Microsoft Office y se permitió escribir macros en Excel, ¿verdad? Ya hemos tenido desarrolladores ciudadanos, y han construido cosas en la suite de Office.

Personalmente trabajé en los años 90 construyendo bases de datos en FoxPro y Microsoft Access para empresas hipotecarias, y fui un desarrollador ciudadano: no era parte del departamento de TI, pero estaba construyendo cosas que se utilizaban en las operaciones diarias, por ejemplo, notificaciones de tasas de interés para los prestamistas. Hemos tenido este grupo de desarrolladores ciudadanos durante mucho tiempo, y la proliferación de bases de datos de Access y hojas de cálculo complejas de Excel solo ha ido creciendo.

Aprende a programar desde cero con el Ultimate Learn to Code Bundle por solo $39

Por lo tanto, las herramientas de bajo código te brindan la oportunidad de permitir que desarrolladores del sistema creen más allá del ámbito de la suite de Office. Ahora pueden crear aplicaciones móviles, automatización de procesos robóticos, flujos de trabajo y aplicaciones web. Pueden hacer más cosas, pero al mismo tiempo, una herramienta de bajo código como Appian te da un control más centralizado, en lugar de que las aplicaciones estén en el escritorio de cada usuario y cada uno haga lo que quiera, puedes tener una gobernanza y un ciclo de vida bien establecidos. Incluso puedes tener un centro de excelencia del departamento de TI para gestionar a los desarrolladores ciudadanos, imponer políticas y asegurarte de mantener la seguridad de la información y las mejores prácticas de desarrollo.

Entonces, es lo mejor de ambos mundos. Otro aspecto en el que se centran las herramientas de bajo código es en la colaboración entre el negocio y el departamento de TI. Por un lado, tienes a los desarrolladores ciudadanos, a quienes les das libertad para crear. Pero también necesitas un ámbito en el que se alinee el negocio y el departamento de TI de manera más estrecha. Y esto a menudo es un proceso gradual a medida que evolucionamos de una metodología de desarrollo cascada a una metodología ágil. Uno de los mayores desafíos en esto es lograr que el negocio participe.

Los usuarios de negocios están acostumbrados a la metodología cascada en la que simplemente proporcionan los requisitos por adelantado y dicen: "Nos vemos en cuatro o seis meses cuando terminen mi aplicación mágica", sin comunicarse regularmente. Por supuesto, sabemos que esto no funciona. La clave de la metodología ágil es tener una comunicación regular con el negocio, demostrar como desarrollador lo que he construido, validar con los interesados del negocio que esto es lo que desean y luego planificar y cambiar el backlog para satisfacer el próximo conjunto de criterios.

Por lo tanto, es una comunicación constante. Las herramientas de bajo código, al proporcionar un mecanismo que el negocio puede comprender mejor, facilitan esta comunicación. En lugar de que los usuarios de negocio vean el código en Java y pregunten: "¿Es esto lo que quieren?", sin realmente entender lo que están viendo, se les puede mostrar una tabla de decisiones o un diagrama de flujo. Se les puede mostrar algo visual que los usuarios de negocio comprendan mejor.

Entonces, una gran parte de las herramientas de bajo código consiste en empoderar tanto al departamento de TI para construir aplicaciones como a los usuarios de negocio para participar mejor en el proceso de desarrollo ágil mediante el establecimiento de un lenguaje común.

Adoptar una cultura ágil es un proceso evolutivo

Bill Detwiler: Sí, eso es interesante. Me gustó la analogía de Microsoft Access y FoxPro. Recuerdo haber hecho cosas similares en los años 90, y creo que eso es comparable al auge de las herramientas de bajo código y sin código con respecto a las suites de productividad empresarial en los años 90 y 2000, ¿verdad? No significa que no necesitemos contadores o personas que usen esas herramientas, sino que más personas tengan acceso a ellas, lo que permite a las empresas ser más productivas y mejorar la forma en que producen sus productos y servicios.

La guía definitiva para el software de gestión de proyectos: Qué necesitan los desarrolladores

Y me gustaría resaltar algo que mencionaste ahora, que es la interacción entre el negocio y el departamento de TI. Hablabas de cómo se necesita este intercambio de información en el proceso ágil. ¿Cómo pueden las empresas lograr esto de manera exitosa si tal vez no lo hayan hecho en el pasado? No estoy seguro, pero la mayoría de las personas con las que hablo han adoptado procesos de desarrollo ágil. Y como parte de eso, involucran a gerentes de producto o intentan que los interesados del negocio se involucren más en el proceso. Pero eso puede ser un poco complicado, como mencionaste, para aquellas empresas que tal vez están acostumbradas a una forma de trabajo específica o que no han establecido esto como parte de su cultura. ¿Cómo has visto que las empresas lo hagan exitosamente?

Malcolm Ross: Sí, esto es evolutivo porque lo que estás mencionando ya no es un problema técnico, sino un desafío cultural dentro de las organizaciones. Durante las últimas décadas, hemos llegado a pensar en el negocio y el departamento de TI como dos unidades de negocio distintas. Y cuando estableces esas barreras artificiales entre los departamentos, se crea un conflicto natural. He estado en reuniones donde el departamento de TI y el negocio ni siquiera podían sentarse juntos en una sala de conferencias debido a la hostilidad. El departamento de TI pensaba que el negocio no entendía la complejidad de administrar las arquitecturas y mantenerlas actualizadas. El negocio decía: "El departamento de TI no responde lo suficientemente rápido, no satisface mis necesidades". Y hay una hostilidad allí.

Entonces, lo que se debe hacer es una ruptura. Si observamos las empresas modernas que tienen éxito hoy en día, como Uber, Lyft, Facebook, entre otras, casi no hay distinción entre el negocio y el departamento de TI. Son prácticamente una sola empresa integrada, y el departamento de TI es una parte esencial, o el hecho de desarrollar software es una parte esencial de cómo funciona su negocio. Ese es probablemente el primer paso, unir estos equipos de manera más estrecha para tener un objetivo común compartido, para que se invierta en el desarrollo de software como parte esencial del negocio y de cómo llegan al mercado.

Y eso es una ruptura cultural de las estructuras jerárquicas y fusionar estas unidades de negocio. Luego, el papel de TI centralizada no es necesariamente llevar a cabo cada proyecto, porque tienes personas trabajando con el negocio en esos proyectos, sino establecer los estándares de la organización. Cosas como la seguridad de la información, asegurarse de que el manejo de la información sea seguro, la experiencia del usuario, establecer un modelo de experiencia del usuario para todas las aplicaciones, SOA (arquitecturas orientadas a servicios) para tener estándares para la exposición de APIs de información para facilitar su reutilización en toda la empresa.

Se trata de cambiar el papel de TI para no enfocarse solo en la entrega de proyectos individuales, sino en supervisar la estrategia de TI en toda la empresa mientras se fusiona el departamento de TI con las funciones comerciales de manera más directa. Esto no es algo sencillo, especialmente al romper a menudo décadas de jerarquías culturales que se han establecido y al intentar fusionar estas unidades de negocio.

Hacer que los desarrolladores conozcan los desafíos reales

Bill Detwiler: Si estamos hablando con personas del lado de TI y del desarrollo, como desarrolladores senior o líderes de equipos y departamentos, ¿qué les aconsejarías para comenzar a derribar algunas de esas barreras? Si estoy en este lado de la mesa y soy un líder de equipo o el director senior de ingeniería de una empresa, y estoy pensando: "Bueno, ¿cómo mueve la pelota el primer paso? ¿Cuáles son los primeros pasos que debo tomar en este proceso?" ¿Mencionas esto en el liderazgo ejecutivo? ¿Intentas crear una relación desde abajo con el director financiero o el director de Recursos Humanos para decir: "Sabes qué sería genial, si tú tuvieras a esta persona en tu equipo, o déjame identificar a las personas en tu equipo que pueden ayudarnos a utilizar estas herramientas de bajo código y sin código"? ¿Cómo deberían comenzar?

Recursos para aprender Kotlin: libros

Malcolm Ross: Obviamente, cada empresa es diferente en su proceso de transformación. Algunas empresas son muy modernas, mientras que otras tienen que lidiar con legados. He trabajado con grandes empresas de servicios públicos de agua y algunas otras grandes empresas de transporte, y lo que les recomendaría es que el departamento de TI salga de sus cubículos. Deben salir de la oficina. Por ejemplo, en la empresa de servicios públicos de agua, les sugeriría que saquen a la persona de su cubículo o de su automóvil y le hagan vestirse con un traje apropiado para ir a trabajar en las tuberías de alcantarillado y agua, y que vivan la experiencia junto con los usuarios de negocio. Se trata de construir respeto.

Otro ejemplo: Appian ha construido varias soluciones para centros de contacto. Y cuando construíamos soluciones para centros de contacto, enviaba a mis ingenieros a centros de contacto en áreas remotas de Kentucky y Salt Lake City, y les decía: "Siéntate en ese centro de contacto y trabaja al teléfono durante tres días. Quiero que manejes llamadas, quiero que vivas la experiencia". Esto no solo le da al personal de TI una perspectiva de cómo es realmente el trabajo para el que están construyendo soluciones, sino que también construye respeto dentro del negocio. El negocio ve a la persona de TI como alguien que está ayudándole en su trabajo, como alguien que está a su lado en el asiento junto a ellos, como alguien que está en las tuberías de alcantarillado con ellos, observando a qué se dedican.

A menudo, en empresas de servicios públicos y energía y en empresas de transporte, que son industrias con legados, hay personas que han estado haciendo el mismo trabajo durante décadas, como el mantenimiento de servicios públicos, y se necesita establecer un nivel de respeto. El negocio debe ver al departamento de TI como un participante en la misión de la empresa. Por lo tanto, esa es una parte cultural. Y una vez que se establece ese respeto, como diciendo: "Sí, soy parte de este negocio. No solo soy esta organización externa de TI. Soy parte de ustedes para ayudar a crear nuevas soluciones". Luego, se trata también de establecer modelos de excelencia. Pero lo que el departamento de TI debe hacer es analizar seriamente sus pilas tecnológicas. A menudo se cae en la trampa de la deuda técnica, es decir, el amor por construir nuevas soluciones pero pasar el 80% del tiempo solo mantenimiento las aplicaciones del día anterior.

Entonces, se debe analizar esa pila de aplicaciones y encontrar soluciones que liberen de ese trabajo. Las soluciones en la nube basadas en bajo código son exactamente eso, donde el proveedor se encarga de actualizar, parchear y asegurar la arquitectura para que el personal de TI pueda enfocarse en la innovación, que es otro beneficio de las herramientas de bajo código, redirigir la atención de las personas que utilizan estas herramientas de desarrollo hacia la innovación en lugar de solo mantenimiento.

Luego, al analizar la arquitectura, se debe comenzar a establecer ese centro de excelencia, una vez que se tiene ese respeto de negocio-TI, para después dictar cómo se maneja la información, cómo gestionar las amenazas de TI y cómo establecer los estándares de TI. Es un proceso de múltiples capas a tener en cuenta, pero comenzar con el respeto y la colaboración entre el negocio y el TI es, probablemente, la etapa más importante.

Tener los procesos bajo control

Bill Detwiler: Me encanta ese enfoque, y quisiera darle una información a la audiencia como una divulgación completa. Comencé mi carrera en TI en una empresa de servicios públicos. Y para los recién llegados que preguntaban por qué los sistemas fallaban o por qué los equipos tenían problemas, les decíamos: "Es porque nunca has estado en una planta de energía de carbón. En Kentucky, para que sepan por mi acento". Pero una vez que salías y veías algunos de los entornos en los que operaban los usuarios de negocio, comenzabas a comprender los desafíos que tenían, y estoy completamente de acuerdo en que eso generaba respeto y comprensión mutua. Esa es una excelente analogía. Bueno, Malcolm, me gustaría concluir porque creo que esto también nos lleva a un punto realmente importante y algo que muchas personas han mencionado, que es acercar los procesos de desarrollo de software al negocio, ¿verdad? Ya sea que se trate de la TI y los profesionales de redes y desarrollo acercándose y viviendo la experiencia del negocio, o permitiendo que los ciudadanos desarrolladores del negocio participen en el proceso de desarrollo de software a través de programas de desarrolladores ciudadanos. Para las empresas que lo han logrado con éxito, no quiero decir que le estén dando responsabilidades de desarrollo a los usuarios de negocio, sino simplemente acercando el desarrollo de software a ellos, ¿tienes alguna recomendación sobre la forma de hacerlo, ya sea en el proceso o en todo lo que has mencionado, para que las personas adecuadas dentro del negocio utilicen estas herramientas de bajo código y sin código para participar en el proceso de desarrollo de software?

Cómo medir el impacto de DevRel y por qué es importante para las empresas

Controlar el proceso para no terminar cubierto de pintura

Malcolm Ross: Sí, eso es una excelente observación también. A menudo ha sucedido con herramientas como Microsoft SharePoint, cuando prometían un entorno de portal que permitiría a todos compartir su información.

Bill Detwiler: Y si puedes hacerlo correr sin que sea más lento que cualquier otra cosa.

Malcolm Ross: Exactamente. Tengo una presentación completa en la que hablo de la historia de SharePoint, donde comparo la situación con ir a una tienda de artículos de manualidades y comprar el mejor set de pintura, y simplemente imaginar que si le doy el mejor set de pintura a mis hijos, van a producir Van Goghs y Picassos y obras de arte maravillosas. Y luego la siguiente diapositiva muestra a un niño cubierto de pintura. Por lo tanto, el gran poder conlleva una gran responsabilidad, como dice el tío de Spiderman. Ese es el desafío con este tipo de herramientas de bajo código y sin código. Sí, los desarrolladores ciudadanos pueden participar en el proceso de desarrollo de aplicaciones. Pero cuidado de no terminar con un niño cubierto de pintura.

Aún necesitas ser un participante activo en las prácticas y estándares de cómo se construye software, y ahí es donde entra en juego el centro de excelencia. Deben establecerse reglas, control y medición mientras se da libertad para el desarrollo con estas herramientas, aunque siempre con un SDLC (ciclo de vida de desarrollo de software) que controle cómo se llevan las cosas a producción y cómo se miden a largo plazo.

Bill Detwiler: Creo que es un buen lugar para terminar porque eso es precisamente el desafío, ¿verdad? Establecer límites, tanto técnicos como desde la perspectiva humana. Es un desafío, pero un buen desafío porque al final te lleva a un lugar donde puedes ser más ágil, donde las empresas pueden llevar software al mercado y responder más rápidamente a las necesidades del negocio, lo cual es especialmente crítico para la supervivencia, como hemos visto el año pasado con la pandemia de COVID, donde las empresas se apresuraron a acelerar sus planes de transformación digital. Malcolm, una vez más, gracias por tomarte el tiempo de conversar con nosotros. Realmente aprecio esto y espero que puedas volver.

Malcolm Ross: Genial. Gracias, Bill. Ha sido un placer.

Lua se posiciona en el top 20 de los lenguajes de programación más populares

En Newsmatic nos especializamos en tecnología de vanguardia, contamos con los artículos mas novedosos sobre Desarrollo, allí encontraras muchos artículos similares a Colaboración eficiente: ciudadanos desarrolladores y líderes de negocio creando soluciones con plataformas de bajo código , tenemos lo ultimo en tecnología 2023.