Glen escribe mucho sobre la pretendida imposibilidad de hacer una estimación real al inicio del proyecto, alegando que en realidad no se sabe nada del mismo. Y usa para referise a esta imposibilidad, el término #NoEstimates.
En su post del 16 de Julio de 2013, Glen aclara que no se trata de desarrolladores que quieran o no hacer estimaciones. No se trata de explorar nuevas formas de hacer las cosas o pretender que se és Yoda y aplicar preguntas de de lógica invertida, o de bloquear a la gente cuando no responden a las preguntas difíciles.
La conversación de #NoEstimates gira en torno a dos puntos:
- Dado un presupuesto fijo, hay que decirle al cliente lo que puede obtener por él en términos del mínimo producto viable (Minimally Viable Product).
- Dado un conjunto de cratacterísticas del mínimo producto viable que se requiere para salir al mercado, hay que decirle al cliente cuando se van a tener cubiertas.
Porque el cliente tiene una cantidad finita de dinero. El cliente tiene una fecha clara en la que su necesidad debe estar resuelta. Ambas deberían tener un rango de valores y un grado de confianza en esos valores.
Entonces, el razonamiento debería ser: "Se necesitan más o menos estas características para un mínimo producto viable, más o menos en esta fecha, o antes. Veamos si se puede establecer un costo que tenga sentido, para que el cliente pueda tomar algunas decisiones sobre si esas las fechas y el conjunto de características del mínimo producto viable son alcanzables".
Es decir: "Hay que decidir cómo se va a gastar el dinero asignado para el proyecto o conseguir más dinero terminar en la fecha requerida".
Como señala Glen, al final solo se trata de tomar decisiones. No aquellas tomadas por los desarrolladores (que vendrán después). Hay que tomar decisiones de negocio a cerca del proyecto. Acerca de los costos y el cronograma del proyecto. Acerca de las capacidades requeridas que serán obtenidas como resultado de la ejecución del proyecto y el valor de negocio entregado por estas nuevas capacidades.
Todo se trata de la toma de decisiones. No las decisiones tomadas por los desarrolladores - que viene después. Sino las decisiones de negocio sobre el proyecto. Sobre el costo y cronograma del proyecto. Acerca de las capacidades necesarias producidas por el proyecto. Sobre el valor de negocio obtenido al explotar esas nuevas capacidades.
Y al final todas las decisiones de negocio terminan en dinero y tiempo: ¿Cuánto? y ¿Cuándo?
Para tomar decisiones sobre el proyecto hay que saber
- Cuánto va a costar,
- Cuando se va a terminar, y
- Cuál es el mínimo producto viable que se va a obtener al final, por el dinero y tiempo invertidos.
Si no se sabe alguna combinación de estos factores no se pueden tomar decisiones.
Si no sabe algo sobre el tiempo y el costo requerido, el cliente - el dueño del dinero - difícilmente podrá tomar decisiones sobre el resultado esperado. ¿Cuándo es que las capacidades producidas generarán el resultado esperado?
Además, hay muchas ideas incorrectas alrededor del tema de estimaciones. Este y otros temas son revisados en otro artículo:
- Se dice que no es posible estimar cosas que nunca hemos hecho antes. Para Glen esto simplemente no es cierto, porque no hay mucho que no se haya realizado antes. Si el Administrador asignado al proyecto realmente no sabe nada sobre el trabajo que va a realizar, probablemente no sea la persona adecuada para el proyecto.
- Las estimaciones son conjeturas, porque no sabemos que nos depara el futuro. Dice Glen que esto es un error fundamental, que implica falta de conocimiento sobre cómo hacer estimaciones.
- Debido a que hacemos entregas constantes, no vamos a tener que estimar (como en métodos ágiles Nota del Traductor). Esta afirmación hace caso omiso de la necesidad de conocer los valores de Estimate To Complete (ETC) y Estimate At Completion (EAC).
- Las estimaciones son un desperdicio, deberíamos estar codificando para generar valor para el cliente. El cliente tiene la necesidad básica de saber cuánto va a costar producir el nuevo valor y cuando dicho valor será entregado. Esto es fundamental para el negocio, para poder tomar decisiones.
Los plazos matan la innovación y reducen la calidad. Dice Glen que esto sólo es cierto si no se planea adecuadamente. Todo el trabajo del proyecto es probabilístico. Este comportamiento probabilístico (y estadístico) exige planificar y gestionar en presencia de incertidumbre. Todas las incertidumbres deberán tener planes de manejo específicos: Ya sea márgenes para protegerse de variaciones que se producen de forma natural, o actividades específicas de protección contra sucesos probables que puedan producir resultados no deseados.
Aquí hay algunas lecturas que sirven de punto de partida para aclarar y desmentir estos conceptos:
Cómo estimar casi cualquier entregable de software en 90 segundos - Este es punto de partida para aprender a estimar proyectos de software. Es un método de búsqueda binaria, que dará una estimación con un 85% de confianza en 90 segundos o menos. Si se tiene experiencia en el dominio del problema, se puede estimar. Si no se puede estimar, es probable que no se tenga experiencia en el dominio del problema.
¿Cómo estimar trabajo que nunca se ha hecho antes? - Este es un lamento común. Si nunca se ha hecho esto antes, ¿cómo poder estimar cuánto tiempo va a tomar? Hay michas formas de hacerlo: Documentos de referencia, modelos paramétricos. modelos de Monte Carlo, etc.
Las estimaciones no son conjeturas, dice Glen. La estimación es la aproximación de algún valor para algún propósito, incluso si los datos son incompletos, inciertos, o incluso inestables. Típicamente, la estimación se deriva de una fuente estadística de datos - ya sea observada o de referencia.
No hay comentarios.:
Publicar un comentario