El cono de incertidumbre en las estimaciones
Podemos definir el proyecto en términos del esfuerzo limitado de tiempo que es requerido para lograr un objetivo. El cono de incertidumbre es la herramienta que utilizamos, consiente o inconsciente, para realizar nuestras estimaciones, llamada en ocasiones margen de error o colchón de tiempo.
La incertidumbre se encuentra en función del nivel de definición de las fases del proyecto, y tiene una repercusión directa en la estimación de costos y plazo de ejecución; estos costos pueden variar desde 0.25x hasta 4x, siendo la “x” el costo real final que solo se conoce con certeza al final del proyecto.
La incertidumbre no beneficia a ninguna de las partes y no hace más que transferir el riesgo de una parte (Cliente) a las otra (Proveedor). Un proyecto que se excede en tiempo y costo solo perjudicará a la parte que asume el riesgo.
En el eje vertical se muestra el grado de error (o incertidumbre) que puede tener una estimación, creada por personas con habilidades para ello. La estimación representa el alcance en términos del esfuerzo, costo y tamaño del proyecto.
Estrechez del cono de la incertidumbre
Unas de las preguntas frecuentes de los Managers y Clientes es: “¿Si te doy algunos días más para trabajar en la estimación, puede disminuir la incertidumbre?”, lo cual es una petición razonable, sin embargo, no será posible cumplirla; varios estudios han encontrado que la precisión en la estimación de software depende del nivel de refinamiento de los requerimientos del Cliente, así como la efectividad de transmitirlos. Entre más refinados los requerimientos y su contexto, se puede obtener mayor precisión en la estimación.
Los desarrollos de software por naturaleza contienen una variabilidad alta y la única manera de bajar la variabilidad es realizando un proceso de Ingeniería de Requerimientos que controle o disminuya dicha variabilidad, con el objetivo que se tenga mejor certidumbre de las expectativas del cliente.
Unas de las preguntas frecuentes de los Managers y Clientes es: “¿Si te doy algunos días más para trabajar en la estimación, puede disminuir la incertidumbre?”, lo cual es una petición razonable, sin embargo, no será posible cumplirla; varios estudios han encontrado que la precisión en la estimación de software depende del nivel de refinamiento de los requerimientos del Cliente, así como la efectividad de transmitirlos. Entre más refinados los requerimientos y su contexto, se puede obtener mayor precisión en la estimación.
Los desarrollos de software por naturaleza contienen una variabilidad alta y la única manera de bajar la variabilidad es realizando un proceso de Ingeniería de Requerimientos que controle o disminuya dicha variabilidad, con el objetivo que se tenga mejor certidumbre de las expectativas del cliente.
El cono representa la incertidumbre, que se tiene por naturaleza al realizar la estimación por las personas con habilidades para ello, por lo que es muy factible que el cono sea peor (ver Figura anterior) cuando las personas que realizan las estimaciones no tienen las habilidades adecuadas para ello. Es imposible tener mejor exactitud solo es posible tener mejor suerte
La estrechez del cono puede eliminar variabilidad en función de la metodología y prácticas que se sigan, por ejemplo; definir el Documento de Visión, Modelo de contexto, Prototipos (o Wireframes), entre otros, pueden ayudar a estrechar la incertidumbre del cono, ya que ayudan a disminuir los riesgos causados por un pobre nivel de detalle de los requerimientos que entran.
Es importante mencionar, que no se intenta detallar el producto entero, sino lo mínimo necesario para reducir la estrechez
Es importante mencionar, que no se intenta detallar el producto entero, sino lo mínimo necesario para reducir la estrechez
Relación entre el cono y el compromiso
Las compañías de software inapropiadamente sabotean sus propios proyectos al comprometerlos al inicio del cono de la incertidumbre. Si una organización se compromete en la etapa de concepto inicial o durante la definición del producto el factor de error está estimado entre 2x y 4x.
El comprometerlo al principio del cono, hace que el proyecto tenga una predictibilidad indeterminada, incrementando el riesgo, la ineficiencia del proyecto, el deterioro de la administración y el éxito del proyecto.
Por lo que se recomienda que el compromiso no se realice en dichas etapas, donde la amplitud del cono hace que las organizaciones sean ineficientes y absorban los riesgos de ello.
Un buen punto para realizar compromisos puede ser, donde la incertidumbre del proyecto esté cerca del 30% (1.3x), en dicho punto se tiene un mejor control y monitoreo de los entregables y avances del proyecto, mejora sustancialmente la eficiencia de los equipos involucrados en el desarrollo
Referencias
http://www.construx.com/Page.aspx?hid=1648
http://www.measurecontrol.com/cono-de-incertidumbre/
Las compañías de software inapropiadamente sabotean sus propios proyectos al comprometerlos al inicio del cono de la incertidumbre. Si una organización se compromete en la etapa de concepto inicial o durante la definición del producto el factor de error está estimado entre 2x y 4x.
El comprometerlo al principio del cono, hace que el proyecto tenga una predictibilidad indeterminada, incrementando el riesgo, la ineficiencia del proyecto, el deterioro de la administración y el éxito del proyecto.
Por lo que se recomienda que el compromiso no se realice en dichas etapas, donde la amplitud del cono hace que las organizaciones sean ineficientes y absorban los riesgos de ello.
Un buen punto para realizar compromisos puede ser, donde la incertidumbre del proyecto esté cerca del 30% (1.3x), en dicho punto se tiene un mejor control y monitoreo de los entregables y avances del proyecto, mejora sustancialmente la eficiencia de los equipos involucrados en el desarrollo
Referencias
http://www.construx.com/Page.aspx?hid=1648
http://www.measurecontrol.com/cono-de-incertidumbre/
No hay comentarios:
Publicar un comentario