Saltar al contenido

Hacer Estimaciones de Tiempos en Software

Antes que nada, seamos realistas: es imposible determinar la duración exacta que va a llevar el desarrollo de un software. No se le puede pedir a nadie, desarrolladores de software incluidos, que adivine el futuro.

Dicho esto, voy a intentar ayudarte a la hora de realizar estimaciones. Pero hay que tener muy claro que será tan solo una estimación, y las estimaciones no serán nunca un número exacto, sino un rango de tiempo aproximado con el que se podrá hacer predicciones hasta cierto punto.

Dicho esto, a la hora de crear un software para un cliente, te puedes encontrar con 2 escenarios:

  • Que haya una fecha límite para desarrollar el software que te piden:
    • Lo que deberás estimar en este caso es la cantidad de trabajo que podrás realizar hasta ese momento.
    • Averiguar si lo que te están pidiendo es posible hacerlo en el tiempo asignado.
    • En caso de que no sea posible desarrollarlo todo, debes indicar qué podrías tener terminado y qué no vas a poder tener acabado, es decir, deberás priorizar y descartar funcionalidades.
  • Que te pidan que estimes el tiempo que te llevará desarrollar el software:
    • Deberás estimar la cantidad de tiempo que te llevará cada funcionalidad.
    • Lleva a cabo los cálculos de cuánto tiempo te llevará realizar cada funcionalidad (luego te explico mis métodos).
    • Prioriza las funcionalidades para que, en caso de que te digan que es demasiado tiempo, sepas qué se puede dejar fuera y qué no para poder dar rápidamente una nueva estimación.

Asignando Prioridades

Como ves, una parte importante es dividir el software en funcionalidades (también llamados casos de uso o historias de usuario) y luego asignar prioridades. Esto es algo que deberías hacer con el cliente (o con tu jefe).

Una forma fácil es repartirlas en 4 grupos:

  • Debe Tener (Imprescindibles): esta es la funcionalidad que, pase lo que pase, el software debe tener. Cuidado porque muchos clientes/jefes tienden a querer meter todo aquí. Aquí debe ir la funcionalidad mínima para que el software funcione (es decir, para tener un producto mínimo viable).
  • Debería Tener (Deseadas): una vez se tenga la funcionalidad más básica, esta es la funcionalidad que debería añadirse para que el programa le sea útil al cliente. Es toda funcionalidad que no es opcional, pero que tampoco es necesaria para que el software funcione mínimamente.
  • Podría Tener (Opcionales): esta es la funcionalidad opcional que al cliente le gustaría que tuviera el software, que podría incluso diferenciarlo de su competencia, pero que el programa podría funcionar si no la tuviera.
  • No Debería Tener: esta es la lista de cosas que el software no debería contener. Esto es importante porque muchas veces se está copiando un software de la competencia y hay ciertas cosas o que no se quieren o que no son necesarias. Si no lo tienes claro, quizá le estés implementando funcionalidades al cliente creyendo que le estás aportando un valor añadido y resulta que al final el cliente no la quería (o que pensaba meterlo más adelante, pero ahora no).

Como puedes imaginar, debes centrarte en tener un producto mínimo viable lo antes posible, implementando la funcionalidad básica que el software debe tener. Luego, le añades las funcionalidades deseadas que debería tener y, si queda tiempo, la funcionalidad opcional que podría tener.

He visto muchos proyectos en los que los desarrolladores se han centrado demasiado tiempo en funcionalidades opcionales para querer impresionar al cliente (o peor: porque les atraía más desarrollar esa parte, o incluso porque les venía bien para su carrera personal) y no han implementado ni lo más básico, quedando un software inservible.

Una vez tengas los grupos, prioriza dentro de cada uno. Aunque sea, agrúpalos en 3 categorías: alta prioridad, prioridad normal, baja prioridad.

Modo Rápido

De acuerdo, no tienes mucho tiempo ni para hacer análisis ni para hacer cálculos.

Pero antes de nada, una aclaración muy importante:

Debes tener en cuenta que debes dejar tiempo para responder correos, atender llamadas, depurar y corregir errores, asistir a reuniones, desayunar, descansar u otras tareas que (seguro) te irán surgiendo.

Vale, pues aquí va mi consejo de como estimar un trabajo:

  1. A cada funcionalidad le asignas un número de días.
  2. Multiplicas por 2 ese número de días (¡este es el paso clave!).
  3. Suma todos los valores obtenidos.
  4. Calcula el 10% de la suma total.
  5. Suma y resta ese 10%, lo que te dará un rango de fechas.

Te pongo un ejemplo:

  1. Tienes 3 funcionalidades: la primera crees que la tendrás en 4 días, la segunda en 2 y la tercera en 3 días. En principio, sumando todas, serían 9 días, es decir, cerca de 2 semanas.
  2. Multiplica por 2 cada una, quedando: la primera en 8 días, la segunda en 4 días y la tercera en 6 días. Sumando todas ahora dan ahora 18 días, unas 3 semanas y media.
  3. El 10% de 18 es 1,8 días. Redondeando lo dejamos en 2 días.
  4. Sumamos y restamos 2 días a los 18, lo que nos queda 16 y 20 días.
  5. La estimación para realizar las 3 funcionalidades será de 3 a 4 semanas.

