Project != Product

La narrativa de abandonar los proyectos y organizarse alrededor de productos ganó. Y tenía razón en casi todo.

El problema es que, durante la mudanza, muchas organizaciones botaron también una disciplina que no era responsable del desastre: el oficio de ejecutar bajo incertidumbre. No el Gantt, el reporte de estado ni el seguimiento ceremonial del plan. La capacidad de convertir una idea en algo entregado, gestionar restricciones reales y pronosticar con evidencia en vez de optimismo.

Ese oficio sigue siendo necesario. Lo que ya no está tan claro es quién lo ejerce.

Tuve una conversación hace poco con una amistad, Product Manager, sobre los problemas que estaba enfrentando en su trabajo. Luego de eso, llevo varias semanas dándole vueltas a esto y todavía no estoy seguro de tenerlo del todo bien. Lo escribo más para ordenarlo que para cerrarlo. Si te parece que me equivoco, escríbeme — hablo en serio.

#.La escena

La escena se repite tanto que ya casi la puedo narrar de memoria. Así se manifiesta, en los equipos que he visto a lo largo de los años. Que quede claro que es eso — lo que he visto — y no un censo, ni el retrato de un equipo en particular.

Alguien de producto presenta. Y presenta bien: hizo entrevistas de verdad, no encuestas de relleno. Tiene una dirección que conecta con la estrategia del negocio. Sabe qué problema quiere resolver, para quién y por qué ahora. Todo bien. Todo sólido.

Entonces alguien pregunta:

—¿Y cuándo está listo?

Y la respuesta es un número.

—En marzo.

Un número que no viene de un histórico, de una distribución ni de iniciativas comparables. Un número razonable, en el sentido más peligroso de la palabra: suena lo bastante plausible para que nadie lo cuestione.

Todo el mundo asiente y lo anota. No porque exista evidencia detrás, sino porque en la sala nadie sabe cómo construir una respuesta distinta. Una respuesta que no sea simplemente razonable, sino defendible.

Y está bien. En serio: está bien.

No todas las personas que trabajan en producto tienen por qué dominar forecasting probabilístico, teoría de colas, gestión de dependencias o análisis de riesgos. Del mismo modo, dominar la ejecución no te convierte automáticamente en alguien capaz de descubrir qué producto vale la pena construir.

Son oficios distintos.

O, mejor dicho, son conjuntos distintos de preguntas.

#.La distinción de siempre

Producto conecta las necesidades de los usuarios con la estrategia del negocio. La disciplina de ejecución se ocupa de llevar una decisión hasta las manos de alguien bajo restricciones reales.

Listo. Ya lo dije.

Y si el artículo terminara aquí sería inútil, porque esa distinción es conocida desde hace años y no necesitas que yo la repita.

Además, el corte no es tan limpio como sugiere la definición. “Producto es el qué y proyecto es el cómo” se ve precioso en una diapositiva, pero no describe cómo se construye software.

El alcance también se descubre durante la ejecución. No terminas de decidir qué vas a hacer y después comienzas, limpiamente, a construirlo. Parte del qué aparece dentro del cómo: cuando pruebas una solución, encuentras una limitación técnica, observas cómo responde un usuario o descubres que una supuesta feature no resolvía el problema.

Separarlos como fases consecutivas sería, en sí mismo, volver a una lógica de cascada.

No son dos fases.

Tampoco son necesariamente dos personas o dos cargos.

Son dos conjuntos de preguntas que permanecen vivos durante todo el trabajo y que requieren competencias distintas:

• ¿Estamos resolviendo un problema que importa?
• ¿Estamos construyendo la solución correcta?
• ¿Qué incertidumbre deberíamos reducir antes de invertir más?
• ¿En qué orden conviene hacer el trabajo?
• ¿Cuándo es probable que esté disponible?
• ¿Qué dependencias pueden impedirlo?
• ¿Qué riesgo estamos aceptando?
• ¿Qué debemos recortar para proteger tiempo, coste y calidad?

Este artículo es sobre el segundo conjunto de preguntas.

No porque sea más importante que el primero, sino porque, en muchas organizaciones, quedó sin un responsable claro.

#.Ellos tenían razón

