Los procesos de innovación, como los platos de la cocina moderna, precisan de tiempos de cocción cortos. El plazo, desde que se produce la chispa de la idea hasta que se pone en mercado -el llamado “time-to-market”-, debe acortarse radicalmente para evitar que el entorno cambie y convierta en obsoleto el producto, incluso antes de comercializarse.
Como el principal factor de obsolescencia es la presencia de competidores en el mercado, parecería que estas prisas no son de aplicación a la Administración pública. En general, soy partidario de no transportar directamente las soluciones de la empresa privada a la lógica de lo público. Ahora bien, la Administración pública posee sus propias razones para acelerar los tiempos en sus proyectos.
- El primer motivo apunta a la propia naturaleza de la innovación, que procede en ciclos iterativos de experimentación y evaluación. Cuando los productos incorporan un componente experimental, necesitan exponerse al contacto con sus usuarios lo antes posible, para poder perfeccionarse a partir de la experiencia de uso. En otro caso, nos encontraremos con proyectos faraónicos que, sin embargo, no consiguen ser adoptados. Recordemos que la tasa de conversión es el indicador clave.
- El segundo motivo tiene que ver con la motivación de las personas y los equipos que llevan a cabo los proyectos. Es imposible mantener el entusiasmo cuando un proyecto dura dos años y no se liberan productos intermedios operativos. Llega un punto en que el plazo de entrega se antoja aleatorio, no existe sentido de urgencia -o, al contrario, todo es urgente- y al final se acaba entregando algo que nadie sabe si responde a lo que desearíamos.
- El tercer motivo es económico. Los proyectos faraónicos son, eso, faraónicos y tienden a incrementar sus costes por encima de lo razonable. Mi consejo es que cualquier proyecto tecnológico que tienda a crecer se descomponga en módulos menores, controlables, de duración corta. Una duración ideal es la que abarca un trimestre. Cuidado con los proyectos plurianuales.
Preveo algunos bufidos al llegar a este punto: “claro, a todos nos gusta que los proyectos acaben lo antes posible, pero cada uno tiene la duración que tiene, y es imposible reducirla radicalmente”.
Pues no. Existen formas de conseguir que los proyectos entreguen productos operativos en plazo corto, con costes menores y con mayor satisfacción de los usuarios. Yo mismo he participado en alguno de ellos.
Agilismo: metodología para proyectos de innovación
Se conoce a la familia de metodologías que producen proyectos ágiles como “agilismo”. Originalmente, la expresión se refiere a métodos restringidos al desarrollo ágil de software. Hoy en día, hay que entender el agilismo como un movimiento social que trata de favorecer un cambio de mentalidad que pone en el centro la colaboración y la adaptación.
La Wikipedia lo explica así:
“El desarrollo ágil de software son métodos basados en el desarrollo iterativo e incremental, donde los requerimientos y soluciones evolucionan mediante la colaboración de grupos auto organizados y multidisciplinarios. Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en lapsos cortos.
El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, sino que la meta es tener una «demo» (sin errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto.”
La mejor manera de acercarse al agilismo es a través del “manifiesto ágil”:
“Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:
- Individuos e interacciones sobre procesos y herramientas
- Software funcionando sobre documentación extensiva
- Colaboración con el cliente sobre negociación contractual
- Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.”
Si cambiamos software por cualquier otro objeto de un proyecto de innovación, seguiría siendo válido.
Bien, ¿y qué empresas utilizan metodologías ágiles? ¿Grupúsculos anarquistas de hackers? Citaré algunos ejemplos: Sony/Ericsson, Telefonica I+D, Adobe, IBM, Intel, Microsoft, Novell, Amazon, Google, mySpace, Yahoo, SAP, Bank of America, Merrill Lynch, Boeing, 3M, Bose… El agilismo es uno de los escasos elementos que comparten Microsoft y Google con el Bank of América.
Y, la Administración pública, ¿qué metodología de proyectos está usando? En general, lo más habitual son los modelos “llave en mano”, con esta secuencia:
- Una definición pretendidamente exhaustiva de requisitos
- Subcontratación a una empresa que se compromete a cumplir los requisitos
- Largo período de desarrollo que no produce prototipos operativos hasta el final
- Entrega del proyecto al cliente
- Comprobación de que cumple los requisitos
- Melancólica comprobación de que, aunque cumple requisitos, no es lo que deseamos
- Lanzamiento del proyecto de versión 2, por la misma empresa que hizo la versión 1
- Se repite el ciclo.
Por lo tanto, estamos usando una metodología con un marco de incentivos favorable al fracaso. Para el contratista, es favorable producir una versión 1 que cumple requisitos pero no se adapta a los deseos del cliente, porque así recibe automáticamente el encargo de realizar la versión 2.
Las metodologías ágiles, en cambio, proceden en ciclos cortos (máximo, 3 semanas) de producción y evaluación. Al final de cada sprint, se redefinen las necesidades, acercando cada vez las soluciones a los deseos del cliente, los cuales nunca pueden estar bien definidos al inicio.
¿En qué casos funciona mejor el “agilismo” que los métodos clásicos? En todos, pero especialmente cuanto mayor sea el tamaño y la complejidad, porque consiguen hacer manejables los proyectos complejos.
Agile en la Administración pública
¿Qué Administraciones públicas han desarrollado proyectos mediante metodologías ágiles? No muchas, la verdad. Vamos con retraso. Voy a poner un ejemplo reciente. El Ayuntamiento de Vitoria-Gasteiz ha publicado recientemente un anuncio de licitación para “la contratación de rediseño de la web municipal usando diseño adaptativo”. En el pliego de prescripciones técnicas se especifica que la metodología a emplear es SCRUM, seguramente la más popular de las metodologías ágiles de desarrollo de software.
El equipo de tecnología de Vitoria-Gasteiz siempre ha ido por delante de la mayoría. Felicidades. Espero que otras Administraciones se acerquen a preguntar y que tomen buena nota. El pliego es de lectura obligatoria
Recomiendo a quien tenga curiosidad que consulte la respuesta que en el Parlamento Vasco dio Idoia Mendia, en nombre del Gobierno Vasco, a una pregunta formulada por el parlamentario Álex Etxeberría, acerca del “Manifiesto Ágil”. ¡En 2010! Allí se nombran tres proyectos de éxito elaborados con esta metodología. ¿Soy yo el único que se emociona al ver que nuestros parlamentarios se interesan por materias como esta?
Para acabar, quiero recordar que el enfoque ágil, que enfatiza la colaboración, la adaptación y el minimalismo en la gestión, puede ser tomado como inspiración para la gestión pública más general. En este sentido, recomiendo vivamente la lectura de “Agile Management”, el último libro de Ángel Medinilla -uno de mis gurús de cabecera. Inspirador.
No hay comentarios:
Publicar un comentario