El Vasa, cuando el Product Owner es el Rey

Hace unos meses visité el museo del Vasa en Estocolmo. Para quien no conozca su historia, el Vasa fue un navío de guerra sueco que en 1628 se hundió en su viaje inaugural tras recorrer apenas un kilómetro de aguas en calma.

Un museo es una experiencia diseñada y éste es un buen ejemplo sobre cómo hacerlo bien. Se construyó ex profeso en 1990 para, una vez recuperado, dar cabida al barco y su sorprendente historia, y es en sí mismo una pequeña obra de arte. Su última renovación en 2012 lleva al interior de su estructura la zona de taquillas, por lo que la cola y compra de entradas se hace refugiado del frío nórdico. Todo un detalle.

Gracias a la baja salinidad de los fríos mares del norte podemos apreciar el enorme navío conservado como ningún otro de su clase y época. Y es que Gustavo II Adolfo quiso un barco de guerra realmente intimidatorio para sus, por entonces, enemigos polacos. Se talaron 1.000 robles y 400 personas trabajaron durante dos años y medio para construir el enorme galeón de 69 metros de eslora y una altura de 52 metros desde la quilla al extremo del mástil principal, como un edificio de 17 plantas aproximadamente para hacernos una idea.

UX2 El Vasa

Foto: Peter Isotalo – CC BY-SA 3.0, Wikimedia Commons.

Además, en su día, estaba profusamente decorado: más de 700 esculturas reproducían la imagen de emperadores romanos, deidades griegas, ángeles, demonios y guerreros junto a bellas sirenas, todo ello decorado en colores bermellón, verde, blanco y oro.

Pero lo relevante de esta historia, para los que hacemos productos digitales, no tiene relación con la ingeniería naval, sino con el comportamiento humano, donde reside el principal origen de este naufragio y de algunos naufragios digitales.

En este caso, su obsesión por crear el navío más impresionante del momento llevó al rey de Suecia a ordenar duplicar el número de cañones. Con el proyecto en marcha, y el tamaño de manga y eslora ya inamovibles, se añadió otra cubierta de cañones aumentando la ya de por sí gran altura del buque, lo que determinó su paupérrima estabilidad y selló su destino.

Utilizando terminología Scrum (metodología ágil), Gustavo II fue el Product Owner del proyecto. Sí, salvando las distancias, porque seguramente ocupaba algunos roles más: solicitaba el “producto” y lo financiaba, pero independientemente de los detalles cometió al menos cuatro grandes errores que resultarán familiares a los que nos dedicamos al negocio del software: no apoyarse en otros stakeholders (otros implicados en el proyecto), ocupar varios roles a los que no prestó la dedicación necesaria, no escuchar al Scrum Master/Arquitecto (el maestro naviero) y, sobre todo, realizar enormes cambios cuando el proyecto estaba muy avanzado.

Todo el suceso es un caso extremo y ejemplar de un mal Product Owner (P. O.). Pero para ser justos, como en todo buen desastre, la acumulación de errores fue alta y no exclusivos de la figura del monarca. También es un caso de HiPPO (Highest Paid Person’s Opinion, opinión de la persona mejor pagada). Y es que a un rey no se le suelen discutir demasiadas decisiones, incluso los responsables de realizar la prueba de flotabilidad a la nave, la abortaron antes de tiempo al ver que existía la posibilidad de que no la superara. Tras la investigación de las autoridades, no se encontró un claro culpable (la opción “culpemos al Rey” probablemente no se contemplara), dictaminando finalmente una responsabilidad colectiva.

Siglos después, en el desarrollo de software, un buen P.O. sigue siendo clave en el éxito de un proyecto. Viéndolo en positivo, me quiero quedar con que también puede ser testimonio de los equipos más brillantes, aquellos que con ingenio y paciencia son capaces de hacer bueno a un mal P.O., o al menos minimizan su impacto, logrando sacar un buen producto adelante.

Queda mucho por andar, pero la buena noticia es que poco a poco este tipo de “reyes del proyecto” están desapareciendo. Internet es el sector más revolucionario en ese sentido. Es tiempo de asertividad, crowdfounding, social media, startups sin jerarquía y CEO en chanclas.

Larga vida… a la revolución que nos está tocando vivir.

 

 

Soy responsable de Customer Experience en Paradigma Digital donde procuro sutilmente manipular a todo el mundo con el loable objetivo de diseñar servicios útiles, vinculantes y rentables. Durante años he tenido un poco de front-end y mucho de diseñador en el sentido más amplio de la palabra, en pequeñas agencias y grandes medios, donde fui lo bastante hablador, pesado y meticuloso para acabar definiendo y diseñando productos digitales.

Ver toda la actividad de David Montalvo

Recibe más artículos como este

Recibirás un email por cada nuevo artículo.. Acepto los términos legales

Posts relacionados

5 comentarios

  1. scrum_friend dice:

    Me ha gustado mucho y me parece muy acertado el artículo. Es un claro ejemplo de como muchas veces los PO en su ignorancia, piden tonterias, imposibles, o tareas que estropean el producto. Creo que muchas veces en la relación PO-SM/Arquitecto se critica a los SM/Arquitectos por no hacer lo que exige el PO, cuando la mayoría de las veces son ellos los más preocupados por la calidad del producto y su éxito, más incluso que el PO, que en sus delirios de grandeza no sabe aceptar una crítica o un ‘no’.

    Por desgracia hoy en día quedan muchos que ejercen de PO sin tener ni idea de lo que eso implica.

    Hay un trabajo muy duro por hacer con los PO, necesitan trabajar mucho en su humildad para aprender a escuchar y reconocer que no por ser los dueños del producto, son sus decisiones las más acertadas, o tienen los conocimientos necesarios para tomar según que decisiones.

    • David Montalvo dice:

      Hola scrum_friend, gracias por comentar. Has dicho casi todo lo malo sobre algunos P.O. y ciertamente todo eso ocurre a veces, demasiadas. Aun así es conveniente no generalizar, tener paciencia y algo vital: ponerte en la piel del otro y conocer sus motivos.

      • Juan Pablo dice:

        Buen artículo y buena respuesta! Creo que al final has dado con la clave. Ponerte en la piel del otro y conocer sus motivos. Creo que en un buen equipo ágil debe haber confianza. El PO debe confiar en el equipo para ser permeable a sus sugerencias y a la vez que estos se sientan libres de hacer las observaciones que estimen oportunas . Por otro lado, también deben confiar en el criterio del PO , dejando el roadmap del producto en sus manos. En una relación de mutua confianza ganan ambas partes, por eso es importante saber por qué la otra parte no está cómoda con la solución propuesta.

  2. Victor dice:

    Y el rol del Service Owner???

    • David Montalvo dice:

      Hola Victor, gracias por tu respuesta. Entiendo que te refieres al rol del Service Owner propio de entornos metodológicos ITIL.

      No he trabajado nunca bajo ese marco, y aunque probablemente busque el mismo fin que el agilismo (dar el mejor servicio posible) la forma de hacerlo resulta muy diferente. Desde luego sobre el papel, y lo escuchado, el sistema ITIL no me seduce, aunque presumo que tu tendrás buenos argumentos a su favor.

      No querría convertir esto en un largo debate sobre metodologías de desarrollo, ya que de hecho, mi post se centra en un error “humano” frecuente, independiente del marco metodológico.

Escribe un comentario