Matt Hubbard es lo que podríamos llamar una autoridad en lo que respecta al desarrollo ciudadano. Director de Excelencia Operativa y Éxito del Cliente en la plataforma de código reducido Agile Point -y una influencia significativa en el marco y los recursos de formación del PMI para desarrolladores ciudadanos-, es algo que ha perseguido con verdadera pasión durante más de una década. 

Cuando soñé por primera vez con el bajo código/sin código (LCNC), antes de que existiera realmente, era director de proyectos en una gran empresa automovilística", dice. Era responsable de estandarizar y controlar los procesos empresariales para el desarrollo de nuevos modelos en Norteamérica. No conseguía crear una aplicación. Los informáticos me dijeron que costaría varios millones de dólares y tardaría años en construirla. Fue entonces cuando pensé que debía haber una forma más flexible".  

Desde entonces ha creado numerosas aplicaciones y ha ayudado a implantar el no-code/low-code en varias grandes organizaciones. Cuando se trata de desarrollo ciudadano, decir que sabe lo que hace es quedarse corto. Aquí comparte algunas lecciones de su viaje, junto con algunos consejos prácticos para los que empiezan.

1. Empezar con algo pequeño

Me trasladé a una nueva empresa y pronto me di cuenta de que tenían problemas similares con la creación de software a medida para operaciones administrativas: demasiado caro, lento e inflexible. Fue entonces cuando intenté crear mi primera aplicación como desarrollador ciudadano. Me apunté a una prueba gratuita de una plataforma de LCNC y empecé a curiosear para ver si era legítima. Y lo era. Básicamente hice una aplicación para buscar actualizaciones de estado, un caso de uso bastante común para un gestor de proyectos. Era muy simple: una aplicación de una tabla con vistas pre-construidas, cuadros de mando y recordatorios automatizados. Solo me llevó 8 horas, pero me ahorró 200 horas al año".

El consejo de Matt: 

• Construye un caso de uso sencillo y aprende de él. Prueba con otro. Las primeras aplicaciones que crees no deben ser empresariales, de misión crítica, porque habrás invertido tanto que no las tratarás como una prueba. Así que empieza poco a poco, experimenta".

2. Implicar a los informáticos lo antes posible

Tras el éxito inicial con una cuenta de prueba, compramos algunas licencias y creamos más aplicaciones. Cada vez que creábamos algo y lo utilizábamos, demostraba su valor. Los informáticos se enteraron de nuestro trabajo y nos pidieron que hiciéramos una pausa para poder realizar una evaluación de riesgos. Esto nos asustó un poco, pero afortunadamente pasamos el escrutinio y se nos permitió seguir adelante con una supervisión moderada por parte de TI. Esta experiencia me enseñó que la colaboración con TI es imprescindible para que el desarrollo ciudadano sea una opción viable y saludable. En retrospectiva, deberíamos haber hablado con TI desde el principio". 

Los consejos de Matt: 

• La expectativa actual es que el departamento de TI construya cosas para ti, pero la realidad es que no pueden construirlo todo y tienen un enorme retraso. ¿Cuál es la solución? El desarrollo ciudadano es una buena solución. Quieres que el departamento de TI se lo apropie. Quieres que formen parte de él". 

• LCNC tiene que enmarcarse como un beneficio tanto para TI como para la empresa, y más como un experimento. Decir: "No te pido que tomes una gran decisión para la empresa ahora mismo, pero creo que aquí hay algo, ¿podemos investigarlo juntos de forma controlada?". 

3. Intentar comprender las objeciones 

La respuesta de los informáticos fue doble. O bien: "no te lo hemos aprobado" o "¿y si tiene vulnerabilidades de seguridad?". Estaba emocionado y frustrado porque sentía que no tenía otras opciones. O bien hojas de cálculo, o bien esta solución ineficaz a largo plazo [construir con TI]. Ambas cosas apestaban. Pero acepté poner en pausa el nuevo desarrollo mientras el departamento de TI investigaba adecuadamente las plataformas. Eso condujo a una relación mucho más saludable para el desarrollo futuro. Resistirse a las objeciones probablemente habría tensado las relaciones y reducido las probabilidades de éxito en el futuro".

Los consejos de Matt:

• Si recibes críticas, primero trata de entender y luego de que te entiendan. Escucha sus objeciones. Aprecie de dónde vienen. Trabaja con ellos para dar cabida a esas objeciones. Sea paciente. Explora formas en que la DC pueda ayudarte, no solo a ti, sino también a TI (por ejemplo, con su cartera de proyectos)".

