Gestión de proyectos para equipos de software: más allá del teatro de procesos

La mayoría de los ingenieros con los que hablamos ha tenido al menos una mala experiencia con un PM. El PM que agendaba un standup diario, dos grooming meetings, una sprint planning, una retro, un “demo prep”, y un “demo demo prep”, y al final del sprint preguntaba por qué la velocidad estaba baja. El PM que volvía los tickets de Jira en specs de novela que ningún ingeniero leía. El PM que, cuando le hacían una pregunta técnica, decía “lo levanto con ingeniería” — sobre su propio proyecto.

Esto es teatro de procesos, y es por eso que los ingenieros piensan que los project managers son inútiles. Pero eso no es lo que un PM de software debería hacer. Un PM de software real remueve obstáculos, es dueño del scope, y protege el foco del equipo. Bien hecho, un PM compone el output de cada ingeniero con el que trabaja. Mal hecho, lo reduce activamente.

Así pensamos sobre esto.

Cuándo los ingenieros deberían manejarse solos

No todos los equipos necesitan un PM dedicado. Algunos equipos están mejor sin uno.

Un equipo puede manejarse solo cuando:

• Son 2-4 ingenieros senior que han enviado juntos antes.
• El product owner (CTO, founder, o PM-en-otro-lado) está involucrado diariamente.
• El scope está bien definido: un feature conocido, una migración clara, un refactor contenido.
• La superficie de stakeholders es chica (1-2 personas).

En esta configuración, añadir un PM crea fricción. Los ingenieros ya saben qué construir. No necesitan que alguien les recuerde actualizar Jira. El CTO puede tener la conversación de planning directamente.

Un equipo necesita un PM cuando cualquiera de estas es verdad:

• 5+ ingenieros, especialmente cuando no están co-localizados en la misma zona horaria.
• Múltiples stakeholders jalando en direcciones distintas (ventas pide X, soporte escala Y, founder empuja Z).
• Dependencias cross-team (frontend esperando backend, mobile bloqueado en API).
• Deadlines regulatorios o contractuales (compliance, compromisos con clientes, ciclos de auditoría).
• Un roadmap que abarca más de un trimestre, donde alguien tiene que ser dueño de la secuencia.

El headcount solo no es la señal. Un equipo de 4 personas en una industria regulada con 5 stakeholders absolutamente necesita un PM. Un equipo de 8 personas construyendo un solo producto con un fundador involucrado quizá no.

Lo que un PM de software realmente owns

El trabajo es específico. Usamos esta lista cuando definimos el scope de un engagement de PM:

1. Definición y protección de scope. El PM es la persona que dice no. O más precisamente: la persona que saca a flote un trade-off cuando llega un nuevo pedido a mitad de sprint. “Podemos hacer eso, pero empuja el feature X al siguiente sprint. ¿Cuál quieres?”. Esa conversación es el trabajo.

2. Planning de sprint / ciclo. Cualquier cadencia que uses, alguien tiene que romper el trabajo en pedazos suficientemente chicos para ser estimables, secuenciados de modo que las dependencias se respeten, y dimensionados para que el equipo tenga 70-80% de compromiso con 20-30% de buffer.

3. Surfacing de riesgos. Un PM junior te cuenta lo que pasó. Un PM senior te cuenta lo que está por romperse. Los riesgos son: la dependencia en la que estamos bloqueados, el ingeniero que está fuera la próxima semana, la API de terceros que ha estado inestable, el compromiso con el cliente que vamos a fallar.

4. Comunicación con stakeholders. El status update semanal, la demo, el email “vamos atrás, esto es lo que estamos haciendo al respecto”. Esto no es tomar notas; es traducción entre la realidad de ingeniería y la expectativa del negocio.

5. Gestión de dependencias. Coordinación cross-team. Coordinación con vendors. Procurement y licenciamiento. El trabajo aburrido que se cae sin PM.

6. Reporting y métricas. Los números que importan: cycle time, escape rate, carga de on-call, deploy frequency. No “story points completados”. Los story points no son métrica, son una ayuda de estimación.

Un PM que está haciendo solamente actualizar Jira y correr standups no es un PM. Es un coordinador. No hay nada malo con un coordinador — pero si estás pagando tarifa de PM senior, deberías esperar los seis ítems de arriba.

Elección de metodología: Scrum vs Kanban vs Shape Up

No hay una metodología universalmente correcta. Hay una metodología correcta para un contexto dado. Así elegimos.

Scrum

Mejor para: trabajo predecible de features con stakeholders externos. Ventas quiere saber cuándo envía un feature. El cliente firmó un contrato con una lista de entregables. Hay un update trimestral al board.

La fortaleza de Scrum es la estructura ritual: cada dos semanas te comprometes, cada dos semanas haces demo, cada dos semanas haces retro. Esa cadencia crea predictibilidad. Los clientes y stakeholders ven un latido.

La debilidad de Scrum es cuando sobre-aplicas los rituales. Si tu standup diario dura 45 minutos con 6 personas, lo estás haciendo mal. Si tus retros son fiestas de echar culpas, lo estás haciendo mal. Los rituales son andamiaje, no el edificio.

Nuestro default para equipos Scrum: sprints de 2 semanas, standup de 15 min máx, planning con techo de 90 min, demo + retro el viernes combinados (45 min cada uno, hard stop).

Kanban

Mejor para: soporte, ops, respuesta de seguridad, y cualquier cosa reactiva. Cuando el trabajo llega impredeciblemente y necesitas fluirlo, los compromisos de sprint son ficción. Sobre-comprometes, después lo arrastras, después sobre-comprometes otra vez.

