Financiar productos, no proyectos: por qué los equipos persistentes cambian los resultados
Una organización que financia iniciativas con alcance y fecha fijos se comportará como organización de proyectos aunque llame equipos a sus equipos. El modelo de financiamiento determina el comportamiento más que cualquier metodología.
Hay una regla que se cumple con una consistencia molesta: la estructura de financiamiento gana siempre. Si una organización financia proyectos con alcance definido y fecha comprometida, va a comportarse como organización de proyectos, sin importar cuánta metodología ágil tenga encima, cuántos equipos multidisciplinarios haya formado o cuántas ceremonias corra por semana.
El motivo es simple. El financiamiento es lo que determina qué se le pregunta a la gente, y la gente responde a lo que se le pregunta. Si lo que se pregunta es “¿vamos a entregar lo comprometido en la fecha comprometida?”, entonces cumplir el alcance es el objetivo, y todo lo que amenace ese cumplimiento —incluido descubrir que el alcance estaba mal— se convierte en un problema a gestionar en vez de en un hallazgo a celebrar.
Lo que el modelo de proyecto produce sin quererlo
Equipos que se arman y se disuelven. Cuando el dinero está atado a una iniciativa, el equipo dura lo que dura la iniciativa. Eso destruye sistemáticamente lo más caro de construir: conocimiento del dominio, confianza interna, entendimiento de por qué el sistema está como está. Cada equipo nuevo vuelve a aprender lo que otro equipo ya sabía y no dejó escrito.
Ausencia de responsabilidad sobre las consecuencias. El equipo que construye no es el que opera, y el que opera no participó de las decisiones. Los atajos que se toman para llegar a la fecha los paga alguien que no estaba en la sala. La retroalimentación entre decisión y consecuencia se corta, y sin esa retroalimentación no hay aprendizaje posible.
Descubrimiento comprimido al inicio. Como el alcance se define para justificar el financiamiento, la investigación tiene que ocurrir antes de tener financiamiento, que es cuando menos recursos hay para hacerla. El resultado es un alcance definido con la peor información disponible en todo el ciclo.
Detener se vuelve fracaso. El compromiso fue entregar. Detener algo a mitad de camino, aunque la evidencia diga que no funciona, se lee como incumplimiento. Entonces se termina, se entrega, y el aprendizaje —que existía y era valioso— se convierte en un producto que nadie usa.
Qué significa financiar productos
Financiar productos significa asignar capacidad estable a un equipo responsable de un ámbito, con resultados esperados en vez de alcance comprometido.
El equipo existe antes de que exista el problema específico que va a resolver el próximo trimestre, y va a seguir existiendo después. Lo que se revisa periódicamente no es si el equipo sigue, sino si el nivel de inversión en ese producto sigue siendo el correcto dada la evidencia acumulada.
El cambio de pregunta es el corazón del asunto:
| Modelo de proyecto | Modelo de producto |
|---|---|
| ¿Entregamos el alcance en la fecha? | ¿Movimos el resultado que importaba? |
| ¿Cuánto costó vs. lo presupuestado? | ¿Qué aprendimos y qué justifica seguir? |
| ¿Quién es responsable del retraso? | ¿Qué información nueva tenemos? |
| Éxito = entregar | Éxito = decidir mejor con evidencia |
Las objeciones reales
“Necesitamos previsibilidad para comprometernos con clientes y con el directorio.” Legítima. Y no se resuelve con alcance fijo, que produce previsibilidad aparente: se compromete una fecha y después se negocia calidad en silencio. Se resuelve con pronóstico basado en el comportamiento histórico del equipo, que da rangos con probabilidad en vez de fechas únicas. Un rango honesto es más útil para planificar que una fecha que todos saben que se va a mover.
“Si el equipo es permanente, ¿cómo controlamos que trabaje en lo importante?” Con resultados definidos y revisión periódica de la evidencia. El control no desaparece: cambia de objeto. Se controla la dirección y el aprendizaje, no la conformidad con un plan escrito antes de saber nada.
“Tenemos áreas que solo hacen proyectos, no productos.” También válida. No todo es producto. Una migración de infraestructura, una implementación regulatoria con fecha legal, una integración por adquisición: son proyectos y está bien tratarlos como tales. El error es tratar como proyecto lo que es un producto vivo con usuarios y evolución continua, que es la mayoría de lo que las organizaciones construyen hoy.
Lo que hay que resolver con finanzas
La conversación con el área financiera es el paso que más veces hunde este cambio, y suele hundirse por una razón evitable: se plantea como una petición de flexibilidad en vez de como un rediseño del control.
Finanzas tiene requisitos legítimos que no desaparecen porque la organización adopte un modelo de producto. Necesita poder proyectar el gasto, explicar variaciones, capitalizar lo que corresponde según la norma contable aplicable y responder ante auditoría. Un modelo que no atienda esos cuatro puntos no se va a aprobar, y con razón.
La buena noticia es que los cuatro se atienden mejor con equipos persistentes que con proyectos.
Proyección de gasto. Un equipo estable tiene un costo predecible: es su capacidad, mes a mes. Un portafolio de proyectos con alcance variable, en cambio, tiene un costo que se revisa cada vez que el alcance se ajusta, que es siempre.
Explicación de variaciones. Con capacidad estable, la variación de gasto es mínima por construcción. Lo que varía es a qué se dedicó esa capacidad, y eso se documenta en las decisiones de portafolio.
Capitalización. Este es el punto que requiere trabajo real y asesoría contable específica, porque los criterios dependen de la norma aplicable y de la naturaleza del trabajo. No es insalvable: muchas organizaciones lo resuelven registrando el esfuerzo por tipo de trabajo en vez de por proyecto. Pero conviene abordarlo explícitamente y temprano, no descubrirlo a mitad de la transición.
Auditoría. Un registro de decisiones de portafolio con fecha, criterio, evidencia y resultado es un rastro de auditoría mejor que un expediente de proyecto, porque muestra el razonamiento y no solo el cumplimiento.
Hay una reformulación que suele desbloquear la conversación. El modelo de proyecto controla el input: cuánto se gasta en qué alcance. El modelo de producto controla el momento de decisión: cada trimestre se revisa si la inversión sigue justificada, con evidencia.
Ambos son formas de control. El segundo es más frecuente y se apoya en información más reciente. Presentado así —más puntos de control, con mejor información— la propuesta deja de sonar a pedir libertad y empieza a sonar a lo que efectivamente es.
La transición sin ruptura
Cambiar el modelo de financiamiento de una organización entera es una intervención mayor que requiere alineación con finanzas, con auditoría y con quien gobierna el presupuesto. No empieza ahí.
Empieza con una excepción deliberada: uno o dos ámbitos que se financian como producto, con equipo estable, resultados esperados y revisión trimestral de evidencia. Todo lo demás sigue igual. La excepción se documenta, se acuerda con finanzas y se acota en el tiempo.
Lo que produce esa excepción, si se sostiene doce meses, es lo único que efectivamente convence: una comparación observable dentro de la propia organización. Ese equipo va a poder responder preguntas que los equipos de proyecto no pueden responder —por qué el sistema está como está, qué se intentó antes, qué evidencia respalda la próxima apuesta— y esa diferencia es visible para cualquiera que trabaje con ambos.
Ningún argumento externo sobre modelos de financiamiento pesa tanto como esa comparación. Y ninguna presentación sobre las bondades del modelo de producto reemplaza el hecho de tener uno funcionando al lado.