Cómo vimos en el post anterior, estamos estudiando los diferentes escenarios que se pueden dar a la hora de gestionar fechas y cómo aporta Scrum. Continuamos con nuevos escenarios:
¿Qué equipo necesito para llegar?
En algunas situaciones, tenemos bastante claro el alcance que queremos acometer y una fecha cerrada. Sin embargo, tenemos un presupuesto grande, y queremos calcular cuántas personas nos harán falta para poder alcanzar la fecha.
Si no disponemos del equipo que lo va a desarrollar, cuidado. Hay empresas que apuestan por unir a un grupo de expertos que haga la estimación. Que una persona o grupo de personas digan lo que van a tardar otro grupo en hacerlo es una muy mala práctica de desarrollo de software. Es vital, que la persona que va a realizar el trabajo diga lo que se tarda, y si no disponemos del equipo estamos añadiendo más complejidad a la respuesta de “¿Tendremos en la fecha lo que queremos?”
El error es pensar que con equipos grandes conseguiremos un alcance en una fecha concreta. La manida frase de “9 mujeres no hacen un niño en un mes”. No siempre añadiendo más personas aceleramos la capacidad del equipo de desarrollar software, más personas aumenta la cantidad de interacciones entre ellas y, por tanto, el número de conflictos, lo que hace más complejo al grupo.
Una vez más Scrum nos ayuda a lidiar con estas situaciones complejas. Creamos un equipo pequeño que sepamos que es capaz de entregar valor. En las primeras iteraciones ganamos experiencia, y podemos añadir más personas al equipo según decidan ellos. De esta manera, podemos gestionar los riesgos en las primeras iteraciones para saber si llegaremos a la fecha. Imagina que creamos un equipo muy grande, invertimos mucho dinero y todo se va al traste tras mucho tiempo de trabajo porque realmente no era rentable.
No tengo fecha, ¿cuánto tardáis en tener esto?
Otra situación habitual, aparece cuando no tenemos una fecha concreta, pero nos piden que demos una en base al alcance conocido: “necesitamos saber cuándo va a estar para poder gestionar con marketing la promoción del producto”.
En este caso, podemos lanzar muchas preguntas para que la persona que nos pide la fecha entienda la dificultad de darla:
- ¿Me garantizas que no va a haber ningún cambio?
- ¿El equipo va a permanecer estable sin atender otras necesidades de otros equipos?
- ¿Cuántas personas se nos pueden ir en este tiempo?
- ¿Las dependencias con terceros se resolverán en las fechas que nos han prometido?
Todas estas preguntas, reflejan variables que no controlamos, y todo lo que no controlamos nos genera una incertidumbre que nos impide saber en qué fecha exacta tendremos el alcance. Esto es lo que conocemos como un sistema complejo, no sabemos cómo se va a comportar en el tiempo porque hay demasiadas variables que tenemos que despejar.
Para explicar la diferencia entre complicado y complejo, me gusta mucho un símil que me gusta mucho y lo comentaba Frederic Laloux: “Un avión es complicado, tiene muchísimas piezas interconectadas, sin embargo puedes quitarle una pieza y saber cómo se va a comportar el sistema. Un plato de espagueti es complejo, si tiras de uno de ellos no hay ordenador en el mundo que calcule cómo se va a comportar el sistema”
Para gestionar con tanta incertidumbre, podemos crear una alianza en la cúal, nos centramos principalmente en llegar cuanto antes a un producto mínimo viable (MVP). En cada iteración medimos nuestra capacidad de desarrollo y con ello podemos tomar decisiones. No es que no hablemos de fechas de finalización, es que lo haremos cuando sepamos la capacidad del equipo, tengamos experiencia y hayamos despejado muchas de estas variables.
Por tanto, no sabremos pronto cuándo tendremos “todo” hecho, pero desde luego podremos inspeccionar muy pronto el camino que estamos siguiendo.
La competencia sí me da fechas
Un argumento para que nos comprometamos en una fecha en un momento muy temprano es la competencia. Al competir contra otra empresa, el argumento de empezar e ir inspeccionando y adaptando nos puede hacer menos competitivos.
Si hay muchas variables que no controlamos y nos lanzamos a un proyecto con un alcance muy cerrado y una fecha cerrada podemos meter la pata. Si la competencia da fechas, pues adelante, vete con la competencia, y cuando fallen puedes volver a nosotros. Es más, ponle unos SLAs con penalizaciones, es probable que ganes mucho dinero.
Esto va a depender de la estrategia que queramos seguir en el mercado. Muchas empresas juegan a dar fecha para ganar cómo sea para después arreglarlo.
Somos empíricos, tenemos que recorrer todo el camino
Si algo hemos aprendido del desarrollo tradicional de software es que, prometer una fecha en periodos muy tempranos con un alcance cerrado puede ser un problema. Necesitamos tener experiencia para poder hablar de fechas de entrega. Si yo necesito saber cuanto me cuesta ir diez veces de Madrid a Sevilla, tendré que ir una vez para hacerme una idea de lo que supone. Por eso, es vital que haya entrega, si viajando a Sevilla me vuelvo a mitad de camino sigo sin saber lo que supone un viaje completo. Por eso, cuando hacemos una entrega completa (hasta producción, aunque lo pongamos en oculto), entonces entendemos lo que supone trabajar en este contexto y nuestra capacidad de entregar. Con esto, ya podemos empezar a hablar de fechas o bien de alcance.
Eso está muy bien, pero yo tengo una fecha y quiero esto…
Imaginemos que nos solicitan una casa para una fecha concreta. De alguna manera, tenemos un alcance cerrado y una fecha cerrada. Sin embargo, podemos “jugar” con cómo sea esa casa. Si cierro mucho los detalles de la casa (azulejos de un determinado tamaño, muebles a medida y exactos e hilo musical…) en ese caso es probable que me estrelle, sobretodo cuando defino mi éxito con que esté todo para esa fecha.
Sin embargo, si trabajamos el alcance, sabiendo que lo que queremos es una casa, podemos priorizar el trabajo y centrarnos en entregar la mayor cantidad de valor para esa fecha. Por eso, con Scrum lo que podemos hacer es: empezamos a trabajar cuanto antes, tratamos de tener un Producto Mínimo Viable lo antes posible para recibir feedback de los usuarios y podamos tomar decisiones para mejorar con datos reales.
De una manera o de otra, si es cierto que tendremos que hacer un salto de fé, en el sentido de que montaremos un equipo y empezaremos a generar gasto sin tener claro lo que vamos a tener y si es rentable. Ese salto de fe es más barato que estar meses analizando para comenzar sin garantías: “el mapa no es el territorio” y por mucho que analicemos no sabremos lo que cuestan las cosas hasta que las hagamos.
Analizaremos en futuros post otras serie de medidas que podemos tomar para gestionar fechas. ¿Reducir la calidad? ¿Medir valor? ¡Lo analizaremos!
