Da a tus colegas mejores comentarios (con Ryan Schaefer de Viget)

Lee la transcripción:

Estamos probando una herramienta de software para transcribir nuestros pódcast. Por favor, disculpa cualquier error ya que el bot no es 100% preciso.

Ben Aston:

Bienvenido/a al pódcast de DPM, donde vamos más allá de la teoría para dar consejos útiles que funcionen a la hora de liderar mejores proyectos digitales. Gracias por sintonizarnos. Soy Ben Aston, fundador de The Digital Project Manager.

Entonces, ¿cómo te enfrentas a la tarea de dar retroalimentación a las personas de tu equipo? ¿Lo afrontas porque sabes que tienes razón, eres un PM, o lo evitas por miedo a que no te tomen en serio? Tal vez recibes retroalimentación, piensas que nadie entiende realmente, o incluso escuchó lo que has dicho, pero como gestores de proyecto, somos responsables de entregar el éxito, aunque eso es complicado cuando nuestros equipos parecen estar yendo por el camino equivocado.

Así que descubre en el pódcast de hoy algunas maneras sencillas en las que puedes dar retroalimentación que ayude a tus equipos a entregar mejores resultados y mantener tus proyectos en camino.

Hoy me acompaña Ryan Schaefer. Ryan pasó de diseñar y construir sitios web a ahora dirigir su desarrollo, y está en DC en una agencia llamada Viget. Hola, Ryan.

Ryan Schaefer:

Hola Ben. Gracias por invitarme.

Ben Aston:

Genial. Ryan, cuéntanos un poco sobre tu rol actual y lo que realmente me interesa es cómo hiciste esa transición de diseño/desarrollo a PM. Es una pregunta que nos hacen a menudo. ¿A qué te dedicas ahora mismo? ¿Es puro trabajo de PM o también te metes un poco en los detalles?

Ryan Schaefer:

Diría que me inclino más hacia labores puras de PM, pero creo que una de las cosas que me facilitó la transición de estar involucrado directamente en la ejecución de diseño y desarrollo hacia la gestión de proyectos fue entender todos los pensamientos y procesos que implican esas áreas.

Eso me permite hablar con los diseñadores y desarrolladores talentosos que tenemos aquí de igual a igual; no tengo que preguntar qué significan las siglas, ni qué herramientas se usan o cosas por el estilo.

Creo que mi experiencia en una agencia de relaciones públicas anterior, donde tenía un rol dual en cuentas y ejecución, me ayudó a pensar en cómo comunicarme con el cliente y trabajar con otros miembros del equipo, cosas así. Así que la transición al PM full scale fue bastante natural para mí, afortunadamente.

Ben Aston:

¿Pero cómo sucedió? ¿Cuál fue el momento clave en que dijiste: “Ya está, voy a ser PM”?

Ryan Schaefer:

Tuvo que ver un poco con querer gestionar desde una perspectiva más global que ejecutando tareas en un silo, pero diría que la razón principal fue que quería unirme a una firma donde todos fueran apasionados por lo digital y tuvieran una mentalidad de avance, porque eso está cambiando la manera en que vivimos como sociedad y como país, y estar rodeado de personas que lo valoran y dominan sus disciplinas digitales era algo que buscaba, sabiendo que eso también me ayudaría a crecer profesionalmente.

Ben Aston:

Genial. Cuéntanos un poco sobre lo que haces actualmente. En Viget, ¿cómo es ese rol de PM?

Ryan Schaefer:

Primero se pronuncia Viget. Nos lo preguntan mucho.

Ben Aston:

¿Vid-get? ¿Vig-et?

Ryan Schaefer:

Viget, sí.

Ben Aston:

Incluso entré al sitio web y vi un gato que decía que es Viget.

Ryan Schaefer:

Sí, hay un botón de “saluda”. Eso es Viget.

Ben Aston:

Eso pasa con nombres graciosos. ¿Qué significa Viget?

Ryan Schaefer:

“Juntos florecemos” en latín.

Ben Aston:

Ah, claro.

Ryan Schaefer:

O algo así.

Ben Aston:

Mi madre se avergonzaría de mí. Lo siento mamá, es profesora de latín. Debería saberlo.

Ryan Schaefer:

Latín fue mi materia menos favorita en la secundaria. Tuvimos que cursarla. No puedo creer que tuvimos que cursarla.

Ben Aston:

Eso te habrá servido para todos los idiomas que hablas ahora, ¿verdad?

Ryan Schaefer:

Sí, exactamente. Pero sí, mi rol en Viget como PM abarca muchas cosas diferentes. Están las responsabilidades principales de PM como cronogramas, presupuestos, planificación, dotación y recursos; y también tenemos tareas más específicas de gestión de producto. No hay gerentes de producto aquí, así que los PM nos encargamos mucho de los recorridos de usuario, definición de funcionalidades, pruebas de calidad, realmente comprender los negocios y productos en los que estamos trabajando, por completo.

Ben Aston:

Genial. ¿Entonces gestionan proyecto y producto?

Ryan Schaefer:

Sí, es un-

Ben Aston:

Una mezcla de ambos.

Ryan Schaefer:

Sí. Van de la mano y es beneficioso hacerlos juntos, pero también son diferentes, por lo que es un buen cambio de ritmo cuando quieres pasar de solo el proyecto a “operar” el proyecto.

Ben Aston:

¿Puedes contarnos algo sobre los proyectos en los que trabajas ahora?

Ryan Schaefer:

Claro. Acabo de pasar hace un par de semanas a dedicarme a tiempo completo a un único proyecto, por primera vez. Es un gran sitio de marketing y un portal para diferentes grupos de audiencia donde pueden iniciar sesión y se les muestra información diferente.

Estamos rehaciendo todo el ecosistema, actualizando el diseño de todos sus materiales digitales, y trabajando en una hoja de ruta para futuros productos, como quizás una app. Es muy involucrado y estoy emocionado de profundizar en un solo proyecto y conocerlo a fondo.

Ben Aston:

Hablando de apps nativas, sé que tienes un Lightning Talk próximo en el DPM Summit sobre consejos para gestionar este tipo de proyectos. ¿Puedes darnos la versión resumida? ¿Qué estás descubriendo sobre la gestión de apps nativas?

Ryan Schaefer:

Sí, mi charla se centrará en lo que he aprendido del mayor proyecto que he gestionado aquí, que fue el diseño y desarrollo de una app para Android.

Hablaré sobre lo aprendido, principalmente las diferencias entre gestionar un desarrollo nativo y uno web más típico, mejores prácticas y requerimientos técnicos que como PM necesitas conocer.

Por ejemplo, el costo del fracaso es más alto en una app, porque puede bloquearse, mientras que una web normalmente solo se recarga. Los lenguajes para aplicaciones nativas no son como JavaScript para webs. Debes resolver el 90% de un problema, en lugar del 30 o 40% en web, donde JavaScript cubre el resto.

También hay controles y restricciones del sistema, como funcionamiento offline, la interacción de los botones del móvil y a dónde llevan. Cosas como esas.

Ben Aston:

Tú has hecho apps web, apps nativas... La tendencia es que todos hacen web apps por lo fácil y rápido. ¿Cómo ves tú el futuro entre web y apps nativas?

Ryan Schaefer:

Una cosa interesante que vemos es el auge de servicios como Squarespace, themes en WordPress, Weebly y demás. Son servicios útiles para quien tiene conocimientos técnicos limitados y puede crear un sitio bonito fácilmente.

Como tienen bajo costo y accesibilidad, es más difícil encontrar desarrollos web tradicionales de marketing. El desarrollo nativo no tiene algo similar todavía, así que encontramos muchas oportunidades ahí. Además, siempre está bien decir que tienes una app propia, ¿no?

Ben Aston:

Sí.

Ryan Schaefer:

El otro punto es que aún quedan muchos productos y software por descubrir. Como en lo que trabajo ahora: un portal donde el usuario ve algo distinto detrás de un login, diferente a lo que puedes crear en Squarespace.

Existe mucha capacidad de personalización, lo que motiva a diseñadores y desarrolladores, y queda mucho por definir en este campo para crear productos más interesantes.

Ben Aston:

Genial. Así que haces desarrollos de apps, sitios de marketing grandes... ¿qué herramientas usas como PM? ¿Con qué herramientas te gusta empezar cada proyecto?

Ryan Schaefer:

Es importante iniciar con fuerza. Me gusta facilitar un kickoff con el cliente, una llamada de visión para hablar de qué hace su organización, su producto, a dónde quieren llegar; también talleres para problemas, metas y objetivos; entrevistas con stakeholders, cosas así.

Son elementos que nunca logras descubrir en venta, aunque seas muy detallado. Cuando entiendes todo eso, es fundamental para definir el alcance y puede tomar varias semanas. Pero vas preparado, avanzas más rápido y entregas un producto final mejor.

Las herramientas pueden ser muchas. Airtable es buena, también GitHub Projects, Zen Hub que va con GitHub, Trello. Usamos todas según preferencias de clientes y propias.

Ben Aston:

¿Alguna herramienta PM reciente que te haya hecho la vida mucho mejor, consejos o atajos que has descubierto?

Ryan Schaefer:

Diría dos cosas. Primero, dediqué tiempo a los atajos de teclado, porque hay muchos más y eso ahorra unos segundos cientos de veces al día.

La otra cosa es...

Ben Aston:

¿Cuál es tu atajo favorito que has descubierto recientemente?

Ryan Schaefer:

Oh, command-shift-T, que reabre la última pestaña cerrada.

Ben Aston:

Muy bueno.

Ryan Schaefer:

Sí, es bueno.

Ben Aston:

Mi favorito reciente, antes tenía una app solo para eso, pero uso Windows. En Windows 10, Windows-V te da el historial de copiar y pegar.

Ryan Schaefer:

Vaya.

Ben Aston:

Por siempre, creo. No sé, nunca busqué tanto, pero suelo jugar al límite pegando cosas, copiar en bloc de notas, hago otra cosa y me olvido de pegar. Así que el historial, incluso con imágenes, me resulta muy útil. Así que Windows-V y command-shift-T, ¿eso dijiste? Ahí están los atajos de la semana.

Ryan Schaefer:

Muy bueno.

Ben Aston:

¿Algo más?

Ryan Schaefer:

La nueva herramienta que uso y que me ha abierto muchas posibilidades es Notion. ¿Has escuchado hablar de ella?

Ben Aston:

Sí.

Ryan Schaefer:

Es como una app de espacio de trabajo. Puedes usarla para notas, colaboración, tiene modo offline, una interfaz limpia, puedes incrustar, hacer toggles y anidar páginas dentro de páginas infinitamente. Tiene app web y móvil, así que puedes usarla donde sea. Es muy personalizable.

Me permite, si estoy en una llamada, abrirla rápido, anotar algo y luego dejarlo bonito fácilmente después o durante.

Ben Aston:

Así que Ryan, de todos los proyectos en los que trabajas y las herramientas que mencionamos, ¿qué te resulta complicado? ¿Cuáles son los retos en el día a día como PM?

Ryan Schaefer:

Muchas cosas. Una es no tener suficiente tiempo. Pero creo que de lo más difícil está el cambio de contexto.

Como PM usualmente tienes varios proyectos y muchas reuniones, así que saltas de una a otra y tienes que “almacenar en caché” todo sobre cada proyecto camino a la siguiente reunión. Para mejorar eso, tomo notas detalladas y hago agendas para cada reunión. Al inicio del día me tomo tiempo con café para pensar el estado de cada proyecto y en qué debe estar al final de la jornada. Siempre trato de mejorar en eso.

Otra cosa es facilitar la colaboración y el traspaso de diseño a desarrollo. A menudo, el diseñador te entrega un mock precioso, hecho con el de UX. Quieres que un desarrollador lo vea antes de mostrárselo al cliente. Pero definir todos los features del front y su gestión en administrador en un compo estático no es sencillo.

Por eso probamos algunas cosas con Airtable, para estructurar el contenido y referenciar los elementos de los comps, así el desarrollador puede decir: “Ok, esto funciona así, aquello de esta manera. Tardará tanto.”

Puede ser tedioso, pero esperamos que valga la pena.

Ben Aston:

Eso porque Airtable es, básicamente, una hoja de cálculo tipo base de datos, ¿no?

Ryan Schaefer:

Sí.

Ben Aston:

¿Y hay integración con InVision, Sketch, lo que usas para prototipos?

Ryan Schaefer:

Tiene integraciones, pero usamos Figma. No creo que tenga integración.

Probamos con Google Sheets, enlaces, etc. No estamos en el punto de integrarlo con una herramienta específica, pero su mayor ventaja es ser una base de datos relacional para enlazar elementos fácilmente, es muy escalable y su UI es limpia y legible.

Ben Aston:

Para los que no han usado Airtable, ¿tienes una hoja por elemento? ¿Cómo estructuras la base?

Ryan Schaefer:

Un poco. Si empezamos con exploración de UX documentamos a dónde va cada ítem de navegación con mapado del sitio y puedes crear otras... No se llaman pestañas, pero son como tabs, y puedes reconciliar lo que tienes enlazando entre tabs y agregar nuevas áreas, ya sea con tags, categorías o bloques de colores.

Eso da claridad y sirve de fuente única de la verdad durante todo el proyecto.

Ben Aston:

Eso soluciona un gran reto: pasar de UX a dev y retener requisitos.

Ryan Schaefer:

Exacto.

Ben Aston:

¿Cómo codificas eso? Usar Airtable es una opción genial; en Word o Sheets solo copias y pegas, y puedes olvidarte de cambiar algo en todos lados. Como base de datos, solo necesitas referenciar un elemento una vez. Muy bueno.

Bueno, hablemos de tu artículo. Para quienes no lo hayan leído, trata sobre cómo dar feedback que realmente beneficie al proyecto y al producto final.

¿Nos das tu visión sobre la retroalimentación, algún tip? Es algo que como PM solemos temer; ¿por qué crees que nos cuesta? ¿Qué miedo crees que hay?

Ryan Schaefer:

Un par de motivos. Uno humano: no queremos ofender ni pisar a los compañeros. Otro: falta de confianza en nuestra opinión, porque les damos feedback a quienes son expertos, los diseñadores y desarrolladores.

Son preocupaciones razonables, pero como PM eres quien está más cerca del cliente y tienes una visión fresca; puedes simular mejor la perspectiva del usuario final. Así que aportas una perspectiva diferente al trabajo de quienes lo producen.

Debemos sentirnos cómodos con ese nivel de experiencia y punto de vista, para dar feedback del tipo: “como PM lo veo por primera vez, ¿transmite claramente lo que hace la organización? ¿Llega a su audiencia? ¿Se nota que esto es un menú desplegable?” Esa reacción ayuda a todos a ajustar el trabajo a las expectativas del usuario y los objetivos de negocio.

Ben Aston:

Me quedo con la idea del “guardianes del éxito”, guardianes de la experiencia de usuario por ser esa mirada nueva.

En el artículo das 10 claves para buen feedback; la primera es informarse bien desde la visión de éxito del negocio. Hablas de hacer un “deep dive” del cliente. ¿Cómo sabes cuándo conoces bien un proyecto? ¿Cuál es tu proceso para ese “deep dive”?

Ryan Schaefer:

Buena pregunta. Creo que nunca sabes al 100%, lo cual está bien.

Ben Aston:

Sí.

Ryan Schaefer:

Creo que las visioning calls son un buen punto de partida para saber cómo se ve la empresa y a dónde quiere llegar (“¿vamos a adquirir otra empresa, fusionarnos, salir a bolsa?”). Luego hay conversaciones con stakeholders ejecutivos para entender cómo planean lograrlo. Eso te da una perspectiva general.

Cuando haces un kickoff con los involucrados, ves cómo se conecta ese proyecto con los objetivos de negocio más altos. Todo debe estar alineado. Hay que recabar información específica en esas conversaciones; si entiendes lo que quieren, puedes ayudar, ya sea refinando la comunicación, rediseñando el aspecto, puliendo el mensaje o proponiendo una app.

Es un proceso en evolución, requiere inversión al inicio. Apostamos mucho a esas fases de descubrimiento, para responder lo que preguntas. Realmente agilizan el proceso y mejoran el resultado final.

Ben Aston:

Así que informarse es entender al cliente, qué es éxito para ellos, qué necesitan los usuarios y lo que les resonará. También mencionabas conocer buenas prácticas y “sumergirse en varias disciplinas”.

Tú vienes de diseño y desarrollo, tienes experiencia. ¿Cómo te pones al día con QA, UX o lo que no dominas? ¿Cómo lograr ese conocimiento básico para dar feedback útil?

Ryan Schaefer:

Sería ideal, cuando ya tienes algo de experiencia para dar feedback detallado, hacerlo de manera objetiva y diplomática, no subjetiva.

La forma de familiarizarse es hablar con todos los del equipo y admitir lo que no sabes. Por ejemplo, vengo del desarrollo, pero no soy tan experto en la experiencia de usuario; no debería temer mirar por encima del hombro de alguien de UX durante una auditoría.

La otra manera es hacer esas tareas uno mismo. Hay montones de recursos para comenzar a programar o diseñar. Se puede sacar inspiración de proyectos ajenos. Yo intento dedicar cinco horas semanales a experimentar con diseño, mantener mis habilidades de código y leer artículos. Otra parte es que cuantos más proyectos y reuniones tienes, más aprendes sin darte cuenta.

Ben Aston:

¿A qué sitios vas para mantenerte actualizado con novedades?

Ryan Schaefer:

Thedigitalprojectmanager.com. Es buena.

También A Girl’s Guide to Project Management. Ad Week es útil para el espacio creativo. En desarrollo, W3Schools no es de noticias, pero tiene recursos para probar efectos, CSS, JavaScript, backend. Son buenos para empezar.

Ben Aston:

Hablabas de pulir habilidades propias; estoy muy a favor de proyectos paralelos para conocer todo mejor. Siempre es más fácil dialogar con desarrolladores si entiendes aunque sea lo básico de cómo funciona todo.