Mira, ya sé lo que estás pensando: “ajá, el señor de los proyectos defendiendo su gremio”. Déjame quitarte esa idea de encima antes de seguir.

Desde 2018, más o menos, la industria decidió algo: el modelo de proyecto es el problema. Mik Kersten publicó Project to Product ^fn-1 y lo dijo sin anestesia: la gestión de proyectos y los centros de costo son el modelo completamente equivocado si quieres innovar en software ^fn-2. Sriram Narayan escribió “Products Over Projects” en el sitio de Martin Fowler ^fn-3. Allan Kelly lo comprimió en cuatro palabras difíciles de mejorar: “products last, projects end” ^fn-4. Y el movimiento #NoProjects se dedicó a rematar al herido ^fn-5.

¿Sabes qué? Tenían razón. Y no lo digo por cortesía retórica.

Narayan lo puso en una sola frase:

“[T]he way project funding works, funds are made available to sustain a team for a duration of time much shorter than the lifespan of the underlying problem being addressed.”

Los fondos se hacen disponibles para sostener un equipo por un tiempo mucho más corto que la vida del problema que ese equipo está resolviendo. Ahí está. Ese es el desajuste estructural, y es letal. Financias dieciocho meses para un problema que va a existir diez años. El equipo entrega y se disuelve. Y como remata Narayan, no hay documentación, traspaso ni transferencia de conocimiento que compense la dispersión completa del equipo que construyó la cosa.

Leybourn y Hastie le dedicaron un libro entero al asunto ^fn-6, y la reseña de InfoQ lo resume así: el libro trata de por qué “running a temporary endeavour is the wrong approach to building sustainable products”. Ese “temporary endeavour” no es casual — es, palabra por palabra, como el PMBOK define un proyecto: “a temporary endeavor undertaken to create a unique product, service, or result”.

Así que sí. El modelo de financiamiento por proyecto — presupuesto temporal, alcance fijo de antemano, equipo que se arma y se desarma — es tóxico para software que nunca está terminado. Concedido. Sin peros, sin matices defensivos, sin “sí, pero”.

El problema es otro. El problema es qué más botamos en la mudanza.

#.Lo que se cayó del camión de la mudanza

Aquí está mi tesis completa, y cabe en una línea: matamos el modelo de financiamiento y, de paso, sin querer, matamos la disciplina de ejecución. Que es otra cosa.

Una es cómo el dinero llega al equipo. La otra es el oficio de llevar algo desde una idea hasta las manos de alguien, dentro de restricciones reales, con evidencia en vez de optimismo. Botar la primera no exigía botar la segunda. Pero venían en la misma caja, y nadie se fijó.

Lo raro es que nadie la recogió del piso.

Mira, verifiqué esto mientras escribía: el Scrum Guide no contiene la palabra “manager” ni una sola vez ^fn-7. Ni en la versión de 2020, ni en la de 2017. Cero veces, en unas cuatro mil palabras. Y en la versión de 2020, la palabra “project” aparece exactamente una vez, en esta frase:

“Each Sprint may be considered a short project.”

O sea, el proyecto no desaparece: se encoge hasta caber dentro de un Sprint. Y ojo, que Scrum no es negligente con la ejecución dentro de ese horizonte — tiene un Product Goal de largo plazo, reparte responsabilidades de planificación y calidad entre los tres roles, y el Sprint Planning incluye un pronóstico basado en desempeño pasado. Lo que queda fuera de su definición mínima es lo que no cabe en dos semanas ni en un solo equipo: las dependencias entre equipos, el presupuesto, los horizontes largos.

Y no estoy diciendo que Scrum eliminó el rol de project manager. Iba a decirlo — es lo que todo el mundo repite — y es falso. Scrum nunca lo tuvo. La ausencia no es un borrado, es un silencio: nunca estuvo ahí para eliminarlo.

Tampoco quiero forzar la lectura. Cuando la guía dice “Within a Scrum Team, there are no sub-teams or hierarchies”, está describiendo lo que pasa dentro del equipo; no prohíbe que exista un engineering manager o un director alrededor. Scrum simplemente no opina sobre cómo se organiza el resto de la empresa. El problema no es que Scrum diga algo equivocado. Es que mucha gente leyó ese silencio como una respuesta.

