- Imaginémonos un proyecto donde planteamos que al 75% del tiempo del proyecto, el valor del alcance logrado era de $100.000.0000, pero si para esa fecha el valor de alcance logrado es de $60.000.000, este último valor corresponde al VALOR GANADO a la fecha..
Lo triste es que si con estos $60.000.000 y 75% del tiempo del cronograma el equipo del proyecto se la pasó haciendo:
- documentación,
- prototipos,
- tablas paramétricas
- funcionalidades que no correspondían al core del negocio,
Lo que hicieron pudo pudo haber sido "muy bueno - funcionar muy bien - ", "muy bonito" pero sino lograron avanzar en lo realmente importante de poco o nada sirve. (se cancela el proyecto por alguna razón externa extraña y ese tiempo y dinero invertido no aportaron a su propósito dentro del negocio del cliente)
En las metodologías ágiles nos enfocamos en el valor de negocio, o sea en las funcionalidades que permiten al cliente poner a funcionar su negocio lo antes posible (buscando cumplir siempre con el principio de pareto : 20% de las funcionalidades que aportan al 80% del negocio), documentando solamente lo realmente importante y aplazando funcionalidades:
- nice to have (seria lindo / chévere que hiciera..)
- o ya que...
- "ya que" estamos haciendo esto.. hagamos aquello
- que solo van a hacer usadas por una persona cada año (o similar) y que se obtienen con query a base de datos
- Programar casos que en el proceso de negocio nunca se presentarán o que se resuelven diciendo "el sistema no soporta esta funcionalidad." o si se dá el caso miraremos si lo hacemos en una próxima versión.
- que emulan al excel, perfectamente pudiendo exportar a excel y allí realizar el tratamiento de datos adecuado (he visto muchos sistemas así.. ¿¿¿ustedes no??? )
Por lo tanto VALOR DE NEGOCIO y VALOR según el PMI son distintos.
Y lo que sería más sensato llamar a la técnica del valor ganado(EVM), mejor como "TÉCNICA ALCANCE COMPRADO/LOGRADO", pues quizás ese alcance comprado/logrado sea o no sea de valor para el negocio y los índices de avance SPI, Y CPI servirán para determinar cuanto estamos cumpliendo con el plan, pero no realmente cuanto valor estamos generando para nuestro cliente.
Nota:
Para una mayor precisión sobre el tema sugiero leer el Chaos Manifesto del 2013, del Standish Group( http://versionone.com/assets/img/files/ChaosManifesto2013.pdf ) el cual cito textualmente: "Our analysis suggests that 20% of features are used often and 50% of features are hardly ever or never used. The gray area is about 30%, where features and functions get used sometimes or infrequently. The task of requirements gathering, selecting, and implementing is the most difficult in developing custom applications. In summary, there is no doubt that focusing on the 20% of the features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction. After all, there is never enough time or money to do everything. The natural expectation is for executives and stakeholders to want it all and want it all now. Therefore, reducing scope and not doing 100% of the features and functions is not only a valid strategy, but a prudent one. "
Nota:
Para una mayor precisión sobre el tema sugiero leer el Chaos Manifesto del 2013, del Standish Group( http://versionone.com/assets/img/files/ChaosManifesto2013.pdf ) el cual cito textualmente: "Our analysis suggests that 20% of features are used often and 50% of features are hardly ever or never used. The gray area is about 30%, where features and functions get used sometimes or infrequently. The task of requirements gathering, selecting, and implementing is the most difficult in developing custom applications. In summary, there is no doubt that focusing on the 20% of the features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction. After all, there is never enough time or money to do everything. The natural expectation is for executives and stakeholders to want it all and want it all now. Therefore, reducing scope and not doing 100% of the features and functions is not only a valid strategy, but a prudent one. "
