Por saltarme una revisión previa casi termino desarrollando desde cero una función que ya existía. A mitad del camino me di cuenta de que estaba repitiendo trabajo y, en lugar de cerrar todo en 3-4 días como había calculado, terminé estirando el desarrollo a una semana solo para ajustar, reescribir y volver a probar todo con calma.
Antes de listar lo que se perdió en ese intento, quiero dejar claro qué fue lo que más me dolió del proceso:
- Horas tiradas estimando tareas que ya estaban resueltas en otra parte del proyecto
- Esfuerzo y foco puestos en una solución que ya estaba desarrollada
- Pruebas más enredadas por tener la misma funcionalidad repetida en distintos módulos
Desde esa experiencia tengo una regla sencilla: revisar primero recursos internos antes de poner números a cualquier tarea. Esa costumbre me ha ayudado a evitar retrabajos, cuidar mejor los recursos del equipo y llevar una gestión de proyectos más ordenada en desarrollo de software.
Estimaciones de desarrollo: El plan que tenía en la cabeza ese día
Las estimaciones que se hacen solo desde la memoria personal rara vez salen bien paradas, y en mi experiencia validar esas ideas con el equipo de desarrollo cambia el juego. En proyectos de desarrollo de software, un plan armado por una sola persona casi nunca alcanza a cubrir todas las variables que entran en juego. Cuando se abre la conversación con el equipo, aparecen espacios para la optimización de recursos, surge la opción de apostar por la reutilización de código y se aclara si alguna herramienta ya resuelve parte de la tarea, algo que ayuda a ajustar la gestión de proyectos y hacerla mucho más aterrizada y precisa.
Estimaciones de desarrollo: Reescribir esa parte y probarla en sitios diferentes
La reutilización de código no siempre se traduce en un desarrollo de software más simple. Cuando tuve que reescribir una función y salir a probarla en varios sitios web, el tiempo que había calculado se disparó. La obligación de adaptar la herramienta a la estructura particular de cada sitio sacó a la luz problemas muy específicos en cada caso y subió la complejidad general del trabajo, sumando nuevos retos en la gestión del proyecto. Al final, esa personalización terminó marcando cómo estimaba los tiempos y cómo organizaba el avance.
Estimaciones de desarrollo: Preguntarme qué parte de lo que voy a hacer ya existe
Revisar qué funcionalidades ya existen es mi primer paso antes de estimar un nuevo desarrollo. Para mí, esta costumbre ahorra dolores de cabeza, evita que el equipo haga trabajo duplicado y cuida mejor el tiempo y el presupuesto. Cuando tengo que planificar una tarea parecida, suelo seguir un orden claro y práctico:
- Defino bien qué funcionalidad necesito cubrir.
- Verifico si ya hay una solución interna o externa que resuelva algo parecido.
- Converso con el equipo de desarrollo para ver si hubo intentos anteriores o piezas que se puedan aprovechar.
- Reviso cómo encajaría todo en lo que ya existe antes de pensar en construir algo desde cero.
Pensar primero en el aprovechamiento de herramientas existentes, para mí, es parte de las buenas prácticas en gestión de proyectos y desarrollo de software. Me gusta apoyarme en referencias como Dev.to, donde se muestra cómo la reutilización baja la sobrecarga y reduce riesgos: pasas de romper más de 10 clases a afectar solo 1 o 2, y además se recorta la transferencia de datos que no aporta valor, lo que ayuda a cuidar información sensible y a bajar el costo de las pruebas.
Consultar primero qué ya existe ha transformado mi forma de estimar tiempos y plantear soluciones. Desde mi experiencia, este cambio evita mucho retrabajo, ayuda a no tropezar con errores básicos en desarrollo y empuja una colaboración más abierta dentro del equipo. Cuando este hábito se vuelve parte del día a día, los procesos se vuelven más claros, los recursos se usan mejor y se fortalece una cultura de aprendizaje compartido y trabajo en conjunto que, para mí, hace una gran diferencia en cómo se construyen los proyectos.