¿Y qué pasa cuando una responsabilidad no tiene dueño explícito? No desaparece. Se difunde. Cae sobre quien esté parado más cerca — con frecuencia el product owner, que ya tiene un trabajo de tiempo completo.

Quiero ser preciso acá, porque esto se lee fácil como un ataque y no lo es. El problema no es que los product managers y los product owners sean incapaces de ejecutar. El problema es que muchas organizaciones les entregaron la ejecución completa sin preguntarse si habían sido formados para ella.

Saber descubrir problemas, entender usuarios, ordenar oportunidades y conectar una iniciativa con la estrategia no te enseña automáticamente a pronosticar fechas, gestionar dependencias, modelar riesgos, controlar el trabajo en curso o reconocer cuándo la presión sobre tiempo y alcance está degradando la calidad.

Pero, en la práctica, ambas cosas terminan en las mismas manos.

El product manager o el product owner recibe la presión de los stakeholders, traduce esa presión en una fecha y después administra el trabajo casi exclusivamente desde la perspectiva que conoce: prioridad, alcance y valor. Cuando la fecha se vuelve inamovible y el alcance sigue creciendo, rara vez tiene autoridad para aumentar el coste. Lo que queda es presionar al equipo, reducir controles, aplazar trabajo técnico o aceptar compromisos que nadie nombró explícitamente.

No porque quiera destruir la calidad. Porque nadie convirtió la calidad en una restricción protegida y nadie asumió la responsabilidad de explicar qué debía moverse cuando las restricciones entraban en conflicto.

Ese es el hueco. No la ausencia de un cargo llamado project manager, sino la suposición de que saber qué conviene construir implica también saber cómo conducir su ejecución bajo presión.

Así se manifiesta, en los equipos que he visto. Que quede claro que es eso — lo que he visto — y no un censo.

La columna de la derecha es el problema que quiero discutir.

SAFe, para ser justos, sí notó el hueco y lo tapó con el Release Train Engineer. Y aquí tengo que ser cuidadoso, porque la primera versión de este párrafo la escribí mal: SAFe sí le asigna al RTE gestión de riesgos, eliminación de impedimentos y facilitación de la ejecución del tren ^fn-8. Las responsabilidades están ahí, escritas. Lo que me llama la atención es el titular con el que lo presenta — “a servant leader and ART coach” — y el hecho de que necesitáramos inventar un rol nuevo, con vocabulario de coaching, para volver a decir lo que un plan de proyecto decía sin ceremonia. La función volvió. El nombre tuvo que disfrazarse.

Ni siquiera el PMI lo tiene resuelto. El PMBOK 7, en 2021, sacó los 49 procesos y las 10 áreas de conocimiento del centro de la guía y los reemplazó por 12 principios y 8 dominios de desempeño, con una sección titulada literalmente “A System for Value Delivery” ^fn-9. El PMI acercándose al lenguaje de valor y resultados. Y en noviembre de 2025 sale el PMBOK 8, que conserva los principios y la orientación a valor pero devuelve unos 40 procesos, ahora presentados como guía adaptable en vez de receta.

No lo leo como que el PMI esté perdido — principios y procesos no son categorías rivales. Lo leo como que la institución que me certificó lleva cinco años buscando en público el equilibrio entre las dos cosas, y todavía no lo encuentra. Si a ellos les cuesta, entiendo perfectamente que a tu equipo también.

#.Me las enseñaron mal

Me formé en esto. Maestría, certificaciones, el paquete completo. Y por eso mismo te puedo decir con autoridad de primera mano que una parte de lo que me enseñaron estaba mal, y que la gente de proyectos arrastra ese error con una terquedad admirable.

Me enseñaron que la ejecución vive en cuatro dimensiones: tiempo, alcance, coste y calidad. Y me enseñaron el triángulo: mueve una, las otras se ajustan. Elige dos. La cosa suena a ley física y tiene la elegancia de las cosas falsas.

Empecemos por la que más me importa, porque es la que ya discutimos en Piano piano si va lontano: la calidad no debería ser una de las variables que negocias.

