¿Cómo hacer un proyecto sin cerrar las especificaciones?

Hacer un proyecto es tan fácil como caminar sobre el agua: lo único que necesitas es que el agua y las especificaciones estén congeladas. Pero ¿y si no podemos congelar el agua o cerrar las especificaciones?

Modelo de triángulo invertido

El desarrollo de software tradicional ha intentado controlar el proceso y el resultado, encorsetando al cliente mediante procesos muy estrictos de ingeniería, escribiendo las especificaciones en documentos de requisitos, documentando  las actas de las reuniones en las que se discuten y graban los cambios en piedra, e intentando bloquear cualquier intento de cambio mediante documentos de control de cambios (generalmente asociados a cambios en el presupuesto inicial) a lo largo de la construcción del software.

Tradicional vs Ágil

La toma de decisiones tradicionales

La mayoría del mercado aborda los proyectos buscando la respuesta a la pregunta: ¿Cuánto cuesta y cuánto se tarda en hacer todo lo que dice el documento de especificaciones? 

Es decir, intentamos fijar las especificaciones del proyecto y estimamos tiempo y recursos necesarios.

Pero como hemos dicho, las funcionalidades no se pueden cerrar, van a cambiar seguro, y por tanto es una pregunta que no puede tener respuesta, y la industria lleva años sin conseguirlo.

 

Toma de decisiones con mentalidad ágil

Nosotros proponemos cambiar de pregunta, y en su lugar preguntarte: ¿cuál es el mejor proyecto que puedo hacer en el tiempo que tengo y con estos recursos de los que dispongo? 

Es decir, proponemos fijar el plazo de entrega del proyecto y los recursos disponibles y ponernos a trabajar para entregar el mejor proyecto posible en esas condiciones. Siempre con la idea de construir el mínimo producto viable, con le objetivo de validar que nuestra hipotesis de negocio es acertada 

Invertir en tiempo y en recursos

Para contestar a esa pregunta sobre la toma de decisiones, debemos contar con herramientas y principios agiles, y en especial gestionar  el proyecto utilizando una matriz Coste vs Beneficio.

coste vs beneficio

 

Con las funcionalidades en esa matriz es fácil saber por donde empezar: 

  1. Las de menor coste y mayor beneficio, no era dificil 😉
  2. Las de mucho coste y mcho beneficio son las difícil, son decisiones estratégicas que hay que meditar.
  3. Esta claro que nadie querrá hacer las de mucho coste  y poco beneficio

Sin embargo la mayoría de los proyectos se desvían y se embrollan al implementar las de poco coste y poco beneficio. Son las típicas que se realizan por el “ya que estamos”. Al final se invierte tiempo y recursos en ellas, en detrimento de otras más valiosas para el negocio. 

La revisión continua de la relación coste vs beneficio debe de estar presente durante toda la vida del proyecto; si pudiéramos congelar las especificaciones, en un primer análisis podríamos decidir cuales abordar. Pero mientras se está desarrollando, nuestros competidores lanzan nuevas funcionalidades que se deben de incorporar a los desarrollos, descubrimos que algunas que parecían fáciles al abordarlas tienen una complejidad técnica no prevista, o al hacer una funcionalidad descubrimos que otras que no habíamos previsto son imprescindibles, etc. 

No debemos de olvidar tampoco el principio de “menos es más”. Al hacer menos funcionalidades, nos centramos en las realmente imprescindibles para el negocio y ayudan a la adopción del usuario final, ya que tendrá menos funcionalidades que entender y una interfaz mucho más sencilla. Cuando hay que organizar muchas funcionalidades para dar acceso a los usuarios finales, las interfaces se vuelven  complicadas.