29 de mayo de 2017

¿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.

19 de mayo de 2017

¿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.

23 de febrero de 2017

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.