Estimar no siempre es timar

¿Por qué las estimaciones SI aportan valor?

En el mundo del desarrollo de software, existe una opinión común en contra de las estimaciones. Se dice que "estimar es timar". Sin embargo, creo firmemente que las estimaciones pueden ser una herramienta valiosa si se utilizan correctamente.

El problema surge cuando las estimaciones pasan a formar parte del roadmap. En ese momento, tendemos a olvidar que son solo eso, estimaciones. Esto puede acabar generando frustraciones entre la empresa y el equipo de desarrollo, las cuales no comparto. Para mí, las estimaciones son indicadores, no promesas inamovibles.

Una de las principales razones por las que las estimaciones a menudo fallan y los tiempos se alargan es trabajar con requisitos ambiguos. La ambigüedad en los requisitos puede hacer que las estimaciones sean menos fiables. Por ejemplo, si se nos pide incluir una funcionalidad específica en un producto, pero los detalles son vagos o sujetos a interpretación, es difícil proporcionar una estimación precisa. ¿Qué significa exactamente "hacerlo más intuitivo" o "más eficiente"? Estas ambigüedades pueden llevar a malentendidos y, en última instancia, a retrasos en el desarrollo.

Otro desafío importante son las sorpresas relacionadas con las tecnologías. En la actualidad, rara vez desarrollamos el 100% de nuestro código desde cero. En su lugar, aprovechamos componentes y librerías desarrollados por terceros para acelerar el proceso. Esto tiene sus ventajas, como evitar la programación detallada de gráficos o la gestión de bases de datos complejas. Sin embargo, también puede generar dependencias inesperadas. Un simple cambio, como sustituir un gráfico de puntos por cruces o emojis, puede tener un impacto significativo en el tiempo de desarrollo. Además, las limitaciones de las tecnologías utilizadas, ya sean bases de datos, proxies o el lenguaje de programación en sí, pueden surgir inesperadamente a mitad del desarrollo, causando retrasos no previstos.

Tampoco podemos olvidarnos de los "fantasmas del pasado". A veces, las decisiones que ya hemos tomado, pueden crearnos obstáculos inesperados. Un ejemplo común es cuando establecemos ciertas restricciones o suposiciones durante la fase inicial de desarrollo, solo para descubrir más tarde que estas ya no son válidas o apropiadas. Por ejemplo, si en el inicio del desarrollo se decidió que un usuario solo podría tener un proyecto activo a la vez, pero ahora se requiere la capacidad de gestionar múltiples proyectos simultáneamente, esto implica una revisión y actualización significativa del código existente.

El proceso de estimación no es solo una cuestión de números. Comienza con una comunicación clara y continua con el equipo de desarrollo. Es esencial asegurarse de que todos tengan la misma comprensión de lo que se está desarrollando. No puedes saber si la librería que están utilizando es adecuada para tus necesidades, pero es probable que tu equipo lo sepa. Tampoco eres responsable de conocer todos los detalles técnicos del producto y sus limitaciones, pero tu equipo las conoce. Estas conversaciones son cruciales para establecer expectativas realistas y abordar los desafíos desde el principio.

A pesar de que las estimaciones pueden no ser siempre precisas, su valor radica en alinear expectativas y anticipar posibles obstáculos. Requiere un esfuerzo adicional en la comunicación y comprensión, pero puede ser una herramienta valiosa en el proceso de desarrollo.

Algunos podrían argumentar que si las estimaciones no siempre son precisas, entonces no valen la pena. Sin embargo, creo que el valor de las estimaciones no radica tanto en su precisión absoluta, sino en la claridad que aportan al proceso. Si proporcionan una base para la comunicación y la comprensión entre el equipo de desarrollo y los interesados, entonces ya han cumplido un propósito importante. Además, si se continúa estimando a medida que avanza la implementación, es probable que las estimaciones se vuelvan más precisas con el tiempo, ya que el equipo adquiere una comprensión más profunda del proyecto y sus desafíos a medida que el alcance se reduce. Si sigues por este camino, el día antes de terminar, probablemente estimen que falta un día de desarrollo.

Realizar este proceso requiere un esfuerzo extra. Requiere hacer preguntas todos los días y entender lo que hay detrás del número de la estimación. Si el trabajo se reduce a simplemente registrar la estimación en un campo de Jira que luego será auditado, es posible que estés perdiendo el valor real del proceso. Estimar no es solo una tarea administrativa, es una herramienta para la comunicación y la gestión de expectativas.

En resumen, las estimaciones pueden ser valiosas si se utilizan como guías y no como promesas inquebrantables. Ayudan a establecer expectativas realistas y a anticipar desafíos potenciales. Sin embargo, es importante recordar que las estimaciones son solo eso: estimaciones. No deben considerarse compromisos inamovibles, sino indicadores flexibles del camino por delante. Con un enfoque adecuado y una comunicación clara, las estimaciones pueden ser una herramienta poderosa en el proceso de desarrollo de software.

---

Podcast de Tenemos que hablar de producto

La semana pasada sacamos el primer episodio del podcast. ¡Ha tenido muchísimo tirón, espero que os gustase!

¡Ya tengo confirmados los 3 próximos invitados para el podcast de este año! Si quieres venir a hablar, ¡sólo quedan 6 plazas!