Encaje: (Re)Negociando la Fecha Límite o las Funcionalidades

En caso de tener una fecha límite, ve sumando funcionalidades hasta alcanzar la fecha límite: esa será la lista de tareas que podrás realizar.

Nunca te comprometas a más. Te lo repito: nunca, nunca te comprometas a más.

Si lo haces, a partir de ese momento será tu responsabilidad si no llegas. Si luego eres capaz de entregar más funcionalidades de las estimadas, perfecto, pero mantente firme en tu estimación.

Si el cliente o tu jefe te dice que es inaceptable, dile que harás todo lo que puedas, pero que lo más seguro es que no estará todo a tiempo.

Intenta renegociar la fecha límite o la funcionalidad, pero jamás les des a entender que quizás lo tengas cuando tus cálculos ya dejan claro que no lo podrás hacer.

Mucha gente cree que echando horas extras y fines de semana lograrán llegar: es el mayor error que puedes cometer. Nunca llegarás a tiempo porque el cansancio se irá acumulando y tu ritmo de trabajo caerá. Con los nervios, cometerás más errores. Al final, te pasarás el tiempo intentando corregir errores que, por agotamiento, no verás su solución aunque la tengas delante de tus narices.

A este proceso de renegociar fechas límite o funcionalidades yo le llamo «Encaje», y lo llevo a cabo de la siguiente manera:

  1. Se van sumando funcionalidades en orden.
  2. Si el total de funcionalidades imprescindibles supera la fecha límite, se debe retrasar (o dejar claro que no lo tendrás a tiempo: nunca aceptes una fecha límite a la que sabes que no llegarás).
  3. Si se cubre todas las funcionalidades imprescindibles, pero no las deseadas, se evalúa con el cliente/jefe si se retrasa la fecha límite o si se restan funcionalidades.
  4. Si no se puede retrasar, se negocia qué funcionalidades entran y cuáles quedan fuera.
  5. Nunca se debe retrasar la fecha límite por las funcionalidades opcionales, salvo que el cliente/jefe exija su entrega. En ese caso, se debe negociar una nueva fecha límite (o no aceptar).
  6. Y nunca, nunca, nunca adelantes la fecha límite. Ni porque creas que vas bien de tiempo ni porque te lo pidan. Ni siquiera porque pienses que van a encajar todas las tareas: siempre surgen cosas o siempre se puede usar el tiempo extra para hacer más pruebas.

Mi Método Fibonacci de Estimación de Tiempos

En caso de que tengas tiempo de realizar un análisis de todas las funcionalidades y hacer una estimación de cada una, este es el método que yo uso (es una variación de PERT).

  1. Hacer una lista lo más completa con todas las funcionalidades.
  2. Divide las funcionalidades en imprescindibles, deseables y opcionales.
  3. Dentro de cada grupo, ordénalas por importancia, teniendo en cuenta dependencias (quizá algo parezca más importante, pero sea necesario que antes se terminen otras funcionalidades).
  4. A cada funcionalidad, asígnale un número de días según la progresión de Fibonacci (cada número de la serie es la suma de los dos anteriores):
    • 1 día: si se tarda 1 día o menos en hacerse.
    • 2 días: si se tarda un par de días, podrían ser 1 pero nunca más de 3.
    • 3 días: si se tarda unos tres días, no puede ser menos de 2 ni más de 5 días.
    • 5 días: si se tarda alrededor de 1 semana, no puede ser menos de 3 días ni más de una semana y media.
    • 8 días: si se tarda alrededor de semana y media, ni puede ser menos de 1 semana ni más de 2.
    • 13 días: si se tarda como mínimo 2 semanas, aunque podría ser más (evalúa en dividirla en tareas más pequeñas).
  5. Más de 13 días sería una funcionalidad demasiado grande y debería dividirse en otras más pequeñas.
  6. Si sois varias personas, se debe llevar a cabo una votación (si solo eres una persona, haces las estimaciones y no son necesarias las votaciones):
    • Cada uno estima cada funcionalidad sin mirar las estimaciones de los demás.
    • Se muestran todas las estimaciones a la vez.
    • Si todas las estimaciones más o menos coinciden, se toma como valor la más votada.
    • Si hay grandes diferencias, los que hayan asignado los valores más extremos deben justificarlo. Se vota de nuevo hasta que haya consenso.
  7. Por cada funcionalidad hay que hacer 2 rondas más:
    • Optimista (O): en el mejor de los casos, los días que se tardarían como mínimo (se escoge la de menor valor de todos). Debe ser inferior o igual a la estimación normal.
    • Pesimista (P): en el peor de los casos, los días que se tardarían como máximo (se escoge la de mayor valor de todos). Debe ser superior o igual a la estimación normal.
  8. Realiza los cálculos (basados en la distribución Beta):
    • Valor Esperado (m): se multiplica el valor normal por 4, se suma el optimista, se suma el pesimista y se divide el resultado por 6: m = (O + 4N + P) / 6
    • Desviación (s): a la estimación pesimista se le resta la optimista y se divide entre 6: s = (P – O) / 6
    • Estimación: al valor esperado se le suma y resta a la desviación: m ± s
      • En caso de haber mucha incertidumbre con algunas funcionalidades, se le suma y se le resta el doble de la desviación: m ± 2s
  9. Se calculan los totales de todas las funcionalidades:
    • Valor Esperado Total (M): se suman los valores esperados (m) de todas las funcionalidades que se vayan a desarrollar.
    • Desviación Total (S): este es el cálculo más complejo, pero no tanto. Se elevan al cuadrado cada una de las desviaciones (s), se suman, y se hace la raíz cuadrada del resultado.
    • Estimación: al valor esperado total se le suma/resta la desviación total: M ± S. Si hay incertidumbre, se le suma/resta el doble de la desviación: M ± 2S.

