¿Cuál es el origen del término "Product Owner" en Scrum?

O expresado de otra manera: ¿Por qué el rol se llama Product Owner ?

Pasé algunas horas investigando la etimología del término, pero no he tenido mucho éxito, por lo que surgió esta pregunta.

No estoy preguntando explícitamente sobre la definición del rol aquí. Hay muchos artículos que explican eso, por ejemplo, en el contexto de Scrum.

En particular, me interesa el razonamiento histórico que ha llevado a denotarlo como "propietario".

También podría tener sentido compartir algo de contexto con usted para explicar por qué surgió esta pregunta en primer lugar: mi experiencia es que los equipos que no están familiarizados con las metodologías ágiles tienden a reemplazar el término "propietario" en sus mentes con alguna variación de un rol que ya saben de las jerarquías tradicionales. Esto a menudo conduce a una interpretación que coloca al propietario del producto en una especie de posición de director o incluso de jefe, lo que puede contrastar fuertemente con lo que uno quiere lograr al implementar procesos ágiles. Para ser específicos, lo que las personas interpretan intuitivamente puede generar puntos de vista contrarios al liderazgo de servicio, los equipos autoorganizados y las jerarquías situacionales en evolución. Es por eso que podría ser necesario explicar mejor el contexto en el que, por ejemplo, la definición de Scrum del "Propietario del producto" El rol debe verse con respecto a los objetivos de la empresa donde se está implementando. Tener una idea sobre las intenciones de nombrarlo "propietario" en primer lugar podría ayudar con eso.

No estoy seguro de hasta qué punto esta pregunta puede ser respondida por alguien que no sea Ken Schwaber o Jeff Sutherland.
tampoco estoy seguro Todavía quería intentarlo en caso de que me haya perdido algo obvio. Todavía estoy un poco sorprendido de que literalmente no haya nada sobre eso en Internet aparentemente. Es una pregunta bastante válida en mi opinión.

Respuestas (7)

Siempre lo he interpretado como que el Product Owner (PO)... es dueño del producto . Él/ella es el representante suplente de los clientes finales, quienes serán literalmente los propietarios del producto en el futuro. Como tal, sus responsabilidades son algo similares a las que serían las del cliente en el sitio en eXtreme Programming.

Y aunque el cliente siempre tiene la razón™, el cliente no es su jefe. Tu jefe es tu jefe. Hipotéticamente, una persona podría desempeñar los roles de PO y gerente, pero yo personalmente lo desaconsejaría: son roles distintos con responsabilidades y objetivos distintos. Tal como lo serían el cliente y el jefe.

De la Guía Scrum , el PO es responsable de:

  • Expresar claramente los elementos del Product Backlog;
  • Ordenar los elementos en el Product Backlog para lograr mejor los objetivos y misiones;
  • Optimizar el valor del trabajo que realiza el Equipo de Desarrollo;
  • Asegurarse de que el Product Backlog sea visible, transparente y claro para todos, y muestre en qué trabajará el Equipo Scrum a continuación; y,
  • Asegurarse de que el equipo de desarrollo comprenda los elementos de la cartera de productos al nivel necesario.

No hay nada allí ni siquiera sobre el liderazgo de servicio, y mucho menos el liderazgo 'normal'. El Scrum Master es el servidor-líder del Equipo Scrum. El PO es un miembro más con diferentes responsabilidades.

Su responsabilidad es pretender que son dueños del producto.

Gracias por su completa respuesta. Eso tiene sentido, sin embargo, tengo problemas con la segunda parte. Hay algo sobre el liderazgo y la gestión en el artículo: "El propietario del producto puede hacer el trabajo anterior o hacer que el equipo de desarrollo lo haga. Sin embargo, el propietario del producto sigue siendo responsable" . y "Para que el Product Owner tenga éxito, toda la organización debe respetar sus decisiones". La rendición de cuentas y las decisiones son aspectos de la propiedad y se superponen inevitablemente con el liderazgo y la gestión.
@starbugs ¿Cómo obtienes liderazgo y gestión de eso? Los desarrolladores siguen siendo responsables del código que escriben. Toda la organización debe respetar cómo eligen organizarse. ¿Significa eso que todos los desarrolladores son líderes y gerentes? Tener responsabilidad y autoridad no es lo mismo que tener liderazgo. Es necesario pero no suficiente.
"El propietario del producto sigue siendo responsable". "[...] toda la organización debe respetar sus decisiones". La responsabilidad y la propiedad no se pueden repartir entre las personas y ese es, a mi entender, el aspecto principal de por qué la OP tiene que ser una sola persona. No puede delegar la responsabilidad al equipo. Para tener éxito y ser responsable, debe poder tomar decisiones y establecer una visión. Eso es todo sobre el liderazgo. Cómo lleva a cabo estas tareas es la parte de gestión.
La responsabilidad y la propiedad del producto no deben difundirse. Los desarrolladores son responsables de otras cosas . Mi punto era que la rendición de cuentas y la responsabilidad, si bien son necesarias para el liderazgo, no son suficientes ; de lo contrario, todos los miembros del Equipo Scrum deberían ser considerados líderes. El PO toma decisiones y establece una visión para el producto. El equipo de desarrollo toma decisiones y establece una visión para el proceso, los estándares y los detalles de implementación, etc. Esto no es gestión. La gestión requiere la gestión de personas , algo que no hacen ni el PO ni el Dev Team.
Sí, mi pregunta está dirigida únicamente al PO, por lo tanto, estaba hablando de su rol de liderazgo y solo de él, no sobre el equipo de desarrollo. En su comentario anterior dijo que no ve liderazgo en lo que establece la Guía Scrum. ¿Está de acuerdo ahora con mi punto sobre el rol de la OP que conlleva aspectos de liderazgo a través de la rendición de cuentas y el respeto por las decisiones? En un mundo perfecto, estaría de acuerdo en que no debería haber un aspecto de gestión de personas asociado con el rol de PO. En realidad, dado que es responsable del producto, es posible que también deba hacerlo (o delegarlo) si es necesario o, de lo contrario, es posible que no tenga éxito.
@starbugs Mi punto es que llamarlos aspectos de liderazgo es problemático, porque es posible tener esos aspectos sin ser un líder , como es el caso con el PO (y con el Dev Team, que mencioné como comparación). Sí, la OP es responsable y está autorizada para tomar decisiones sobre el producto. No, el PO no es un líder.
FYI: Nunca me ha importado el término "retraso". Hubiera preferido verla referida como una lista de tareas o una lista de cosas por hacer. El presente término tiene connotaciones que para mí son engañosas.
@MikeRobinson Sí... Recuerdo que una vez tuve que explicarle a mi jefe: "Sí, tenemos una acumulación de 1000 problemas, ¡pero no tenemos una acumulación de 1000 problemas!" Creo que eso contribuyó a su "Odio todas estas tonterías ágiles. Haz lo que quieras, pero mantenme fuera de esto".

TL;RD

Tendrás que preguntarle a Ken Schwaber o Jeff Sutherland de dónde acuñaron el término. La fuente del término no parece estar documentada públicamente, pero probablemente lo introdujeron en algún momento entre 1995 y 2001.

Una etimología no canónica

Durante los años 90, varias personas estaban examinando prácticas e ideas ágiles. Scrum y XP son dos de los marcos desarrollados durante este período, con una definición formal de XP aparentemente anterior a la de Scrum por algunos años.

El rol de propietario del producto en Scrum tiene una estrecha relación con el rol del cliente en el sitio en eXtreme Programming. Podría decirse que XP usa términos que se dirigen a los miembros del equipo de desarrollo, mientras que Scrum usa términos que intentan atraer más a las partes interesadas del negocio. (Este tipo de terminología orientada a los negocios es aún más evidente en marcos como SAFe). Se podría argumentar además que el cliente en el sitio es un rol que se define en gran medida desde la perspectiva interna del equipo, mientras que un propietario del producto es un rol con delegados. responsabilidad desde la perspectiva organizacional . Considere el siguiente examen de la "propiedad" para ver por qué esto puede ser así.

En Scrum, la noción de "propiedad" surge de la obligación del rol de ser el único responsable de maximizar el valor del producto en desarrollo. La Guía Scrum dice , en parte:

El Dueño del Producto es la única persona responsable de administrar el Product Backlog... El Dueño del Producto es una persona, no un comité... Para que el Dueño del Producto tenga éxito, toda la organización debe respetar sus decisiones.

Básicamente, siempre he interpretado la parte de "propiedad" del término como una forma de garantizar que el rol del Propietario del producto sea una persona singular en lugar de un comité, lo que a su vez tiene la intención de simplificar el marco y reducir la carga organizacional de proporcionar clientes en el sitio. En los marcos de gobierno, los roles de Propietario de la aplicación o Propietario de los datos a menudo se estructuran de manera similar, para facilitar las comunicaciones y generar responsabilidad.

Esta cadena de razonamiento proporciona una explicación pragmática para la introducción del término y proporciona alguna explicación de su valor de utilidad sobre otros términos relacionados. Sin embargo, solo los autores del marco pueden atribuir canónicamente cómo se decidió el término para Scrum.

Más allá de lo que está en la descripción del rol táctico, siempre he considerado el rol de juez o árbitro cuando el equipo no puede llegar a un consenso sobre la decisión que debe tomarse para mantener la entrega encaminada, por lo tanto, son el "propietario" de la decisión. Necesitan escuchar y comprender los puntos de vista de los ingenieros y sus diferencias, así como los de las partes interesadas del negocio. El liderazgo de servicio y la empatía desempeñan un papel fundamental en este papel, si la OP quiere tener éxito en la gestión de relaciones matrices tan complejas.

Aquí está mi uso ciertamente informal del término:

El "propietario del producto" representa al Todopoderoso Cliente y, a menudo, es el enlace más directo del equipo con él, y suele informar directamente a él. Esta función se centra muy específicamente en lo que hará el producto y para quién lo hará eventualmente, y en garantizar que todo realmente cumpla con los objetivos comerciales para los que se encargó, según lo visto por las unidades comerciales que lo encargaron. y que funcione correctamente y se integre en el entorno comercial predominante (!) . En las reuniones de equipo, el propietario del producto es, por lo tanto, un representante de esas partes interesadas.

Considero que el rol hermano de " gerente de producto" es sutilmente diferente, porque este rol se preocupa por "cómo" se realiza el trabajo. Entonces, si tuviéramos que llevar esta analogía hasta el final, el rol del "gerente de producto" es mantener contentos a los "dueños del producto". Conceptualmente, "Gerentes = manos a la obra, Propietarios = manos libres", en términos de la actividad de desarrollo real del día a día.

Y, para mí, tener los dos roles claramente separados y formalizados es muy beneficioso: el propietario tiene los ojos fijos en los propietarios reales... el contexto comercial real en el que se ejecutará el producto terminado... mientras que el gerente tiene su los ojos fijos en el proceso que se está utilizando para construirlo y cambiarlo. Llámalo "administración de Jano", el dios romano de dos caras.

Creo que este error común proviene de la palabra "propietario". "Propio" tiene dos significados diferentes: 1. tener, poseer; y 2. admitir o confesar. El dueño del producto no es quien tiene la posesión del producto; más bien es quien admite o niega las especificaciones del producto en backlog.

Bienvenido a PMSE, Mohammad. +1 para un punto interesante. Entiendo la definición del diccionario. ¿Es esta su interpretación de lo que significa Scrum por "propietario" o conoce otra fuente que hace el mismo punto acerca de "admitir" los elementos del backlog? Solo pregunto porque me gusta la idea y podría querer usar esa explicación nuevamente en el futuro.
Estimado @nvogel, muchas gracias por su desafiante pregunta. Eso fue sólo lo que capté de su significado. Desafortunadamente, no tengo ningún recurso que respalde mi opinión.
Lo siento, pero esto no es correcto. "Admitir" también tiene múltiples significados. Está utilizando su significado de 'permitir entrada', pero por contexto ese claramente no es el significado previsto. El 'admitir' en 'admitir o confesar' tiene el mismo significado que "Sí, reconoceré lo que hice. Lo admito ; maté a tu perro". El 'Propietario' en 'Propietario del producto' se refiere claramente al primer significado de la lista, no al segundo.
Bueno, "bienvenido a los caprichos del idioma inglés, o cualquier idioma humano". La palabra "propietario" también podría significar *"persona con responsabilidad activa en la toma de decisiones con respecto a algo en lo que tiene una participación medible". El punto de vista del cliente externo y/o parte interesada del negocio está representado por la OP, cuya tarea es representar sus intereses de manera pragmática.

