Sabemos que las partes interesadas y los clientes quieren estimaciones. Pero… ¿las estimaciones para los desarrolladores son útiles?
Se benefician de poder planificar, priorizar y predecir las fechas en que se entregará su producto.
Pero para un desarrollador, los beneficios son menos claros. De hecho, puede parecer que no hay ningún beneficio si las estimaciones se interpretan como una promesa esculpida a fuega y luego se usan constantemente en su contra.
Por tanto, no es de extrañar que los desarrolladores a menudo se muestren reacios a realizar estimaciones.
Si hacer algo siempre parece causar problemas, ¿por qué seguir haciéndolo? ¿No es esa la definición de locura?
Entiendo y simpatizo con esta forma de pensar, pero la verdad es que las estimaciones para los desarrolladores pueden beneficiar a los equipos.
De hecho, con el tiempo pueden elevar su estatus a los ojos de las partes interesadas y brindarle más poder de negociación de lo que cree.
¿Pero cómo? ¿Por dónde empezar?
Mi experiencia de ser responsable de las estimaciones
Cuando comencé a desarrollar, el hecho de que me pidieran una estimación me puso nervioso porque sabía que todas las estimaciones que había dado podrían usarse en mi contra.
No solo eso, sino que rara vez se nos celebró por lograr una estimación. No hubo recompensas ni bonificaciones si terminaba de codificar algo dentro de mi estimación.
Simplemente hice lo que dije que haría, cumplí una expectativa básica. Nadie se dio cuenta realmente.
¿Pero si termino tarde? La gente se dio cuenta y notó lo suficiente como para que a veces me gritaran.
Esta primera experiencia se quedó conmigo a medida que avanzaba hacia un puesto directivo.
Si se suponía que los gerentes se enojaran con los desarrolladores que terminaron tarde, eso es lo que haría.
Este era el único estilo de gestión que había visto en ese momento.
Aprendí rápidamente que responsabilizar a los miembros del equipo por estimaciones incorrectas no funcionaba.
Los desarrolladores que trabajaban para mí eran, al igual que yo, crónicamente optimistas y tendían a subestimar la cantidad de tiempo que llevaría completar algo.
Como nuevo gerente, pensé que si mantenía al equipo en sus estimaciones demasiado optimistas, es posible que no las cumplieran, pero estarían cerca.
Terminaríamos los proyectos más rápido de lo que esperaba mi jefe y las partes interesadas. Y me vería bien como nuevo gerente.
Como era de esperar, eso no funcionó. Cuando presioné al equipo para que alcanzara estas estimaciones, pronto se dieron cuenta de que había consecuencias de estimar demasiado bajo: tendrían que trabajar horas extra o recortar gastos para cumplir con el plazo.
Esa no era una forma divertida de trabajar, por lo que aprendieron a aumentar sus estimaciones como una forma de hacer que el ritmo fuera más sostenible.
Era tenso, la deshonestidad se estaba afianzando y supe entonces que necesitaba un mejor enfoque.
Un incentivo valioso para que los equipos estimen: poder de negociación
Como mencioné al comienzo de esta publicación, los beneficios de la estimación parecen apilarse a favor de las partes interesadas.
Quería alentar a mi equipo a querer estimar en lugar de verlo como un ejercicio arbitrario que solo podría meterlos en problemas.
Para entonces, estaba gestionando varios equipos. Naturalmente, algunos equipos fueron mejores en estimar que otros.
Y noté algo muy interesante: los equipos que habían dado mejores estimaciones sobre sus últimos proyectos tenían mejores relaciones con sus partes interesadas.
Las partes interesadas escucharon cuando esos equipos dijeron que cumplir con un plazo era imposible.
Qué sucede cuando un equipo no hace bien las estimaciones (o se niega a intentarlo)
Imaginamos a un equipo que se niega a estimar; no tiene antecedentes de cumplir con sus estimaciones para los desarrolladores.
O imagine un equipo que es terrible en la estimación: tienen un historial pobre de cumplir con lo que dicen que es posible.
Su jefe llega al equipo, describe un conjunto de funciones y le pregunta al equipo cuánto tiempo llevará, insinuando que realmente debe entregarse en seis meses si es posible.
El equipo estima el trabajo y decide que llevará mucho más de seis meses. Los miembros del equipo explican que necesitan más recursos, más tiempo o que pueden entregar en seis meses con menos funciones.
¿Pero toda esa funcionalidad en seis meses? Simplemente no es posible.
¿Cuál es la respuesta probable del jefe en una situación como esta? “Hagámoslo en seis meses”.
Ahora, antes de que decidamos que este jefe es un idiota, recuerde que este equipo no tiene historial de estimaciones o un historial de estimaciones deficientes.
El equipo no se ha ganado el derecho a ser escuchado cuando dicen que el plazo es imposible.
En este caso, es probable que el jefe vea la resistencia del equipo como algo a superar en lugar de una opinión informada basada en hechos.
Un buen (no perfecto) historial de estimaciones eleva el estado de confianza del equipo
Comparemos ahora esta situación con una en la que el equipo estima y estima bien.
No quiero hacer trampa y decir que el equipo calcula perfectamente. Son buenos, no perfectos.
Por ejemplo, en un proyecto anterior le dijeron al jefe que podían entregar en abril o mayo, y terminaron justo antes de finales de mayo.
En otro proyecto, los miembros del equipo dijeron que tomaría tres meses. Y entregaron justo en la fecha límite, pero tuvieron que posponer un par de elementos del product backlog bastante pequeños.
Por lo tanto, no son estimadores perfectos, pero son buenos.
Y ahora el jefe le pregunta a este equipo si pueden ofrecer cierta cantidad de funcionalidad en seis meses.
Este equipo estima el trabajo, lo considera y los miembros del equipo finalmente le dicen al jefe que es demasiado.
No se puede hacer y, de manera realista, necesitarían ocho o nueve meses.
¿Le dice el jefe a este equipo que lo haga igual que con el primer equipo?
No. Este equipo ha proporcionado estimaciones creíbles en el pasado, por lo que el jefe presta atención cuando dice que no se puede hacer.
El jefe incluso tratará al equipo como socios iguales para resolver su problema compartido de qué hacer, dado que la fecha límite deseada es imposible.
Es probable que el jefe y el equipo discutan formas de resolver su problema compartido.
Quizás se puedan agregar más personas al equipo. O podría agregarse un segundo equipo completo.
Quizás uno o dos requisitos tengan un impacto enorme en el cronograma.
Quizás no sea un problema lanzar la funcionalidad completa con un mes de retraso, siempre y cuando ciertas funciones se entreguen a tiempo.
Una relación sana y respetuosa
El historial de este equipo de proporcionar buenas estimaciones conduce a una relación sana con el jefe que se basa en el respeto mutuo y la confianza. Esto permite al jefe y al equipo explorar opciones como iguales. Para todos las estimaciones para los desarrolladores son importantes.
Puede ser difícil imaginar los beneficios que le esperan si puede construir un historial sólido de estimaciones exitosas, pero están ahí. No me malinterpretes: este tipo de relación no se construye de la noche a la mañana, pero puedo garantizar que no se construirá en absoluto si un equipo se niega a estimar.