La evidencia es vieja y es clara. En Accelerate, Forsgren, Humble y Kim lo dicen con una palabra que delata su propia sorpresa — “astonishingly” — y con datos de miles de equipos detrás: no hay trade-off entre mejorar el desempeño y alcanzar más estabilidad y calidad ^fn-10. Los que van rápido van estables, y van estables porque construyen calidad adentro, no a pesar de ello. Ese hallazgo se cita congelado en el tiempo con demasiada frecuencia: son datos de 2017, y el reporte DORA de 2024 encontró que el clúster medium tiene mejor tasa de fallos que el high ^fn-11. La correlación se mantiene dentro de cada grupo pero se agrieta entre grupos. El cuerpo de conocimiento está vivo. Lo que no se ha movido es lo central: la calidad no debería funcionar como una palanca discrecional que ajustas para cumplir la fecha.

El handbook de DSDM ^fn-12 me cambió el argumento. DSDM es el marco ágil que invirtió el triángulo: fija tiempo, coste y calidad al terminar la fase de fundamentos, y absorbe los imprevistos moviendo lo único que queda — las features.

Pero lo interesante no es eso. Lo interesante es lo que dice del modelo tradicional. Yo asumía que el modelo clásico “fija la calidad”. No. DSDM dice algo más incómodo y más real:

“Under such pressure, quality often becomes a variable, as a result of introducing compromises which have not been thought through, by reducing essential quality control steps or by cutting back on testing.”

La calidad no está fija en el modelo clásico: está desprotegida. Cuando aprietas el tiempo y el coste con el alcance clavado, la calidad es lo único que queda sin custodia. Nadie decide sacrificarla. Simplemente es la que cede, porque es la única que puede ceder en silencio.

Así que de las cuatro dimensiones, una cambia de naturaleza: la calidad es una restricción que se declara, no una palanca que se jala. Sigue siendo una variable del sistema — se puede medir, proteger y degradar, y los equipos la intercambian todo el tiempo. El punto es que casi nunca lo deciden: la dejan caer. Y de las tres que quedan, el alcance suele ser la más segura y la más transparente de ajustar, siempre que hayas fijado antes un piso de calidad del que no te mueves.

Digo “suele” a propósito. Hay proyectos donde el alcance mínimo lo define un regulador, donde una funcionalidad no se puede partir en dos, o donde entregar la mitad no entrega la mitad del valor sino ninguno. DSDM propone una estrategia coherente, no una ley natural.

¿Y el tiempo y el coste? Ahí es donde el oficio de verdad empieza. Y no se parece en nada a un Gantt.

#.Casi toda nuestra evidencia es basura

Si le preguntas a alguien de proyectos por evidencia de que los proyectos fracasan, te va a citar el CHAOS Report de Standish. Es probablemente la estadística más reconocible de la disciplina: 31% de proyectos cancelados, 53% con problemas, 16% exitosos ^fn-13.

Ese dato no aguanta el peso que le ponemos encima. Y desarmarlo es la mejor forma que conozco de explicar por qué la ejecución es un oficio y no un adorno.

Empieza por la definición. Para Standish, “éxito” significa entregado a tiempo, dentro del presupuesto, y con todas las features especificadas inicialmente. Léela otra vez. Eso no mide valor entregado. Mide adherencia a un estimado hecho cuando menos sabías. Un proyecto que descubrió a mitad de camino que la mitad del alcance era inútil, lo recortó, y entregó algo que la gente ama, es un fracaso según Standish. Un proyecto que entregó puntualmente cien features que nadie usa es un éxito.

En 2010, Eveleens y Verhoef publicaron en IEEE Software un paper con un título que ya dice bastante: “The Rise and Fall of the Chaos Report Figures” ^fn-14. Agarraron las definiciones de Standish y las aplicaron a 5,457 pronósticos reales de 1,211 proyectos reales. Encontraron esto:

Una empresa real — Landmark Graphics, que subestima sistemáticamente sus pronósticos — obtiene 5.8% de éxito según Standish. Los autores construyeron entonces una organización ficticia con las mismas desviaciones exactas pero con el signo invertido: sobrestima en lugar de subestimar. Esa organización obtiene 94.2% de éxito.

