¿Cómo responder a la pregunta de "Cuánto vas a tardar"?

Cartas para estimar la complejidad
Utilizando la técnica de Planning Pocker

Es inevitable. Te lo van a preguntar; y no importa cuanta información te falte: quien te pregunte "¿Cuánto vas a tardar?" querrá una contestación inmediata y no aceptará otra respuesta que una cifra. El asunto entonces es cómo responder rápidamente y con cierto criterio.

Negocia, calcula y argumenta

Para decir cuánto vas a tardar no vale mirar al cielo, esperar la inspiración divina y dar una cifra. Si dices un número sin más criterio que la "inspiración" o la "intuición", no podrás justificarlo cuando te rebatan la cifra diciendo que es muy grande.

Y lo harán, tarde o temprano.

Quien te pregunta cuánto vas a tardar, espera que le digas el menor número posible porque es tu cliente y quiere tenerlo cuanto antes y pagar poco, porque es tu jefe y quiere que termines pronto para asignarte a otras tareas, porque es un comercial y quiere que el producto sea "barato" para venderlo mejor...

El asunto es que debes asumir que en algún momento alguien dirá o pensará que te has pasado de lo que esperaba, cuando dices cuánto vas a tardar. De modo que, para darle credibilidad a tu respuesta y evitar o cambiar el criterio de tu interlocutor, deberías justificar el dato basándote en una estimación consensuada con tu interlocutor.

¿Cómo estimar rápidamente cuánto vamos a tardar?

Partamos del hecho de que estamos hablando de estimaciones rápidas, en momentos previos a la existencia del proyecto. De modo que queda absolutamente descartado cualquier método de estimación paramétrica como Puntos de Función, COCOMO, Puntos de Casos de Uso o, incluso, estimaciones más ágiles, como las basadas en Puntos de Historias de Usuario; primero, porque no se ha analizado suficientemente el problema como para descomponerlo al nivel que éstos métodos requieren y, segundo, porque no hay tiempo para hacerlo.

De modo que, para no adivinar, ni intentar aplicar unas métricas imposibles, una buena opción es hacer una estimación por analogía, haciendo una lista de los requisitos que se nos piden y asignándoles una complejidad a cada uno que, finalmente, traduciremos a un valor en horas.

Entonces, el proceso para estimar por analogía cuánto tardaríamos en hacer un desarrollo, podría ser el siguiente:

1. Hacer una lista de los requisitos que nos han planteado.
2. Buscar el requisito más simple que encontremos y calificarlo con la complejidad que estimemos.
3. Seleccionar el siguiente requisito no calificado y asignarle una complejidad, teniendo en cuenta las calificaciones asignadas a los requisitos previamente analizados.
4. Repetir el paso 3, hasta que no queden requisitos por calificar.
5. Asignar un valor en horas a cada requisito, según su complejidad para pasar de un valor cualitativo de complejidad a uno cuantitativo de su duración.
6. Sumar el total de horas teniendo en cuenta todos los requisitos.

Dicho así parece simple y, al mismo tiempo indefinido. ¿Qué complejidad asigno a un requisito? ¿Qué pasa si no tengo experiencia previa? ¿Qué cantidad de horas asigno a requisitos de determinada complejidad?

¿Cómo calificar la complejidad de un requisito?

Para simplificar la calificación, siempre partiremos del principio de que es más fácil calificar la complejidad de algo simple y conocido, que de algo complejo y desconocido. 

Por ese motivo, cuando se comienza a estimar, se parte buscando lo que parece el requisito más simple, intentando recordar si ya hemos hecho alguna vez algo parecido y cuán complejo fue; para asignar entonces a dicho requisito la misma complejidad que la de nuestras experiencias pasadas. Ahora, si no encontramos ninguna experiencia parecida, tendremos que descomponer este primer requisito (y solo este) hasta el punto de entender cómo podríamos desarrollarlo y, una vez entendido, estaremos en condiciones de definir la complejidad del mismo.

Una vez calificado el requisito más simple con un grado de complejidad, el resto se calificaría basándose en la experiencia y comparándolo con el requisito ya calificado sin necesidad de comprender a fondo las interioridades del mismo. Para ello, bastaría con responder a las preguntas:

1. ¿Ya he hecho antes algo parecido? ¿Cuán complejo fue?
2. ¿Este requisito es igual, más complejo o mucho más complejo que los anteriores?

Al final del proceso de calificación se obtiene una lista de requisitos cuya complejidad de implementación está justificada en nuestra experiencia y en el análisis realizado. Por supuesto, no es una estimación inmutable y, seguramente las estimaciones cambien, si repetimos el proceso varias veces o consultamos con otra persona. Sin embargo, es probable que estos cambios sean puntuales y con poca variación, sin grandes saltos, en sentido general.

