Cómo optimizar tus procesos con la gestión de flujos de trabajo (con Marc Boscher de Unito)

Lee la transcripción:

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

Ben Aston:

¿Pierdes mucho tiempo buscando la información que necesitas? Estoy seguro de que sí. Y aún más, como alguien que gestiona a otras personas, ver a tu equipo pasar horas tratando de encontrar información es increíblemente doloroso. La realidad es que no existe un sistema de gestión de flujos de trabajo que sirva para todos por igual. Es posible que a tu equipo de UX y estrategia le guste usar Trello o Asana, pero cuando se trata de tus desarrolladores, inevitablemente querrán usar JIRA. Entonces, ¿cómo gestionas esta locura? ¿Cómo decides quién gana? De hecho, hubo un informe de McKinsey que señalaba que la mayoría de los empleados pasan aproximadamente ocho horas a la semana solo buscando información.

La buena noticia es que hay una manera de solucionar este problema, y esa solución es un sistema de gestión de flujos de trabajo. Así que si te interesa ahorrar tiempo, ahorrar tiempo y presupuesto a tu equipo, continúa escuchando el pódcast de hoy. Hablaremos sobre la creación y optimización de un sistema de gestión de flujos de trabajo. Gracias por sintonizarnos. Mi nombre es Ben Aston. Soy gestor de proyectos digitales y fundador de thedigitalprojectmanager.com. Estamos en una misión para ayudar a los gestores de proyectos digitales a entregar mejor y ayudar a quienes gestionan proyectos en el mundo digital a tener éxito.

Si quieres conectarte con nuestra comunidad, entra a thedigitalprojectmanager.com donde encontrarás multitud de recursos para adquirir habilidades, ganar confianza y comenzar a entregar mejores proyectos. Hoy me acompaña Marc Boscher: Marc es un desarrollador web convertido en gestor de producto, y ahora es el CEO y fundador de Unito. Así que Marc, bienvenido al pódcast de hoy.

Marc Boscher:

Gracias por invitarme.

Ben Aston:

Cuéntanos un poco la historia. ¿Cómo pasas de ser desarrollador web a gestor de proyectos y luego a gestor de producto y finalmente a fundar tu propia empresa? Háblanos un poco de esa evolución.

Marc Boscher:

Bueno, me tomó algunos años, supongo, todo comenzó en la burbuja puntocom y las cosas avanzaban muy rápido. Estuve involucrado en tecnología hasta llegar al producto. Básicamente llevo 20 años dedicado a los productos. Cuando estás en producto, tienes la oportunidad de observar problemas constantemente y siempre piensas "alguien debería resolver esto", y nunca llegas a hacerlo. Pero guardé esa lista y, básicamente, Unito surgió de uno de esos problemas que veía todo el tiempo.

Ben Aston:

Entonces, dices que llevas 20 años trabajando con productos, pero Unito es un producto relativamente nuevo. ¿De dónde surgió la inspiración para desarrollar específicamente y abordar ese problema?

Marc Boscher:

Bueno, la gestión de productos y, hasta cierto punto, de proyectos implica trabajar con muchísimos equipos y diferentes habilidades, y rara vez tienes autoridad. No eres su jefe. Tienes que gestionar mediante la influencia. Eso significa que no puedes decidir qué herramientas van a usar. A menudo te toca adaptarte a la mezcla de herramientas que usa cada equipo con el que tienes que trabajar. Así que me encontraba constantemente saltando entre Zendesk, Asana, JIRA, GitHub y esas herramientas, pagando el precio. Y ese es uno de esos momentos en los que piensas: "alguien debería solucionar esto". Normalmente esto se resuelve obligando a todos a usar la misma herramienta. Pero cuando evolucionaron las APIs, surgió la idea: ¿podemos conectar esas herramientas y dejar que la gente trabaje en su herramienta sin que los PM tengan que perder tanto tiempo gestionando? Integrar esas herramientas, evitar perder el tiempo preguntando en qué estado está todo o si una persona va tarde y cómo afecta eso a otra. Esa fue la semilla de la idea: un típico caso de resolver tu propio problema. Si tenía tracción, pues lo llevaríamos adelante. Y aquí estamos hoy.

Ben Aston:

Genial. Cuéntanos un poco sobre el set de herramientas que integras internamente. Sé que puedes conectar herramientas y software de gestión de proyectos como Trello y Asana y JIRA. Pero, ¿cuáles son tus herramientas preferidas y cómo funciona esa integración?

Marc Boscher:

Personalmente, soy adicto a las herramientas, así que las uso prácticamente todas. Es emocionante encontrar alguna que encaje con tu forma de pensar y se adapte a tu rol. Ganarás mucho en productividad, pero lo difícil es convencer a los demás para que cambien. El mayor problema para adoptar tecnología hoy en día no es técnico, no es instalar el software, sino lograr que la gente lo use. Ahora tenemos una docena de herramientas. Hace un par de semanas lanzamos la integración con ClickUp. La próxima semana lanzamos otra y otra en tres o cuatro semanas. Estamos desarrollando integraciones para el sector de gestión de proyectos: Asana, Wrike, Trello... y también empezamos por las herramientas de desarrollo: GitHub, BitBucket, GitLab y JIRA, centrándonos en conectar project managers con equipos técnicos o usuarios de negocio con equipos técnicos que no hablan el mismo lenguaje (ni de herramientas ni técnico). Con el tiempo, hemos añadido Zendesk (soporte), HubSpot (ventas y marketing). Es decir, cómo logras que el trabajo no se quede solo dentro de un equipo, sino que cruce la organización. Ese es un problema mucho mayor, donde se pierde y desperdicia mucho tiempo.

Ben Aston:

Mencionaste que eres adicto a las herramientas. ¿Has descubierto alguna nueva recientemente que te entusiasme y que pienses que todos deberían probar?

Marc Boscher:

Todas las que integramos son las mejores herramientas del mercado. Pero nos gusta pensar que no hay una sola herramienta perfecta. Depende de lo que necesites, quién eres y cómo trabajas. Esa es la creencia central: no recomiendo una herramienta sobre otra, depende de cada caso. Ese es el fundamento del negocio: cada quien tiene su herramienta, la que más le ayuda a ser productivo. El reto es que nunca es la misma. Cada día surgen nuevas herramientas. Solemos elegir las más populares y que están creciendo. Por supuesto, es fundamental que tengan una capa de API para poder integrarlas. Hoy en día la mayoría la tiene porque ya tienen esa visión de ecosistema.

Ben Aston:

Muy bien. Marc ha escrito un artículo que puedes ver en thedigitalprojectmanager.com y se titula "Cómo construir un sistema de gestión de flujos de trabajo". Hay ejemplos allí. Pero para quienes no lo han leído, ¿puedes explicar un poco más a qué te refieres exactamente con gestión de flujos de trabajo? Creo que los gestores de proyectos entendemos qué son los procesos: cómo llevar una cosa de A a B, siendo A el inicio y B el final del proyecto, pasando por ciertos pasos. Ese es el proceso.

Son los pasos que seguimos para sacar los proyectos adelante y la idea es ir añadiendo valor en ese recorrido de A a B. Entonces, ayúdanos a entender qué es la gestión de flujos de trabajo y cómo encaja dentro de esa lógica para llegar de A a B dentro de las restricciones del proyecto, asegurando que aportamos valor al final.

Marc Boscher:

Sí, es muy similar a lo que ya conocemos: los procesos. Se usan flujos de trabajo y procesos como sinónimos. Nos gusta pensar que los procesos son secuencias lineales de pasos, así solemos pensar y planificar proyectos: primero esto, luego lo otro, etc. Pero justamente la realidad cambia.

Cuando la gente empieza a trabajar, surgen cosas, tienes que colaborar entre equipos, incluir a otros en ese entorno tan dinámico, especialmente en el trabajo digital actual. No es lineal ni específico, hay mucha menos previsibilidad. Por ejemplo, desarrollas software, campañas de marketing, lanzamientos de producto o procesos de ventas... cada equipo define su proceso y hay marcos para eso.

Pero cuando trabajas colaborativamente entre áreas, hay menos estructura: reuniones, videollamadas, chats. Menos uso de herramientas para gestionar el trabajo y la entrega. La gestión de flujos de trabajo es una capa que conecta todos esos procesos, los cruza y los integra.

Ben Aston:

Entonces, si el sistema de gestión de flujos de trabajo contempla escenarios de tipo "si esto, entonces aquello", y mencioné antes que el recorrido de A a B nunca es una línea recta sino una serie de bucles, derivaciones, idas y vueltas. Necesitamos gestionarlo. Por ejemplo, presentamos el UX al cliente mientras desarrollamos los estilos, pero tal vez aprueban el UX y no los estilos, ¿cómo seguimos?, ¿cómo mantenemos el proyecto avanzando y aseguramos que todos estén conectados y actualizados al mismo tiempo para iniciar desarrollo aunque el diseño continúe? Entender todo esto nos permite ser más eficientes porque dejamos de ver los proyectos como una línea recta y más como ciclos entrelazados. Se crean flujos paralelos: UX, diseño, desarrollo, QA... y pueden colaborar de forma ágil. ¿Ese es el concepto de gestión de flujos de trabajo?

Marc Boscher:

Exactamente. Es aplicar los principios de ágil, como no intentar controlar todo, dar más libertad para colaborar, eliminar obstáculos, trabajar en ciclos cortos... pero las herramientas hoy dificultan esto, porque cada uno usa una diferente. El primer paso en la gestión de flujos de trabajo es ir a donde ocurre el trabajo: aceptar que la gente está en diferentes herramientas e ir ahí.

Integrar las herramientas donde ocurre el trabajo, y el segundo paso es mapear el flujo entre ellas. Definir reglas y guías de colaboración, por ejemplo, cómo trabaja Marketing con Desarrollo o cuándo se requiere involucrar a los diseñadores, PMs, y developers, permitiéndoles colaborar desde sus propias herramientas sin tener que salir de ellas.

Así, sin tener que ir de aquí para allá solo buscando actualizaciones. Un ejemplo simple: tu plan de proyecto está en un diagrama de Gantt en Wrike o Asana. Una actividad que deben hacer los developers se convierte automáticamente en un issue de JIRA pero sigue sincronizada, así el PM ve todo el progreso desde su herramienta.

Marc Boscher:

Así pueden ver dependencias entre departamentos o equipos sin tener que estar saltando entre herramientas. Reconocer dónde ocurre el trabajo, conectar todo y definir las reglas: si sucede algo en este proyecto, quiero verlo reflejado en mi plan de proyecto, por ejemplo. Así nadie tiene que abandonar sus herramientas. Toda la información es accesible donde estés: más riqueza, menos fricción para colaborar. Ahí puedes empezar a optimizar y mejorar.

Ben Aston:

Mencionaste que cada equipo usa herramientas diferentes. Muchas veces la realidad es que convencer, por ejemplo, a un equipo de diseño para trabajar en JIRA es inviable. Lo bueno de herramientas como Unito es que permiten trabajar a cada uno en la herramienta que mejor se adapte. Es un desafío constante buscar una herramienta que lo haga todo, pero cada software tiene su propia filosofía de gestión de proyectos, lo que hace que colaborar sea fácil o difícil según la combinación de equipos. Por ejemplo, he intentado que equipos de diseño usen JIRA y simplemente no funciona, más aún si el workflow es complejo.

