Lean UX - Principios

En un anterior artículo descubrimos qué es Lean UX, continuamos profundizando en sus principios que deben ser considerados para una adecuada implantación dentro de la organización.

Lean Ux representa una nueva etapa evolutiva en el diseño de productos. En donde el factor humano es esencial, que está representado por el Equipo de Desarrollo, Cliente y Usuarios y de la fluida comunicación entre estos actores nos lleva a un cambio de mentalidad, es decir, de cómo hacer las cosas, de cómo enfrentar el trabajo.

Todo esto trae como consecuencia un cambio en la cultura de la organización. Algunas empresas le será más fácil poder ajustarse a esta nueva forma de hacer las cosas y a otras no, es necesario evaluar el impacto que va a tener este cambio y los beneficios e inconvenientes que llevará esta transición.

Los Equipos deben ser multifuncionales debido a que se van a encargar de desarrollar todo el producto, deben ser equipos que tengan todo el conocimiento necesario para hacerlo. Se debe llevar una acción colaborativa entre los miembros del equipo, que permita una mayor eficacia en dicho desarrollo.

El equipo no debe ser mayor de 10 personas, cuya dedicación sea exclusiva al proyecto y que trabajen en el mismo lugar, es decir, coubicados. Es fundamental que en el equipo se den estas tres palabras, comunicación, concentración y camaradería y qué estén reunidos en un mismo proyecto, aumentando su eficacia.

Se promueve la conciencia a nivel equipo y no la búsqueda de personas destacadas, debido a que estos miembros reducen la colaboración. Si añadimos individuos de este tipo a nuestro equipo, con grandes egos y determinados a brillar por encima de todos, se rompe la colaboración del equipo.

El equipo solo debe crear lo necesario para ir avanzando y evitar crear un gran stock sin probar ni implementar. Hay que tener en cuenta, que si se hace y no probamos lo que estamos haciendo funciona, no sabremos si vamos por buen camino. Consiste en obtener feedback por parte del cliente para ver cuál es su experiencia, es decir, saber que están haciendo con nuestros productos y porque lo están haciendo. Esto debe ser llevado por todo el equipo de manera frecuente y regular. Todo esto nos permitirá validar nuestro trabajo. También permite establecer una empatía con el usuario y con los problemas a los que tienen que enfrentarse.

Hay que concentrarse en aprender y luego se irá creciendo. Es arriesgado poner en producción una idea que no se ha probado, puede ser que funcione como que no. Al asegurarnos de que una idea funciona antes de hacerla crecer, permite reducir el riesgo que conlleva un despliegue de funciones.

Hay que eliminar todo aquello que no contribuya a conseguir el objetivo final del proyecto. El tema es centrar en aquellas cosas que verdaderamente aporten valor y eliminar aquellas cosas que nos distraen o reducen nuestra efectividad.

El equipo a través de herramientas visuales se expone su trabajo y permite el escrutinio público de compañeros, colegas y clientes. Esto permite la inspiración de nuevas ideas y permite que la información sea transparente a todos los actores que participan.

Las respuestas a las cuestiones más difíciles que tendrá que afrontar el equipo no surgirán de una sala de reuniones sino de la reacción de los clientes. El debate de ideas es una pérdida de tiempo en lugar de analizar los potenciales escenarios.

El equipo debe buscar soluciones para los problemas de negocio y no simplemente entregar una serie de funcionalidades. El equipo debe encontrar su propias soluciones eso permite el empoderamiento del proyecto.

El foco está en la entrega de valor, en la satisfacción del cliente, por lo tanto, ellos darán su opinión sobre nuestras ideas mucho antes de lo que lo han hecho en el pasado. Es mucho mejor averiguar que nuestras ideas son erróneas antes que dedicar tiempo y recursos a construir un producto que nadie quiere. Son ellos los que tomarán la decisión de la compra de lo que hemos diseñado, cuanto más pronto le demos intervención veremos si nuestras ideas están listas para pasar a la fase de desarrollo.

El equipo tiene permiso para equivocarse, es decir, el hecho de experimentar puede acarrear que no se haya acertado, el equipo debe tener la libertad de equivocarse. Este permiso significa que puede contar con un entorno seguro en el que experimentar, una filosofía que se debe aplicar tanto un entorno técnico como en cultural de la organización. El permiso de equivocarse alimenta la cultura de la experimentación que, a su vez, da lugar a la creatividad. La creatividad por su parte hace que aparezcan soluciones innovadoras.

Debe haber un conocimiento, una comprensión del producto y de los clientes en el equipo, que se construye poco a poco. Cuanto más sepa el equipo, como colectivo, de lo que está haciendo y de porque lo está haciendo, menos dependerá de informes de segunda mano y de documentos detallados para continuar con su trabajo.