Así que háganlo; crean su portafolio o lo que sea. Leer está bien, pero hacerlo por ti mismo es distinto. Si pides al diseñador algo, intentar hacerlo te ayudará a dimensionar el esfuerzo, lo que es clave para el feedback.

¿Tienes alguna anécdota de cómo esto puede volverse en tu contra? A veces, cuando damos retroalimentación, pensamos que sabemos pero ellos son los profesionales. ¿Te han dicho “cállate Ryan, tú no eres el diseñador, yo sí”? ¿Cómo consigues que valoren tu opinión y no te vean solo como el PM?

Ryan Schaefer:

No me ha pasado aún, afortunadamente. Parte por los grandes compañeros y parte por centrarme en la visión del cliente, que el equipo debe respetar. Especialmente cómo cada decisión se relaciona con los objetivos definidos al principio.

Así, no digo “no me gusta ese color”, sino “las guías de marca lo ponen como terciario y ocupa mucho espacio: ¿no será negativo para ellos?” El diseñador seguro ya pensó en ello y tiene razones; si tiene sentido para ti, lo tendrá para el cliente. Si no lo consideró, es útil mencionarlo, y podrá repasar su razonamiento o corregir si hace falta.

Ben Aston:

Genial. Algo útil de tu artículo es recordar que no depende solo de ti. Si el diseñador usa el color incorrecto, puedes involucrar al director creativo: “¿te parece bien usar este otro color?” Puedes sumar otras opiniones y no cargar con todo tú solo.

Mencionabas también prever diferentes respuestas del equipo: unos agradecen el feedback y otros no. Hablas de tough love, motivar, pero sin perder el mensaje.

Es un reto, porque queremos ser amables, pero ¿cómo balanceas el tough love, ser concreto y dar halagos constructivos? ¿Cómo hacer esto sin enmarañar el mensaje? Suena complicado.

Ryan Schaefer:

No es una ciencia exacta y me gustaría poder dar pasos 1, 2 y 3. Pero como PM seguro tienes inteligencia emocional para leer cómo reciben el feedback.

Lo que ayuda es ser específico. No defiendes cosas subjetivas; centras el feedback en decisiones objetivas ligadas a los objetivos del proyecto.

Un consejo: transmite confianza en su habilidad para resolver lo que hacen. Eso motiva a todos, tanto si toman la crítica personalmente como de forma indiferente.

Creo que todos apreciamos recibir comentarios positivos si son concretos y sinceros, no condescendientes.

Ben Aston:

Por último, si alguien escucha esto y siente que su voz no cuenta frente al equipo de UX o diseño, ¿qué les recomendarías?

Ryan Schaefer:

La primera vez que veas algo que no te convence, no opines de inmediato, especialmente si es la primera vez. Tómate un tiempo, revisa en tu escritorio, haz notas. Identifica dónde crees que falla el diseño, y lo más importante, sugiere mejoras.

Esto te da tiempo para reflexionar como hacen ellos y te permite sustentar tus ideas. Cuanto más profundo y preparado estés, más respeto y apertura tendrás del equipo para implementar esos cambios.

Ben Aston:

Buenísimo. La gente puede ponerse a la defensiva cuando decimos “no me gusta, creo que no está bien”... Pero si no estás seguro, es buena idea analizar por qué piensas así y dar tu razonamiento: “no siento que esté bien porque x, y, z; el cliente quiere esto, ¿cómo crees que lo va a cumplir?” Podemos preguntar al que hizo el trabajo y luego plantear posibles soluciones. Hacerlo en la pizarra ayuda; no se trata de quitarles el trabajo de diseño, sino de proponer ideas. Eso ayuda a valorar lo que dices.

Ryan, muchas gracias por acompañarnos. ¡Fue genial tenerte aquí!

Ryan Schaefer:

Muchas gracias. Lo aprecio.

Ben Aston:

Cuéntanos tu experiencia: ¿has dado feedback? ¿Cómo lo recibió el equipo? ¿Se molestaron o agradecieron que notaras algo que no habían visto?

Cuéntanos en los comentarios y entra en thedigitalprojectmanager.com para unirte a nuestro equipo de Slack. Allí encontrarás todo tipo de conversaciones interesantes sobre gestión de proyectos digitales.

Y si te ha gustado lo que escuchaste, suscríbete y déjanos una valoración honesta en el podcast DPM en Apple Podcasts. Valoramos mucho tus valoraciones y reseñas, ¡gracias por ello!

Hasta la próxima, gracias por escucharnos.