Ocurre en muchas ocasiones: más de las que nos gustaría y más de las que queremos admitir. En esta profesión de desarrollo de software, en la que tenemos metodologías, métricas, procesos, calidad, más de una vez nos habremos encontrado sufriendo el complejo de Jack Bauer.
Ocurre de forma progresiva: primero tenemos todo planificado y bajo control, todo parece ir sobre la seda, y cuando menos te lo esperas, salta un problema para el cual no tenías un plan de contingencia. La cuestión no es tanto si sabemos o no planificar, sino más bien cómo afrontar los problemas. Esos problemas que se suelen manejar en un comité y que en más ocasiones de las que nos gusta admitir, tememos escalarlos a ese comité por no asumir responsabilidades.
¿La consecuencia? Pues que trasladamos a nuestros equipos esa responsabilidad, enmascaramos la culpa con una falsa urgencia (o no tan falsa), y movilizamos nuestros ejércitos para afrontar lo que parece ser un capítulo de la serie de televisión "24". Con un plazo imposible de cumplir, nos embarcamos en una tarea sobrehumana, y sustituimos la culpa, la gestión y las metodologías por un compromiso y resolución que nos lleva a ser protagonistas de esa serie, donde hay que salvar el mundo, hacer tareas imposibles, recorrer varias veces toda la ciudad y todo ello en 24 horas.
¿Os suena? Pues sí, esto es el complejo de Jack Bauer, personaje protagonista de esa serie de televisión, y que representa muy bien las situaciones de "bombero" o "apagafuegos" en las que nos vemos inmersos.
Esta forma de afrontar los problemas, la podéis encontrar en la red con otros nombres. Uno que me ha gustado es el antipatrón "apagafuegos". Os recomiendo leer esa web de antipatrones.
Hay que tener mucho cuidado con esta forma de actuar, porque lleva a ser estimulante. Nos podemos sentir héroes salvando el mundo, apagando fuegos constantemente, en ese complejo de Jack Bauer. En lugar de afrontar los problemas como lo que son, no podemos tratar de resolverlos todos a la primera de cambio, en ese ciclo de subida (esfuerzo heroíco de resolver el problema) y de bajada (bajón inevitable que tenemos cuando la situación ya es estable y la adrenalina se agota...hasta el siguiente fuego).
Hay quien ve esta forma de actuar como una adaptación al cambio. Pero adaptarse al cambio no significa afrontar los problemas con sesiones a lo Jack Bauer (es decir 24 horas sin dormir y con esfuerzos histéricos para resolver las cosas). Hay que atajar los problemas de base, porque distraer al equipo de esa forma significa alejarlo del objetivo del proyecto. Esa distracción no supone 24 horas, sino mucho más: el coste de recuperar el ritmo, y también de recuperarse de ese esfuerzo.
Los cambios los gestionamos nosotros, no al revés.
sábado, 24 de mayo de 2014
jueves, 1 de mayo de 2014
Cuidado con las estimaciones ágiles
Hoy os voy a traer un caso real. En estos tiempos en las que las metodologías ágiles están en todas partes, es el momento de reflexionar el qué queremos, pero sobre todo, qué necesitan nuestros clientes.
En concreto, mucho cuidado con las estimaciones ágiles porque los clientes siguen necesitando saber en muchas ocasiones cuándo van a estar disponibles sus aplicaciones, y a qué precio. Os adjunto una conversación que podría ocurrir a pocos metros de donde estáis:
- [Cliente] ¿Cuánto va a costar esto? ¿Y cuánto tiempo tardaremos en tenerlo? La verdad es que tenemos unas fechas límite muy definidas, y el presupuesto no nos da para muchos cohetes.
- [Vendedor/Técnico ágil] Pues es que nosotros no estimamos en horas, sino en StoryPoints. Pero no se preocupe, porque esto es un marco de trabajo Scrum altamente reconocido.
- [Cliente] ¿Ah, sí? Pues que sepas que mientras tanto, te pagaré en BarPoints (tickets del bar). Pero no te preocupes, porque esto en nuestra cafetería de empresa es una forma de pago altamente reconocida.
En fin. Creo que ha quedado claro. Mucho cuidado con las obsesiones y sobre todo actitudes talibanes respecto al agilismo. De nuevo tenemos las balas de plata de nuestra generación. Y de nuevo, hemos de usarlas como lo que son: tan sólo una herramienta más, que hemos de adaptar a cada situación y necesidad.
¿Y tú ...qué les das a tus clientes? ¿Lo que ellos necesitan, o lo que tú les quieres dar?
En concreto, mucho cuidado con las estimaciones ágiles porque los clientes siguen necesitando saber en muchas ocasiones cuándo van a estar disponibles sus aplicaciones, y a qué precio. Os adjunto una conversación que podría ocurrir a pocos metros de donde estáis:
- [Cliente] ¿Cuánto va a costar esto? ¿Y cuánto tiempo tardaremos en tenerlo? La verdad es que tenemos unas fechas límite muy definidas, y el presupuesto no nos da para muchos cohetes.
- [Vendedor/Técnico ágil] Pues es que nosotros no estimamos en horas, sino en StoryPoints. Pero no se preocupe, porque esto es un marco de trabajo Scrum altamente reconocido.
- [Cliente] ¿Ah, sí? Pues que sepas que mientras tanto, te pagaré en BarPoints (tickets del bar). Pero no te preocupes, porque esto en nuestra cafetería de empresa es una forma de pago altamente reconocida.
En fin. Creo que ha quedado claro. Mucho cuidado con las obsesiones y sobre todo actitudes talibanes respecto al agilismo. De nuevo tenemos las balas de plata de nuestra generación. Y de nuevo, hemos de usarlas como lo que son: tan sólo una herramienta más, que hemos de adaptar a cada situación y necesidad.
¿Y tú ...qué les das a tus clientes? ¿Lo que ellos necesitan, o lo que tú les quieres dar?
Suscribirse a:
Entradas (Atom)