Lo que verdaderamente se evalúa de un proyecto son los resultados y no la documentación que se entregue. Es complicado predecir qué funciones contarán con el mayor aprecio por parte de los clientes. Habrá que tomar la decisión de mantenerla, cambiarla o sustituirla.

El progreso de un proyecto depende de los resultados que se consiguen, no de los documentos que el equipo escriba. Los documentos no solucionan los problemas de los clientes, lo hacen los buenos productos. Lo que importa es la calidad del producto o como reacciona el mercado ante él.

Bueno, en cada párrafo he ido describiendo las bases, los principios sobre los que se basa Lean UX.

Product Owner vs Product Manager

Muchas organizaciones tienen dificultades para entender dónde acaba el rol del Product Owner y empieza el de Product Manager y viceversa y también en qué punto se pueden llegar a superponer sus acciones.

El Product Owner es el responsable de desarrollar el producto,  para ello debe gestionar los elementos del Product Backlog y que el Sprint entregue un resultado incremental y funcional;  por sobre todo que ese resultado cumpla con los objetivos del sprint y es dónde reside el éxito del mismo.  

El Product Manager se encarga del Negocio de producto, del rendimiento económico del mismo, se encarga de sus cuentas de resultados, en definitiva es el responsable final del producto.

Hasta aquí pareciese que cada uno tiene su espacio de trabajo, pero si profundizamos en el análisis del Product Owner veremos que este rol tiene un enfoque estratégico y táctico y el Product Manager tiene un enfoque estratégico y es ahí donde está el conflicto de qué acciones corresponden a uno y a otro.

Un Product Owner para desarrollar el producto necesita conocer las necesidades y expectativas de clientes y usuarios, así como qué productos similares gestiona la competencia, con toda esta información se creará el producto,  en definitiva identificará los requisitos que conforman ese producto, desarrollando épicas e historias de usuario. Todo esto responde a una gestión estratégica por parte del Product Owner.

Luego el Product Owner transferirá ese enfoque estratégico, que reside en el Product Backlog, a uno táctico que está representado en el resultado de qué cada sprint. El éxito de un sprint reside en cumplir con los objetivos del sprint.

El Product Manager tiene una responsabilidad ejecutiva sobre los resultados del producto, es decir, si el producto entrega los beneficios esperados, potenciando las ventas e identificando esos nichos de mercado que permitan el posicionamiento del producto; todo esto nos lleva a un enfoque estratégico del producto, y reiterándome es ahí donde está conflicto en aquellas organizaciones que cuentan con los dos roles.

También puede suceder que en una organización no exista el rol de Product Manager y sea necesario que el Product Owner cubra acciones como gestionar el presupuesto del producto  y la cuenta de resultados del mismo.

Es necesario establecer una definición clara de las acciones, que no permitan que se solapen, se puede ver que el Product Manager tiene que dar la cara por el producto, pero no puede ejecutar la responsabilidad del mismo. Una herramienta que permitiría mejorar la descripción de roles  y responsabilidades  es la Matriz RACI+F, para solucionar este solapamiento de roles. En dónde la A es el responsable que da la cara, es decir, el responsable y definir quién es el consultado, informado o facilita cada proceso.

¿Qué es Lean UX?

Consiste en integrar la experiencia del usuario (UX) dentro de un enfoque Lean. La Experiencia del Usuario es una filosofía de diseño que permite desarrollar productos que satisfacen necesidades de aquellos que lo usarán y así mejorar su experiencia de uso. Lean es un modelo de gestión enfocado en entregar el mayor valor para los clientes, incrementando la velocidad de respuesta por medio de la reducción de desperdicios, costes y tiempos. Tanto Lean Startup como la experiencia del usuario, conviven de forma simbiótica dentro de Lean UX.

Lean UX se asienta sobre tres pilares  que son Lean Starup, Desing Thinking y metodologías de desarrollo de software, como Scrum.

Lean Startup, se centra en la entrega de valor al cliente, cuidando aquella secuencia de acciones que permiten responder a una necesidad del cliente y por la cual el cliente está dispuesto a pagar. Es importante identificar aquellas actividades que no aportan valor, las cuales serán consideradas desperdicios y deben ser eliminadas. Otras de las cuestiones que aborda Lean es producir lo que verdaderamente se va a consumir, hacer de más ya es considerado un desperdicio. Pero Lean plantea que todo esto no es suficiente que es necesario una mejora continua para llegar a una producción ideal.

