Esta entrada va de “recortar”, de quitar funcionalidad en un producto/proyecto y de cómo mediante esa técnica podemos intentar conseguir mantener los proyectos bajo control.

¿De dónde viene esto de recortar?

La primera vez que leí sobre esto fue en uno de mis libros favoritos sobre gestión de proyectos: “Rapid Application Development” de McConnell (también quizá mi autor preferido). Hablaba del concepto de triage que creo que tiene una traducción difícil pero viene a ser algo así como decidir a quién salvar y a quién no basándose en la gravedad de sus heridas cuando hay una catástrofe, conflicto, etc. El caso es que McConnell explicaba el triage como una forma de decidir qué entra y que no en un proyecto en un momento dado.
Puede parecer evidente pero ese concepto marcó la diferencia para mí: hasta entonces todo el tema de planificación, estimación y demás siempre acababa chocando con la idea de trabajar más horas para poder encajarlo todo y que diera tiempo. Esta idea lo cambiaba todo: deja cosas fuera. Así de simple.
Claro, McConnell dice que hay veces en las que es más importante entregar a tiempo aunque falten funcionalidades, que no llegar para nada. Una idea interesante que además es prácticamente la clave de todos los métodos ágiles, el desarrollo incremental, etc, etc.
En mi opinión (especialmente en desarrollo de productos, pero creo que también en proyectos porque siempre abre las puertas a la negociación) es siempre mejor poder entregar 3 funcionalidades completas en un momento dado que no poder entregar absolutamente nada porque tenemos 5 a medias. Abre las puertas a poder sacar un producto antes que la competencia (esto lo menciona McConnell en su libro), a poder negociar con el cliente (oye, tenemos 3 características listas para poner en producción, con esto podéis empezar a trabajar perfectamente porque lo que falta son puntos adicionales… y con esto comenzar a facturar) y a tener una solución de respaldo en el equipo (cubrirte las espaldas estando siempre, o casi, listo para la entrega).

Recortar siempre funciona

Me he puesto a escribir esto porque el otro día apliqué, de forma casual, esta misma técnica en la vida real, y funcionó bien: estábamos visitando una serie de sitios y comenzaba a hacerse tarde. Nos faltaba un único lugar por ver y posiblemente nos daría tiempo a visitarlo deprisa pero, decidimos dejarlo para otra ocasión y regresar. Vamos, eran las 6 y algo de la tarde, teníamos una hora y pico de vuelta hasta el punto de partida y en lugar de continuar volvimos.
La primera idea que me pasó por la cabeza fue: “¿y qué hacemos el resto de la tarde?”. Porque claro, veía que al final nos iba a sobrar tiempo si no visitábamos ese último sitio… que sería una “pérdida de tiempo”. Al final dimos la vuelta, como dije, pero: en lugar de a las 6 y pico eran casi las 7 cuando comenzamos el regreso, llegamos en algo más de una hora, las 8 y algo, así que no “sobró tiempo” precisamente (siempre hay algo que se complica), y sin embargo nos dio tiempo a volver sin prisa y nos dimos cuenta que de ninguna forma podríamos haber visto el último sitio. Nos dio tiempo a volver, cenar tranquilamente, dar una vuelta… vamos, un buen plan para un fin de semana tranquilo.
¿A dónde voy con esto? Pues que la primera impresión cuando quitas una característica de un SPRINT y dejas algo de holgura es: “qué vamos a hacer con el tiempo que sobra?”. Se crea como una cierta sensación de “desasosiego” en la cual se tiende a pensar que vamos a acabar con los brazos cruzados arrepintiéndonos de no haber metido la característica XXX. Al final, desgraciadamente (o no), eso nunca pasa: las cosas se alargan un poco, siempre se tarda algo más de lo esperado y el haber quitado esa característica nos permite llegar al final del camino en condiciones en lugar de con la lengua fuera y con cosas a medias (como el último punto del camino visitado en 10 minutos en lugar de con calma).

Recortar es la principal herramienta para maniobrar el proyecto

Siguiendo con el mismo autor, en “Software Estimation: Demystifying the Black Art” McConnell cuenta que gestionar un proyecto es posible cuando la diferencia entre la estimación y el tiempo disponible es menor de un 20%. Por encima de esa diferencia el proyecto simplemente es imposible (proyecto suicida, por cierto, otro buen libro sobre este tipo de proyectos es Dead March, de Yourdon, otro clásico), y o se cambian los objetivos o mejor no meterse (o asumir en dónde estamos). Precisamente cuando esto ocurre (y hay muchos más dead march de los que pensamos) estar preparados como equipo y gestionar las funcionalidades a implementar correctamente (cubrirnos las espaldas entregando de forma incremental) puede ser totalmente clave.
Al final recortar puede ser postponer para una siguiente versión, pero quitar de la actual a fin de cuentas.

El impacto del recorte

