¿Agilidad en un negocio de alcance fijo?
Quiero contarles de un experimento-realidad que viví en Castor hace poco, empresa en la que trabajo (www.castor.com.co).
Nosotros tenemos como lineamiento no hacer proyectos con Alcance, Recursos y Tiempos fijos, de hecho, una de las mejores decisiones que hemos tomado en nuestra empresa a lo largo de la historia es trabajar con marcos ágiles, creemos profundamente en la Agilidad y nos ha dado muy buen resultado. Incluso sé que varios de nosotros, incluyéndome, hacemos lo posible por aplicarla tanto a nuestro trabajo como a nuestras vidas.
A finales del 2018, un prospecto nos solicitó hacer un proyecto (el desarrollo de un Software) y nos expresó que nosotros éramos los primeros candidatos, sólo que era precisamente con alcance, presupuesto y tiempos fijos. Y ¿saben qué?… era un proyecto mediano, y su valor nos llamaba la atención, unas ventas interesantes y el esfuerzo (alcance, tamaño de equipo y el tiempo que su momento estimamos se le debía dedicar) podía ser manejado de cara a las posibles desviaciones (Diferencias entre lo estimado y lo ejecutado, en tiempos, alcances o costos). Y sí… Queríamos vender más ese mes, aún asumiendo ciertos riesgos. La complejidad funcional de la necesidad era mediana, el cliente necesitaba hacer unos tableros de visualización de datos para apoyar en la toma de decisiones, teníamos experiencia de más de 3 años en este tipo de soluciones y más de 8 años con marcos ágiles y según el contexto y la situación los riesgos eran muy manejables.
Después de pensarlo varias (de hecho muchas) veces, rascarnos la cabeza, darnos golpes de pecho, llegamos a la siguiente decisión: Bueno chicos, es un riesgo controlado, van a haber desviaciones, van a haber inconformidades, y discusiones, pero podemos entregar un software que cumpla con las historias de usuario planteadas por el cliente, vamos a poder generar valor y de paso tener satisfacción al trabajar, e ingresos y rentabilidad para la empresa…. y empezamos el proyecto.
Un detalle no menor… había un “jefe importante y ocupado” del lado del cliente, aplicamos todos los marcos, artefactos y ceremonias ágiles a nuestro alcance y conocimiento que considerábamos pertinentes (como scrum con sus ceremonias o entregas tempranas y de valor) pero en el día a día, en la realidad, las entregas de valor las recibía un “analista” del cliente y aproximadamente cada 15 días lo miraba el “jefe ocupado” y como era de esperarse no le servía, y asumía que debíamos haber hecho otras cosas y bueno, esto no estaba en los cálculos…En las Retrospectivas (reuniones de retroalimentación donde el equipo revisa su forma de trabajo, comunicación, prácticas de valores y principios) se evidenció esto, y se decidió que se debía hablar con el equipo de trabajo del cliente y ajustar la comunicación.
Esto es un claro ejemplo de aplicar marcos ágiles, sin importar si hay un marco ágil formalmente definido en la relación cliente – proveedor, los empleados del cliente escucharon (sí amigos, la gente que no aplica marcos ágiles en su cotidianidad también escucha) y se hizo un inventario de que faltaba de lo pedido en las historias de usuario, que era nuevo y que se debía corregir… y así 3 ó 4 veces. Importante: Esto lo hicimos desde el principio del proyecto y pudimos superar la situación.
En las entregas de cada sprint (iteración) Como era de esperarse, necesitaban más funcionalidades a desarrollar en el software, el cliente asumía que lo debíamos hacer de inmediato y gratis. Lo bueno es que esas desviaciones estaban “planeadas en el presupuesto” y asumimos nosotros como proveedores algunas y ellos los costos de otra, además el contrato nos protegía, aunque como lo dice el manifiesto ágil: Valoramos más la colaboración con el cliente que la negociación contractual, el contrato lo decía, pero nunca quisimos mirarlo.
¿Saben qué fue fuerte? La experiencia de usuario en la aplicación. El cliente no quiso incluir tiempo para el diseño de la aplicación en el presupuesto, fuimos explícitos en que se necesitaba y al final nos expresó su disconformidad porque el software no era tan ergonómico como debía ser… aunque el contrato lo amparaba no quedamos contentos nosotros. Y aún hoy pensamos que muchísimas empresas pequeñas, medianas y hasta grandes a veces no quieren pagar por diseños de experiencia de usuario, entonces ¿Qué hacemos? ¿Renunciamos a estos negocios? ¿O como las aerolíneas de precios bajos les hacemos explícito que si no lo contratan no pueden quejarse y afrontar su decisión? En esta situación aplicamos temas que hemos aprendido en los Open Space, en las iniciativas ágiles de tantos años y en las discusiones con amigos que aplican estos marcos: “Sale como tiene que salir” y … adelante.
Finalmente se trabajó, se aprendió, se conoció un cliente nuevo, se facturó y se logró un mejor estado financiero para ese mes… y en las mismas circunstancias, creo que lo volveríamos a hacer.
Algunos apuntes que pueden ser o no ciertos, simplemente es nuestro punto de vista:
- Como en todo, la teoría es mucho más fácil que la realidad y hay momentos en los que hay que vender (generando rentabilidad) y asumir riesgos (controlados).
- Llegar a ser ágiles cuando los recursos (tiempo, tamaño de equipo y presupuesto) son muy limitados, es más difícil.
- Amamos la Agilidad, pero en cada circunstancia hay que tomar riesgos y hacer experimentos según el contexto y la realidad del momento.
- Trabajar en proyectos con “alcance fijo”, no quiere decir que no se deba o pueda aplicar trabajo con marcos ágiles, las interacciones frecuentes, con las revisiones oportunas son parte de la clave del éxito de las actividades que hacemos, no es necesario, decir que se está ejecutando un marco ágil, para hacer trabajo en esa vía.
- El cliente ganó también, un producto que están usando, una visión diferente de trabajar y un ejemplo de aplicación en un caso real de marcos de trabajos ágiles.
PD: Gracias a nuestros amigos Carlos Arturo Quiroga y a Jorge Abad por sus conocimientos , revisión y aportes.
Mantente al tanto de nuestras publicaciones a través de nuestras redes sociales: LinkedIn, Instagram y Twitter.
Escucha nuestro Podcast: Transformación Cultural en Latinoamérica
Descarga gratis nuestro eBook sobre DevOps: Descarga Libro Proyecto Ouróboros