Design Thinking es una metodología que crea ideas innovadoras que se fundamenta en la eficacia en entender y dar solución a las necesidades reales de los usuarios. Parte de la forma en la que trabajan los diseñadores de producto. La innovación en estos productos se alimenta de la observación directa de lo que la gente quiere y necesita en sus vidas y de cómo se hacen los productos, que características les parece más atractivas que otras, teniendo también en cuenta su presentación, cómo se presentan en el mercado, los canales de venta, etc. Para todo se requiere de la colaboración de un equipo que esté presente todo momento.

La tercera parte de Lean UX son las metodologías de gestión de proyecto con un enfoque ágil, aquí nos centramos en entregar resultados parciales, incrementales y funcionales. El enfoque ágil promueve un desarrollo iterativo al gestionar el proyecto, que permite la entrega de resultados parciales que serán evaluados por los stakeholders y que con sus feedback irán adecuando el producto a un mayor nivel de aceptación, esos resultados se sumarán a un resultado final. Una cualidad importante del desarrollo iterativo es que los resultados sean funcionales, así se podrá evaluar si las funcionalidades están acorde a las expectativas de los clientes. En esto también juega de manera muy relevante la retrospectiva que permite incorporar mejoras a medida que se desarrolla el proyecto.

Estas tres partes son fundamentales para poder lograr un producto ajustado a las necesidades y expectativas de los usuarios.

¿Cómo nos organizamos para presupuestar un proyecto en un entorno Ágil?

Las organizaciones están inmersas en una etapa de cambios, denominada Transformación Digital, asumir esto conlleva ser más flexibles y poder adaptarnos rápidamente para dar respuestas al mercado; pero aún hay muchas organizaciones que no están preparadas para dar ese salto; debido su manera de trabajar, es decir, su cultura dificulta el cambio.

Uno de los procesos tradicionales de todas las organizaciones es la financiación de los proyectos, que responde a una gestión poco flexible y lejos de esta nueva filosofía de trabajo.

El objetivo de este artículo es mostrar un modelo de Agile Budgeting, que permita a las organizaciones pasar de un proceso centrado en el coste a un enfoque Agile, que soporte los procesos financieros y presupuestarios de la organización, donde se trabajará con equipos estables, permitiendo la flexibilidad y la toma rápida de decisiones.

En la actualidad, en muchas empresas para gestionar un presupuesto se utiliza el Contrato de Precio Fijo, que es aquel en que el cliente y el proveedor firman el contrato a un precio que no se modifica, suceda lo que suceda durante el proyecto. El precio del contrato se fija en base a los requerimientos. Los impedimentos que aparecen durante el desarrollo del proyecto no nos permite cumplir con ese contrato, todo esto genera desconfianza y malestar entre las partes implicadas.

Otra opción es hacer un Contrato Tiempo y Materiales, este tipo de contrato tiene dos componentes: un componente fijo como puede ser el precio por hora, el precio por unidad, el precio por metro cuadrado,… y otro componente variable, el número de horas o metros cuadrados que se invertirán finalmente.  Aquí el precio final está en base al alcance que se quiere conseguir en el proyecto y como en un proyecto ágil el alcance no está totalmente definido, ya es una situación que conlleva a la desconfianza de una buena gestión.

Ante la insatisfacción de los resultados y la desconfianza que permiten estos tipos de contratación se busca algún modelo de gestión de costes que se pueda desarrollar dentro de un enfoque Agile.

En los proyectos de desarrollo de software es común que se parta de una figura difusa de lo que se quiere obtener, teniendo en cuenta al mercado y a los feedback de nuestros stakeholders; esto conlleva continuos ajustes, que debe ser soportado por un modelo de gestión, que nos permita hacerlo sin trampas.  Lo que he visto que más se adapta a esta situación, es utilizar un modelo de inversión, que consiste en entregar un producto, que sea atractivo en el mercado, se invierte un capital que servirá para la construcción del producto y luego se mide el retorno de inversión y así se tiene un modelo enfocado en la inversión que permita gestionar proyectos Agile.

Lo que se intenta, es que ante los cambios, se realicen las menos gestiones posibles y que nos dé la suficiente flexibilidad para adaptarnos al mercado y poder entregar resultados que impacten en él. Para una organización que está arraigada a procesos tradicionales se hace complicado llegar a desarrollar un modelo de inversión.

Entonces…..

En base a la estrategia de la organización se analizan el porfolio y se determina qué productos aportarán mayor beneficio a la organización y en función de esto empezamos a segmentar nuestro presupuesto.

Una vez determinados los productos que merecen nuestra atención el siguiente paso es identificar los recursos necesarios para llevarlo adelante.

El equipo debe estar basado en un tipo de producto y ser estable, por ejemplo si tenemos tres productos serán tres equipos los encargados de priorizar y construir el producto. Estos recursos deberán ser multifuncionales, es decir, que atiendan varias cuestiones como tecnológicas, negocio,  riesgos, cuestiones legales, etc.

Las iteraciones de los diferentes equipos deben tener la misma cadencia. (Por ejemplo 2 semanas), para que el modelo de financiación sea sencillo.

A nivel de financiación de producto, la revisión del producto se hace cada cierto tiempo (por ejemplo cada 3 o 4 meses).

Estableciendo una iteración y revisión de producto a tiempo fijo esto nos facilitará el modelo de financiación. Por lo tanto cada cierto tiempo se decide si se tiene que quitar o agregar capacidad de un proyecto  o en otro. De esa manera estabilizamos el presupuesto cada cierto tiempo adecuándonos a los cambios.

Ya tenemos un coste fijo,  de esta forma al saber cuánto me sale un sprint, teniendo en cuenta la duración de este y además teniendo en cuenta que cada tanto tiempo revisamos la financiación del producto, ya esto simplifica mucho la gestión del dinero.

Otro aspecto a considerar,  que las personas se deben contratar a nivel porfolio y no a nivel proyecto, esto permite que podamos desplazar los recursos sin vernos afectado por temas de contratación y teniendo en cuenta las necesidades de otros proyectos.

Otro aspecto muy importante a considerar y que cierra el modelo de inversión, es medir el retorno de inversión. Para ello debemos a integrar a todas las unidades de negocio que participan el ciclo de vida del producto. Estas unidades de negocio están orientadas al negocio y participan desde un primer momento hasta la entrega de resultados al cliente.

Habitualmente dentro de la gestión del software tenemos un área de desarrollo y de mantenimiento, pero para conseguir esto a nivel estructural, debemos integrar a todas unidades de negocio involucradas (por ejemplo: marketing, Operaciones, áreas de negocio, etc.), enfocados en el mercado, con cadenas de valor, en donde un mismo equipo actúa desde que el cliente solicita algo hasta que se le entrega. Esta integración conlleva gran cantidad de gente, teniendo en cuenta la demanda.

Una vez integradas las unidades de negocio podremos determinar el retorno de inversión generado en cada unidad de negocio y así de esta manera creo que podemos mejorar y cambiar el modelo de Budgeting dentro de las empresas hacia un enfoque Agile. No es una tarea fácil, hay que hacer muchos cambios dentro de la organización, pero veo que este es el camino para armonizar la gestión de desarrollo  con un presupuesto Agile.

Product Owner - Responsabilidades I

La transformación digital en las empresas trajo consigo nuevos actores que son importantes conocerlos y tener sus responsabilidades debidamente definidas. 

Hace unos años la figura de Comunity Manager no existía como tampoco la del Product Owner. 

Como todo lo nuevo trae consigo la confusión hasta comprender y situar la figura del Product Owner dentro de la empresa. En mi experiencia voy identificando muchas dudas y malas decisiones respecto de este rol; situaciones clásicas que se da en organizaciones con un enfoque tradicional, que están afrontando cambios y buscan una  solución fácil o una figura que cubra el rol entre los que ya existen en la empresa. 

En este caso me centraré más en el Product Owner, que me es más a fin, por dar formación en Scrum. Siempre que doy un curso de Scrum, cuando llegamos al punto de las descripción de roles el de Product Owner es el que genera más interés y consulta. Qué hace el Product Owner, cuáles son sus responsabilidades, qué características debe tener el rol?

El Product Owner es responsable de entregar el máximo valor del Producto desarrollado en el proyecto, a tal fin gestiona el Product Backlog, donde se encuentra definida la calidad y el alcance del proyecto.

Una de las actividades, que realiza dentro del Product Backlog, es desarrollar las Historias de Usuario y Criterios de Aceptación que van a permitir mejorar la interpretación de los requisitos del cliente por parte de los miembros del Scrum Team. Esta acción no estará completa si el Product Owner no está disponible para el Scrum Team a fin de resolver dudas que se tenga acerca del producto. Es necesario que se desarrolle un verdadero compromiso entre el Product Owner y los Scrum Team a fin de resolver todas las dudas que se presenten.

En otro orden de cosas el Product Owner debe controlar el presupuesto del proyecto, cualquier decisión de contratación o inversión que se tome debe tener el su visto bueno.  Por ejemplo un Product Owner debe conocer  cuánto se invierte en la realización de un Sprint.

Como en toda metodología relacionada con los proyectos se debe hacer una gestión de los interesados del proyecto que permitan una comunicación fluida y por supuesto una mirada favorable al proyecto que se está desarrollando. Para mejorar esta visión es necesario muchas veces reportar a los interesados.


Es un rol de total relevancia dentro proyecto representa la visión del producto y es considerado la voz del cliente. 

El próximo artículo continuaré describiendo y profundizando dentro de este rol.