Parece una labor muy pesada, pero créeme que una vez le coges el ritmo, se hace en poco tiempo y el porcentaje de acierto en la estimación es bastante elevado. Merece la pena.

Yo me suelo hacer hojas de cálculo desglosando funcionalidades, poniendo el resultado de las estimaciones de cada uno, y programo las fórmulas para que los sumatorios y resto de cálculos los haga automáticamente.

Este método lo he usado en múltiples proyectos con varios clientes (y jefes) y nunca me ha fallado por más de un 10%, lo que creo que es bastante aceptable visto lo visto en el mundo del desarrollo de software.

Te voy a poner unos ejemplos que te pueden aclarar algunos cálculos:

  1. Partimos de que hay que implementar 3 funcionalidades:
    • Para la primera estimo un tiempo normal de 3 días, un optimista de 2 y un pesimista de 5.
    • Para la segunda estimo un tiempo normal de 2 días, un optimista de 1 y un pesimista de 5 (ya que podría darme más guerra de lo esperado al ser algo en lo que no tengo mucha experiencia).
    • Para la tercera estima un tiempo normal de 5 días, un optimista también de 5 días y un pesimista de 8 días (ya que tengo mucha experiencia en ello y tengo bastante certeza de que serán 5 días, pero meto un pesimista de algo más por si acaso).
  2. Ahora tenemos que obtener el valor esperado de cada funcionalidad:
    • Primera: multiplico 3 (tiempo normal) por 4, lo que me da 12. Le sumo 2 (optimista) y 5 (pesimista), lo que me da un total de 12 + 2 + 5 = 19. Esto lo divido entre 6, lo que me da 19 / 6 = 3,17.
    • Segunda: [(2 x 4) + 1 + 5] / 6 = 14 / 6 = 2,33.
    • Tercera: [(5 x 4) + 5 + 8] / 6 = 33 / 6 = 5,5.
    • El valor estimado total será: 3,17 + 2,33 + 5,5 = 11.
  3. Ahora tenemos que obtener las desviaciones:
    • Primera: a los 5 de la estimación pesimista le resto los 2 del optimista, lo que me da: 5 – 2 = 3. Ahora tengo que dividirlo entre 6, lo que me da: 3 / 6 = 0,5.
    • Segunda: (5 – 1) / 6 = 0,67.
    • Tercera: (8 – 5) / 6 = 0,5.
    • Para calcular la desviación total primero tengo que elevar cada desviación al cuadrado y sumarlas: (0,5)2 + (0,67)2 + (0,5)2 = 0,95. Y luego hacer la raíz cuadrada del resultado, lo que da 0,97. Vamos a redondearlo a 1 día.
  4. Para la estimación total, hay que sumar el valor estimado total de 11 con la desviación total calculada, que es 1, pero como tengo cierta incertidumbre con la segunda tarea, decido sumarle el doble de la desviación total, que en este caso serían 2.
  5. La estimación total me quedaría entre 11 – 2 y 11 + 2, es decir, entre 9 y 13 días. Esto, traducido a semanas (recuerda, nunca des números exactos), entre 2 y 3 semanas.

En caso de no tener tiempo para hacer todos los cálculos y tenerlo que hacer rápido, recuerda que hay que sumar todo (2 + 3 + 5 = 10), multiplicarlo por 2 (10 x 2 = 20), calcular el 10% (10% de 20 es 2) y sumárselo y restárselo para obtener el rango (20 – 2 = 18, 20 + 2 = 22), lo que da un valor de entre 18 y 22 días, entre 3 y 4 semanas.

Como ves, sale más que con el método «largo», pero es que la estimación la has tenido que hacer con menos tiempo y es necesario meter cierto margen de incertidumbre (además, es típico en estos casos que luego se quejen, te pidan bajarlo, y les termines diciendo entre 2 y 3 semanas, por eso lo suelo hacer así).

¿Y Tú, Qué Opinas?

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *