Haciendo las cosas bien (con Michael Luchen de Crema)

Leer la transcripción:

Estamos probando la transcripción de nuestros podcasts usando un programa de software. Por favor, disculpa cualquier error, ya que el bot no es 100% preciso.

Ben Aston:

Apesta cuando las cosas no funcionan, y cuando pasamos semanas o meses construyendo un proyecto, solo para que un error escurridizo nos decepcione en la UAT final. Pero, ¿por qué eso parece suceder casi siempre y hay algo que podamos hacer al respecto? Bueno, si los errores te molestan, sigue escuchando porque en el podcast de hoy vamos a conversar sobre cómo podemos hacer las cosas bien con un producto y proceso mejorados y la magia de un plan de gestión de calidad.

Gracias por sintonizar. Soy Ben Aston, fundador de project managers. Bienvenido al podcast DPM. Tenemos la misión de ayudar a los Project Managers a tener éxito, para ayudar a quienes gestionan proyectos a entregar mejor. Estamos aquí para ayudarte a llevar tus habilidades en gestión de proyectos al siguiente nivel. Revisa thedigitalprojectmanager.com para conocer nuestros cursos y recursos que ofrecemos a través de la membresía. Este podcast es patrocinado por Clarizen, el líder en software de gestión de proyectos y portafolios empresariales. Visita clarizen.com para más información.

Hoy me acompaña Michael Luchen y Michael es uno de nuestros expertos residentes en DPM. Es coach de producto. En Crema y son una agencia digital que crea apps web y móviles para empresas disruptivas y líderes de la industria. Trabaja de forma remota normalmente desde D.C., y les ayuda a mejorar su colaboración para analizar y resolver problemas complejos. Ha trabajado con Adidas, Callaway Golf entre otros, y es coach en Crema. Hoy vamos a hablar con él sobre cómo construir un plan de gestión de calidad. Pero hola Michael, bienvenido al programa.

Michael Luchen:

¡Hola Ben! ¿Cómo estás?

Ben Aston:

Bien, gracias. Y tengo curiosidad, mientras hemos estado hablando y grabando podcasts durante, supongo, los años, tu rol ha evolucionado y me interesa tu posición de coach que tienes ahora, que creo que es un nuevo título de trabajo. ¿Puedes contarnos un poco sobre qué es ser coach de producto y qué significa eso en Crema?

Michael Luchen:

Sí. Bueno, como mencionaste, esto surge tras cerca de siete años de experiencia práctica en dirección de proyectos y productos. Y la verdad, el rol aún está en definición. Estamos tratando de entender qué es un coach en Crema. Ahora mismo lo vemos simplemente como un líder servicial que ayuda a los clientes a comprender la práctica Ágil para convertirse en mejores versiones de sí mismos. Usualmente puedo servir como facilitador, estratega de producto y pensador de diseño para ayudarles a replantear problemas y encontrar enfoques innovadores. Pero creo que lo interesante de este nuevo rol y aventura para Crema es intentar marcar la diferencia en una industria saturada, pero abordándolo desde un ángulo muy particular que no sea prescriptivo. Hay muchos procesos de coaching prescriptivos ahí fuera y nosotros queremos ser diferentes.

Ben Aston:

Entonces, en tu rol, ¿trabajas con un equipo pequeño y directamente con el cliente? ¿Es más un rol estratégico cuando ayudáis a definir la hoja de ruta del proyecto o producto?

Michael Luchen:

Sí, es—

Ben Aston:

¿O es más enfocado a la entrega?

Michael Luchen:

… Es parecido a lo que dices, pero más amplio y centrado en las personas. Algo que me encanta de la gestión de proyectos es poder crear un entorno saludable para los equipos para que hagan su mejor trabajo. Esto lleva eso un paso más allá, ayudándoles a los clientes a tener las herramientas y mentalidad necesarias para crear una cultura productiva dentro de sus equipos y así obtener resultados excelentes.

Ben Aston:

Entonces, ¿qué tipo de retos te enfrentas para ayudar a los clientes a cambiar esa mentalidad de entrega?

Michael Luchen:

Sí, hay muchos retos, pero creo que tienen que ver con que los resultados no siempre son instantáneos. No es algo que yo pueda llegar, decir “haz esto”, y ya mejorará. Hay mucho de eso por ahí: aprende la metodología X y tu equipo tendrá éxito. Pero lo importante es entender el contexto y la cultura de la organización y saber que cuando empoderas a líderes, lleva tiempo experimentar y ver cómo se integran los aprendizajes.

Ben Aston:

Totalmente. Creo que es cierto que no existe un único proceso que funcione absolutamente bien para tu organización o agencia. Y si sigues meramente los pasos, no conseguirás resultados mágicos. No hay una varita mágica que resuelva todo. A veces la gente piensa “Ágil es esa varita mágica”, pero, ¿qué significa eso realmente? Parece un rol interesante lo que buscas, ¿lo haces sobre todo en remoto o también presencialmente con los clientes?

Michael Luchen:

Definitivamente una combinación. Ahora, mientras grabamos esto, 100% remoto. Pero creo que las relaciones se pueden construir en persona, así que si es posible, es bueno iniciar el coaching in situ. Sin embargo, la capacidad de generar una conversación productiva por Zoom o usando Loom para Compartir Pantalla y colaborar en mural boards ha sido valiosa. Se puede hacer de las dos maneras.

Ben Aston:

Hablando de trabajo remoto, estamos en plena cuarentena por coronavirus y tú diste un taller sobre teletrabajo. Para quienes lo hayan perdido, ¿cuál sería el consejo o truco más efectivo que usas para no volverte loco trabajando en casa? Porque sé que normalmente ibas a espacios de coworking y tienes mucha experiencia trabajando aislado en casa. ¿Qué haces para mantenerte sano?

Michael Luchen:

Buena y oportuna pregunta. Mentalmente trato de recordar que colaboro y trabajo con otras personas. Hacer llamadas de Zoom con cámara tantas veces como sea posible ha sido fundamental. Suena básico, ahora Zoom es la app gratis más descargada, pero abordarlo intencionadamente, saltar a una videollamada y conversar ayuda a ver las interacciones no verbales que son clave, sobre todo como gestor de proyectos. Incluso pongo una segunda pantalla para ver las caras de todos mientras comparto pantalla.

Ben Aston:

Creo que es buen consejo y Zoom es una gran herramienta. A veces, con Slack, solo te quedas escribiendo y olvidas que pierdes mucha comunicación y la oportunidad de construir relaciones. La conversación es diferente vía chat que por Zoom, así que vístete y haz esa llamada por Zoom, realmente vale la pena.

Dices que haces coaching remoto y presencial, aunque ahora todo es remoto. ¿Puedes contarnos algunos de los proyectos en los que trabajas actualmente?

Michael Luchen:

Sí, ahora estoy pasando de la gestión de producto al rol de coach. Estoy cerrando un gran proyecto empresarial de varios años y me resulta genial hacerlo desde el mindset de coach porque hay mucho solapamiento al trasladar el coaching al plano del practicante. Ahora mismo estoy desarrollando los servicios de coaching y, sobre todo, ¿cuál será el diferenciador clave por el que Crema puede marcar la diferencia y servir a los clientes con humilde confianza?

Ben Aston:

¿Qué cuellos de botella de entrega estás detectando como oportunidades mientras construyes este rol?

Michael Luchen:

Una buena metáfora es que abordamos el coaching como un semestre universitario, porque creo que mucho del coaching efectivo es por experimentación, que quienes reciben coaching experimenten y aprendan. Mi rol es facilitar, guiar y mentorear desde la experiencia de la práctica.

Esto implica reuniones periódicas, retrospectivas, observaciones y notas compartidas tipo “prueba esto en tu próxima reunión”. Crear un ritmo para que después de semanas o meses, podamos mirar atrás y ver una mejora evidente y mayor capacidad de producción.

Ben Aston:

¿Y cómo ayudas a identificar qué áreas dentro de una organización priorizar al pensar en ser más Ágil? Porque habrá muchos procesos diferentes. ¿Cómo ayudas a seleccionar los aspectos ideales para comenzar?

Michael Luchen:

Comienza con una encuesta. Una charla, pero no solo con un contacto, sino también con managers, desarrolladores, quien quiera estar involucrado. La encuesta busca dudas sobre qué es lo más importante a resolver. Después, mi equipo y yo procesamos el resultado y lo contrastamos con la información recibida para recomendar una o dos áreas clave que traerán buenos resultados.

Ben Aston:

Eso suena inteligente. ¡Suerte con eso!

Michael Luchen:

Gracias.

Ben Aston:

Quiero volver al tema del post y a la gestión de calidad. Si no has leído el artículo, lo encuentras en thedigitalprojectmanager.com: se titula “cómo desarrollar un plan de gestión de calidad”. Michael describe de manera detallada y paso a paso cómo crear el plan de calidad. Si eres miembro, puedes acceder al plan de gestión de calidad, la lista de dispositivos objetivo y la plantilla de requisitos y chequeo de calidad para que pongas todo esto en práctica fácilmente.

No profundizaremos en el proceso de crear el plan porque está en el post. En resumen, Michael explica cómo crear un plan de calidad para tus proyectos o productos. Y justamente quiero empezar preguntando sobre el concepto de calidad; en tu proceso hablas de crear una comprensión común de lo que significa calidad en el proyecto. ¿Por qué es tan difícil precisar esto?

Michael Luchen:

Para empezar, la calidad la veo como dos cosas: calidad de producto y calidad de proceso. La primera es la calidad tangible o digital del producto, e incluye el resultado del trabajo del equipo de diseño/desarrollo y más. La calidad de proceso es donde como PMs tenemos mayor influencia y se refiere al proceso que cultivamos y cómo ello impacta en la capacidad de resultado de nuestro equipo. Un ejemplo sería la medición de la velocidad para ver cómo va el proceso.

Tener una comprensión común de calidad es difícil porque hay mucha subjetividad y emoción. Hay muchos interesados y todos, incluso el propio equipo de desarrollo o diseño, llegan con perspectivas diferentes. Por ejemplo, un interesado puede querer un nivel de calidad que cumpla con expectativas, mientras que un desarrollador podría querer código perfecto, limpio. Debemos facilitar y lograr ese equilibrio.

Ben Aston:

Sobre ese equilibrio, es paradójico. Con Ágil tenemos criterios de aceptación para cada historia de usuario. Y luego la definición de “hecho” que se aplica a todas. Pero desde el enfoque Ágil, que busca entregar valor de forma iterativa, a veces el concepto de calidad parece chocar con la rapidez; ¿qué es más importante, los criterios de aceptación, la definición de hecho o entregar valor aun si nos obliga a ir más despacio?

Michael Luchen:

Buena pregunta, me encanta porque va al corazón del tema. Creo que enfocar en la calidad no choca con Ágil, al contrario, lo acelera y habilita. Si al inicio defines junto al equipo qué es calidad y qué no, pones un sano enfoque y guía. Ayuda a saber qué debe y qué no debe considerarse.

A nivel práctico, los criterios de aceptación sirven a Ágil si los ves con la perspectiva correcta. Por ejemplo, si tu equipo desarrolla una historia de usuario y surge un obstáculo técnico que modifica un criterio, eso propicia una buena discusión. No hay que ir más despacio, se hace una pequeña pausa, se actualiza el criterio de aceptación, y eso preserva la calidad.

Ben Aston:

Creo que es cambiar el enfoque sobre calidad: no es que calidad esté reñida con entregar valor rápido, sino que calidad forma parte esencial del valor entregado. Si el producto no cumple cierto umbral de calidad, no tiene todo el valor posible. Así, calidad es un componente del valor y cuando lo definimos bien, ahí se genera ese valor.

Michael Luchen:

Exacto.

Ben Aston:

Tus enfoques hablan de dividir la responsabilidad por la calidad. En grandes agencias hay equipos QA dedicados, pero muchas veces termina siendo trabajo del PM o los desarrolladores. Hablas de impulsar el rol de ingeniero de pruebas, ¿por qué es tan crucial?

Michael Luchen:

Muy buena cuestión. Por experiencia, cuando era PM, hacía yo mismo el QA, y ahora poder colaborar con ingenieros de pruebas es un cambio total. Son cruciales porque entrenan una mirada crítica sobre la calidad. El test engineer es, desde mi punto de vista, el mejor socio para un PM porque analiza a detalle lo que se construye y entrega, desde lo técnico al impacto general, y cómo el desarrollo llega a los usuarios. Además, al integrarlo, se multiplica el valor del trabajo de designers, developers y del propio PM.

Ben Aston:

La mentalidad de QA o ingeniero de pruebas es muy distinta a la del PM. El PM ve el camino óptimo, prueba “como debería funcionar” e inconscientemente espera que funcione para no invertir más tiempo. El QA, en cambio, tiene experiencia rompiendo y pensando en la experiencia de usuario, yendo más allá del camino ideal, aplicando rigor y exhaustividad para que el producto entregue la mayor calidad posible porque siempre habrá errores.

Esto me lleva a la pregunta: en tu artículo hablas de seleccionar los dispositivos objetivo, que es un reto porque los clientes pueden tener teléfonos viejos o exigir que funcione en navegadores y sistemas antiguos. ¿Cómo gestionas ese tema y orientas al cliente cuando quiere compatibilidad universal, incluso en dispositivos del pasado y futuro?

Michael Luchen:

Seleccionar los dispositivos objetivo es uno de mis ejercicios favoritos, sobre todo con background de PM porque ayuda a enfocar en la calidad y en los resultados que busca el usuario. Si el cliente pide soporte para todos los dispositivos y sistemas, puedes comenzar a preguntar por los usuarios reales y sus necesidades. El debate, por ejemplo con Internet Explorer, puede resultar importante si la app lo requiere por algún nicho.

La conversación sobre dispositivos permite que el equipo y el cliente se centren en el usuario y se priorice basándose en lo que importa y el tiempo que conlleva.

Ben Aston:

Un consejo para quienes redacten una declaración de trabajo o definan criterios de aceptación: especificad bien los dispositivos compatibles y no digáis genéricamente “funciona en todo móvil y escritorio por siempre”, porque, como evolucionan los navegadores, puede dejar de funcionar. Definir los dispositivos objetivo es fundamental.

Pasando a los casos de prueba: ¿qué opinas del desarrollo guiado por pruebas (TDD) y si realmente aporta valor? ¿Tus ingenieros de prueba documentan sobre la marcha o siguen un plan exhaustivo de testing?

Michael Luchen:

En mi experiencia en Crema, los ingenieros de pruebas lideran la cultura de que la calidad es tarea de todos. Los desarrolladores practican el TDD y se aseguran de incluir pruebas de integración en el código para los componentes relevantes. Así, los ingenieros de pruebas pueden concentrarse más en testing manual desde la perspectiva del usuario, pruebas automatizadas, exploratorias y límites.

Ben Aston:

Dices que la calidad es responsabilidad de todos, pero el riesgo es que nadie la asuma realmente. ¿Cómo fomentas la calidad como valor en la organización, prácticamente?

Michael Luchen:

Comienza con educación, creando canales de Slack para conversar sobre ello y mantener la discusión sobre qué significa la calidad para nuestros proyectos. Desde lo práctico, sobre todo para los PMs, poner procesos que permitan checks de calidad a lo largo del trabajo. Así calidad se integra al proceso. Por ejemplo, usamos JIRA y en los flujos de trabajo establecemos revisiones de código para cuando algo pasa de ‘en progreso’ a ‘en staging’, previo a QA.

Ben Aston:

Integrar calidad en el proceso, no solo como un paso más luego del desarrollo. Es decir, que tanto desarrollo como testing estén integrados. Mencionas incluir testing unitario en el código. ¿Cómo decides cuándo usar testing automático? ¿Cuándo vale la pena dada la inversión, cómo lo balanceas?

Michael Luchen:

Buena pregunta. El testing manual es útil y de bajo esfuerzo, especialmente en experiencias de usuario complejas donde automatizarlas sería excesivo. Un ejemplo sería un drag-drop complicado. El testing automatizado es útil para flujos repetitivos, como formularios largos. Extra puntos si los ingenieros logran rellenar datos locos automáticamente.

Ben Aston:

Entonces, tu enfoque de plan de gestión de calidad es lograr que sea parte integral del proceso y además adaptado al proyecto y los componentes. ¿Cómo defines/aseguras que la planificación orgánica de calidad realmente es la apropiada? ¿Cómo sabes si vas por buen camino?

Michael Luchen:

Buena pregunta. Soy fan del proceso orgánico. Así como medimos la velocidad tras unos sprints para prepararnos para el proyecto, veo la calidad igual. El artículo da una buena base y marco para empezar, pero siempre es solo una suposición inicial. Si el equipo es nuevo, habrá ajustes según evolucione el proceso tras los primeros sprints/semanas. Hay que permitir cierto margen, aunque no de forma radical. Por ejemplo, si tras el lanzamiento vemos que un dispositivo objetivo nadie lo usa, podemos actualizar la lista y redirigir esfuerzos a otra parte.

Siempre que inicie un nuevo proyecto, será según la experiencia anterior, pero con empatía hacia el nuevo equipo.

Ben Aston:

El sentido común es clave en la gestión de calidad. Si todo gira alrededor de calidad y controles, se corre el riesgo de quedar atrapados haciendo burocracia, no generando valor. Hay que balancear entre las comprobaciones planificadas y la adaptación flexible, volviendo al espíritu Ágil: no atarse a un plan cerrado, sino aceptar pruebas exploratorias y adaptaciones para entregar valor incrementalmente y aumentar el valor del producto/proyecto a lo largo del tiempo.

Michael Luchen:

Exactamente.

Ben Aston:

Recientemente lanzamos un podcast en nuestro sitio hermano llamado QA Lead. Si te interesa QA o trabajas con testers o QAs, diles que consulten QAlead.com y como PM revisa también el artículo que tiene ejemplos y plantillas accesibles con la membresía.

Si no has usado un plan de gestión de calidad, pruébalo. Te ayudará a repensar tu proceso y cómo puedes entregar más valor ofreciendo un producto de mejor calidad.

Estos consejos han sido valiosos, pero destaco la idea de que la calidad debe cultivarse en toda la organización. Incluso sin ingenieros de pruebas, pensar en calidad no solo es “¿está roto o no?” sino también un reflejo de nuestro proceso y motivo de mejora a nivel organización, siempre con mentalidad iterativa. Gracias Michael por tus aportaciones.

Michael Luchen:

Gracias.

Ben Aston:

¿Y tú qué opinas? ¿Cuáles son tus trucos, tips y consejos para entregar proyectos o productos con calidad? Compártenos lo que funciona y lo que no. Si tienes historias de fracasos o éxitos, cuéntanos en los comentarios.

Y si quieres aprender más y avanzar profesionalmente, únete a nuestra comunidad DPM en thedigitalprojectmanager.com/membership para acceder a nuestro equipo en Slack, plantillas, talleres, office hours, eBooks y más. Si lo que escuchaste hoy te gustó, suscríbete y mantente en contacto en thedigitalprojectmanager.com. Hasta la próxima, ¡gracias por escucharnos!