La misma calidad de estimación. Idéntica. Seis por ciento contra noventa y cuatro por ciento, y lo único que cambió fue el signo del sesgo.

La métrica de Standish no mide éxito. Mide en qué dirección te equivocas. Y como toda métrica que se convierte en objetivo, se pudre: los autores documentan una organización que adoptó las definiciones de Standish y cuyos gerentes empezaron a inflar presupuestos para garantizar el “éxito”. En sus palabras, la métrica “perverts rather than improves estimation accuracy”. Es la ley de Goodhart otra vez, la misma que discutí en La muerte del LOC, y aparece donde uno menos la busca.

¿Y de dónde salió la muestra de 1994? Jørgensen y Moløkken-Østvold fueron a buscarlo y encontraron que Standish describe su propio método así ^fn-15:

“We then called and mailed a number of confidential surveys to a random sample of top IT executives, asking them to share failure stories.”

Pidieron historias de fracaso. Y con eso calcularon una tasa de fracaso. Cuando los investigadores le pidieron a Standish que explicara su metodología, Jørgensen y Moløkken-Østvold resumen así la respuesta que recibieron: dar esa información “would be like giving away their business for free”.

Y el remate, que está en el paper de IEEE Software. Cuando Eveleens y Verhoef confrontaron a Standish con sus hallazgos, el chairman Jim Johnson respondió:

“All data and information in the Chaos reports and all Standish reports should be considered Standish opinion and the reader bears all risk in the use of this opinion.”

Opinión. Los autores cierran el paper así: “We fully support this disclaimer, which to our knowledge was never stated in the Chaos reports.” Ese descargo nunca apareció en los reportes que Standish vende.

Para ser justo con el rigor: nadie ha demostrado que las cifras sean numéricamente falsas. Nadie puede — los datos crudos nunca se publicaron, los reportes no son revisados por pares. El argumento no es “mienten”. El argumento es que no son auditables y no significan lo que crees que significan. Es una distinción importante y no la voy a difuminar.

#.Lo que sí aguanta

Ahora, que la evidencia popular sea mala no significa que no haya evidencia. Hay, y es buena, y casi nadie la cita.

Flyvbjerg y Budzier, en Harvard Business Review, estudiaron 1,471 proyectos de IT ^fn-16. El sobrecosto promedio fue 27% — nada dramático. Pero ese promedio esconde la historia real:

“Fully one in six of the projects we studied was a black swan, with a cost overrun of 200%, on average, and a schedule overrun of almost 70%.”

Uno de cada seis. Y ojo, porque este dato se cita mal constantemente: el 200% es del subconjunto de cisnes negros, no del promedio. El promedio es 27%. Lo que mata no es que los proyectos de IT se pasen un poco. Es que una proporción anormal de ellos se sale de la carretera por completo. Y mientras todos miran el promedio, nadie está mirando ahí.

Algo que casi nadie menciona al citar este estudio: la muestra es 92% de agencias públicas y 83% de proyectos en Estados Unidos. Los autores dicen haber encontrado poca diferencia con el resto, pero ese sesgo existe y deberías saberlo. Y el artículo nunca define numéricamente qué es un “cisne negro”, así que el “uno de cada seis” no es auditable desde ahí. Para el argumento serio hay que ir al paper académico de 2022, con 5,392 proyectos ^fn-17. Conviene bajarse de la jerga, porque esta es la parte que de verdad importa.

Piensa en la estatura de las personas. Se concentra en un rango estrecho: hay gente más alta y gente más baja, pero nadie mide cuatro metros, y por más personas que midas, el más alto del mundo jamás va a duplicar el promedio. Los extremos existen, pero están amarrados. En un mundo así, el promedio te dice casi todo lo que necesitas saber.

Ahora piensa en la riqueza. El promedio, solo, dice muy poco, porque en cualquier grupo puede haber alguien con diez mil veces más que el resto, y esa sola persona mueve el número. Los extremos no están amarrados: mandan.

Los sobrecostos de software se parecen a la riqueza, no a la estatura. Eso es lo que demostraron con 5,392 proyectos. Y los autores lo dicen sin acusar a nadie: los gerentes “may be unwittingly exposing their organizations to extreme risk by severely underestimating the probability of large cost overruns.” Sin darse cuenta. No por negligencia, sino por planificar como si estuvieran midiendo estaturas.

Y esto no es algo que se aprenda haciendo discovery. Que el promedio, solo, es una estadística peligrosamente incompleta. Que los sobrecostos extremos no son la anomalía improbable que sugieren los modelos convencionales, sino una parte gorda de la distribución. Que el riesgo vive en los extremos, y que hay que ir a buscarlo ahí.

¿Y qué haces con eso? Flyvbjerg propuso hace veinte años una respuesta que sigue siendo la mejor disponible: reference class forecasting ^fn-18, que él define como “a method for systematically taking an outside view on planned actions”. En cristiano: deja de preguntarte cuánto va a tomar este proyecto, con sus particularidades y su equipo y su encanto único. Pregúntate cuánto tomaron los proyectos parecidos. La vista de afuera, no la de adentro — una distinción que, contrario a lo que casi todo el mundo cree, no viene de Thinking, Fast and Slow sino de un paper de Kahneman y Lovallo de 1993 ^fn-19.

Tu intuición sobre tu propio proyecto, sola, es una base débil. Una clase de referencia comparable te deja calibrarla contra algo que pasó de verdad. No la sustituye — la aterriza. Eso es el oficio.

#.Nuestro cono también es mentira

Y ya que estamos derribando cosas, déjame derribar una de mi propia casa.

Todo el que estima software conoce el cono de incertidumbre: al inicio de un proyecto tus estimados están en un rango de 4x hacia arriba o hacia abajo, y el cono se cierra conforme aprendes. Se atribuye a Barry Boehm y se presenta, siempre, como una curva derivada empíricamente.

Fui a buscar la fuente. El rango de 4x es real y está ahí ^fn-20. Pero tiene una nota al pie, la número 4, escrita por Boehm, que dice:

“These ranges have been determined subjectively, and are intended to represent 80 percent confidence limits.”

Subjetivamente. Lo dice él. Los multiplicadores canónicos de esa figura no salieron de los datos: salieron del juicio experto de un señor muy inteligente. Y son límites de confianza del 80%, no cotas absolutas. Ha habido investigación posterior sobre cómo evoluciona la incertidumbre en un proyecto — no estoy diciendo que la idea sea falsa. Estoy diciendo que solemos presentar esos números con mucha más autoridad empírica de la que tenía la fuente original. Boehm ni siquiera lo llamó “cono” — su figura se llama “Software cost estimation accuracy versus phase”. El nombre bonito se lo puso Steve McConnell en 1997, trece años después de ese paper.

Mi gremio no tiene autoridad moral aquí. Nosotros también citamos folclore y le llamamos evidencia.

#.El puente que nadie cruza

Hasta aquí he desarmado bastante. Toca construir.

Si me obligaran a resumir el oficio de ejecución en un solo concepto — uno — sería este: el coste de la demora. Cost of delay. Y es el mejor puente que existe entre producto y proyecto, porque es simultáneamente una pregunta de los dos.

Donald Reinertsen construyó el marco completo en The Principles of Product Development Flow ^fn-21, y su principio E3 no se anda con rodeos:

“If you only quantify one thing, quantify the cost of delay.”

¿Por qué? Porque es uno de los pocos denominadores económicos que te dejan comparar decisiones que de otro modo son incomparables. ¿Vale la pena partir este lote en tres? ¿Vale la pena tener capacidad ociosa? ¿Cuál de estas dos cosas va primero? Sin coste de demora, todas esas preguntas se responden con jerarquía y volumen de voz. Con coste de demora, se responden con aritmética.

El problema es que casi nadie lo tiene. Reinertsen explica que priorizar así solo se puede cuando conoces el coste de la demora, y entonces suelta, de pasada, que esa es “information that 85 percent of developers do not have” ^fn-21. Lo escribió en 2009 y sigue describiendo la sala en la que estuviste ayer.

Ochenta y cinco por ciento. Y lo cito con cuidado, porque este dato circula deformado: Reinertsen dice “developers”, no “empresas”. Tampoco es un estudio con muestra y método — es la afirmación profesional de un señor que para entonces llevaba veintiséis años escribiendo sobre el tema. Vale por lo que vale.

Hay otro dato suyo, en el mismo capítulo. En las empresas que no calculan el coste de la demora, distintas personas del mismo proyecto dan respuestas que varían 50 a 1. Cincuenta a uno. Sobre el mismo proyecto, en la misma empresa, la misma semana.

Lo bonito del concepto es que la pregunta “¿cuánto nos cuesta cada semana de retraso?” no es de producto ni de proyecto. Necesita el conocimiento de negocio de uno y el conocimiento de flujo del otro. Es literalmente la conversación que ambos oficios deberían estar teniendo y no tienen.

Y sobre el tiempo, la respuesta moderna ya existe y no es un Gantt. Es probabilística. Daniel Vacanti lo resume en una línea que debería estar pegada en la pared de cada sala de planificación: un pronóstico sin una probabilidad pegada al lado es determinista ^fn-22. Y el futuro no lo es. Cuando alguien pregunta “¿cuándo está listo?”, la respuesta profesional no es “el 15 de marzo”. Es “90% de probabilidad de terminar antes del 22 de marzo, basado en nuestro histórico de las últimas doce semanas”. Ese número sale de correr miles de escenarios contra tu propio histórico de entregas — una simulación de Monte Carlo. La simulación es sencilla y con un histórico medianamente limpio la montas en una tarde con lo que ya está en Jira. Conseguir que el histórico esté limpio, esa es otra conversación.

Con una advertencia que Vacanti subraya y que la gente ignora: todo esto depende de que tu histórico se parezca a tu futuro. Si tu flujo cambia constantemente — cambió el equipo, cambió lo que cuenta como “terminado”, hay trabajo que lleva meses abierto — entonces la confianza del pronóstico se desploma, tenga probabilidad pegada o no. Los supuestos de la ley de Little, que relacionan cuánto trabajo tienes abierto con el ritmo al que sale, sirven justamente para chequear si tu proceso es lo bastante predecible como para que valga la pena pronosticarlo. Monte Carlo no rescata el caos. Primero estabilidad, después pronóstico.

#.El espejo, de este lado

Llevo mil palabras señalando un hueco del lado de producto. Toca la simetría, porque sin ella esto es una pelea de gremios y no un argumento.

Mi formación no me preparó para producto. Y no me di cuenta durante años.

Nuestro pecado tiene una forma característica: convertir el discovery en un cronograma. Poner las entrevistas de usuario en el Gantt, con fecha de fin, como si entender a alguien fuera una tarea con dependencia. Preguntar “¿cuándo terminamos de descubrir?” esperando que después ya no quede incertidumbre — que es donde la pregunta se rompe. Un spike sí puede durar una semana y un experimento sí puede tener criterio de parada; lo que no existe es el punto donde dejas de aprender y empiezas a construir.

Cuando uno se entrena en ejecución, desarrolla un reflejo: convertir todo en un plan. Y hay una clase de problema — justo la que le importa a producto — donde ese reflejo es el equivocado. Marty Cagan enumera cuatro riesgos que hay que atacar antes de construir: valor, usabilidad, factibilidad y viabilidad de negocio ^fn-23. Adivina cuál de los cuatro es el mío. Uno. Uno de cuatro. Y aun así hemos entrado a esas conversaciones convencidos de que un plan bien hecho las resuelve todas.

Cagan lo escribió sin caridad, y con razón: las empresas con mentalidad de IT siguen financiando proyectos — output, lo que sale — en vez de equipos de producto medidos por resultados de negocio — outcome, lo que cambia ^fn-24.

Un plan impecable que entrega puntualmente lo incorrecto sigue siendo un fracaso. Y eso es algo que mi gremio, el de las cuatro dimensiones, tardó demasiado en aceptar — porque nuestras métricas no saben distinguir entre entregar bien y entregar lo correcto. Standish, otra vez, en el fondo de todo.

