Por Pablo Sartor, profesor del IEEM, escuela de negocios de la UM
Cada vez más organizaciones procuran ser —o mostrarse como— “ágiles” (agile como se las conoce por el término en inglés). ¿De qué se trata esto exactamente, para qué sirve y qué implica?
¿Qué es “Agile”?
Es una filosofía para la gestión de proyectos y desarrollo de productos y servicios. Diversas metodologías que respetan sus principios fueron introducidas en el mundo del software en los 90, por ejemplo, Scrum y Extreme Programming, popularizando el concepto y extendiéndose a otras disciplinas. Se basan en el desarrollo iterativo, incremental y autoexplicativo de soluciones a problemas cuyos requisitos evolucionan y se van precisando a lo largo del proyecto.
¿Por qué surge el concepto?
Las metodologías tradicionales, en particular en el desarrollo de software, buscaban optimizar el uso de los recursos, mediante el foco y la reducción de la necesidad de coordinación. Las hipótesis básicas implícitas eran: a) es posible para el cliente especificar con detalle todo lo que necesita del producto; b) dichas necesidades no cambiarán; c) podemos prever la satisfacción que cierta solución concreta brindará ante un set de requerimientos dado; y d) podemos escribir documentos completos y sin ambigüedades, que no dejen nada librado a distintas interpretaciones. Bajo estas hipótesis, el mecanismo tradicional de “cascada” es el óptimo; comenzar negociando hasta el último detalle los requisitos a cumplir (alcance, tiempos, costos), luego diseñar la solución, luego implementarla, testearla, corregir cualquier defecto y, finalmente, ponerla en funcionamiento. El problema es que con el paso del tiempo todo atenta contra estas hipótesis. Los proyectos son más complejos. Hay más posibilidades tecnológicas, de las cuales los clientes suelen estar más lejos, por lo que una cosa es lo que imaginan en cuanto a la utilidad de una solución y otra distinta lo que experimentan cuando se enfrentan al producto entregado. El sentido de urgencia es mayor, no hay tiempo ni disposición para detenerse demasiado en definir los detalles del producto a desarrollar. Además, se sabe que las necesidades cambiarán en breve, es decir, durante el desarrollo del proyecto. Agile es, de algún modo, una renuncia realista a la pretensión naïve de control y predictibilidad que subyace detrás de esas hipótesis, que como vimos, cada vez aplican menos a los proyectos habituales.
¿En qué se basa?
En 2001 diecisiete expertos en desarrollo de software signaron un “manifiesto”[1] para dejar sentados los principios de la filosofía ágil. Cuatro pilares, que comento a continuación, le dan sustento.
a) Individuos e interacciones más que procesos y herramientas.
Nada sustituye la iniciativa personal y la comunicación frecuente entre los miembros del equipo y con los clientes, con escasos protocolos, principalmente orientados a asegurar un intercambio diario de problemas encontrados, avances y tareas en las que unos necesitan de otros. Las herramientas para sistematizar la comunicación y dejar registro de las decisiones tomadas son útiles, pero solo en la medida en que no entorpezcan el ritmo de los avances.
b) Software funcionando más que documentación extensiva.
El producto, que evoluciona con cada entrega incremental, está siempre “terminado” en casi todos los sentidos. No en cuanto al alcance (las funciones que brinda) pero sí en cualquier otro aspecto: es prolijo, optimizado y organizado de modo que sea lo más autoexplicativo posible. La metodología desaconseja el “atar con alambre” partes del producto durante un tiempo a la espera de que llegue el momento de reorganizarlo… lo cual raramente sucede en la realidad. Siempre existe la tentación de atar una parte para avanzar rápidamente en alcance y más adelante ordenarlo todo, o dejar mecanismos intermedios de registro o documentación que ya habrá tiempo para estructurar mejor. Bajo esta metodología, esto es visto como “pan para hoy… hambre para mañana”.
c) Colaboración con el cliente más que negociación contractual.
Es utópico pretender que el cliente defina exactamente cada detalle del producto que mejor atenderá a sus necesidades, es conveniente transitar un proceso a través del cual lo descubra. Claro que ello requiere una disposición de ambas partes a ser razonables ante futuros cambios de rumbo, ajustes, errores, costos resultantes y la generación de un ámbito de confianza mutua —que bajo las hipótesis tradicionales no es necesaria en cuanto todo queda sellado a fuego en las cláusulas de un contrato negociado a priori—.
d) Respuesta ante el cambio más que seguir un plan.
La única certeza al lanzar el proyecto es que los requisitos cambiarán, aparecerán otros nuevos o dejarán de ser necesarios. Deben aceptarse estos cambios como algo natural del proceso e incluso deseable para ajustar los esfuerzos a las necesidades exactas del cliente. El enfoque iterativo permite empezar por los aspectos que planteen mayores incertidumbres y reaccionar a ellas en forma temprana, como recomiendan las metodologías lean[2]. Planificar sin exagerar es conveniente, pero, sobre todo, porque es la forma de prepararse mejor para los eventuales cambios de rumbo. Este es otro pilar que debe ser “comprado” por el cliente, que debe estar dispuesto a revisar alcances y, eventualmente, a que haya que sacrificar certeza en tiempos y esfuerzos de un tradicional proyecto “llave en mano”.
¿Qué es lo principal para tener en cuenta a la hora de adoptar este enfoque?
Es importante que el cliente entienda el proceso iterativo que deberá recorrer, ya sea interno o externo. Se requieren formas diferentes para cotizar, medir el avance y cobrar, que deberán ser acordadas. Gracias al pilar de “producto terminado”, al cabo de las primeras iteraciones ambas partes se conocerán mucho más y podrán continuar la relación —incluso renegociando futuros avances— o cambiar de proveedor sin pérdida de la inversión inicial. Es clave también asegurarse una participación activa y continua de actores adecuados del cliente. Finalmente, por parte del proveedor, resulta fundamental la actuación del líder del proyecto que, por la naturaleza de la metodología, requerirá de más aplicación de habilidades blandas que de las más tradicionales.
[1] http://agilemanifesto.org/iso/es/principles.html
[2] http://theleanstartup.com/
Publicado en Café & Negocios, El Observador, 13 de junio de 2018.
Conocé el próximo Programa Enfocado: Dinámicas organizacionales Ágiles
Descargar PDF
