Cutteando el Scope

3 Feb

De la misma saga que Creepeando el Scope aquí les traigo unas ideas respecto a como, en determinadas ocasiones, podremos acortar el alcance de un proyecto que estamos gestionando.

El alcance de un proyecto se refiere al conjunto de requerimientos (funcionalidades, documentos, capacitación, etc.) que se han acordado, tanto con el cliente, usuarios y demás interesados, para que se encuentren todos entregados al finalizar el proyecto.

Ahora bien, el camino desde que no tenemos ningún requerimiento concluido hasta tenerlos a todos suele ser un camino con obstáculos. Por diversos motivos, muchas veces, en las fechas en las cuales se ha planificado entregar parte de los requerimientos, nos encontramos con que NO tenemos lo que debíamos tener y ya nos vemos dando las explicaciones del caso.

Para gestionar estos escenarios donde debemos dosificar la entrega del alcance del proyecto y disminuir el riesgo de no cumplir con los plazos, les propongo una serie de pasos que pueden ayudar.

Lo primero que se debe enfocar, ante cada entrega, cual es el nivel de expectativa a cumplir en el usuario/cliente y los demás interesados. La siguiente figura refleja este punto:

Las primeras entregas suelen ser las que concentran la mayor ansiedad puesto que se desea comenzar a observar el verdadero avance de un proyecto, y esto tiene relación directa con acceder a funcionalidades implementadas, no prestandole demasiada atención a cuestiones “extras” para ese momento, como son las validaciones de datos o las mejoras vinculadas a la eficiencia del producto. Asi, como primera consideración podemos decir que los requerimientos acordados para una entrega pueden recortarse según el nivel de detalle que la expectativa de la entrega genere. Por ejemplo, en las primeras entregas, de los requerimientos mas importantes a entregar, se tendrá mayor expectativa que los mismos funcionen a que los mensajes de error se presenten en rojo.  Es decir, en las primeras entregas se esperará que todas las funcionalidades acordadas para dicha fecha se encuentren en el entregable y no tanto que para todas esas funcionalidades, sus respectivos manejos de errores sea el final.

Esta estrategia de recortar según el nivel de expectativa la podemos combinar con otras tres estrategias extras:

Reduciendo el Alcance de un Proyecto

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 (en teoría al menos!) para cada una de los requerimientos que se piden.

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

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

Entregar 50% menos de requerimientos

  • Usando un backlog priorizado de trabajo: el Dueño del Producto puede hacer que el equipo trabaje en orden 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..
  • 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 50% menos de detalles en cada requerimiento

  • 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

  • Desarrollar 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.
  • 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.
  • Propuesta: ABMC y Reportes, de baja prioridad y a recortar funcionalidades.

En resumen, y tomando un ejemplo entonces…la semana que viene digamos que tenemos una entrega!!!, con ésta estamos justo en la mitad del proyecto:

  • Según la expectativa del usuario podemos determinar que de los requerimientos a entregar, no solo el usuario deseará evaluar funcionalidades sino también validaciones de datos y escenarios alternativos.
  • Según el análisis de los 3 metodos presentados, optamos por el 3 de manera que priorizaremos los requerimientos a entregar y en los que se encuentren en el tope de la lista, el tridente funcionalidades-validaciones-escenarios sera implementado en su totalidad; para los que se encuentren al final de la lista dicho tridente será mas relajado.

Espero haber sumado. Nos vemos, Gastón.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: