Trucos de Gestión de Proyectos (con Natalie Semczuk)

Lee la Transcripción:

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

Ben Aston:

Hola a todos y bienvenidos a esta última edición del Podcast de Gestión de Proyectos Digitales. Hoy, conmigo, tengo a Natalie, y estoy muy emocionado de realizar el primero de nuestros podcasts, donde vamos a hablar con las personas que realmente han escrito algunos de los contenidos y artículos en el sitio.

Natalie publicó recientemente un artículo con nosotros en The Digital Project Manager, Trucos de Gestión de Proyectos, y a todos les encantan los trucos. Si te gustan los trucos, publicamos un artículo hace un tiempo sobre trucos para Slack que fue tremendamente popular. Natalie aquí ha creado una lista de diez trucos diferentes que ha ido usando a lo largo de los años como gestora de proyectos digitales, y van desde lo muy práctico hasta quizás lo más filosófico y de cómo abordamos la gestión de proyectos. Lo vamos a comentar hoy.

Primero, dejaré que Natalie se presente. Natalie, ¿por qué no nos das un resumen de quién eres, qué tipo de proyectos realizas y todo sobre ti?

Natalie Semczuk:

Claro, gracias. Es genial estar aquí. Soy una gestora de proyectos digitales freelance. Trabajo principalmente de forma remota con firmas pequeñas y medianas, normalmente en diseño y desarrollo web, a veces aplicaciones. Trabajo con equipos para ayudarlos a lograr el éxito en sus proyectos, colaboro con clientes y también asesoro en procesos operativos y en cómo hacer que tu equipo remoto sea aún mejor.

Ben Aston:

Genial. ¿Quieres hacernos un resumen rápido de algunos de los proyectos en los que has estado trabajando últimamente, si puedes hablar de ellos? ¿Qué tipo de proyectos, qué clase de gestión digital realizas? ¿Es más estratégica, de campañas de marketing, de desarrollo web...? ¿Qué tipo de DPM eres?

Natalie Semczuk:

Normalmente son creaciones de sitios web o desarrollos de backend, cosas así. Ahora mismo estoy en dos proyectos activos. Uno es para una pequeña escuela primaria privada y están actualizando gran parte de su sistema backend. Así, gestionan la clasificación y organización del alumnado, ese tipo de cosas. Estoy supervisando la gestión del proyecto, el desarrollo y la integración que recolecta todos los datos de los alumnos de los sistemas existentes y los introduce en una solución personalizada donde profesores y padres pueden acceder a ver el progreso del alumnado a lo largo del año.

También estoy trabajando en un diseño y construcción de sitio web, desde cero, para una pequeña start-up de San Francisco que está lanzando productos muy interesantes. No puedo contar mucho más, pero son esas fases típicas de diseño y desarrollo, algo de estrategia añadida, y está siendo bastante divertido hasta ahora.

Ben Aston:

Genial. Muy bien. Así que profundicemos en tus diez trucos. Probablemente no entremos en cada uno de ellos al detalle, pero ¿puedes hacernos un resumen de cómo surgieron? Tenemos algunos muy ejecutivos y prácticos y otros más filosóficos sobre cómo deberíamos ser como PMs. ¿Cómo llegaste a estos trucos?

Natalie Semczuk:

Creo que es una mezcla de ver lo que hacen otros PMs con los que he trabajado, evaluar lo que les ha funcionado bien, y la experiencia propia. Mucho surge de trabajar en remoto, donde tienes más y menos control sobre tu entorno. Menos sobre tu equipo, más sobre tu ambiente personal. Como DPMs usamos muchas herramientas y comunicamos constantemente. Eso es gran parte del trabajo, y es fácil olvidar los detalles de depurar las herramientas y la comunicación para que nos sean útiles y pasemos menos tiempo en tareas repetitivas y aburridas, y más en lo realmente importante.

Ben Aston:

