La planificación de un proyecto de software empieza por reducir incertidumbre. Mi objetivo es que negocio y equipo técnico puedan decidir qué construir, qué investigar primero y qué dejar fuera. No hace falta resolver cada detalle, pero sí reconocer qué supuestos podrían cambiar el alcance o impedir la entrega.
La disciplina es la misma al diseñar una API, conectar un pipeline de datos con el CRM o revisar por qué una solución de IA no llega a producción. Primero describo el trabajo y sus límites. Después elijo herramientas.
Empieza por un proceso y una persona responsable
Pido que alguien describa la última vez que se ejecutó el proceso: qué entró, quién intervino, dónde hubo una excepción y cómo supo que había terminado. Eso permite distinguir una necesidad observada de una funcionalidad que suena bien en una reunión.
- ¿Quién usa el sistema y quién acepta la entrega?
- ¿Qué entrada recibe y qué salida necesita?
- ¿Qué decisión seguirá tomando una persona?
- ¿Qué herramienta o solución manual funciona hoy?
- ¿Qué restricción obligaría a cambiar de enfoque?
El responsable debe poder resolver prioridades. Si operaciones, ventas y dirección esperan resultados distintos, lo dejo visible antes de convertir sus peticiones en tareas de desarrollo.
Un registro de decisiones, evidencias y pendientes
Uso una ficha breve por decisión: pregunta, evidencia disponible, supuesto pendiente, responsable y condición para revisarla. Marco cada punto como confirmado, pendiente o bloqueante. Una afirmación del proveedor o una captura aislada no demuestran que la integración funcione con las condiciones reales del proyecto.
| Decisión | Evidencia que pediría | Si falta |
|---|---|---|
| Trabajo y primera entrega | Un recorrido revisado por la persona que lo ejecuta, con inicio, final y exclusiones. | Observar el proceso antes de cerrar alcance. |
| Acceso a sistemas | Documentación y prueba autorizada con los permisos y datos necesarios. | Comprobar acceso antes de comprometer la integración. |
| Datos y autoridad | Muestra sanitizada, significado de campos y responsable de corregir discrepancias. | Acordar reglas antes de copiar o sobrescribir registros. |
| Excepciones | Ejemplos de datos incompletos, fallos y decisiones que requieren revisión. | Definir una salida manual antes de automatizarla. |
| Operación | Responsable de alertas, accesos, recuperación y aceptación del lanzamiento. | No dar por resuelta la continuidad tras entregar código. |
No hace falta bloquear todo el proyecto por un detalle menor. Sí conviene detener la parte dependiente de una incógnita que pueda invalidar su diseño. El resto puede avanzar si tiene límites claros y el responsable acepta ese riesgo.
Ejemplo hipotético: solicitudes que terminan en un ERP
Imagina una empresa que recibe solicitudes por correo y las registra en su ERP. Negocio pide un portal para evitar transcribir datos. Antes de dibujar pantallas, comprobaría si el problema está en la entrada, en las reglas de aprobación o en las correcciones posteriores.
Supuesto: el ERP permite crear solicitudes. Evidencia necesaria: una prueba autorizada en un entorno adecuado que confirme campos obligatorios, permisos y respuesta ante una solicitud repetida. Responsable: la persona que administra el ERP. Si solo hay acceso de lectura, el portal no puede prometer escritura automática.
En ese caso, plantearía una primera entrega que prepare solicitudes para revisión y carga manual, o investigaría otra vía de integración. Registraríamos quién acepta esa limitación y qué evidencia permitiría cambiarla. Este ejemplo no describe un cliente ni un resultado obtenido: muestra una decisión que conviene tomar antes de presupuestar el flujo completo.
Qué debe quedar claro antes de contratar desarrollo
La salida útil de la planificación es un conjunto de decisiones revisables, no un documento largo que nadie mantiene. Antes de comprometer construcción, quiero poder recorrer estos puntos con quien compra y con quien operará el sistema:
- Problema y alternativa actual: qué se quiere mejorar y por qué no basta con ajustar una herramienta existente.
- Recorrido y exclusiones: qué entra en la primera entrega y qué seguirá siendo manual.
- Dependencias comprobadas: accesos, muestras y capacidades verificadas; pendientes con responsable.
- Decisiones de arquitectura: opción elegida, alternativa descartada y condición que nos haría reconsiderarla.
- Evidencia de entrega: cómo se demostrará que el recorrido funciona y quién lo aceptará.
- Operación y siguiente paso: quién atiende incidencias y si corresponde construir, investigar o detener el proyecto.
No es una garantía de precio o plazo. Si una dependencia sigue abierta, debe aparecer como incertidumbre en la propuesta. Una prueba técnica acotada puede resolverla; no hace falta contratar todo el producto para obtener esa respuesta.
Cuándo hace falta dirección técnica
Si hay decisiones contradictorias, varios proveedores o nadie puede explicar las consecuencias de cada alternativa, añadir programadores puede aumentar el trabajo pendiente de coordinar. La necesidad inmediata puede ser mi servicio de CTO externo: ordenar alcance, arquitectura y responsabilidades con el equipo. En qué problemas puedo resolver como CTO técnico explico el contexto de ese apoyo.
Cuando las decisiones están suficientemente claras y necesitas construir, puedes revisar mi servicio de desarrollo de software a medida y SaaS: alcance de entrega, aceptación, traspaso y responsabilidades de mantenimiento que acordaríamos antes de empezar.
Planifica también la evidencia de operación
Un proceso que falla debe dejar información suficiente para identificar el paso afectado y decidir qué hacer. Defino qué estados, registros y avisos necesita el operador, evitando guardar contenido sensible innecesario. Esa decisión afecta al diseño desde el inicio.
El caso de Adslyfy y su visibilidad de ejecuciones, errores y capturas muestra esa capa operativa documentada. Sirve para concretar qué significa disponer de evidencia; no demuestra ahorros ni resultados para el ejemplo del ERP.
Trae la decisión que hoy bloquea el proyecto
Para revisar una planificación, trae el proceso actual, una muestra sanitizada, los sistemas implicados y la incógnita que impide decidir. No envíes credenciales ni datos de clientes. Con esa base podemos determinar si falta definir el producto, verificar una dependencia o preparar desarrollo.
Si necesitas esa revisión antes de comprometer el proyecto, cuéntame qué quieres resolver y qué sigue sin comprobar.