Comienza Tus Proyectos con Buen Pie (con Suze Haworth)

Lee la transcripción:

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

Ben Aston:

Bienvenido al podcast DPM, donde vamos más allá de la teoría para darte consejos expertos de gestión de proyectos digitales. Gracias por escucharnos. Soy Ben Aston, fundador de The Digital Project Manager.

Ahora todos sabemos que el inicio de un proyecto es realmente crucial para su éxito, pero puede ser un momento muy complicado. Hay mucha ambigüedad, mucha confusión, desacuerdos frecuentes y mucha incertidumbre. Como PM, nuestro trabajo es poner el proyecto en marcha y mantenerlo en movimiento, y puntos extra si realmente comenzamos a liderar el proyecto en la dirección correcta. Pero, ¿qué podemos hacer realmente para asegurarnos de que partimos en esa dirección adecuada? De eso trata el episodio de hoy. Sigue escuchando para descubrir cómo puedes poner en marcha tus proyectos correctamente.

Hoy me acompaña Suze Haworth. Hola, Suze.

Suze Haworth:

Hola.

Ben Aston:

Suze es una de nuestras expertas residentes en DPM en The Digital Project Manager. Trabaja como gerente de proyectos digitales independiente senior en Londres. Y Suze, ¿por qué no nos cuentas un poco sobre algunos de los proyectos en los que has estado trabajando últimamente?

Suze Haworth:

Sí. Soy una PM independiente. Hace poco, hace unas semanas, terminé un contrato, pero fue un contrato a largo plazo en una agencia. Tenía dos roles clave allí. Uno era más de directora de programa para una cuenta. Era para Specsavers, que es una gran marca de gafas al por menor en Reino Unido, y también están en los países nórdicos y Australia. Eso era gestionar un PM senior para toda la parte creativa y de UX, los Specsavers digitales. Así que era un programa de trabajo bastante grande. Y también estaba trabajando en un proyecto para Ikea. Era un proyecto para diseñar y construir un prototipo de un sistema de diseño para la marca.

Ben Aston:

Genial. Entonces lo de Specsavers, ¿era más un proyecto de e-commerce y optimización de conversión?

Suze Haworth:

Sí. Realmente dependía del mercado, pero en realidad no suelen vender gafas en línea por ciertas regulaciones. Así que mucho era para incentivar a la gente a reservar citas e ir a las sucursales. Pero sí, mucha optimización de conversión como dices.

Ben Aston:

Sí. ¿Qué fue difícil en esos proyectos? ¿Cuáles fueron algunos de los desafíos que enfrentabas, ya fuera por el propio proyecto, el cliente o el equipo? Creo que siempre es interesante para la gente escuchar que otros tienen problemas similares. Entonces, ¿qué fue complicado?

Suze Haworth:

Sí. Con el programa de trabajo de Specsavers, en realidad fue un momento muy interesante cuando empecé porque comencé en marzo, que es el inicio del año nuevo, y nos movimos completamente a una nueva forma de trabajar. Antes habíamos estado trabajando como agencia de diseño junto con su agencia de desarrollo y participando en todos sus equipos scrum. Así que había un dúo de diseñador y especialista UX en cada equipo scrum a través de sus flujos de trabajo. Decidimos sacar a todos nuestros diseñadores y especialistas UX de esos equipos scrum y formar un solo equipo de nuestro lado. Luego pasamos a más bien un proceso de doble pista, así que corríamos lo que llamamos una pista de descubrimiento casi por encima de la pista de entrega, que era más el equipo de desarrollo basado en scrum.

Eso nos permitió hacer pruebas de usuario, exploraciones, hipótesis y comprobar suposiciones con usuarios. Mucha más investigación y datos para alimentar todo eso, y nos dio margen para realmente entregar cosas necesarias para los usuarios. Así que fue un momento interesante para implementar esa nueva forma de trabajo y hacerla funcionar. Sí, fue un reto pero también muy emocionante.

Ben Aston:

Entonces, ¿cuál era tu papel? ¿El del propietario del producto? Tienes esos dos flujos de trabajo paralelos. Uno para estrategia, UX y diseño—supongo que ahí ocurren las pruebas de usuario para identificar necesidades, se priorizan, y algunas pasan al flujo de diseño y UX y luego bajan a desarrollo. ¿Era así?

Suze Haworth:

Sí. Lo que veíamos era que el dúo de diseño y UX en el scrum, trabajando en esas dos semanas... era muy limitante y mucho tiempo se iba en aspectos técnicos. Acababan en largas reuniones de planificación de sprints, a veces trabajando solo en pequeñas partes o asistiendo a reuniones para hablar de bugs. De pronto, se alejaban de pensar en las necesidades reales del cliente y se acercaban más al lado técnico. Por eso decidimos separarlos y hacer una pista por encima, de manera que tuviesen tiempo suficiente. Seguía habiendo entregas rápidas, pero ese tiempo nos permitía ver los datos y pesquisas existentes, identificar suposiciones y luego hipótesis que puedan resolver puntos de dolor del cliente.

Luego podíamos hacer diseño UX rápido, prototipar según la necesidad específica, llevarlo rápidamente al cliente y validarlo antes de pasar a producción. Así se agiliza el desarrollo y se evita construir cosas que el cliente no quiere. Así tratamos de actualizar decisiones de UX y diseño antes de entrar en el sprint. Seguíamos incluyendo a gente técnica en la pista de descubrimiento, sobre todo para validar la factibilidad técnica, para decir: “Esto es lo que quiere el cliente, y le ha gustado esta función que hemos diseñado”. Así que fue para agilizar el proceso y para asegurar que realmente entregamos lo que necesita el usuario más que simplemente lo posible técnicamente. ¿Me entiendes?

Ben Aston:

Creo que eso es un reto para muchas agencias que usan scrum. Scrum no es la única forma de hacer un proyecto ágil, pero parece ser lo más aceptado, que hay que usar scrum. Pero uno de los grandes desafíos cuando se intenta scrum en una agencia es, ¿qué hacen UX y diseño en el sprint? Un camino es que vayan uno o dos sprints por delante del desarrollo, pero entonces nada se termina. La idea de un sprint es entregar algo usable que pase los criterios de aceptación, y es difícil lograr eso en dos semanas pasando por estrategia, UX, diseño y desarrollo de una función.

Me gusta la idea de llevarlos en dos flujos de trabajo paralelos, y a medida que se valida algo, el product owner lo baja al backlog de desarrollo. Así tienes dos backlogs: estratégico, donde surgen las preguntas, y el de ejecución, cuando ya se ha validado. Eso resuelve varios retos sin duda.

Suze Haworth:

Exacto. Así te aseguras que desarrollas funciones validadas por clientes, hay menos desperdicio—mucho más lean, lo cual es siempre positivo.

Ben Aston:

Genial. Hablemos de iniciación de proyecto, de arrancarlo. Tengo curiosidad, en los proyectos de Ikea y Specsavers, ¿estuviste involucrada desde el principio o no?

Suze Haworth:

Sí, en Specsavers fue un equipo retenido y se planeó para el año entero, con un equipo definido. Yo entré cuando esa forma de trabajo ya se había planteado de manera general y el alcance ya definido. Uno de los retos, que también menciono en mi artículo, es tomar un proyecto que otro ya inició o alguien más definió el alcance. En este caso, lo tomé poco después de formado, cuando la forma de trabajo empezó a implementarse noté que necesitaba ajustes y fue evolucionando bastante. Porque una cosa es planear y otra es experimentarlo realmente—te das cuenta de lo que funciona y lo que no y hay que adaptarlo.

En Ikea, trabajé por etapas, y entré en la segunda etapa. El proyecto ya se había iniciado antes de que yo me uniera.

Ben Aston:

Eso suele pasar: los PM tomamos proyectos no siempre desde el inicio, lo que añade confusión. Como PM eres incorporado después de que negocio, cuentas o ventas hayan planteado pero no planificado todo. Hay cierta incertidumbre. Así que hablemos de cómo manejar el inicio: mencionaste la importancia de personas, proceso y producto, y de alinear y clarificar. Es el quién, el cómo y el qué. Empecemos con las personas. Cuando asumes el inicio o llegas al proyecto, ¿qué buscas gestionar en cuanto a personas, para arrancar bien?

Suze Haworth:

Es clave pensar en quién compone el equipo del proyecto. Al iniciar, defines quién trabajará en él, revisando no solo la disponibilidad sino quién es adecuado según habilidades y estilo de trabajo, el tipo de proyecto y cliente.

Si conoces a tu equipo, entiendes quiénes trabajan mejor juntos. Obviamente a veces dependes de la disponibilidad, pero ser consciente desde el principio ayuda, porque aunque tengas que usar personas concretas, saber cómo trabajan te ayuda después si surgen problemas.

Es importante que los involucrados estén desde el inicio. Tras años trabajando con diseñadores, desarrolladores y QA, he visto que odian no estar desde el comienzo y recibir algo ya decidido solo para ejecutar, sin autonomía. Eso genera problemas.

Si el tiempo y el presupuesto lo permiten, involucra al equipo desde el principio, aunque sea superficialmente, tras el kickoff interno inicial habla con ellos sobre qué piensan, qué esperan y cómo quieren trabajar, así se involucran desde el principio.

Ben Aston:

Eso también se relaciona con la asignación de recursos. Mientras antes puedas conseguir el equipo adecuado y su compromiso, mejor, así consigues buy-in. Porque la gente reacciona mal si hereda ideas de otros sin tiempo para pensarlas. Queremos que sientan que es “su” proyecto. Con ese sentido de propiedad se logran mejores resultados.

Suze Haworth:

Exactamente, sí.

Ben Aston:

Ahora, pensando en el proceso, eso también es clave. Una vez definido el equipo, ¿cómo usarlo para entregar el proyecto? Tocaste el punto de cómo iniciaron en Specsavers, pero suele haber desacuerdo sobre el proceso, la metodología y las herramientas. ¿Cómo alineas al equipo ante estos desacuerdos casi inevitables?

Suze Haworth:

Rara vez se logra un proceso ideal para todos. Siempre habrá tensiones. Depende: a veces heredas un proceso definido por la agencia o lo dicta el cliente. Si puedes definirlo tú, mejor, así se adapta al proyecto y cliente. Si es proceso heredado, en el kickoff interno explica por qué lo usas, para obtener buy-in temprano.

Pero es clave adaptar el proceso sobre la marcha. No hay que aferrarse si no funciona. El equipo debe saber que si hay problemas con el proceso, herramientas o comunicación, deben hablarlo para buscar soluciones juntos.

Ben Aston:

Esa flexibilidad es la clave del éxito. A veces los managers o equipos pueden ser dogmáticos: “Eso no es scrum”, “Eso no es ágil”, “Eso es muy waterfall”. Lo importante es lo que funciona para el equipo, el proyecto y el cliente, no cómo debe llamarse la metodología. Todas las iniciativas son distintas, así que aplicar un solo método es muy complicado, a menos que sea desarrollo continuo de pequeñas mejoras, donde sí conviene estandarizar. Pero cuando es un proyecto completamente nuevo y cliente nuevo, todo es válido.

Hemos cubierto el quién y el cómo, equipo y proceso. Cuando empiezas un proyecto frecuentemente el “qué”—lo que realmente se debe entregar—es lo más difícil, porque muchas veces heredas un alcance ambiguo del equipo de ventas o cliente. ¿Cuál es tu proceso para despejar la ambigüedad y concretar lo que realmente se debe entregar?

Suze Haworth:

Depende del tipo de proyecto. Idealmente, no quieres que las cosas estén totalmente cerradas al inicio, porque las cosas cambian y puede terminar siendo algo muy distinto. Prefiero alcances que permitan cambios y entregables no fijos, pero a veces el cliente exige otra cosa. Para esclarecerlo, hay que dialogar y entender bien las necesidades del usuario y negocio, el contexto.

Luego, compartes esos requisitos con tu equipo; no sólo una persona, sino líderes funcionales o algunos integrantes, para debatir qué implica el alcance y los requisitos y definir algunos parámetros de lo posible.

Ben Aston:

En esas sesiones iniciales para definir qué haremos, juntar al equipo en una sala durante media jornada, con pizarra y post-its, ayuda a diseñar la solución a alto nivel. Lo que busco es un entendimiento y alineación compartida. Al principio todos entienden cosas distintas, pero cuando se dibuja y se pegan notas, surgen conversaciones que aclaran ambigüedades, lo cual permite luego ir al cliente con diferentes opciones.

Esa visión de conjunto y compartir la “foto de la pizarra” al inicio del proyecto ayuda después: todos preguntan por ella porque vincula las piezas y lo entregable.

Y adelantando, tener esa solución de arquitectura general—poner la bandera—ayuda a definir dónde inicia y termina el proyecto. Así se delimitan los parámetros y hay alineación. Luego, en el proceso de descubrimiento, sirve para clarificar qué es posible.

Suze Haworth:

Sin duda. Talleres así, con el equipo y después con el cliente, son excelentes para arrancar. Ayudan a entender dónde está parado cada uno. Quizá primero uno interno y luego otro con el cliente está muy bien.

Ben Aston:

Entonces, cubrimos el quién (personas y equipo), el cómo (proceso y metodología) y el qué (esbozo de solución y arquitectura). Allí se puede empezar a perfilar presupuesto, calendario y métricas de éxito; tener todo en la pizarra del inicio, aunque luego cambie, es de gran utilidad.

Pero a veces, esa iniciación del proyecto ocurre antes de la aprobación oficial; existe tensión sobre cuánto avanzar. ¿Eres de avanzar a fondo, o prefieres ser cauta y avanzar sólo lo suficiente para mover el proyecto? Muchas veces no hay sign-off y si no se avanza, no se entregará nunca. ¿Cómo manejas esa tensión entre avanzar mucho y el riesgo de perderse, o ser cauta y quedarte corta después?

Suze Haworth:

Yo tiendo a ser más cauta pero abierta. Si el cliente se retrasa en aprobar, le informo sobre retrasos y cómo afectan al global. Hay que ser consciente de los riesgos si algo no se cierra y esa demora el inicio formal.