Entonces, al diseñar el proceso y decidir qué tan complejo hacer el sistema de flujos de trabajo, ¿cómo determinas cuántos controles poner, cómo automatizar sin hacerlo excesivamente complejo? Uno de mis problemas con JIRA es que cuando diseñan el flujo parece que te quedas encajonado. ¿Cómo evitas eso cuando construyes un sistema de gestión de flujos de trabajo y tratas de automatizar, por ejemplo, que crear una tarjeta en Trello cree automáticamente el issue en Jira? ¿Cuándo es demasiado complicado? ¿Por dónde empiezas?

Marc Boscher:

Desde el principio, nuestro objetivo es que los usuarios de negocio puedan configurarlo, no los técnicos. Es fundamental, porque no puedes depender de un desarrollador para integrar equipos. Todo debe ser visual y poder definir reglas en lenguaje natural.

Por ejemplo, cuando pasa X, debe pasar Y en el equipo de ingeniería. Pero también debe mapear cosas entre procesos que quizá no sean igual de detallados: en desarrollo puedes tener QA, revisión de código, staging... muchos pasos. En marketing solo te interesa si la funcionalidad está lista para lanzar, sin tanto detalle. El sistema debe permitir decir: en marketing, este es mi proceso, ¿cómo corresponde con el de ingeniería? No tienen por qué coincidir uno a uno. Los diez pasos de desarrollo pueden ser solo "en desarrollo" para marketing.

Todo parte del diálogo: ¿cómo trabajas tú? ¿cómo trabajamos nosotros? y luego dar flexibilidad para que los usuarios de negocio configuren e iteraren la relación. No hay que definir todo de golpe. Empieza con reglas simples: cuando asigno algo a Ben, aparece en su herramienta. O cuando escalo un ticket de soporte, se crea en Jira. Vas viendo el flujo de información y cómo se adapta la gente, y así luego puedes sofisticar y ahorrar tiempo.

Ben Aston:

Veo detrás de ti lo que parece un workflow dibujado en la pared. Al diseñar o mapear el proceso, ¿lo visualizáis primero en tablero o lo construís directamente en la herramienta? ¿Qué métodos usáis para comprender el panorama general del proceso?

Marc Boscher:

Vimos que los clientes lo dibujaban en pizarras, así que creamos una función visual dentro de la herramienta para mapear dónde ocurre el trabajo y cómo debe fluir entre equipos. Eso es clave: los clientes dominan su proceso interno, pero cuando se trata de colaborar fuera de su equipo, no saben cómo lo hacen los demás. Los PM lo viven en carne propia, pues cruzan esos límites todo el tiempo.

Pero, en vez de que el PM gaste tiempo traduciendo y sirviendo de puente, ¿qué tal si las herramientas dejan de ser obstáculo y la comunicación fluye automáticamente? Así el PM puede centrarse en alinear, priorizar, identificar riesgos; no en el trabajo recursivo de informar a todos. Ahí no está el valor ni el tiempo bien invertido.

Ben Aston:

Sí, mucho tiempo de gestión de presupuestos es asegurarse de que la gente está enterada de los cambios, de que leen el ticket, de que ven la actualización en Trello. Reconocer que cada quien trabaja diferente y permitirlo es el futuro.

Pero, ¿qué pasa cuando falla? ¿Cuáles son los desafíos de estos sistemas? Creo que uno de los problemas es confiar ciegamente en el workflow, pero igual pueden perderse cosas por el camino. Imagino que uno de los retos es esa confianza excesiva. ¿Qué otros desafíos has visto con los sistemas de gestión de flujos de trabajo?

Marc Boscher:

La comunicación siempre es clave, con o sin sistema. Si facilitas la comunicación (permitiendo que cada uno use su herramienta para trabajar, comunicar y actualizar a los que no están en la misma), esa exigencia disminuye. Piénsalo como una orquesta: cada músico tiene su instrumento (su herramienta), los violines están en Trello y el piano, en Jira. Hay un director de orquesta, normalmente el PM, guiando para que estén sincronizados. No harás que todos toquen violín; su fortaleza es su instrumento. La orquesta moderna funciona así, el PM guía a un grupo autónomo, cada uno domina su herramienta.

El objetivo es que todos vean al director y se vean entre sí. Hoy, cada uno está en su cajita, aún más en remoto. La orquesta está dispersa, hay desfases, distintos horarios... resulta más difícil mantener la armonía. El workflow management es esa batuta para orquestar a todos sin cambiar su modo de trabajar, cruzando zonas horarias y herramientas.

Ben Aston:

¿Y cómo ves que esto evolucione? Cuando imaginas el futuro del trabajo, de los proyectos, de tu herramienta, ¿cómo crees que evolucionará y cambiará el rol del project manager?

Marc Boscher:

Esperemos que pase menos tiempo haciendo trabajo mecánico y más tiempo dirigiendo la orquesta. Creemos que la tendencia a usar más herramientas seguirá, porque ya es muy barato construir software y fácil adoptarlo, así que habrá más y más herramientas. Hay que ir donde la gente trabaja, aceptarlo y facilitar la autoorganización. Luego, es fundamental mantenerlos alineados, conectados. Si tienes una capa de gestión de flujos de trabajo que los conecta, tendrás mucha más visibilidad de lo que ocurre. Cuando preguntaste "¿quién gana?" al principio, eso supone que alguien pierde (tiene que cambiar de herramienta). Creemos en un futuro donde nadie pierda y todas las herramientas trabajen juntas de forma fluida. Esperamos ser esa plataforma; creemos que la gestión de flujos de trabajo lo hará posible.

Ben Aston:

Si soy nuevo optimizando procesos o la gestión de flujos de trabajo (en muchas agencias pequeñas el CEO es también PM y ventas), ¿por dónde empiezo con el diseño del proceso y la optimización del flujo? ¿Cuáles son los primeros pasos para comprender y diseñar el proceso óptimo y llegar a automatizar? Porque hay un trabajo previo, ¿cómo abordar ese primer paso?

Marc Boscher:

Siempre hay pequeños cambios fáciles de aplicar y la barrera de entrada es más baja de lo esperado. No es tan complejo como parece: cada cliente organiza su proyecto a su manera. Cuando eres una agencia pequeña tienes que adaptarte al proceso y herramienta del cliente. Próxima vez, empieza con un proyecto, observa qué usa el cliente y cuál sería tu herramienta ideal. Si sólo pudieras usar la misma, podrías repetir mejores procesos internamente. Si el próximo cliente usa otra herramienta, prueba una integración. Ese es el enfoque: ¿y si enlazaras ambas herramientas? Es poco invasivo y fácil de probar.

No tienes que cambiarlo todo de golpe; empieza con un equipo pequeño, proyecto pequeño o workflow reducido: ¿cómo hago para que marketing pida un cambio a desarrollo web? ¿Cuánto tiempo te lleva ese proceso? O que soporte escale un ticket a desarrollo. Empieza por ahí y ve iterando.

Ben Aston:

Creo que la mentalidad más ágil es construir, probar y aprender. Cuando diseñamos y optimizamos procesos, la realidad es que no sale perfecto a la primera. Hay que encontrar oportunidades para estructurar procesos inexistentes, aprendiendo de lo que salió mal en el último proyecto. ¿Por qué el diseño empezó tarde? ¿Por qué el desarrollo comenzó antes de tiempo? Detectar esas lecciones permite crear proceso, probarlo, mapearlo y a partir de ahí aprender y ajustar. Ese es un excelente primer paso. Marc, muchísimas gracias por acompañarnos hoy. Nos encantó tenerte aquí.

Marc Boscher:

Gracias, Ben.

Ben Aston:

Si quieres aprender más y mejorar tu diseño de procesos de gestión de proyectos, entra a thedigitalprojectmanager.com. Allí encontrarás una gran cantidad de recursos, membresía, formación online... Pero hasta la próxima, ¡gracias por escucharnos!