• Lo que me encuentro con las grandes empresas es que piensan que el siguiente paso es encontrar la plataforma perfecta. Eso les lleva a la parálisis por análisis, arriesgando mucho para tomar la decisión correcta de inmediato. Es un enfoque equivocado. Es mejor tener una idea del tipo de plataforma que buscas, una dirección general, y luego probarlas. Llegarás a un punto en el que te sientas cómodo con una plataforma y entonces la utilizarás a gran escala. Y entonces empiezas a desarrollar tu modelo operativo: normas, barandillas y estructuras organizativas en torno a la DC. También conocido como modelo de madurez en cinco fases del PMI". 

Para más información, consulte nuestro artículo sobre cómo mitigar los problemas informáticos.

4. La ampliación de LCNC requiere competencias diferentes

En mis primeras creaciones de aplicaciones, no pensé en los estándares de aplicación para una experiencia de usuario coherente; no pensé en construir para facilitar el mantenimiento; no pensé en la eficiencia de mis fórmulas y vistas. Normalmente empiezas creando aplicaciones para ti mismo, para resolver tus propios problemas. Pero luego te das cuenta de que puedes crear aplicaciones para un público más amplio, fuera de tu departamento".

Los consejos de Matt: 

• Hay que darse cuenta de que construir para mucha gente es diferente. Escalar es un juego diferente. Es difícil. Hay que pensar con lógica y empezar a pensar en normas y coherencia". 

• Se trata de crear un esquema: ¿dónde poner el botón de guardar? ¿Qué esquemas de color vas a utilizar? ¿Cómo vas a diseñar tu flujo de trabajo? No hace falta aprender todo eso antes de empezar, porque entonces no empezarás nunca, pero una vez que empiezas a llegar a un público más amplio tienes que empezar a aprender estas técnicas". 

5. Los entornos empresariales presentan cuatro problemas principales

• Bloqueo de proveedores. Si utilizas una plataforma para crear tantas aplicaciones que acabas gestionando tus operaciones con ella, el proveedor de la plataforma puede tener influencia. No conviene poner todos los huevos en la misma cesta. Si eres una gran organización y tienes un par de plataformas desde las que ejecutar tus aplicaciones, es útil porque entonces tienes un poco de influencia".

• Los costes de las licencias, sobre todo para los usuarios ocasionales. Hay distintos modelos de precios, pero la mayoría se basan en el usuario. Se puede cobrar independientemente del uso que haga el usuario de la plataforma, lo que resulta muy complicado si se trata de crear una aplicación de cara al público. Es difícil adaptar la estructura comercial y los precios a la forma en que se utilizan las plataformas. Pero hay plataformas con modelos de precios para usuarios ilimitados e incluso concurrentes (por ejemplo, 100 usuarios pueden utilizar la plataforma a la vez)". 

• Falta de herramientas de gestión a escala empresarial. Muchas plataformas sin código no tienen entornos de desarrollo: todo está en producción. Eso es un reto cuando se pasa a escala empresarial. Significa que cada cambio que haces afecta a la gente, en directo. Eso está bien con aplicaciones sencillas, pero si tienes dependencias, ¿cómo haces esos cambios sin afectar negativamente a la gente en tiempo real? Algunas plataformas tampoco ofrecen una visibilidad sencilla de todas las aplicaciones de tu ecosistema ni información sobre quién las posee o mantiene, desde una ubicación central. Eso también es un reto". 

• La interfaz de usuario tiene ciertas limitaciones. La razón por la que el no-código es rápido es que reutilizas cosas que ya existen. Para que algo ya exista, tiene que haber sido creado. Si intentas construir sin código y quieres personalizar la interfaz diciendo "me gustaría tener este color aquí, o un botón aquí, o hacerlo un poco diferente", no puedes. Siempre es lo mismo. No tienes que pensar en todos esos detalles extra; la plataforma ya ha pensado en ello por ti. Si eso es importante para ti, quizá tengas que optar por plataformas de bajo código. Hoy es un compromiso, pero quizá no lo sea en el futuro". 

6. Si tu entorno no es propicio, busca en otra parte 

Si el LCNC y el desarrollo ciudadano no están permitidos porque no es así como se hacen las cosas en tu organización, quizá tengas que dejar de darte cabezazos contra la pared y seguir adelante. Ahora, cuando busco un trabajo de mejora de procesos, pregunto si utilizan LCNC. ¿Me autorizarán a crear aplicaciones? Y si la respuesta es negativa, probablemente me vaya a otro sitio". 

Una última cosa para recordar

No sientas que tienes que tenerlo todo resuelto antes de dar un paso. Ahora el mundo es diferente: puedes experimentar y aprender porque las plataformas de LCNC son muy accesibles, a diferencia de las gigantescas compras de software del pasado".