Aun así, recomiendo ir avanzando y reflexionando. Incluso con precaución, lo ideal es avanzar lo suficiente para mantener el impulso. Al principio siempre hay momentum; si se anula, el equipo e incluso el cliente pueden perder interés. Mantener el ritmo es positivo; conviene avanzar de a poco.

Ben Aston:

¿Cuáles son tus estrategias cuando el arranque del proyecto se estanca por falta de impulso o por ambigüedad no resuelta y se detiene todo?

Suze Haworth:

Es complicado porque quizá ya tienes recursos asignados pero sin la luz verde definitiva para empezar formalmente. Si hay algo de tiempo, reserva para que el equipo empiece algunas tareas: investigar competidores, analizar datos existentes, seguir pensando a bajo nivel mientras se puede arrancar en serio.

Ben Aston:

Incluso tener una reunión breve de equipo ayuda: “Chicos, pensábamos arrancar esta semana, pero aún no, aquí lo último que sabemos”. Así mantienes la atención del equipo.

Suze Haworth:

No hay nada peor que quedarse en silencio y que, un mes después, vuelvas a contactar para decir “ahora sí, arrancamos”. Es mejor informarles de lo que hablas con el cliente, explicar el motivo de la demora y qué se puede hacer mientras tanto. Mantener la comunicación es fundamental.

Ben Aston:

Un reto común para muchos gestores de proyectos es tomar un proyecto a la mitad: heredamos lo planificado por otros en personas, proceso y producto, pero la responsabilidad de entregarlo pasa a nosotros. ¿Tienes consejos para clarificar la complejidad en ese caso?

Suze Haworth:

Es quizá uno de los mayores retos porque casi nunca participas desde el principio (pitch o fase de ventas). Suele estar resuelto por alguien más (jefe de proyectos, delivery, etc). Casi siempre te llega un proyecto con costes ya cerrados y alcance difuso, y hay que ajustar el alcance al presupuesto. Muchas veces hay que adaptarse a lo que otro ha definido.

Pero consiste en tomar esos parámetros y ver dónde hay flexibilidad. Si tienes un coste definido, revisas el alcance y lo que puedes entregar y haces las negociaciones necesarias si ves que se vendió más de lo posible. Hay que ser realista; si no, no se podrá cumplir. Así que revisa alcances y plazos para ajustarlos.

Si asumes un proyecto con kickoff previo por otra persona, es importante recabar toda la información posible, sobre el proyecto, lo entregado, el cliente, etc. Y hacer un mini-kickoff, aunque sea a mitad del proyecto: reúne al equipo, habla con el cliente y plantea un “reset”, como punto de arranque contigo. Aunque la gente sienta que es repetido, ayuda a identificar qué ha funcionado, qué no, y qué se debe hacer diferente. No tiene que ser largo, pero es crucial.

Ben Aston:

Ese reset—tener la confianza para pedir un reset—es clave, porque a veces llegas y no sabes nada. Pero al hacer preguntas básicas y aparentemente tontas, casi siempre surgen ambigüedades que otros también tienen. Con el tiempo, todos hacen supuestos no documentados y la comprensión se desvía aunque haya habido un taller inicial. Ese reset y las “preguntas tontas” destapan problemas y retos que estaban latentes. Es muy útil.

Suze Haworth:

Nunca temas hacer muchas preguntas. Lo digo siempre, incluso a PMs nuevos: pregunta sin miedo a parecer poco entendido. Es mejor preguntar ahora y saber lo necesario que callar y después llevarte una sorpresa. Hay que preguntar mucho.

Ben Aston:

Gran consejo: la clave de la iniciación de proyecto está en la comunicación, en hacer preguntas difíciles e incómodas que nadie más quiere formular. Así se obtiene claridad, se ahorra trabajo y es más fácil dirigir el proyecto hacia esa “estrella del norte” común. Así que Suze, muchas gracias por acompañarnos. Ha sido un placer tenerte con nosotros.

Suze Haworth:

Gracias a ti. Un placer.

Ben Aston:

Y como una de nuestras expertas DPM, Suze estará en nuestro próximo curso que comienza en febrero. Se llama “Dominando la gestión digital de proyectos”, un curso intensivo de siete semanas con lecciones interactivas en video, paneles de discusión y opción de sesiones de coaching. Así que si quieres aprender a iniciar proyectos correctamente inscríbete en DPMSchool.com antes de que se llenen las plazas. Si quieres contribuir a la conversación sobre iniciación de proyectos, comenta en este post y entra también en la sección de recursos de DigitalProjectManager.com para unirte a nuestro Slack donde encontrarás muchas conversaciones sobre iniciación de proyectos y cómo gestionarlos. Hasta la próxima, ¡gracias por escuchar!