Menú Cerrar

Tips para estimar mejor tus proyectos de desarrollo

La estimación es quizá una de las áreas más difíciles en la ingeniería de software. Cambios en los requerimientos, falta de conocimiento de las tecnologías a utilizar, y expectativas fijadas por las necesidades del negocio, hacen que dar tiempos para un proyecto a veces parezca un acto de magia en vez de una labor de ingenieria.

En el siguiente video te comparto 4 tips que me han ayudado muchísimo a estimar mejor los proyectos en que he participado. Debajo del video encontrarás la transcripción.

¿Tienes alguna anécdota que te haya ocurrido estimando? Déjala en los comentarios.

Link al video en YouTube | Suscríbete a mi canal


¿Cuánto te vas a demorar?

Esa es la típica pregunta que te hacen cuando vas a iniciar un proyecto o un requerimiento.

Es una pregunta que sabemos es supremamente difícil. Sabes que una mala respuesta puede llevar a algunas semanas trasnochando, o al final pedir tiempo adicional para terminar.

Quiero contarte 4 tips muy rápidos acerca de cómo puedes estimar mejor.

No te voy a hablar de técnicas de estimación. Quiero mencionar unos tips para estimar mejor. Son consejos muy rápidos y prácticos, que puedes empezar a aplicar desde hoy para que mejoren tus estimaciones.

Primer tip: No des estimados a la ligera

No te dejes presionar en situaciones donde tu jefe te pide rápidamente un número.

Ejemplo de un posible diálogo entre jefe y empleado:

Jefe: Hola Pepito, el nuevo cliente está un poquito impaciente. Dime más o menos cuánto tiempo se va a demorar el proyecto. Solo un estimado. No tiene que ser preciso, pero dame mas o menos una idea.

Empleado: Uy jefe, la verdad no sabría decirle. Es que no me he podido sentar a hacer el estimado y mirar bien los requerimientos. La verdad no sé.

Jefe: No, no, no. Pero no te preocupes, no tiene que ser precioso. Dame algo a “vuelo de pájaro”. No te preocupes; lo que me digas ahora no te va a comprometer. Es solamente para hacerme una idea.

Empleado: Pues bueno jefe, ya que lo pone así, yo diría que a “vuelo de pájaro”, esto se puede estar demorando,  mas o menos, no sé, digamos, un mes.

Y adivina qué, ese estimado que des te va a comprometer. No importa si te dicen que es para hacerse una idea. No importa que te digan que es para “ver” hacia donde va el tema. El número que des ahí es como si lo estuvieras escribiendo en mármol. Te van a pedir y te van a exigir sobre ese número.

Así que ten cuidado con dar esos estimados rápidos. Es muy normal que te los pidan.

Segundo tip: Detalla muy bien lo que tienes que hacer

Foto por Glenn Carstens-Peters en Unsplash

Evita estimar de un “solo golpe” piezas muy grandes. Un ejemplo de algo que deberías evitar hacer:

“OK, voy a estimar el módulo de gestión de productos… digamos que me voy a demorar…. una semana.”

Es un error grave estimar algo tan grande de esa manera. Va a causar que te desfaces por mucho.

Un mejor enfoque es que tomes ese módulo, y lo dividas en cada una de sus características y funcionalidades. Luego puedes estimar cada una. Si alguna de esas funcionalidades es muy grande, vuelve y divídela hasta que llegues a actividades o tareas  de un tamaño mucho más razonable.

De hecho, esto me recuerda una historia que me compartió un miembro de la comunidad.

Esta persona contaba que en algún proyecto, el estimado que obtuvo fue de 300 horas. A su jefe le pareció un estimado demasiado grande. Entonces le pidió que entrara a detallar cada una de las tareas que tenía ese proyecto. Luego de estimar en detalle cada tarea, se dio cuenta de que el proyecto tomaba 500 horas en vez de 300.

El proyecto iba a tomar muchísimo más tiempo del pensado. Esto solo lo hubiera descubierto analizando con suficiente detalle lo que le estaba pidiendo.

Tercer tip: Haz una prueba de concepto

Tienes que estimar algo, pero no estás seguro si la tecnología que estás proponiendo es la correcta. A lo mejor no sabes si alguna librería va a funcionar bien. O tienes algo que causa demasiada incertidumbre en el estimado. Lo anterior evita que sepas si el requerimiento va a tomar una semana o un mes, por ejemplo.

En esta situación, es muy útil que dediques algo de tiempo a hacer un “hola mundo” o una prueba de concepto.  El objetivo es que puedas aclarar esa duda grande que tengas acerca del requerimiento o del proyecto. Una vez tengas certeza que la tecnología es la correcta, o que la librería sí es la que necesitas, entonces ya puedes estimar con mayor confianza. Esa incertidumbre que tenías, la aclaraste, y ya tienes una mejor dimesión de lo que hay que hacer.

Al momento de estimar, haz una prueba de concepto si tienes dudas acerca de una tecnología o librería a usar en el proyecto. Click To Tweet

Hacer pruebas de concepto no solo sirve para verificar la la viabilidad de alguna tecnología. También ayuda mucho para aclarar las ideas de nuestros usuarios, ya que les da algo que puedan “palpar” para saber si es lo que en realidad necesitan.

Cuarto tip: No estimes solamente el desarrollo

He visto mucho proyectos donde solamente se incluyen todas las actividades de desarrollo. Pero se ignoran todas las tareas que hay alrededor.

Algunos ejemplos de tareas que se ignoran en los estimados, y requieren tiempo:

  • Diseño del sistema.
  • Despliegues.
  • Scripts para automatizar tareas.
  • Configuración de ambientes.
  • Documentación técnica.
  • Solicitud de permisos.

Por ejemplo, dependiendo de la empresa, a lo mejor tienes que completar unos formatos o unos documentos para que el proyecto pueda ser desplegado.

Todo lo anterior toma tiempo, y afecta el estimado del proyecto.

Entonces es muy importante que esas tareas las contemples.

Cierre

Eso era lo que tenía para compartirte el día de hoy. Son 4 tips para estimar mejor, muy sencillos y directos.

Aquí no hay nada de métodos avanzados, ni trucos extraños. Obviamente hay muchas formas de estimar. Hay muchas recomendaciones y buenas prácticas. Te quería compartir 4 que a mi personalmente me funcionan muy bien.

No son a prueba de balas, pero definitivamente ayudan.


Suscríbete a mi lista de correo.

Te avisaré de nuevo material que te ayude a ser un mejor desarrollador o arquitecto.
Publicado en Desarrollo de software