Kanban reemplaza el time-box con límites de WIP y métricas de flujo. El equipo acuerda el work-in-progress máximo por estado (backlog → en-progreso → review → done). Cuando pegas el límite, no puedes empezar trabajo nuevo; tienes que desbloquear lo existente.

Kanban también funciona para equipos de producto, especialmente los maduros que no necesitan el latido de la demo de sprint. Muchos de nuestros equipos más senior corren un Kanban continuo con review mensual en vez de un sprint bi-semanal.

Shape Up

Mejor para: empresas product-led con liderazgo de diseño e ingeniería involucrado. Shape Up es el método de Basecamp: ciclos de 6 semanas de trabajo significativo, 2 semanas de cooldown, sin standups diarios, hill charts en vez de burndowns.

La premisa de Shape Up: la unidad de trabajo de producto significativo son 6 semanas, no 2. Dos semanas es suficiente para entregar un feature pero no suficiente para enviar algo que los usuarios noten. Seis semanas es suficiente para enviar algo que mueva la métrica.

Usamos Shape Up para clientes construyendo SaaS consumer o product-led donde el equipo tiene ingenieros senior y una cultura de diseño fuerte. No lo usamos para equipos B2B con compromisos pesados con clientes — los ciclos de 6 semanas no mapean a las cadencias de ventas.

La matriz

Contexto	Usar
Compromisos con clientes, timelines externos	Scrum
Reactivo / soporte / ops	Kanban
Product-led, equipo senior, design-driven	Shape Up
Equipo mixto de producto + soporte	Scrum para producto, Kanban para soporte, boards separados

El error más común que vemos: aplicar Scrum a un equipo de soporte. El equipo se siente mentido cada sprint porque la mitad del trabajo planeado se va por tickets. Cambia a Kanban. El mundo se vuelve más callado.

La cadencia semanal que sí envía

Para un equipo de sabor Scrum, esta es la cadencia que recomendamos:

• Lunes — Planning (60-90 min). Revisa el backlog, comprométete al scope del sprint, identifica dependencias y riesgos.
• Mar-Jue — Standups (15 min, async si es posible). Qué hice, qué estoy haciendo, qué me bloquea. Cualquier cosa que necesite conversación real se mueve a una llamada de seguimiento.
• Viernes — Demo + Retro (60-90 min combinados). Muestra lo que se envió (5-10 min por ítem). Después 20 min de retro: qué fue bien, qué no, un experimento para el siguiente sprint.

Notas:

• Los standups no necesitan ser en vivo. Standups async en Slack están bien para equipos senior, especialmente cross-timezone.
• Retros sin acciones son solo sesiones de quejas. Cada retro debe terminar con un cambio específico para el siguiente sprint.
• Las demos son para el equipo y los stakeholders, no para el PM. Si haces demo solo al PM, mátalo.

Para equipos Kanban, reemplaza el sprint planning con un triage semanal (30 min) y la demo con un review mensual. Los standups se vuelven “WIP review” — check rápido de qué está atascado y qué necesita atención.

Anti-patterns a evitar

El PM como gatekeeper. Los ingenieros no pueden hablar con producto sin pasar por el PM. Esto es veneno. El PM debe ser un conector, no un muro.

El PM como tomador de notas. Si el output principal de tu PM son notas de reuniones, mal casteaste el rol. Contrata un coordinador a la mitad del costo.

El PM como conserje de Jira. Actualizar tickets es responsabilidad del ingeniero haciendo el trabajo, no del PM. Si delegaste esto al PM, tus ingenieros realmente no son dueños de su trabajo.

Inflación de story points. Cuando la velocidad se vuelve métrica de performance, los puntos se inflan. La velocidad sube. El output queda plano. Después el equipo odia el sistema. Deja de medir velocidad. Mide cycle time y deploy frequency.

Extensión de sprint. “No terminamos así que extendemos el sprint 3 días”. No. Rueda el trabajo sin terminar al siguiente sprint y averigua por qué la estimación estuvo mal. El timebox del sprint es sagrado.

El PM que no entiende el trabajo técnico. Un PM que no puede leer un diagrama de sistema o seguir una conversación técnica va a ser pisado por los ingenieros (con razón) y bullied por los stakeholders. No colocamos PMs sin background técnico.

Cómo se ve un engagement de PM con Softronic

Nuestros engagements de PM típicamente corren como retainers mensuales porque el project management es trabajo continuo, no trabajo de proyecto.

Un retainer estándar de PM a $2,000/mes incluye:

• Un PM senior dedicado (5+ años, background técnico, fluent en inglés, overlap horario US/LatAm).
• Hasta 25 horas/semana en tu equipo.
• Facilitación completa de Scrum / Kanban / Shape Up según corresponda.
• Reportes semanales a stakeholders.
• Risk register mantenido continuamente.
• Setup de herramientas si se necesita: Linear, Jira, GitHub Projects, ClickUp — tenemos opiniones pero nos adaptamos a tu stack.

Para engagements de mayor toque (coordinación multi-equipo, workloads regulados, PM dedicado 40 hrs/semana), los retainers escalan desde ahí.

Conclusión

Un buen PM es la contratación de mayor leverage en un equipo de software después de los propios ingenieros senior. Un mal PM es un impuesto sobre cada ingeniero que toca. La diferencia es si está haciendo las seis cosas de la lista de arriba o solo corriendo reuniones.

Si tu equipo está enviando más lento de lo que la capacidad real de los ingenieros sugiere, el cuello de botella usualmente no es ingeniería. Es coordinación, priorización, y scope. Eso es trabajo de PM.

Podemos matchear un PM senior a tu equipo en 10-14 días. Discovery call es gratis.