La planificación inicial de un proyecto de software consiste en ordenar las primeras decisiones antes de comenzar a construir. Su objetivo no es predecir todo con exactitud, sino entender el propósito del proyecto, definir un alcance razonable, identificar riesgos y acordar una forma de trabajo.
En software siempre existe incertidumbre. Puede cambiar una necesidad, aparecer un problema técnico, faltar información o descubrirse una dependencia no prevista. Por eso, planificar no significa escribir un documento rígido que nunca se modifica. Significa crear una base para tomar mejores decisiones durante el desarrollo.
Una buena planificación inicial ayuda a evitar confusiones, expectativas irreales, prioridades desordenadas y esfuerzos invertidos en funcionalidades de bajo valor.
Planificar permite pasar de una idea general a un proyecto más concreto. Ayuda a responder qué se quiere lograr, quién participará, qué límites existen y cómo se medirá el avance.
La planificación inicial sirve para:
El objetivo explica qué se espera lograr con el proyecto. Debe expresar una necesidad o resultado, no solo una lista de funcionalidades. Un objetivo claro permite evaluar si el proyecto avanza en la dirección correcta.
Por ejemplo, no es lo mismo decir:
que decir:
El segundo objetivo indica usuarios, necesidad y resultado esperado. Esto ayuda a priorizar mejor las decisiones posteriores.
La planificación inicial debe reconocer quiénes influyen en el proyecto o serán afectados por el sistema. Si se ignora a un actor importante, pueden faltar requisitos, aparecer resistencia al cambio o descubrirse tarde una restricción crítica.
Conviene identificar:
Además de nombrarlos, es útil registrar qué espera cada actor y qué decisiones puede influir.
El alcance describe qué incluye y qué no incluye el proyecto en una etapa determinada. Es una herramienta para evitar malentendidos. Sin alcance, cada persona puede imaginar un producto distinto.
Un alcance inicial debería indicar:
Definir qué queda fuera es tan importante como definir qué queda dentro. Ayuda a controlar expectativas y a planificar futuras versiones.
Es útil distinguir entre alcance del producto y alcance del proyecto.
| Tipo de alcance | Qué describe | Ejemplo |
|---|---|---|
| Alcance del producto | Características y funcionalidades que tendrá el software. | Permitir registro de usuarios, reservas, cancelaciones y notificaciones. |
| Alcance del proyecto | Trabajo necesario para construir, entregar o modificar el producto. | Relevar requisitos, diseñar pantallas, implementar, probar, capacitar y desplegar. |
Confundir ambos puede generar problemas. Una funcionalidad pequeña para el usuario puede requerir mucho trabajo técnico si involucra migración de datos, seguridad o integración con sistemas externos.
Las restricciones son límites que condicionan el proyecto. No siempre son negativas; simplemente forman parte del contexto y deben considerarse desde el inicio.
Algunas restricciones comunes son:
Un plan realista reconoce restricciones en lugar de asumir que el equipo puede construir cualquier cosa en cualquier condición.
Un supuesto es algo que el equipo considera verdadero para poder planificar, pero que todavía no está completamente confirmado. Registrar supuestos ayuda a detectar riesgos.
Ejemplos de supuestos:
Si un supuesto resulta falso, el plan puede cambiar. Por eso conviene revisarlos temprano.
Un riesgo es una situación incierta que, si ocurre, puede afectar negativamente el proyecto. Identificar riesgos desde el inicio permite preparar respuestas.
| Riesgo | Impacto posible | Respuesta inicial |
|---|---|---|
| Requisitos poco claros | Retrabajo y cambios tardíos. | Realizar entrevistas, prototipos y validaciones tempranas. |
| Integración desconocida | Retrasos o imposibilidad técnica. | Construir una prueba de concepto al inicio. |
| Usuarios poco disponibles | Validación insuficiente. | Acordar calendario de revisiones con responsables. |
| Fecha fija con alcance grande | Entrega incompleta o baja calidad. | Priorizar una primera versión mínima y realista. |
| Dependencia de una sola persona | Bloqueos si esa persona no está disponible. | Compartir conocimiento y documentar decisiones críticas. |
La priorización permite ordenar funcionalidades o tareas según su valor, urgencia, riesgo y dependencia. No todo puede construirse al mismo tiempo, por lo que el equipo necesita decidir qué es más importante.
Algunos criterios de priorización son:
Una buena práctica es evitar que todo sea "prioridad alta". Si todo es urgente, en la práctica nada está priorizado.
En muchos proyectos conviene definir una primera versión con valor real pero alcance limitado. A veces se la llama producto mínimo viable, versión inicial o producto mínimo útil. El nombre puede variar, pero la idea es entregar algo que permita aprender y resolver una necesidad concreta sin esperar a construir todo.
Una primera versión debe:
Mínimo no significa descuidado. Una versión pequeña también debe ser clara, verificable y mantenible.
Estimar significa aproximar el esfuerzo, tiempo o costo necesario para realizar un trabajo. En software, la estimación inicial suele tener incertidumbre porque no todo se conoce desde el principio.
Para estimar mejor conviene:
Una estimación no es una promesa absoluta. Es una herramienta de conversación y planificación.
Un entregable es un resultado concreto producido durante el proyecto. Puede ser código, documentación, prototipos, configuraciones, informes o una versión del sistema.
En una planificación inicial pueden definirse entregables como:
Los entregables deben aportar claridad. Si un documento no ayuda a decidir, construir, validar o mantener, probablemente necesita simplificarse.
Además de planificar el producto, el equipo debe acordar cómo trabajará. Estos acuerdos evitan confusiones operativas durante el desarrollo.
Algunos acuerdos útiles son:
Un plan de comunicación define qué información se compartirá, con quién, cuándo y por qué medio. No todos los interesados necesitan el mismo nivel de detalle.
| Destinatario | Información necesaria | Frecuencia posible |
|---|---|---|
| Cliente o patrocinador | Avance, riesgos, decisiones de alcance y fechas. | Semanal o por hito. |
| Usuarios referentes | Prototipos, funcionalidades para validar y dudas de negocio. | Durante análisis y al cierre de incrementos. |
| Equipo técnico | Tareas, decisiones técnicas, bloqueos y cambios. | Frecuente o diaria. |
| Soporte u operaciones | Cambios próximos, despliegues, configuración e incidentes. | Antes de entregas y durante operación. |
Supongamos que un centro deportivo quiere un sistema para gestionar reservas de canchas.
Este ejemplo muestra cómo una planificación inicial convierte una idea general en decisiones concretas.
Al planificar proyectos de software suelen aparecer errores como:
Una planificación inicial puede comenzar con una plantilla breve:
| Objetivo | ¿Qué resultado se quiere lograr y por qué? |
|---|---|
| Actores interesados | ¿Quiénes participan, usan, financian, aprueban o se ven afectados? |
| Alcance inicial | ¿Qué incluye la primera etapa? |
| Fuera de alcance | ¿Qué no se hará por ahora? |
| Restricciones | ¿Qué límites de tiempo, costo, tecnología, normativa u operación existen? |
| Riesgos | ¿Qué podría afectar negativamente al proyecto? |
| Entregas | ¿Qué resultados concretos se entregarán y cuándo aproximadamente? |
| Acuerdos de trabajo | ¿Cómo se comunicará, validará, probará y gestionará el trabajo? |
La planificación inicial permite comenzar un proyecto de software con mayor claridad. No garantiza que no habrá cambios, pero ayuda a que el equipo entienda qué busca lograr, qué límites existen, qué riesgos debe cuidar y cómo trabajará.
Para quien comienza, la idea principal es esta: un proyecto de software bien iniciado no necesita conocer todos los detalles, pero sí debe tener objetivos, alcance, prioridades, riesgos y acuerdos explícitos.
En el próximo tema estudiaremos con más detalle alcance, objetivos y restricciones de un sistema, profundizando en cómo definir los límites de una solución de software.