Gestión de proyectos de software: la guía sin humo

La gestión de proyectos de software no es la gestión de proyectos «de siempre» con otra jerga. Tres propiedades del software rompen los métodos clásicos y explican casi todos los desastres de estimación que has vivido:

El avance es invisible. En una obra ves el segundo piso; en software, un 80 % puede significar que falta la parte difícil. Los porcentajes de avance en software son opiniones con formato de número, y por eso el progreso se mide en software funcionando, no en tareas cerradas ni en horas quemadas.

El alcance cambia mientras se construye. Al ver el producto, el cliente entiende mejor lo que quiere y pide cambios; es parte del proceso, no una traición. Un método que trata cada cambio como una excepción burocrática termina ignorado. La gestión aquí consiste en canalizar el cambio con reglas —control de cambios y re-priorización del backlog—, no en prohibirlo.

Existe la deuda técnica. Ninguna otra industria entrega el proyecto «un poco torcido» para cumplir la fecha y sigue cargando el defecto años después. En software sí, y esa deuda invisible frena cada entrega futura. Un plan que no reserva tiempo para pagarla se ralentiza mes a mes sin motivo aparente. Si gestionas varios frentes técnicos a la vez, la organización por dominios que proponemos en software y gestión de proyectos complementa lo que ves aquí.

Para equipos de 2 a 15 personas, el proceso que funciona es deliberadamente corto. Cinco etapas, cada una con una cadencia y un resultado observable:

Dos reglas que sostienen el ciclo: nada entra al sprint sin prioridad del backlog, y nada sale del sprint sin QA. Si el equipo trabaja con flujo continuo en lugar de sprints cerrados —habitual en soporte y producto maduro—, la variante kanban con límites de trabajo en curso cumple la misma función; el modelo híbrido está desarrollado en ScrumBan.

En un equipo de dos a quince personas, crear un puesto de project manager dedicado suele añadir un nodo de reportes, no capacidad de entrega. Lo que el proceso necesita son tres funciones, y las tres pueden convivir en personas que además construyen:

• Quien prioriza. Decide el orden del backlog y responde dudas de alcance en horas, no en semanas. Es la función de product owner y suele ser el fundador, el lead técnico o el cliente interno.
• Quien facilita. Sostiene el ritmo: el tablero al día, los bloqueos visibles, la retro en fecha. Es un rol rotativo y de medio tiempo, no un cargo.
• Quien asegura calidad. QA puede ser compartido, pero tiene que existir explícitamente: cada cambio se prueba antes de integrarse, sin excepciones «porque era chico».

El síntoma de que faltan funciones no es el desorden visible; es la pregunta que nadie responde rápido: qué se construye primero y por qué. Si esa respuesta tarda más de un día, el problema es de priorización, no de personal. Un project manager formal se justifica cuando coordinas varios equipos o clientes simultáneos con interdependencias —y en ese caso su trabajo es gestionar el portafolio, no pasar lista de tareas—.

Las métricas que predicen si un proyecto de software llegará son de flujo, porque miden el trabajo terminado y no la actividad:

• Lead time. Días desde que una tarea se compromete hasta que está en producción. Es la métrica de las promesas: con ella puedes decir «esto llega en dos semanas» con datos en la mano.
• Throughput. Tareas terminadas por semana. Te permite proyectar fechas con el historial real del equipo en lugar de con su optimismo.
• Bugs en producción. Los defectos que escaparon del QA. Si crecen release tras release, el problema no es de testing sino de alcance y prisa.
• Trabajo en curso. Cuántas cosas hay abiertas a la vez. Es la causa subyacente de casi todo: lead time largo y bugs suelen ser síntomas de WIP desbordado.

Lo que no medir: story points por persona, horas registradas contra estimadas y ocupación al 100 %. Comparar puntos entre personas corrompe las estimaciones en un sprint, las horas quemadas no dicen nada del valor producido y un equipo ocupado no es un equipo que entrega. Estas métricas de flujo, además, son las que alimentan cualquier dashboard serio del proyecto sin que nadie tenga que rellenarlas a mano.

El error clásico de un equipo que crece es copiar el stack de una empresa de mil personas: flujos de trabajo de doce estados, campos obligatorios, ceremonias en cascada. El costo no es la licencia sino la fricción: cuando actualizar una tarjeta toma dos minutos de formularios, el tablero miente porque nadie lo actualiza.

Lo que un equipo de 2 a 15 necesita caben en una lista corta: un tablero con límites de trabajo en curso, un backlog priorizable, checklists y procesos documentados para lo repetible, sincronización con el repositorio —que en software es donde de verdad vive el avance— y una vista de estado que no haya que armar a mano. Las opciones con menos complejidad que un corporativo están comparadas en alternativas a Jira.

Si quieres exactamente eso —kanban con límites WIP, GitHub sync, checklists y automatizaciones, datos en JSON local en tu carpeta, sin cuenta ni asientos— Hito está pensado para equipos de 1 a 15 personas.

👉 Prueba Hito gratis — gestión de software local-first con GitHub sync, sin nube.