Yo te estimo

¿Cuánto tardas en comprar en el almacén de la esquina y volver? Esa pregunta tiene una respuesta que todos conocemos y aproximadamente es de 5 o 10 minutos. Ya sabemos dónde se encuentra el lugar que deseamos y cuáles son los productos que tenemos. Conocemos los tiempos de atención del personal y el horario que hay mas gente. Eso hace que podamos planificar nuestra cena sin problemas y que nada faltará. Sin embargo podemos encontrarnos con problemas, tal vez no se encuentra algún producto, tal vez salimos tarde y ya cerró o hay demasiada gente. O nos encontramos con alguien en el camino y nos desviamos a tomar un café o revisamos que teníamos que comprar más cosas y lo que parecía que nos llevaría unos minutos pasa a ser media hora o más. 
Que pasa si nos preguntamos cuanto tiempo lleva reparar un auto, encontrar una falla en una máquina o construir un puente. Incluso preguntas más complejas como cuándo se recuperará la economía o cuándo será la próxima pandemia. 

Algo un poco más cercano al día a día de un desarrollador sería la estimación de un proyecto o funcionalidad de software a medida. Todos sabemos que necesitamos diferentes perfiles, experiencias, habilidades en diferentes tecnologías. Aparecerán complejidades propias del proyecto y luego surgirán otras a partir de las relaciones humanas. 

En la mayoría de los casos se tiende a subestimar las tareas debido a que en experiencias anteriores sabemos la solución y pensamos que conocemos el camino. ¿Cuántas veces nos pasó de intentar implementar algo funcionando en un ambiente que dejó de funcionar en otro? En la industria del software, incluso aquello que sabemos que funciona, debemos verificarlo porque como dice Murphy. ¨Si algo puede fallar, fallará. Es por eso que necesitamos realizar pruebas de test unitarias y de integración para diferentes escenarios y así considerar una calidad aceptable para una nueva pieza de software. 

Necesitaremos conocer el dominio de todas las posibilidades que existen y crear un caso de prueba para cada uno de esos posibles escenarios. Así poder darnos por satisfechos cuando se ejecuten correctamente en nuestro ambiente aunque eso no garantice al ciento por ciento su fiabilidad cuando se encuentre productiva esa pieza de software.

De esta forma se intentará minimizar errores y así aumentar el retorno de la inversión ya que ese producto de software comenzará un camino hasta llegar a ser productivo. Cuanto más cerca de ser productivo se encuentre y tenga que volver a ser tomado por un desarrollador porque ha fallado, será más caro y disminuye su retorno. El peor caso es que el error suceda en producción ya que se estará impactando en el usuario final, teniendo además de la pérdida económica la baja de reputación.

Volviendo a la estimación del trabajo, sucede que para estimar solemos cometer errores en el pronóstico. Existen generalmente lo que llamamos sesgo positivista y se tiende a considerar menos tiempo del necesario para hacer un trabajo porque no consideramos escenarios alternativos ya que desconocemos todas las posibilidades que puedan aparecer. 
Es por eso que para estimar debemos conocer bien cada uno de los componentes a realizar, su funcionamiento y su contexto en toda la aplicación. Es necesario conocer los ambientes donde serán implementadas y también las complejidades que puede tener el cliente y su negocio. 

Es fácil equivocarse porque nuestro cerebro puede visualizar solamente lo conocido en el camino de esa pieza del software, pero además de ello debemos imaginarnos aquellos posibles escenarios que puedan suceder. No debemos caer en la trampa de lo conocido. No subestimar las tareas y comprender que cada uno de los componentes es probable que falle. Habitualmente se deberá adicionar algún parche a lo ya realizado una vez que la pieza de software se encuentre productiva, pero debemos minimizar esos ajustes. 

Todo esto no significa magnificar la estimación sino es un recordatorio para estar alertas de que tenemos que conocer muy bien todo el recorrido y el contexto de lo que estamos haciendo y modificando para que la estimación sea lo más precisa, posible. Anotar los pronósticos y luego verificar los tiempos resultantes es una buena práctica que ayudará a mejorar estimaciones. Mientras tanto quedará asombrado por los resultados.

Como una buena practica, podría incluirse la revisión de estimaciones en la ceremonia retrospectiva de un sprint, en donde todo el equipo pueda participar y aprender sobre los resultados obtenidos. La sinceridad evitando sesgos a la hora de plantear nuevas estimaciones y la experiencia en cada una de estas revisiones ayudará a ir generando mejores resultados. En caso que las tareas sean conocidas, el riesgo podrá minimizarse y el suplemento de tiempo para imprevistos sera menor a aquel que pueda tener una tarea desconocida que implique investigación o trabajo con nuevos componentes, interfaces, etc.

En una sesión de planificación deberá tenerse en cuenta ademas el skill (habilidades y conocimientos) de la persona encargada y su familiaridad con el entorno de trabajo. Como recomendación a la hora de escribir requerimientos podemos citar que siempre es bienvenido el detalle en las especificaciones de las historias o defectos reportados para evitar malentendidos. El análisis profundo de los casos ayuda a realizar verificaciones del funcionamiento por parte del desarrollo antes de la entrega de ese producto de software. El objetivo en la planificación es que todas las partes se pongan de acuerdo sin presiones.

Como espíritu de esa planificación se deberá buscar el diálogo sincero, el acuerdo unánime y el diálogo franco, sin miedos y evitando seguir a la manada por parte de cada uno de los miembros entendiendo la tarea como algo del equipo en lugar de hacerlo pensando en alguna persona. La estimación debe ser pensada fuera de presiones y con el mayor sentido de realidad posible. No se trata de hacerlo mas rápido sino de imaginarse cómo va a suceder realmente y los obstáculos que podrán surgir en el camino para que cuando transcurra esa estimación pasemos por situaciones que ya habíamos contemplado previamente. Al estimar tareas a realizar en períodos de tiempo menores o dividir una tarea en múltiples tareas nos facilitará la estimación y evitaremos sorpresas.

Otro de los sesgos puede aparecer cuando los tiempos son acotados y nuestro cliente o superior necesita un plazo menor que el necesario. Se tiende a pensar que se puede completar la tarea simplemente por un sesgo de autoridad, donde pensamos la forma de acomodar el proceso en el tiempo dado, en lugar de planificar el proceso y que la estimación tome el tiempo que tenga que tomar. Lo que sucede habitualmente es que se debe entregar el producto de software antes de lo que está estimado. Mi consideración personal, es siempre enfocar en la mayor calidad posible sin considerar si eso implica mayor tiempo.

Una pieza de software con un diseño cohesivo y bajo acoplamiento posiblemente dure en el tiempo y sea robusto y flexible a los cambios futuros haciendo que tenga bajo mantenimiento y pueda evolucionar junto al resto de la aplicación. Si nos enfocamos en la calidad, nos faltará tiempo pero eso será questión de hacer entender al cliente que ese esfuerzo invertido tendrá su recompensa. Cuando algo funciona, el usuario se acuerda que funciona y cada día puede ver que responde, pero nadie recuerda si cierto producto demoró un poco más en salir. En cambio, cuando algo no funciona, el usuario nos lo recuerda todos los días, desgastando la relación.

Solo resta animarse a comenzar, cuando se trata de estimar, cuanto más experiencia tengamos, podremos ser mejores proyectando el tiempo que demandará nuestro próximo trabajo. Ser imaginativos y evitar los sesgos de cualquier tipo. Habitualmente una estimación de un trabajo nunca lleva menos tiempo que el planificado.