Gestión de proyectos
Gestión de proyectos: la guía completa y práctica
En una línea: gestionar un proyecto es llevarlo de una idea a un resultado concreto, dentro de un tiempo y un presupuesto, con la menor cantidad de sorpresas posible. No hace falta un título ni un software caro para hacerlo bien: hacen falta cinco fases claras, roles definidos y un método de seguimiento que tu equipo realmente use. Esta guía cubre las dos — la teoría mínima indispensable y la práctica — y enlaza a artículos más profundos sobre cada tema.
Qué es la gestión de proyectos (sin la definición de manual)
La definición de manual dice que la gestión de proyectos es "la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto para cumplir sus requisitos". Es correcta y no ayuda a nadie que la lea por primera vez.
En la práctica, gestionar un proyecto es responder tres preguntas todo el tiempo: ¿qué falta para terminar?, ¿quién lo está haciendo? y ¿estamos a tiempo? Todo el aparato de metodologías, plantillas y software existe para responder esas tres preguntas más rápido y con menos reuniones. Si tu proceso actual —por informal que sea— responde las tres sin esfuerzo, ya estás gestionando proyectos correctamente. Si no, esta guía te da el mínimo necesario para llegar ahí.
Un proyecto se diferencia de una tarea recurrente (una operación) en que tiene principio, fin y un resultado único. Facturar cada mes no es un proyecto; migrar de sistema de facturación, sí. Esa distinción importa porque las tareas recurrentes se gestionan con checklists y las tareas de proyecto se gestionan con hitos — confundir ambas es la razón número uno por la que un tablero se vuelve un cementerio de tarjetas que nadie cierra.
Las 5 fases de todo proyecto
Sin importar la metodología, todo proyecto atraviesa cinco fases. Podés fusionarlas o repetirlas en ciclos cortos (eso es exactamente lo que hace Scrum), pero no podés saltarte ninguna sin pagar el costo después.
| Fase | Pregunta que responde |
|---|---|
| 1. Inicio | ¿Vale la pena hacer esto? |
| 2. Planificación | ¿Qué hay que hacer, en qué orden y con qué recursos? |
| 3. Ejecución | ¿Quién hace cada cosa, hoy? |
| 4. Seguimiento | ¿Vamos a tiempo? ¿Qué cambió? |
| 5. Cierre | ¿Qué entregamos y qué aprendimos? |
La mayoría de los proyectos que se atrasan no fallan en la ejecución — fallan porque se saltaron la fase 1 (nadie definió si valía la pena) o la fase 2 (nadie definió el orden real de las tareas). Ver el desarrollo completo de cada fase, con ejemplos, en las 5 fases de un proyecto.
Roles: quién hace, quién aprueba, quién solo necesita saber
El motivo más común de fricción en un proyecto no es técnico: es que dos personas creen que son responsables de la misma decisión, o que nadie cree serlo. Una matriz RACI (Responsable, Aprobador, Consultado, Informado) resuelve esto en una tabla de diez minutos: por cada entregable, quién lo hace, quién lo aprueba, a quién hay que consultar antes y a quién solo avisar después.
No hace falta usarla en cada tarea — reservala para las 5-10 decisiones grandes de un proyecto (qué se entrega, cuándo se lanza, quién aprueba el presupuesto). Guía completa con plantilla en matriz RACI: qué es y cómo armarla.
Metodologías: Waterfall, Agile y todo lo de en medio
Existen dos familias de metodología. Waterfall (cascada) planifica todo el proyecto antes de empezar y ejecuta en un solo tramo lineal: bueno cuando el alcance es fijo y conocido (construcción, cumplimiento regulatorio, migraciones con fecha dura). Agile (Scrum, Kanban) planifica en ciclos cortos y ajusta sobre la marcha: mejor cuando el alcance puede cambiar según lo que se aprende en el camino (producto, software, marketing).
La pregunta que decide cuál usar no es "¿qué está de moda?" sino: ¿sé hoy exactamente qué hay que entregar, o lo voy a descubrir en el camino? Si la respuesta es "lo sé", cascada. Si es "lo voy a descubrir", Agile. Comparativa completa, con tabla y ejemplos de cada uno, en Scrum vs Kanban.
Herramientas: qué necesitás de verdad
Antes de evaluar software, tres cosas que cualquier sistema de gestión de proyectos —desde una hoja de Excel hasta un ERP— tiene que resolver:
- Una única fuente de verdad del estado de cada tarea, visible para todo el equipo sin pedirle a nadie un update por chat.
- Trazabilidad: poder ver quién cambió qué y cuándo, sin depender de la memoria de alguien.
- Bajo costo de mantenimiento: si actualizar el tablero toma más esfuerzo que hacer el trabajo, el equipo deja de actualizarlo y el tablero miente.
Un Kanban simple con columnas Por hacer / En curso / Hecho cumple los tres puntos para la mayoría de los equipos pequeños. La complejidad adicional (sprints, automatizaciones, dependencias entre tareas) se agrega cuando el dolor de no tenerla es mayor que el costo de aprenderla — no antes.
Los 3 errores que arruinan más proyectos que cualquier metodología
Después de años viendo proyectos fallar, la causa raíz casi nunca es "elegimos mal la metodología". Suele ser una de estas tres:
- Alcance que crece sin que nadie lo apruebe — el clásico "ya que estamos, agreguemos esto también". Ver cómo definir el alcance y frenar el scope creep.
- Estimaciones optimistas por defecto — nadie estima a propósito mal, pero casi todos subestiman por sesgo. Ver cómo estimar tiempos sin fallar siempre.
- Nadie es dueño de la decisión — dos personas creen que aprueban lo mismo, o ninguna. Se resuelve con la matriz RACI mencionada arriba.