Desarrollar software implica tomar decisiones con información incompleta. Al iniciar un proyecto, muchas veces no se conocen todos los detalles del problema, el alcance puede cambiar y aparecen dificultades técnicas o de coordinación. Por eso, estimar, gestionar riesgos y hacer seguimiento son actividades esenciales.
Estas actividades no garantizan que todo saldrá exactamente como se planeó, pero ayudan a anticipar problemas, ordenar el trabajo, comunicar expectativas y tomar decisiones oportunas.
Estimar es realizar una aproximación razonada sobre el esfuerzo, el tiempo, el costo o la complejidad de un trabajo antes de ejecutarlo completamente.
Una estimación no es una promesa exacta ni una adivinanza. Es una predicción basada en información disponible, experiencia, supuestos y nivel de incertidumbre.
Idea clave: una buena estimación comunica tanto el valor esperado como la incertidumbre que existe alrededor de ese valor.
En un proyecto de software se pueden estimar distintos aspectos, según la decisión que se necesita tomar.
La incertidumbre es mayor cuando el problema es nuevo, los requerimientos están poco definidos, la tecnología no se conoce bien o existen dependencias externas. A medida que el equipo aprende y avanza, las estimaciones pueden ajustarse.
Por eso, una estimación temprana debería expresarse con prudencia. No es lo mismo decir "tardará exactamente 10 días" que decir "probablemente entre 8 y 14 días, si no cambian los requerimientos principales".
El esfuerzo representa la cantidad de trabajo requerido. La duración representa el tiempo calendario que transcurre hasta completar ese trabajo. No son lo mismo.
Una tarea puede requerir 16 horas de esfuerzo, pero durar una semana si la persona responsable también atiende reuniones, soporte, revisiones o dependencias de otros equipos.
| Técnica | Descripción | Uso típico |
|---|---|---|
| Juicio experto | Se basa en la experiencia de personas que conocen trabajos similares. | Estimaciones iniciales o tareas conocidas. |
| Analogía | Compara el trabajo actual con uno anterior de características parecidas. | Proyectos con referencias históricas. |
| Descomposición | Divide el trabajo en partes más pequeñas y estima cada una. | Funcionalidades medianas o grandes. |
| Estimación por rango | Expresa un mínimo, un valor probable y un máximo razonable. | Trabajos con incertidumbre. |
| Estimación relativa | Compara tamaños o complejidad entre tareas. | Equipos ágiles y planificación iterativa. |
Una tarea grande suele ser difícil de estimar porque contiene muchas incógnitas. Dividirla en partes más pequeñas ayuda a descubrir actividades ocultas, dependencias y riesgos.
Por ejemplo, "implementar pagos" puede incluir diseño de interfaz, integración con proveedor, validaciones, pruebas, manejo de errores, registro de transacciones, seguridad, documentación y despliegue.
Una estimación debe indicar los supuestos bajo los cuales fue realizada. Si el alcance cambia, si aparece una dependencia nueva o si se descubre un problema técnico importante, la estimación puede dejar de ser válida.
Por eso, el equipo debe comunicar cambios de contexto a tiempo y ajustar la planificación cuando la realidad del proyecto lo exige.
Un riesgo es un evento o condición incierta que, si ocurre, puede afectar negativamente los objetivos del proyecto. Puede afectar plazo, costo, calidad, alcance, seguridad, satisfacción del cliente o continuidad del trabajo.
No todos los riesgos tienen la misma importancia. Algunos son poco probables pero muy graves; otros son frecuentes pero de bajo impacto.
| Tipo de riesgo | Ejemplo |
|---|---|
| Técnico | La tecnología elegida no soporta el rendimiento requerido. |
| De requerimientos | El alcance cambia frecuentemente o las reglas no están claras. |
| De equipo | Una persona clave no está disponible durante una etapa crítica. |
| De integración | Un servicio externo no responde como se esperaba. |
| De negocio | La prioridad del proyecto cambia por decisiones de la organización. |
| De calidad | Se acumulan defectos porque las pruebas se postergan demasiado. |
Gestionar riesgos implica identificarlos, analizarlos, priorizarlos, definir acciones y revisarlos durante el proyecto. No se trata de eliminar toda incertidumbre, sino de evitar que los problemas importantes sorprendan al equipo demasiado tarde.
| Respuesta | Descripción | Ejemplo |
|---|---|---|
| Evitar | Cambiar el plan para que el riesgo no ocurra. | No usar una tecnología experimental para un sistema crítico. |
| Reducir | Disminuir probabilidad o impacto. | Hacer una prueba técnica temprana antes de comprometer una solución. |
| Transferir | Pasar parte de la responsabilidad a otro actor. | Contratar soporte especializado para una plataforma compleja. |
| Aceptar | Reconocer el riesgo y convivir con él si el impacto es tolerable. | Aceptar una demora menor en una función no crítica. |
El seguimiento permite comparar el avance real con lo planificado, detectar desvíos y tomar decisiones. No consiste solamente en preguntar si una tarea está terminada, sino en entender el estado del trabajo, los bloqueos, la calidad y los riesgos activos.
Un buen seguimiento evita que los problemas se acumulen en silencio hasta el final del proyecto.
El estado del proyecto debe comunicarse con claridad. Ocultar problemas para evitar conversaciones incómodas suele generar consecuencias peores. Informar a tiempo permite renegociar alcance, modificar prioridades, agregar apoyo o ajustar fechas.
Un informe de estado útil no necesita ser extenso. Debe responder qué se completó, qué está en curso, qué está bloqueado, qué riesgos existen y qué decisiones se necesitan.
Supongamos un sistema de turnos médicos. El equipo estima que la funcionalidad de recordatorios llevará entre 6 y 10 días porque debe integrarse con un servicio externo de correo. Uno de los riesgos es que el proveedor limite la cantidad de mensajes por hora.
Para reducir ese riesgo, el equipo realiza una prueba técnica temprana, define mensajes de error claros, registra intentos fallidos y planifica una alternativa si el proveedor no cumple las condiciones necesarias.
La estimación, la gestión de riesgos y el seguimiento permiten conducir un proyecto de software con mayor claridad. Ayudan a transformar incertidumbre en información útil para planificar, priorizar y comunicar.
En el próximo tema veremos mantenimiento, evolución y soporte del software, etapa en la que el producto continúa cambiando después de su primera entrega.