Bienvenido, bienvenida a Rodobo, un boletín quincenal que explora la relación entre el diseño de producto, la experimentación, analítica y las empresas.
Si hay una tarea que haya realizado todas las semanas desde hace más de 2 años es estimar. Por eso, me gustaría escribir sobre lo que he aprendido y estoy aprendiendo sobre ello. Probablemente no llegue a ninguna conclusión específica, pero creo que este será uno de esos temas a los que recurriré de vez en cuando.
Por qué estimamos
“¿Cuánto tiempo crees que tardarás en hacer esto?” es una pregunta extremadamente común en mi día a día, y probablemente, una de las más “temidas”.
Y es que, es verdad, en todos los ámbitos de la vida, tanto en el trabajo como en tu vida personal, con tiempo limitado es normal que intentemos controlar cada uno de los aspectos que rodean esa ejecución. Normalmente es imposible y la mayoría de las personas con las que hablo de estimar proyectos, odian hacerlo.
Y he de decir que con razón. En ocasiones, después de todo este tiempo, pienso que es una pérdida de tiempo mal implementada. El problema de ello es que nadie explica qué es realmente una estimación o cómo pensar en estimar. Y como resultado, la pregunta de “¿cuánto tiempo crees que tardarás en hacer esto?” tiene tanto sentido como cualquier otra en la que utilices palabras inventadas.
Esto se agrava por el hecho de que realmente hay mucho en la sencilla práctica de estimar. En mi opinión y experiencia, hacer una estimación perfecta requiere entender de forma profunda y detallada el problema, al tiempo que mucha intuición para saber moverte en la incertidumbre que provoca.
A veces, cuando alguien me dice que estimar es fácil, suelo bromear diciendo que por supuesto que lo es, que solamente necesitas entender de diseño, desarrollo, marketing, producto, estadística, psicología y saber negociar. Casi nada.
Pero, por suerte, no necesitamos ser capaces de estimar perfectamente un proyecto o una tarea para que la estimación sea de utilidad, sino que lo que necesitamos es estimar más, ser conscientes de los errores que se han cometido, aprender de los problemas, anticiparte a los próximos y documentar, de alguna forma, todo lo hecho hasta ahora.
El problema con estimar
En mi experiencia, el problema central de una estimación es que combina dos cosas muy diferentes. Por un lado cómo de grande es una tarea, y por otro cuánta incertidumbre hay sobre ella. Dependiendo del problema que realmente estemos intentando solucionar, necesitaremos combinar estas dos cosas de forma diferente. No se trata únicamente de una sola cosa.
Cuando se nos pregunta “¿Cuánto tiempo crees que tardarás en hacer eso?”, puede que la otra parte espere un solo número como respuesta, cuando la realidad es que no hay una sola respuesta.
Por ejemplo, consideremos el tiempo promedio que podemos tardar en realizar una tarea y el tiempo que podríamos tardar si las cosas, si el curso del proyecto, no va como se espera. Obviamente, estos dos escenarios, en una estimación tienen preguntas diferentes.
La defensa de quienes hacen producto, dan servicios a diferentes clientes, con problemas, aunque similares, enfocados de forma diferente es que cada tarea es completamente nueva y depende de muchos factores.
Y estoy de acuerdo en eso, pero es responsabilidad del equipo controlar esos factores e incluso atreverse a desafiarlos, porque la realidad es que cuando diseñas, desarrollas un producto o defines una nueva funcionalidad, el trabajo es bastante rutinario y el problema no es tan específico como pensabas que sería.
De hecho, lo complicado de un proyecto no es el diseño ni el desarrollo, es entender el problema que tiene una persona y la razón por la cual tú eres la elegida para solucionarlo. De incertidumbre podríamos hablar mucho, cualquier proyecto grande tiene incertidumbre.
Por ejemplo, leyendo sobre arquitectura hace unas semanas se enfatizaba el hecho de que son proyectos propensos a tener estimaciones muy alejadas de la realidad, incluso cuando las tareas son, en cuestión, bastante rutinarias. ¿Significa eso que la estimación está mal? Por supuesto que no.
Entonces, la primera respuesta a “¿Cuánto tiempo crees que tardarás en hacer esto?” es otra pregunta con variantes “¿Cuál es el problema que quieres resolver?”, y dependiendo de cuál sea la respuesta a esa pregunta, darás una respuesta muy diferente a la de la primera.
Incluso es posible que “¿Por qué necesitas saberlo?” sea también un buen desatascador de estimaciones en proyectos con mucha incertidumbre inicial. No por nada sino porque quizás podamos explorar otras alternativas con menor incertidumbre para resolver un problema.
Y es que, en la mayoría de veces, cuando estimamos, lo hacemos para intentar responder preguntas como “¿Cuánto tiempo esperamos tardar en hacer esta tarea?” y “¿Terminaremos este trabajo para esta fecha límite?”. Son preguntas que parecen muy similares pero que son muy diferentes, porque responden a la incertidumbre y a los cambios de forma diferente.
Si queremos saber cuánto tiempo esperamos tardar en hacer una tarea, lo que realmente queremos saber es lo que esa tarea cuesta en promedio. Esto nos permite decidir si merece la pena hacerlo. Si haces cosas que en promedio te generan más ingresos de lo que te cuestan, obtienes un beneficio. No descubro nada, pero así es el negocio, profesionalmente y para proyectos personales como este y el podcast.
Por lo que probablemente lo que necesitemos a la hora de estimar es cambiar el enfoque de la pregunta. Lo llevo pensando mucho tiempo. Podemos ignorar eventos improbables a la hora de estimar, que si hay una posibilidad de que una tarea, un proyecto se complique y resulte más difícil de lo que esperábamos, solamente lo descubriremos un tiempo después de haber empezado. Y por eso citaba que la base es la confianza, comunicación y tener conversaciones que en principio pueden parecer incómodas pero que, en el fondo, son lo más normal cuando se establece esa confianza y comunicación.
Y lo hago porque las personas asumen que si estimas que podrás hacer un proyecto en dos semanas y la fecha límite es dentro de dos semanas y media, eso significa que todo está bien y que no necesitas preocuparte. Piensa en este punto en los improbables, en lo que puede ocurrir. Lo que interesa aquí no es cuánto tiempo tardamos sino lo que tiene que ocurrir en el mejor y en el peor escenario.
Cómo poder estimar
Antes mencionaba que para estimar tenemos que documentar para tener conocimiento de lo que tardamos en realizar en promedio una tarea. Lo repito mucho porque a veces estimamos sin ser conscientes del problema real. Y en esos escenarios, cualquier respuesta es perfectamente razonable, porque serán nuestras opiniones las que guíen esa estimación.
Siempre menciono las estimaciones como plazos de tiempo que nos marcamos para hacer ese trabajo en condiciones normales. Lo interesante de esto es saber cuáles son esas condiciones normales, lo que podríamos denominar como las cláusulas de esa estimación.
No en vano, una estimación no deja de ser una propuesta de condiciones. El tiempo es una de esas condiciones, pero por detrás hay otras tantas que pasamos por alto porque el fin de la estimación, lo que se espera de ella, es una medida de tiempo, no un contrato. Y siento que es aquí dónde fallamos de forma más recurrente.
Esta es la razón por la cual la pregunta más importante al estimar es “¿Cuál es el problema que quieres resolver?”, y cualquier intento de dar una estimación en ausencia de eso es un sin sentido. Lo repito, una estimación debe tener en cuenta el tamaño de la tarea, como la incertidumbre que haya sobre ese tamaño, y cómo combinas esos dos factores depende completamente del problema que estés intentando solucionar.
Este punto es complicado porque en la realidad no tienes un entendimiento tan claramente definido como para saber si hay una incertidumbre grande en el problema o en las tareas que tienes que hacer. El resultado es que, sintiéndolo mucho, no se puede ser tan preciso cuando estimas como lo harías en modelos estadísticos definiendo la probabilidad.
No se trata de eso sino de documentar, de ver en retrospectiva qué salió mal (y qué salió bien para tener esas condiciones normales) en proyectos que se desviaron de las estimaciones iniciales y trazar un plan sobre cuánto tiempo nos llevaría de media si eso surgiera en los proyectos que estimamos, por su complejidad, que pudiese pasar. Y no se trata de ser pesimista sino de tener información.
Incluso a veces la media es el único tipo de estimación que tiene algún sentido para este problema. Y, ¿cómo pensar adecuadamente en el problema? Ese es un tema para otra edición. Este tema, por ahora, lo dejaremos aquí. Lo bueno de hacerlo es que cuando vuelva a ello con más experiencias me daré cuenta de cómo ha evolucionado lo que pensaba en este momento. Si no, ¿para qué escribiría entonces?
Nueva conversación en el podcast
Con Marta Alemán, product designer con background en desarrollo front.
Marta está especializada en desarrollar proyectos desde la idea hasta la construcción final del mismo, empezando por investigación hasta el desarrollo, pasando por conceptualización y diseño.
Hablamos, entre otros temas, de:
Sus aprendizajes siendo freelance
Qué significa para nosotros la práctica del diseño
El papel de la intuición, tendencias y habilidades blandas
Pensamiento de negocio en diseño de producto
La importancia de las herramientas y cómo usarlas
Inteligencia Artificial, no-code y el futuro del diseño y desarrollo
Muchísimas gracias por tu tiempo, Marta. Dejo el episodio aquí abajo y en este enlace.
Otras lecturas y podcasts
Una frase
If you let people's perception of you dictate your behavior, you will never grow as a person. Mr. George Feeny, Boy Meets World.
Algunos datos de esta newsletter
Si te gusta mi contenido, lo mejor que puedes hacer es compartirlo. También he habilitado una página en Ko-fi para que puedas invitarme a un café.
Suscripciones: 2.431 personas. Muchísimas gracias.
Tasa de apertura de la edición anterior: 49%
Clics en enlaces: 9% de los usuarios que abrieron el email hicieron clic en un enlace.
Visualizaciones de la edición anterior: 2.100 visualizaciones.
Nos leemos en 15 días.
Gracias.
Muchas gracias.