El origen es... Ciertos métodos fueron desarrollados en empresas de software y no para grupos de TI (empresas como Easel o Borland). Por lo tanto, Turbo Pascal era un "producto" que vendían, no era una marca, Borland era la marca, por lo tanto, si lideras el grupo Turbo Pascal, eres "propietario" del producto.

El marketing no tenía un concepto de propietario del producto, se centraba en la marca-gerente de marca

Es por eso que es legítimo que el propietario del producto de la "compañía de software" trabaje en estrecha colaboración con el equipo, pero no necesariamente para un gerente de marca o una persona de la línea de negocios, ya que ellos están dirigiendo el negocio.

Sugiero mirar los roles principales en un equipo ágil. Es fundamental comprender el papel de todos de manera integral para que todo tenga sentido. Si el equipo se ha aferrado a un término específico "propietario", puede ser porque buscan autoridad o control y no miran todo lo involucrado. Resalte todos los roles y responsabilidades y permítales descubrir dónde quieren estar en función de sus valores y habilidades.

  • Gerente de producto
  • Dueño del producto
  • Maestro Scrum
  • Equipo Scrum

Si bien cada situación es diferente, tener claridad sobre los roles, motivaciones y responsabilidades te permitirá adaptar tu equipo a tu tamaño y objetivos.

Scaled Agile Framework tiene algunos buenos materiales para dibujar las distinciones. https://www.scaledagileframework.com/propietario-del-producto/ ingrese la descripción de la imagen aquí

Gracias por tu respuesta. Si no me equivoco, los marcos ágiles escalados no existían cuando surgió la definición original de Scrum del PO.
Tal como está escrito, esta respuesta no parece intentar responder a la pregunta "¿Por qué el rol se llama Propietario del producto ?". Si está sugiriendo que se trata de un problema XY, hágalo más explícito.
Estoy tratando de abordar la motivación detrás de la pregunta. - ¿Por qué preguntar dónde se originó un término? Para entender mejor su significado. - ¿Cómo se puede entender mejor un solo rol? Comprender el ecosistema en el que participa ese rol y cómo se relaciona e interactúa con los otros roles. Tomé un enfoque más holístico. Otras personas que busquen y encuentren el título estarán motivadas de manera similar. El equipo en cuestión se ha aferrado a una sola palabra porque saben lo que eso significa para ellos. Necesita expandir su pensamiento y mostrar todo lo que implica un equipo de producto ágil
@starbugs sí, Scaled Agile llegó más tarde, pero tiene mucha información sobre las mejores prácticas y tiene algunas de las guías más claras. Empecé a desarrollar en los años 80 y recuerdo cuando se creó el manifiesto ágil en los años 90 y vi cómo los equipos lucharon, aprendieron y adaptaron su uso. Parece que está luchando con algunos anti-patrones y le ofrecí SAFE como un buen recurso para ayudar a su equipo a pasar del control personal al liderazgo de servicio. Algunos de los diagramas en SAFE realmente brindan una buena claridad al menos para mí cuando les estoy explicando a otras personas.
@eAndy: Su contribución es muy bienvenida. De hecho, tienes toda la razón. La pregunta se encuentra en el contexto de establecer estructuras ágiles en múltiples equipos que nunca han trabajado de esa manera y necesitan comprender los roles involucrados. Habiendo dicho eso, todavía no veo cómo respondes a la pregunta. Dije explícitamente que la definición de una orden de compra no es objeto de la pregunta, ya que ya hay suficiente información disponible al respecto.
Bienvenido a PMSE. Voté negativamente porque esta fue una respuesta bien escrita que no entendió el punto de la pregunta original. Estaré feliz de cambiar mi voto una vez que la etimología (o al menos la diferenciación) del término "propiedad" se aborde con mayor claridad.
Emití un voto a favor basado en el contenido general del comentario y las fuentes bien citadas, aunque puede que no sea una respuesta exacta a la pregunta planteada originalmente. Todavía encontré la respuesta bien escrita, informativa y beneficiosa para mí.
¿Cuál es el origen del término "Product Owner" en Scrum?
RespuestasAquíPolítica de privacidad1y, 0v