¿Cómo cuantificar en horas la duración la complejidad?

Después de la cualificación, necesitamos cuantificar la complejidad para obtener un resultado en horas y poder responder a la pregunta de cuánto vamos a tardar para hacer determinado desarrollo.

Cuantificar a partir de datos previos

Lo ideal sería contar con estadísticas de proyectos anteriores. Tener una base de datos donde hemos ido guardando por cada proyecto realizado, la lista de requisitos, su complejidad estimada y su duración real.

Con estos datos, podríamos hacer una estimación del proyecto actual con unas cifras cercanas a nuestro desempeño medio y dar una estimación difícil de cuestionar porque, simplemente, negar las estadísticas sería poco razonable.

Cuantificar a partir de una duración "negociada"

Si no tenemos estadísticas que faciliten una cuantificación completa de todos los niveles de complejidad, podríamos, una vez más, apoyar la estimación en la adaptación del principio antes mencionado: es más fácil estimar la duración de algo simple y conocido, que de algo complejo y desconocido.

De modo que, partiremos asignando una duración en horas a la funcionalidad más simple del proyecto y negociaremos esa duración con quien nos ha pedido la estimación. 

Una vez consensuada la duración del requisito más simple, asignaremos duraciones proporcionales a cada complejidad.

Una convención generalmente aceptada es que a medida que aumenta la complejidad, la duración suele aumentar en una proporción mayor, debido a que mientras más complejo es lo que se estima, más imprecisa será la estimación y, por tanto, deberá admitirse un mayor margen de error.

Por ejemplo, algo simple, podría ser el doble de largo que algo muy simple y no, solamente, un poco más largo. De hecho, es frecuente considerar que, a medida que aumenta la complejidad, el tiempo estimado se duplique.

Algo a tener en cuenta es que el punto donde se asigna la primera estimación es clave pues, una vez nuestro interlocutor haya aceptado la estimación inicial, el resto se justificará en el propio sistema de estimación de la complejidad y la duración donde cada valor estará ligado al resto. 

Es decir, que el tiempo que tendrás que negociar será el de la funcionalidad más simple, en la que ambas partes podrán argumentar y justificar sus cifras y, una vez hecho, el resto de las estimaciones será una consecuencia coherente con esa estimación inicial y, por tanto, el resultado final será difícil de cuestionar pues estará basado en un valor consensuado.

Un ejemplo práctico

Supongamos que alguien nos pregunta cuánto tardaríamos en hacer una pequeña aplicación móvil para generar una alarma en caso de una emergencia. La idea es que el usuario pueda indicar un teléfono y que, en caso de emergencia, baste con abrir la aplicación para que ésta recupere el teléfono guardado y le envíe a dicho número un SMS con el texto "SOS" y un enlace a un mapa con la posición del usuario.

Lo primero sería listar las funcionalidades del sistema:

1. Guardar teléfono de contacto para emergencias.
2. Enviar SMS con mensaje y enlace a mapa con posición del usuario.

Sin embargo, la segunda funcionalidad, podríamos descomponerla en dos más simples y más fáciles de estimar: obtener posición del usuario y enviar SMS con un texto predeterminado. De modo que la lista de funcionalidades podría quedar así:

1. Guardar teléfono de contacto para emergencias.
2. Obtener posición del usuario.
3. Enviar SMS.

Luego tendríamos que estimar la complejidad de cada una. Debido a que tenemos poca experiencia en desarrollos móviles (solo hemos hecho cosas básicas) estimamos que:

1. Guardar teléfono de contacto para emergencias es "muy simple" pues ya hemos hecho antes otras aplicaciones de gestión de datos y guardar un solo dato en local es una tarea bastante sencilla. 
2. Obtener posición del usuario es "muy complejo" porque -por lo que sabemos- hay que lidiar con distintos niveles de precisión en la localización, temas de batería y no lo hemos hecho nunca.
3. Enviar SMS es algo "simple" pues, aunque no lo hemos hecho nunca, hemos leído algo sobre las APIs implicadas en las comunicaciones por SMS y parecen bastante fáciles de usar.

No obstante, nuestro potencial cliente nos dice que lo de la posición no debería ser "muy complejo" pues ya le hicieron anteriormente una aplicación con localización integrada y los desarrolladores le comentaron que era menos complejo de lo que parecía. De modo que, con la promesa de ponernos en contacto con esos desarrolladores para que os ayuden con las dudas que puedan surgir, acordamos bajar la complejidad del segundo punto de "muy complejo" a "complejo", quedando la complejidad por requisito así:

1. Guardar teléfono de contacto para emergencias: "Muy simple" (XS). 
2. Obtener posición del usuario: "Complejo" (L).
3. Enviar SMS: "Simple" (S).

(Con el tiempo verás que es cómodo utilizar el sistema de tallas XS, S, M, L, XL y XXL para definir cualitativamente la complejidad de los requisitos.)

Ahora toca estimar cuánto tardaremos en implementar el requisito más simple: el número 1.

Dada nuestra experiencia, decimos que implementar la interfaz, guardar el dato y hacer las pruebas pertinentes, nos tomaría algo más de medio día de trabajo (5 horas, aproximadamente); pero nuestro cliente -siempre inconforme- protesta porque le parece excesivo 5 horas para algo "tan elemental"; así que nos enzarzamos en un debate sobre la calidad del software, la documentación que no ve el usuario final, las pruebas unitarias, los test exploratorios... y después de estirar y encoger las propuestas, quedamos en que 4 horas para el requisito 1 estarían bien.

Así que solo nos falta trasladar la duración en horas a cada requisito restante, partiendo de que cada requisito podría tomar el doble de tiempo que otro con una complejidad inferior. Es decir, si tuviéramos un requisito por cada complejidad, la duración de cada uno sería:

1. Muy simple (XS): 4 h.
2. Simple (S): 8 h.
3. Medio (M): 16 h.
4. Complejo (L): 32 h.
5. Muy complejo (XL): 64 h.
6. Muy muy complejo (XXL): 128 h.

Lo que en nuestro caso, significaría una duración en horas por requisito de:

1. Guardar teléfono de contacto para emergencias: "Muy simple" (XS), 4 h.
2. Obtener posición del usuario: "Complejo" (L), 32 h.
3. Enviar SMS: "Simple" (S), 16 h.

Lo que en total, nos daría una duración de 52 horas o 6 días y medio, ideales; es decir, 6 días y medio si trabajáramos 8 horas exclusivamente en el proyecto.

No obstante, para ser realistas, de las 8 horas diarias, es muy probable que perdamos 1 o 2 horas en comunicaciones (e-mails, llamadas telefónicas), o interrupciones varias (consultas, incidencias con otros productos, etc.). De modo que, siendo objetivos,  aunque el tiempo de desarrollo serían 52 horas, el tiempo para entregar el producto sería de casi 9 días.

Un par de aclaraciones útiles

Las estimaciones de requisitos muy complejos son malas

Volvamos a la lista de tiempos por complejidad enunciada para el ejemplo anterior y fijémonos cómo, a pesar de que el requisito más simple dura solo 4 horas, el más complejo puede parecer excesivamente extenso.

1. Muy simple (XS): 4 h.
2. Simple (S): 8 h.
3. Medio (M): 16 h.
4. Complejo (L): 32 h.
5. Muy complejo (XL): 64 h.
6. Muy muy complejo (XXL): 128 h.

Ese contraste es, justamente, lo que nos ayudará a hacer estimaciones más realistas pues, a medida que aumentemos la complejidad de un requisito, estamos diciendo que sabemos poco de él y que, por tanto tenemos menos idea de cuánto va a durar su desarrollo y, por ende, que estamos siendo imprecisos.

De modo que, si tienes un requisito estimado como "muy muy complejo", es sinónimo de que deberías descomponer ese requisito en otros menos complejos que puedas entender mejor y, por tanto, estimar mejor.

Demasiadas estimaciones de requisitos muy simples son malas

Esto podría parecer una contradicción con la afirmación anterior, pero no lo es. Es mejor tener requisitos con estimaciones de complejidad pequeña, que estimaciones de complejidad muy grande porque significa que seremos más precisos a la hora estimar la duración de los mismos.

Sin embargo, no es frecuente que tengamos información tan detallada como para comprender a fondo todos los requisitos y evaluarlos con complejidades simples. De hecho, es muy frecuente que cuando estemos generando estimaciones, subestimemos la complejidad de las mismas y generemos estimaciones a la baja.

Por eso, si tienes muchas estimaciones de requisitos muy simples, deberías reevaluarlas con detención intentando ver posibles riesgos que podrías estar pasando por alto.

Conclusiones

Lamentablemente, en muchas ocasiones que nos piden estimar cuánto vamos a tardar en un desarrollo, no disponemos de la información ni el tiempo suficiente como para aplicar un método de estimación que tenga en cuenta la mayor cantidad de variables posibles y, en su lugar, debemos apoyarnos en la experiencia y unos principios simples que nos permitan hacer unas estimaciones que, si no son tan precisas, al menos sean justificables; porque, sin olvidar que cualquier estimación de tiempo en una fase temprana y con poca información de base puede tener una desviación grande del resultado final, siempre será mejor una estimación argumentada que una "corazonada".