Así que no: esto no va de que producto aprenda proyectos. Va de que las competencias habituales de producto no garantizan dominio del pronóstico, el flujo, las dependencias ni el riesgo — y de que la formación tradicional en proyectos no garantiza dominio del discovery, la estrategia ni la validación de valor. Va de que dejemos de asumir que alguien, por su título, ya trae las dos cosas.

#.La disciplina huérfana

Entonces, ¿qué hacemos?

No voy a decirte “contrata un PMP”. Sería vender mi gremio, y además no funcionaría — el título es lo de menos. Hay un conjunto de responsabilidades concretas que no tiene dueño, y todo el mundo asume que alguien más las carga.

Estas son. Léelas y pregúntate quién las hace en tu equipo:

• Pronosticar con evidencia, no con optimismo. Vista de afuera. Proyectos parecidos. Distribuciones, no puntos. Si tu respuesta a “¿cuándo?” no dice su nivel de confianza ni sus supuestos, no es un pronóstico incompleto: es una promesa esperando a que alguien la cobre.
• Conocer el coste de la demora. Aunque sea aproximado. Aunque sea un rango. Si nadie en el equipo puede decirte qué cuesta una semana de retraso, están priorizando por volumen de voz.
• Gestionar cuánto trabajo está abierto a la vez, y de qué tamaño. Cuando el trabajo empezado supera la capacidad real del equipo, las esperas crecen y todo tarda más — igual que una fila de supermercado con demasiada gente adentro. Y mientras más grande el paquete que entregas de una sola vez, más tarde te enteras de que venía malo. No es preferencia estética: es el comportamiento que estudia la teoría de colas desde hace un siglo.
• Ver las dependencias antes de que exploten. Nadie mira esto hasta que un equipo lleva tres semanas bloqueado esperando a otro.
• Llevar un registro de riesgo que alguien lea. Aburrido. Anticuado. Funciona.
• Proteger la calidad explícitamente, porque como nos enseñó DSDM sin querer, lo que no se protege es lo que cede en silencio.

¿Quién hace eso? Puede ser un delivery lead. Puede ser el engineering manager. Puede ser el tech lead. Puede hacerlo un product manager o un product owner, por supuesto — pero no por virtud del título, ni porque producto sea dueño de todas las decisiones. Puede hacerlo si además domina, o si está acompañado por alguien que domine, el pronóstico, el flujo, las dependencias, el riesgo y la protección explícita de la calidad.

El título me da igual. El error no es que producto participe en la ejecución; el error es entregarle toda la ejecución a producto y fingir que las competencias vienen incluidas. Y lo que tampoco me da igual es la respuesta “es que eso lo lleva el equipo”, que en la práctica quiere decir nadie, dicho con mejor ropa.

Porque Jira no lo hace. Jira es un lugar donde poner cosas.

#.Cierre

Kersten, Kelly, Narayan y los demás ganaron la discusión. Y la ganaron bien: el modelo de financiamiento por proyecto merecía morir y el mundo es mejor con equipos de producto duraderos.

Pero cuando desmontamos la casa, botamos algo que no estaba roto. La disciplina de ejecución — la de verdad, la de las distribuciones y las colas y el coste de la demora, no la del Gantt y el status report — sobrevivió a su propio modelo de financiamiento y nadie fue a rescatarla. Se quedó ahí, tirada entre los escombros, mientras el resto de nosotros discutía si los story points deberían ser Fibonacci.

Y por eso, cuando alguien de producto o un stakeholder responde “en marzo” con toda la seguridad del mundo, no me molesta. Me preocupa otra cosa: que nadie sepa que esa pregunta tiene una respuesta profesional y un poco más correcta. Que, de hecho, existe un oficio detrás. Que hay cien años de investigación operacional, teoría de colas y economía del desarrollo esperando a que alguien los use.

Project != Product. No porque uno valga más. Porque son dos oficios, y ninguno de los dos es el que tú crees que ya dominas.

Que alguien de producto no sepa pronosticar con evidencia está bien. No es su oficio, y nadie le dijo que lo fuera. Lo que no está bien es que hayamos armado tantos equipos donde ese oficio no es de nadie, y sigamos sorprendiéndonos cuando la fecha llega y no está. O cuando la fecha nos la impone un Product Manager y un Designer con base en una sopa de fe y oraciones.