3 Maneras de Reducir el alcance

La forma más común para que los equipos entreguen productos más rápido es reduciendo el alcance de cada producto. Sin embargo, esto no puede hacerse de manera arbitraria. Hay motivos de negocio reales para cada una de los requerimientos que se piden (¡o al menos eso esperamos!).

Bob Hartman nos cuenta 3 formas básicas por las cuales los equipos pueden reducir el alcance de manera exitosa.

Cómo reducir el alcance

Para lograr que un equipo entregue 50% más rápido se puede:

1. Entregar 50% menos de requerimientos.
2. Entregar todos los requerimientos pero con un 50% menos de detalles en cada requerimiento.
3. Entregar todos los requerimientos con distinto nivel de detalle en cada requerimiento.

Veamos en detalle de qué se trata cada estrategia.

Entregar 50% menos de requerimientos

La explicación es obvia, y es la más facil de implementar. Como las metodologías ágiles usando un backlog priorizado de trabajo, el Dueño del Producto puede hacer que el equipo trabaje en órden de prioridad hasta que se haya entregado el suficiente valor para hacer una entrega razonable. El peligro acá es no ser lo suficientemente agresivo sobre cuánto es suficiente. La mayoría de los Dueños de Producto todavía caen en la trampa y agregan más características al producto aunque el mismo ya pueda entregarse. Supongo que esto ocurre porque los Dueños de Producto son conservadores por naturaleza.

Nuevamente, este método es simple y efectivo, excepto cuando los equipos de ventas y marketing "prometieron" características que están con baja prioridad en la lista. Si un equipo entrega 25 de las 26 características prometidas, el cliente podría enojarse. Si entrega estas mismas 25 características cuando se habían prometido sólo 20 van a ser felicitados como héroes. ¡Hay que ser muy cuidadoso con los compromisos externos para poder cumplirlos!

Entregar todos los requerimientos pero con un 50% menos de detalles en cada requerimiento

Esta es un poquito diferente. Evita el problema del método anterior porque se entregan todos los requerimientos. Este método se basa en el hecho de que el 64% de las características se usan poco o nada (según el estudio de Standish Group). Para poder entregar un 50% más rápido, se debería eliminar en promedio el 50% de cada requerimiento, e igualmente no dañaríamos el "núcleo" del software, el cual será usado la mayor parte del tiempo.

La desventaja es que se trata por igual a cada requerimiento, y es probable que recortemos demasiado en algunos requerimientos, y no lo suficiente en otros. Lo que nos lleva al método final...

Entregar todas los requerimientos con distinto nivel de detalle en cada requerimiento

Con este método se desarrollan por completo los requerimientos de mayor prioridad, mientras que los menos importantes se construyen sólo lo suficiente como para poder decir que funcionan bien. Los requerimientos en el medio de los extremos van teniendo cada vez menos características y detalles a medida que disminuye su prioridad. Esto permite que los requerimientos más importantes sean más útiles, y las características menos importantes terminan siendo las menos útiles. Esto salva el problema del primer método ya que se entregan todos los requerimientos, y también supera los problemas del segundo método porque se entrega el máximo valor para los elementos de mayor prioridad.

Conclusión

El primer método se encarga de "cortar" el alcance de manera horizontal (una línea horizontal a través del backlog, mostrando el último requerimiento que se desarrollará). El segundo método corta de forma vertical (una línea vertical por el backlog, mostrando cuánto se desarrollará comparado con el máximo). El tercer método corta de forma diagonal (una línea diagonal hacia la derecha, mostrando cuánto se va a desarrollar de cada elemento del backlog). El primer método es el más común, pero es muy real el problema de dejar afuera características ya prometidas. El último método es superior, pero también el más dificil de lograr.

El último método puede lograrse creando una pequeña parte de cada requerimiento durante las primeras iteraciones. De esta manera el Dueño del Producto sabe que se podrían entregar todas las características en algún momento futuro, si los detalles no importaran. En ese punto el Dueño del Producto puede priorizar cuánto tiempo y esfuerzo quiere aplicarle a cada requerimiento, y así va creando el nivel de detalle apropiado - y como siempre, con la libertad de cambiar prioridades si así conviene.

Es común caer en la trampa de pensar que se necesitan todos los requerimientos para entregar el producto. Si se logramos establecer las expectativas de manera correcta, podremos ver que es muy raro que ese sea nuestro caso.

Articulo Original: DosIdeas