Product architect - Revision history

Mberne: /* Véase también */

2026-05-20T13:09:51Z

Véase también

← Older revision		Revision as of 15:09, 20 May 2026
Line 64:		Line 64:

	<div class="bok-tags">		<div class="bok-tags">
	[[Propietario del producto]] [[Product ~~Builder~~]] [[Agile ~~Enabler~~]] [[Spec-Driven Development]] [[Double-~~track~~]] [[OKR]] [[Product discovery]] [[Vibe coding]]		[[Propietario del producto]] [[Product builder]] [[Agile enabler]] [[Spec-Driven Development (SDD)]] [[Double-Track]] [[OKR]] [[Product discovery]] [[Vibe coding]]
	</div>		</div>

Mberne: /* Rol en Spec-Driven Development */

2026-05-20T13:09:30Z

Rol en Spec-Driven Development

← Older revision		Revision as of 15:09, 20 May 2026
Line 32:		Line 32:
	=== Rol en Spec-Driven Development ===		=== Rol en Spec-Driven Development ===

	En el marco [[Spec-Driven Development\|SDD]], el Product Architect actúa como diseñador y aprobador de specs:		En el marco [[Spec-Driven Development (SDD)\|SDD]], el Product Architect actúa como diseñador y aprobador de specs:

	* En la puerta 1 (validación de requisitos), evalúa si los requisitos reflejan las necesidades reales del producto.		* En la puerta 1 (validación de requisitos), evalúa si los requisitos reflejan las necesidades reales del producto.
	* En la puerta 2 (validación del diseño), valida que las decisiones técnicas son coherentes con la arquitectura del sistema y la dirección del producto. No necesita escribir el diseño técnico —eso lo hacen los [[Product ~~Builder~~\|product builders]]— pero sí aprobarlo.		* En la puerta 2 (validación del diseño), valida que las decisiones técnicas son coherentes con la arquitectura del sistema y la dirección del producto. No necesita escribir el diseño técnico —eso lo hacen los [[Product builder\|product builders]]— pero sí aprobarlo.

	== Indicador clave ==		== Indicador clave ==

Mberne: /* Nuevas competencias */

2026-05-20T13:09:17Z

Nuevas competencias

← Older revision		Revision as of 15:09, 20 May 2026
Line 28:		Line 28:
	* '''Data literacy:''' capacidad de leer, interpretar y cuestionar datos de uso del producto, experimentos y métricas de validación.		* '''Data literacy:''' capacidad de leer, interpretar y cuestionar datos de uso del producto, experimentos y métricas de validación.
	* '''Diseño de experimentos:''' definir qué hipótesis se va a validar, cómo y con qué criterio de éxito antes de comenzar la construcción.		* '''Diseño de experimentos:''' definir qué hipótesis se va a validar, cómo y con qué criterio de éxito antes de comenzar la construcción.
	* '''Comprensión del [[Double-~~track~~\|doble carril]]:''' decidir cuándo una idea merece la transición del carril rápido (vibe coding, validación) al carril robusto (vibe engineering, producción), y cuándo devolverla al carril rápido por cambio de requisitos.		* '''Comprensión del [[Double-Track\|doble carril]]:''' decidir cuándo una idea merece la transición del carril rápido (vibe coding, validación) al carril robusto (vibe engineering, producción), y cuándo devolverla al carril rápido por cambio de requisitos.

	=== Rol en Spec-Driven Development ===		=== Rol en Spec-Driven Development ===

Mberne: /* Del backlog de features al repositorio de hipótesis */

2026-05-20T13:09:10Z

Del backlog de features al repositorio de hipótesis

← Older revision		Revision as of 15:09, 20 May 2026
Line 20:		Line 20:
	=== Del backlog de features al repositorio de hipótesis ===		=== Del backlog de features al repositorio de hipótesis ===

	Cada ítem del backlog debería poder responder: ¿qué problema resuelve y para quién? El backlog contiene dos tipos de ítems que conviven: [[Historia de usuario\|historias de usuario]] (intención y contexto de negocio para la comunicación humana) y [[Spec-Driven Development\|specs SDD]] (especificaciones detalladas para guiar el trabajo de agentes de IA). No todos los ítems necesitan el mismo nivel de especificación: un prototipo rápido puede partir de una historia; una funcionalidad crítica para producción requiere una spec completa.		Cada ítem del backlog debería poder responder: ¿qué problema resuelve y para quién? El backlog contiene dos tipos de ítems que conviven: [[Historia de usuario\|historias de usuario]] (intención y contexto de negocio para la comunicación humana) y [[Spec-Driven Development (SDD)\|specs SDD]] (especificaciones detalladas para guiar el trabajo de agentes de IA). No todos los ítems necesitan el mismo nivel de especificación: un prototipo rápido puede partir de una historia; una funcionalidad crítica para producción requiere una spec completa.

	=== Nuevas competencias ===		=== Nuevas competencias ===

Mberne: Created page with "{{Meta-bok|min=5}} El '''Product architect''' (también denominado ''AI Product Owner'' o ''Product Owner con IA'') es la evolución del rol de propietario del producto en equipos que trabajan con herramientas de inteligencia artificial generativa. Sigue siendo responsable de maximizar el valor del producto decidiendo qué merece construirse y validando que cada incremento resuelve un problema real, pero en un entorno donde la IA permite cons..."

2026-05-20T13:08:53Z

Created page with "{{Meta-bok|min=5}} El '''Product architect''' (también denominado ''AI Product Owner'' o ''Product Owner con IA'') es la evolución del rol de propietario del producto en equipos que trabajan con herramientas de inteligencia artificial generativa. Sigue siendo responsable de maximizar el valor del producto decidiendo qué merece construirse y validando que cada incremento resuelve un problema real, pero en un entorno donde la IA permite cons..."

New page

{{Meta-bok|min=5}}
El '''Product architect''' (también denominado ''AI Product Owner'' o ''Product Owner con IA'') es la evolución del rol de [[Propietario del producto|propietario del producto]] en equipos que trabajan con herramientas de inteligencia artificial generativa. Sigue siendo responsable de maximizar el valor del producto decidiendo qué merece construirse y validando que cada incremento resuelve un problema real, pero en un entorno donde la IA permite construir casi cualquier cosa, la pregunta estratégica ya no es "¿podemos construirlo?" sino "¿deberíamos construirlo, y por qué?".

El rol y su denominación han sido descritos por Scrum Manager en la guía ''Scrum en equipos con IA'' (v1.0, marzo 2026) y en ''SDD — Spec Driven Development en equipos ágiles''.

== Foco principal ==

El product architect concentra su trabajo en tres áreas:

* '''Visión estratégica:''' mantiene y comunica una visión clara de hacia dónde va el producto, con criterio sobre qué hipótesis valen la pena perseguir y cuáles no.
* '''Validación continua con usuarios reales:''' el indicador clave del Product Architect no es cuántos ítems entrega el equipo, sino cuántos de esos ítems resuelven problemas reales de usuarios. La validación precede y orienta la construcción.
* '''Decisión sobre qué entra en el backlog:''' el backlog deja de ser una lista de features para convertirse en un conjunto de hipótesis a validar. La IA puede construir rápido; el Product Architect decide qué vale la pena construir.

== Qué cambia respecto al propietario del producto clásico ==

=== La paradoja de la productividad ===

En equipos con IA, el equipo produce más: el carril rápido permite generar prototipos en horas, y el carril robusto acelera significativamente la implementación. Esta mayor productividad solo genera valor si hay validación estratégica detrás: más output no equivale a más outcome. El Product Architect gestiona esta paradoja: su trabajo es asegurar que la mayor velocidad de construcción esté orientada a problemas reales, no a acumular funcionalidades no validadas.

=== Del backlog de features al repositorio de hipótesis ===

Cada ítem del backlog debería poder responder: ¿qué problema resuelve y para quién? El backlog contiene dos tipos de ítems que conviven: [[Historia de usuario|historias de usuario]] (intención y contexto de negocio para la comunicación humana) y [[Spec-Driven Development|specs SDD]] (especificaciones detalladas para guiar el trabajo de agentes de IA). No todos los ítems necesitan el mismo nivel de especificación: un prototipo rápido puede partir de una historia; una funcionalidad crítica para producción requiere una spec completa.

=== Nuevas competencias ===

El Product Architect necesita competencias adicionales a las del propietario del producto clásico:

* '''Data literacy:''' capacidad de leer, interpretar y cuestionar datos de uso del producto, experimentos y métricas de validación.
* '''Diseño de experimentos:''' definir qué hipótesis se va a validar, cómo y con qué criterio de éxito antes de comenzar la construcción.
* '''Comprensión del [[Double-track|doble carril]]:''' decidir cuándo una idea merece la transición del carril rápido (vibe coding, validación) al carril robusto (vibe engineering, producción), y cuándo devolverla al carril rápido por cambio de requisitos.

=== Rol en Spec-Driven Development ===

En el marco [[Spec-Driven Development|SDD]], el Product Architect actúa como diseñador y aprobador de specs:

* En la puerta 1 (validación de requisitos), evalúa si los requisitos reflejan las necesidades reales del producto.
* En la puerta 2 (validación del diseño), valida que las decisiones técnicas son coherentes con la arquitectura del sistema y la dirección del producto. No necesita escribir el diseño técnico —eso lo hacen los [[Product Builder|product builders]]— pero sí aprobarlo.

== Indicador clave ==

El valor del Product Architect '''no se mide por cuántos ítems entrega el equipo''' sino por cuántos de esos ítems resuelven problemas reales de usuarios. Un equipo que entrega muchas funcionalidades que nadie usa ha fallado en la dimensión más importante, independientemente de su velocidad.

== Error frecuente ==

<div class="bok-aviso">
'''Usar la velocidad de la IA como excusa para no validar.''' La reducción del coste de construcción que aporta la IA hace tentador construir más sin validar más: "si es tan barato construirlo, construyámoslo y ya veremos". Pero construir sin validar, aunque sea rápido y barato, sigue siendo un desperdicio: el coste no está en la construcción sino en el aprendizaje que se pierde al no saber si algo funciona o no. La velocidad de la IA debe ir acompañada de una cadencia equivalente de validación con usuarios reales.
</div>

== Recursos ==
<div class="bok-recurso">
📄 [https://scrummanager.com/files/scrumenequiposconia.pdf '''Scrum en equipos con IA''']<span class="detalle">Descarga gratuita · Scrum Manager</span>
</div>
<div class="bok-recurso">
🏦 [https://scrummanager.com/skillarena/scrum-con-ia '''Scrum en equipos con IA''']<span class="detalle">Skill Arena · Scrum Manager</span>
</div>
<div class="bok-recurso">
📊 [https://scrummanager.com/website/c/info/resource.php?id=374 '''Guía didáctica SDD''']<span class="detalle">Recursos · Scrum Manager</span>
</div>
<div class="bok-recurso">
🏦 [https://scrummanager.com/skillarena/sdd-en-equipos-agiles '''SDD en equipos ágiles''']<span class="detalle">Skill Arena · Scrum Manager</span>
</div>

== Véase también ==

<div class="bok-tags">
[[Propietario del producto]] [[Product Builder]] [[Agile Enabler]] [[Spec-Driven Development]] [[Double-track]] [[OKR]] [[Product discovery]] [[Vibe coding]]
</div>

<div class="bok-ecosistema">
<div class="texto">
<span class="titulo">'''¿Quieres avanzar en agilidad?'''</span>
<span class="sub">Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a [https://scrummanager.com/skillarena/ '''Skill Arena''']: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.</span>
</div>
<div class="botones">
<div class="bok-btn-outline">[https://www.scrummanager.com/website/c/calendar/show-courses.php Buscar convocatorias]</div>
<div class="bok-btn-filled">[https://scrummanager.com/club/ Club Agile]</div>
</div>
</div>

[[Category:Glosario de términos]]
[[Category:Scrum]]
[[Category:Prácticas ágiles]]