Hay un aspecto de esto de recortar que me preocupa especialmente y no es el impacto que puede tener en el resto de gente implicada en el proyecto (directivos, clientes, dptos. de marketing, etc), sino el que tiene en el propio equipo de desarrollo.
Los desarrolladores, por alguna razón, (para dar más bibliografía recomendaría el clásico Peopleware), somos demasiado optimistas (de ahí que la Ley de Parkinson, vamos, que el trabajo siempre se extiende hasta ocupar todo el tiempo disponible, no se aplique al desarrollo, y de ahí que como muy bien dice McConnell en “black art”, el problema de la industria de software no sea de “estimación” sino de “subestimación”. Nunca te preocupes por sobrestimar, si los desarrolladores tienen tiempo de sobra, terminarán igualmente a tiempo. Ignorar este punto supongo que crea enormes quebraderos a todos los “jefes de proyecto”…). Como iba diciendo, que somos muy optimistas y siempre pensamos que nos va a dar tiempo a terminar todo, y lo que es peor, nos sentimos mal si nos dejamos algo fuera. De hecho el sentimiento inicial ante el recorte es algo así como de “culpabilidad” ya que el equipo siente que “está haciendo trampa”. Y no es fácil superar ese sentimiento. Hay que explicarlo, hay que coger un poco de distancia, hay que priorizar, y hay que entender que tenemos limitaciones claras de tiempo y de personal y que hay que hacer lo que mejor se pueda con lo que tenemos. Y que para eso hay que recortar.
No sé si esto parece una tontería o no, pero la realidad es que es un punto muy a tener en cuenta para que el desarrollo no se descontrole debido a la desmoralización del equipo.
Siempre me viene a la mente el tema de “ingeniería vs ciencia” o lo de “empresa vs universidad”. Me explico: la tendencia natural de muchos de nosotros es la de intentar lograr la solución perfecta (al menos la que creemos que lo es), lo que normalmente es una aproximación muy buena desde el punto de vista “científico” (o de práctica universitaria) y nos sentimos mal ante la solución “de compromiso”: hacerlo lo mejor que puedas teniendo en cuenta que lo importante es respetar las restricciones del proyecto, y el tiempo suele ser la mayor de ellas. Esto último es casi la definición de ingeniería (o de aprox. más empresarial). Vamos, el tema de “mejor algo que funcione bien en la fecha correcta que una maravilla de la técnica con 4 meses de retraso, acumulando pérdidas, poniendo en peligro el proyecto, la empresa, etc, etc, etc”. Curiosamente esto último encaja con todos los métodos ágiles y la idea de “release often and frequently” y lo de “tener algo cuanto antes” (implicaciones empresariales sobre este tema en Rework). Y no hace falta recurrir a un gurú de scrum, la sabiduría popular ya decía “lo perfecto es enemigo de lo bueno”, ¿no?
En definitiva, que hay que explicar siempre al equipo cuáles son los objetivos globales, y que para tener una versión del sistema en la fecha X, es mejor dejar fuera unas cuantas características que llegar sin tiempo, sin haber probado y sin nada que entregar. Cuando todos crean esto firmemente no habrá problemas de motivación ni de entendimiento. Una vez que sepáis cómo hacerlo (variará en cada caso), repetidlo con frecuencia porque todo desarrollador tiende a olvidarlo rápido

Priorización

Y una vez que todos nos creemos que esto de recortar va bien… ¿cómo lo hacemos? ¿Qué se deja fuera? Vuelve el debate y el problema. En el fondo es fácil, hay que identificar aquello que realmente es importante considerando los objetivos globales del proyecto. Se dice muy fácil pero luego no lo es tanto porque nos metemos en nuestra burbuja y tendemos a perder la visión global un poco, y nos parece que esa característica super-hacker es muy, muy importante cuando al final el usuario ni la va a ver.
“Black art” nos vuelve a dar unas cuantas pistas: me gusta la técnica T-Shirt sizing que consiste en clasificar cada característica con una escala sencilla en 2 aspectos: desde el punto de vista de implementación y desde el punto de vista de “impacto de negocio”. Por ejemplo, desde el punto de vista de desarrollo:
• Funcionalidad 1: pequeña
• Funcionalidad 2: grande
• Funcionalidad 3: mediana
Y desde el punto de vista de negocio:
• Funcionalidad 1: alto
• Funcionalidad 2: medio
• Funcionalidad 3: alto
Nos llevaría a planificar primero la Funcionalidad 1 (alto impacto y poco coste de implementación), luego la 3 y dejar para lo último (incluso potencialmente fuera) la Funcionalidad 2.
Como decía, McConnell lo explica mucho mejor y en detalle en “Black art”, así que guardad el “puntero”.
Hay otro libro muy conocido “Agile Estimating and Planning”, de Mike Cohn que dedica un buen número de capítulos a cómo priorizar: desde a nivel financiero hasta un punto que considero muy interesante y que es “prioritizing desirability” (capítulo 11) y en el que introduce el modelo de Kano de satisfacción de cliente para identificar qué características son las que hay que implementar primero basándose en si son obligatorias (sin ellas el producto no sirve aunque no “emocionan” a nadie), lineales (cuántas más, mejor), o realmente “innovadoras” (aquellas que marcan la diferencia realmente). Incluso habla de formas de trabajar en las que te saltas alguna característica obligatoria (poniendo los pelos de punta a los desarrolladores más “científicos” ) para tener antes el producto en la calle impactando con “delighters” (como él los llama) y así ganar a la competencia.
Cohn explica cómo hacer encuestas a clientes para saber, de forma objetiva, de qué tipo es cada funcionalidad (Kano model).

User pain

La técnica que usamos en Códice para priorizar bugs es el “user pain” y nos permite “objetivizar” un poco los bugs que metemos en nuestro sistema de “issue tracking”. Básicamente en lugar de meter prioridad alta, media, baja (siempre es alta!!) respondemos a ciertas preguntas en plan:

Hay un cálculo por detrás que da un valor de 1 al 100 (100 es mucho “dolor”) según las respuestas y luego tenemos la lista priorizada, intentando no tener nunca bugs por encima de un valor 30 (de hecho ahora que lo miro veo que tenemos uno del 29!).

Conclusión

Recortar es una “trampa” fantástica que permite que todo encaje. No podíamos aplicarlo en el colegio (“profe, no me examine de los temas 5 y 6 que no me ha dado tiempo a estudiarlos, pero los 4 primeros me los sé de memoria!”) y eso nos ha marcado mucho, pero en “la vida real” puede ser clave para tener éxito en los proyectos y además hay mucha bibliografía aplicable al tema.