Genial. Así que ese es un buen punto de partida para el truco número uno: “Automatiza al máximo tus herramientas de gestión de proyectos.” En tu artículo, y si no has leído el artículo, está en thedigitalprojectmanager.com, en la portada ahora mismo. Cuéntanos brevemente cuáles son tus herramientas favoritas de PM y cómo las elegiste.

Natalie Semczuk:

Depende de la empresa, uso variedad de herramientas. Casi siempre Slack, Gmail o Google Suite. Para herramientas de gestión de proyectos, he usado mucho Basecamp 3, Trello, y una mezcla interesante entre ambas llamada Breeze.pm. Herramientas típicas de flujos de trabajo, además de Slack y Google y esos programas.

Ben Aston:

Sí, genial. En las automatizaciones que mencionabas, parece que tienes cosas organizadas para que cuando alguien hace algo, o cuando suceden ciertas cosas, recibes notificaciones y sucede algo mágico. ¿Es necesario que tu equipo trabaje de la misma manera? ¿Cómo has conseguido organizar al equipo para que funcione?

Natalie Semczuk:

La mayoría del tiempo sí. Algunos trucos sólo los controlo yo. Son para mi beneficio, como las notificaciones y las herramientas que uso, decido cómo recibirlas, si en resumen semanal o en tiempo real, etc. Las integraciones entre herramientas, por ejemplo GitHub con Slack, o Trello con Slack, requieren que el equipo siga cierto proceso, por el uso mismo de esas herramientas. Creo que es fácil conseguir que hasta el equipo más “salvaje” comprometa su repositorio o algo así. Es beneficioso tener las integraciones activas, independientemente del proceso que se siga.

Ben Aston:

Genial. Si la gente pudiera hacer solo una automatización, ¿cuál es la única automatización que agradeces haber hecho cada día?

Natalie Semczuk:

La mejor para mí es usar Slack como herramienta de chat en todos los equipos. Integrar la herramienta que gestiono en un canal es tan útil, recibo información sobre actualizaciones de tareas, incidencias, tareas finalizadas. Así tengo visión inmediata de lo que pasa. No necesito entrar a otro programa ni revisar el correo. Esa integración es la automatización más fácil. Si no usas ese tipo de herramientas, me gusta recibir resúmenes por correo, así tengo un sitio central para ver todo sin entrar en seis programas diferentes para consultar el estado de algo.

Ben Aston:

¿Algún momento en que tus automatizaciones fallaron y acabaste con un desastre porque no pasó lo que debía?

Natalie Semczuk:

Sí, puede pasar en ambos sentidos: que las integraciones fallen y no lo notes a tiempo, o que funcionen demasiado bien y acabes abrumada de notificaciones en el mismo sitio, lo cual tampoco es ideal.

Ben Aston:

Pasemos al número dos: “Usa una Matriz RACI en cada proyecto.” Para quienes no conocen RACI, cuéntanos un poco y por qué te gustan.

Natalie Semczuk:

Admito que las uso de una manera poco tradicional en mis proyectos, pero la idea básica es mostrar claramente todos los roles, responsabilidades y propiedad de cada proyecto, especificando quién o qué equipo debe implicarse, cómo y para tomar qué decisiones. Muchas personas hacen estas matrices al iniciar el proyecto. Creo que es una forma muy clara de explicar, por ejemplo, que el cliente es responsable de decidir qué contenido se produce, pero nosotros debemos tener visión sobre esos temas, entre departamentos, etc. Es, básicamente, designar responsabilidades específicas.

Ben Aston:

Genial, y sé que en el artículo pones un ejemplo de RACI. ¿Cómo decides quién va en cada columna? ¿Quién es consultado, quién sólo informado, qué implica estar informado, quién es responsable? ¿Cómo tomas esas decisiones?

Natalie Semczuk:

Depende del proyecto. Suelo seguir el precedente o proceso habitual para las fases principales. Según agencias, se sabe cuándo entra el cliente, diseño o desarrollo. Asigno esas personas de nivel alto según lo ya conocido. Pero también hay que dictarlo como PM en proyectos complejos o cuando hay muchos involucrados. O bien decidirlo en colaboración con el equipo, seleccionando entre todos quiénes son responsables o informados. Puede haber superposición, pero es muy útil asignar bien cada rol.

Ben Aston:

Sin duda. Algo que suele ser difícil en RACI es saber hasta qué nivel de detalle llegar. ¿Lo partes en fases, tareas, entregables? ¿Cómo lo decides y hasta dónde profundizas?

Natalie Semczuk:

En proyectos pequeños, prefiero hacerlo por fases importantes y grandes entregables. En proyectos grandes, más complejos, o de largo plazo, lo desgloso mucho más. Me gusta usar la Matriz RACI incluso para cosas que normalmente no se piensan, como el flujo de contenidos o actualizaciones después del lanzamiento. Esto ayuda al cliente y otros interesados a entender el trabajo implicado y pensar en ello con antelación. Así todos están alineados y las expectativas quedan claras usando la Matriz RACI en el proyecto.

Ben Aston:

Muy bien. Ahora, el truco tres es: “Saluda a tu equipo y compañeros cada día.” Suena obvio, pero en trabajo remoto y usando herramientas como Slack, a veces se pierde. ¿Cómo gestionas eso, la comunicación virtual y presencial?

Natalie Semczuk:

Sí, hay que buscar un equilibrio. No es fácil decir qué interacción personal es la mejor, y si es remoto se fuerza aún más, reuniéndose sólo en llamada o vídeo. Pero es muy útil mantener esa relación, recordar a todos que seguimos ahí. Me gusta variar: escribo por privado a compañeros para preguntarles por temas o simplemente cómo están. O bien escribo en el canal general del proyecto “Hola, ¿cómo están? ¿Algo que comentar?”

Creo que tener esa interacción casual es muy valioso, no sólo buscar siempre un objetivo de conseguir información o estado del proyecto, sino relajarse un poco.

Ben Aston:

Genial. El truco número cuatro: “Aprende a decir no en los proyectos. Con amabilidad, pero con firmeza.” Cuéntanos más de eso.

Natalie Semczuk:

Decir no es algo que me costaba como PM joven. Es difícil cuando eres una persona sociable, pero lo veo esencial para protegerme, proteger a mi equipo y al proyecto. Hay que saber cuándo es el momento adecuado para negarse o rechazar algo—ya sea un cambio de alcance, proteger el tiempo del equipo, aclarar cosas para evitar tomar decisiones precipitadas, etc.—y saber cómo gestionarlo bien.

Ben Aston:

Cuéntanos un caso en que tuviste que rechazar algo y cómo lo hiciste para que todos quedaran lo más contentos posible.

Natalie Semczuk:

Un truco es que no siempre es un no rotundo. Recientemente, esta semana, trabajaba con un equipo con Sprints y tuvimos que reorganizar todas las reuniones. Debía decirle que no a un miembro del equipo sobre un día de reunión. Él prefería lunes, yo decía que no porque los lunes no son ideales. Le expliqué que lo entendía, pero que por el bien del equipo debía ser el martes. Le propuse revisarlo en el futuro si no funcionaba. Así fue un no suave pero justificado y corté el debate que ya no llevaba a ninguna solución.

Ben Aston:

Sí, firme pero justo.

Natalie Semczuk:

Eso intento.

Ben Aston:

A veces como PM tienes esa autoridad para establecer las reglas. Sobre decir no al cliente, casos como ampliar alcance, acortar tiempos, reducir costes... ¿Qué técnicas usas para mantener la relación y el proyecto en rumbo enfrentando esas sensibilidades?

Natalie Semczuk:

Intento redirigir y entender el porqué de la petición. En el artículo explico que la educación ayuda mucho. Por ejemplo, si quieren adelantar una entrega, les explico los costes, posibles recortes de funcionalidad, impacto en la calidad, y les señalo el límite: “No podemos adelantar tanto sin comprometer la calidad, y como empresa no trabajamos así.” O explico: “Si tuviéramos que cortar tanto para cumplir, la web no funcionaría.” Hay que ser firme, sin dejar resquicio, pero también explicar las opciones.

Ben Aston:

Es importante que el cliente entienda cuando decimos no, sin ambigüedad. Debemos dar alternativas: “Puedes elegir A o B, B tarda más y cuesta más, pero tendrás mejor calidad...” Así sienten que conservan el control y pueden decidir.

Natalie Semczuk:

Totalmente de acuerdo, es fundamental.

Ben Aston:

Ahora, “Ve tus proyectos como oportunidades de aprendizaje.” ¿Qué has aprendido últimamente?

Natalie Semczuk:

He hablado de aprender más sobre desarrollo, he estado en muchos proyectos técnicos y siempre aprovecho para preguntar al equipo y así lo entiendo mejor desde la gestión de proyectos, puedo ayudar al cliente a comprender. Además, me gusta ver cómo piensan los clientes, sus estrategias, sus negocios; sobre todo en proyectos web, siempre hay que enseñar y aprender cómo usan y actualizan sus webs, problemas que encuentran... Es casi investigación de experiencia de usuario. También es buen momento para probar nuevas técnicas o patrones de comunicación, no de forma radical pero sí ajustando el enfoque y viendo si funciona.

Ben Aston:

En el artículo hablas sobre retrospectivas como oportunidades de aprendizaje. ¿Cómo las utilizas con tu equipo para asegurar cambios reales?

Natalie Semczuk:

Sólo el hecho de hacer retrospectivas ya es muy sano para el equipo. En proyectos complicados donde hay quejas o frustraciones, siempre sale un aprendizaje. Llevar eso a una retrospectiva permite reflexionar tanto sobre las dificultades como sobre lo que sí funciona. Me gusta documentar los puntos clave mientras hablamos, normalmente comparto pantalla y tomo notas, igual que usar una pizarra en persona. Es importante acordar uno o dos puntos a mejorar en el futuro, aunque no se implementen de inmediato, al menos tener esa conciencia compartida ayuda al equipo.

Ben Aston:

Muy bien. El truco siguiente es: “Controla tus notificaciones.” ¿Cuáles son para ti las más útiles y las menos útiles a la hora de priorizar?

Natalie Semczuk:

En general, cualquier notificación sin leer me genera estrés. Quiero borrarlas de inmediato, pero si las leo y no actúo se me olvidan. Así que silenciaré casi todo lo que no sea mensaje directo o algo importante del proyecto. Los mensajes directos siempre los dejo activados. Silencio el “ruido”, mensajes de bots o comunicaciones no esenciales. También aplico filtros en Gmail para no saturarme con emails que no sean del cliente. Saber los disparadores que me hacen reaccionar ayuda mucho.

Ben Aston:

Interesante. El próximo truco: “Educa todo lo posible.” ¿Cómo aprendes y creces ahora, y qué podrían aprovechar otros?

Natalie Semczuk:

Siempre recomiendo ser transparente con lo que uno no sabe, también lo menciono en el artículo. No todo es desarrollo personal, sino saber preguntar al equipo cuando algo se me escapa. No soy experta en todo, pero si hay algo que me resulta confuso, por ejemplo temas de servidores, DNS o hosting, hago el esfuerzo de entenderlo, ya que tendré que explicarlo al cliente y así puedo comunicar con contexto. Entender cómo funciona ayuda mucho a la hora de hablarlo con el cliente y el equipo técnico.

Ben Aston:

¿Webs, blogs o recursos que sigas habitualmente?

Natalie Semczuk:

La verdad, suelo buscar en Google lo que necesito, pero me encanta escuchar podcasts fuera de mi campo directo, ya sea de diseño o estrategia de contenido. Escuchar de vez en cuando podcasts técnicos me ayuda a estar familiarizada con la terminología y entender mejor lo que pasa.

Ben Aston:

Eso es muy importante. Como gestores de proyectos debemos liderar, no sólo administrar, y por eso necesitamos saber sobre estrategia, UX, diseño, desarrollo, QA... así entender cómo avanza cada disciplina y aplicar ese conocimiento para liderar y sonar competentes ante el cliente. Así lideramos proyectos más eficazmente.

Saltemos al truco diez: “Apunta siempre los números.” ¿Cuáles son importantes para ti?

Natalie Semczuk:

Trabajo sobre todo con equipos de coste por tiempo y material, así que revisar los informes de horas es clave, no sólo para el presupuesto o control, sino también para ver detalles como descripciones, bloqueos, colaboraciones inesperadas, etc. Eso me ayuda a entender qué ocurre realmente, ya que al trabajar en remoto no veo todo de primera mano.

Saber cómo se emplea el tiempo es vital, y no es para juzgar, sino para entender lo que pasa. También analizo cifras de presupuesto. Con esto obtengo buenas pistas de comunicación, flujos de trabajo, bloqueos o temas que quizá puedo ayudar a resolver en el futuro. Regularmente reviso las herramientas de gestión para ver conversaciones, tareas bloqueadas, etc. Reviso tareas completadas, bloqueadas, etc.

También importan los recursos: horas por semana asignadas, vacaciones próximas, todo eso es “de números”, pero al final afecta presupuesto, cronograma, velocidad, y todo el trabajo involucrado.

Ben Aston:

Genial. Un comentario en tu post era de alguien que pasaba de AM a PM en agencia de marketing y no tenía estructura definida. ¿Algún consejo para reportar horas usando hojas Excel, herramientas recomendadas, cómo lo haces tú?

Natalie Semczuk:

La mayoría de los equipos usan Harvest u otra herramienta de seguimiento de tiempo, ahí cada uno registra sus horas y yo puedo sacar informes diarios, semanales, mensuales. Lo clave es ver cómo tu equipo reparte sus horas y hace el seguimiento, y construir el sistema según eso. Si es para reportar al cliente, exporto CSV o Excel o Google Sheets, limpio los registros y lo resumo si se necesita un detalle.
Si es para informes internos, obtengo los datos de la herramienta directamente y los comunico oralmente o por correo.

Ben Aston:

¿Y cómo reconcilias esos datos? La gente apunta las horas, pero ¿cómo sabes si va dentro del plan? ¿Con qué frecuencia concilias contra el estimado? ¿Cómo funciona ese proceso?

Natalie Semczuk:

Normalmente hago esa revisión semanalmente, si la semana es muy activa, varias veces. También he estado en proyectos donde no hay registro hora a hora, sino bloqueos de días completos. En esos casos reviso que lo planificado se haya cumplido, lo comparo con reportes internos.
Conciliar las horas es descargar el informe y compararlo con la estimación o presupuesto, revisar si hay tiempo asignado a formación, etc., y así tener una visión semanal. Así también mantengo actualizado al cliente y si se revisa semanalmente no suele haber oscilaciones importantes.

Ben Aston:

Muy bien. Muchas gracias Natalie por acompañarnos. Ha sido muy útil para entender cómo trabajas y algunos de estos trucos que has compartido para que podamos aprender también. Y si nos estás escuchando y quieres contribuir a la conversación, nos encantaría que compartieras tus comentarios en el post de Natalie en thedigitalprojectmanager.com, o en nuestra comunidad de Slack que puedes encontrar en el sitio en la sección comunidad.

Gracias Natalie por acompañarnos, esperamos tenerte pronto de vuelta. Ha sido un placer.

Natalie Semczuk:

Muchas gracias a ti.