Modelo operativo orientado a producto: presupuesto, equipos y métricas

En muchas áreas de TI el trabajo llega en forma de proyecto. Alguien aprueba un presupuesto, se arma un equipo, se entrega un alcance en una fecha y el equipo se disuelve. Lo construido pasa a "operación", que lo recibe con documentación incompleta y sin presupuesto para mejorarlo. Al año siguiente, la siguiente mejora sobre el mismo sistema es otro proyecto, con otro equipo que vuelve a aprender lo que el anterior ya sabía.

El modelo orientado a producto parte de otra pregunta. En lugar de "¿qué proyecto financiamos este año?", pregunta "¿qué servicios necesita el negocio y qué capacidad estable hace falta para que mejoren de forma continua?". La unidad de trabajo deja de ser la iniciativa temporal y pasa a ser el producto o servicio, con un equipo que lo construye y lo opera durante toda su vida.

Este artículo explica qué cambia en tres frentes (presupuesto, equipos y métricas) y cómo encaja el modelo con prácticas que ya tienes, como ITIL y la PMO. No es un cambio de nombres: si el presupuesto y las métricas siguen siendo de proyecto, los equipos también lo seguirán siendo.

De proyectos a productos: qué cambia

Un producto, en este contexto, no es necesariamente algo que se vende. Puede ser la banca móvil, el motor de originación de créditos, la plataforma de pagos interna o el servicio de identidad que usan otras aplicaciones. Lo que lo define es que tiene usuarios identificables, un valor que se puede medir y una vida larga, que no termina con la primera entrega.

El diagrama resume las cuatro diferencias que más pesan en la práctica.

Hay que decirlo con claridad: los proyectos no desaparecen. Una migración de centro de datos, un cambio regulatorio con fecha fija o la implantación de un sistema nuevo siguen teniendo inicio y fin. Lo que cambia es que dejan de ser la forma por defecto de organizar todo el trabajo de TI.

Presupuesto: financiar capacidad, no iniciativas

En el modelo por proyectos, cada iniciativa compite por fondos con un caso de negocio que promete un alcance. El presupuesto se aprueba una vez al año, el alcance se congela para poder estimar y cualquier aprendizaje posterior se convierte en un cambio de alcance que hay que volver a aprobar. El incentivo es pedir todo al principio, porque después será difícil conseguir más.

En el modelo por producto se financia la capacidad persistente de un equipo, o de un conjunto de equipos, asignada a un producto o a un flujo de valor. La pregunta de gobierno deja de ser "¿se entregó lo prometido?" y pasa a ser "¿esta inversión está moviendo los resultados que esperábamos?".

Esto no significa entregar un cheque en blanco. Un esquema razonable incluye:

• Revisiones periódicas, por ejemplo trimestrales, donde cada producto muestra resultados, plan para el siguiente ciclo y riesgos. La capacidad se puede aumentar, reducir o redistribuir entre productos.
• Objetivos de resultado acordados con el dueño de negocio: menos abandono en un trámite, menos tiempo de respuesta en un proceso, menos incidentes en un servicio crítico.
• Una reserva separada para iniciativas puntuales que sí son proyectos, con su propio caso de negocio.
• Visibilidad del costo total del producto: equipo, infraestructura, licencias y soporte, no solo el desarrollo.

Un punto que conviene resolver temprano con Finanzas es el tratamiento contable. En muchas organizaciones el desarrollo de software se capitaliza por proyecto, y un equipo estable mezcla trabajo nuevo, mejoras y operación. Cómo se registra cada tipo de esfuerzo depende de la norma contable que aplica y de la política interna; no lo decidas solo desde TI.

Equipos: alineados al flujo, de plataforma y habilitadores

Un equipo de producto es estable, multidisciplinario y responsable de su servicio de punta a punta: construirlo, desplegarlo, operarlo y mejorarlo. La estabilidad no es un detalle. Un equipo que se mantiene acumula conocimiento del dominio, del código y de los usuarios, y ese conocimiento es lo que permite cambiar rápido sin romper.

El enfoque de Team Topologies ofrece un vocabulario útil para diseñar la estructura. Propone cuatro tipos de equipo:

• Alineado al flujo (stream-aligned): trabaja sobre un flujo de valor para un grupo de usuarios. Es el tipo principal; los demás existen para que este avance con menos fricción.
• De plataforma: ofrece servicios internos (entornos, despliegue, observabilidad, bases de datos) que los equipos de flujo consumen en autoservicio.
• Habilitador: ayuda temporalmente a otros equipos a adquirir una capacidad, por ejemplo pruebas automatizadas o prácticas de seguridad, y luego se retira.
• De subsistema complicado: se ocupa de un componente que exige conocimiento muy especializado, como un motor de cálculo de riesgo.

El mismo enfoque define tres modos de interacción entre equipos: colaboración, "X como servicio" y facilitación. Hacer explícito el modo evita un problema frecuente: equipos que deberían consumir un servicio y terminan en reuniones permanentes de coordinación.

El Service Manual de GOV.UK aporta otra perspectiva: organiza el trabajo alrededor de servicios y de un equipo que los gestiona a lo largo de fases (descubrimiento, alfa, beta y en vivo). La fase "en vivo" no es el final del equipo, sino el momento en que el servicio sigue mejorando con datos reales de uso.

Para infraestructura y operaciones, este modelo cambia el rol. En lugar de una cola central que recibe pedidos de todos, parte de ese equipo se convierte en plataforma y parte se integra en los equipos de producto con prácticas de fiabilidad. Lo desarrollamos en de administradores a SRE.

Métricas: resultados y flujo en lugar de alcance y fecha

"En tiempo, en alcance y en presupuesto" mide si se cumplió un plan. No mide si el plan era bueno ni si el servicio mejoró. En un modelo por producto conviene combinar dos familias de métricas.

La primera son las métricas de resultado, propias de cada producto y acordadas con el negocio: tasa de finalización de un trámite digital, tiempo de aprobación de un crédito, satisfacción de los usuarios internos, cumplimiento de los niveles de servicio que importan. Para elegir bien estas últimas puedes ver SLA que miden lo que le importa al negocio.

La segunda son las métricas de flujo y estabilidad. El Accelerate State of DevOps Report 2019, de DORA, usa cuatro medidas del desempeño de entrega de software: frecuencia de despliegue, tiempo de entrega de los cambios, tiempo de restauración del servicio y tasa de fallos de los cambios. Su hallazgo central, sostenido en varias ediciones, es que velocidad y estabilidad no se contraponen: los equipos con mejor desempeño logran ambas.

Dos advertencias prácticas. Primero, estas métricas sirven para que el equipo mejore, no para comparar equipos entre sí ni para evaluar personas; usadas así, se distorsionan rápido. Segundo, el flujo sin resultado es actividad: desplegar más seguido solo tiene sentido si mejora algo que el usuario nota.

La tabla resume cómo cambia cada dimensión.

Dimensión	Modelo por proyectos	Modelo por producto
Unidad de financiación	Iniciativa con caso de negocio	Capacidad de un equipo asignada a un producto
Horizonte	Fecha de cierre del proyecto	Vida del servicio, con revisiones periódicas
Equipo	Temporal, armado por iniciativa	Estable, multidisciplinario
Responsabilidad	Entregar y transferir a operación	Construir, operar y mejorar
Métrica principal	Alcance, plazo y costo	Resultados de negocio y flujo de entrega
Gestión del cambio de alcance	Solicitud formal de cambio	Repriorización del backlog en cada ciclo
Conocimiento	Se dispersa al cerrar	Se acumula en el equipo

Cómo convive con ITIL y la PMO

Un temor habitual es que el modelo por producto obligue a desmontar la gestión de servicios o la oficina de proyectos. No es así, pero ambas cambian de función.

ITIL

ITIL 4 ya habla en términos de cadenas de valor y de cocreación de valor con el usuario, lo que encaja bien con equipos organizados por producto. Las prácticas siguen siendo necesarias; lo que cambia es quién las ejecuta y con qué granularidad:

• Gestión de incidentes y de problemas: el equipo de producto participa en la resolución y es dueño de las correcciones de fondo, en lugar de recibir tickets de un tercero.
• Habilitación de cambios: los cambios rutinarios de un equipo con buen historial pueden pasar a modelos de cambio estándar preaprobados; los de alto riesgo siguen con revisión.
• Gestión del nivel de servicio: cada producto tiene objetivos de nivel de servicio propios, ligados a sus resultados.

Si estás empezando con ITIL, en las cinco prácticas ITIL 4 con las que conviene empezar explicamos por dónde hacerlo.

PMO

La PMO pasa de controlar proyectos a gestionar el portafolio de productos y la capacidad. Sus nuevas tareas incluyen mantener el mapa de productos y sus dueños, preparar las revisiones periódicas de inversión, seguir las métricas de resultado, detectar dependencias entre equipos y seguir gobernando los proyectos que sí lo son. También conserva un rol clave con los proveedores: cuando parte de la capacidad es externa, el contrato debe reflejar equipos estables y resultados, no solo entregables. Lo tratamos en PMO y VMO como servicio.

Por dónde empezar

El cambio es organizacional y toma tiempo. Recomendamos avanzar por etapas:

1. Elige uno o dos productos piloto con usuarios claros, un dueño de negocio comprometido y cambios frecuentes. Evita empezar por el sistema más crítico o por el más aislado.
2. Define el producto y su dueño: qué incluye, a quién sirve, qué resultados persigue y quién decide las prioridades.
3. Forma un equipo estable con las capacidades necesarias para construir y operar, aunque al principio comparta algunos perfiles.
4. Acuerda con Finanzas el esquema de financiación del piloto y su tratamiento contable.
5. Mide desde el inicio las cuatro métricas de entrega y dos o tres métricas de resultado, para tener línea base.
6. Ajusta ITIL y la PMO para el piloto: modelos de cambio estándar, objetivos de servicio propios y revisión trimestral.
7. Revisa y extiende después de dos o tres ciclos, con evidencia sobre qué funcionó.

Un error frecuente es renombrar los equipos de proyecto como "equipos de producto" sin tocar el presupuesto ni las métricas. El resultado es el mismo modelo con otro vocabulario. Otro es crear equipos estables sin un dueño de producto con autoridad real para priorizar; el equipo termina atendiendo pedidos de todos.

Como el modelo afecta la estructura de equipos, roles y la forma de financiar TI, conviene validar el diseño con Recursos Humanos y Finanzas antes de extenderlo.