Qué Puedes Dejar de Hacer en Tus Proyectos (con Patrice Embry)

Lee la Transcripción:

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

Ben Aston:

Gracias por sintonizar. Soy Ben Aston, y este es el pódcast de Digital Project Manager.
Siempre nos dicen todas las cosas que debemos estar haciendo, y yo soy una de esas personas que lo dice. Existe esta presión por mejorar, hacer las cosas bien y, de hecho, la presión de que se note que haces las cosas correctas es bastante grande, pero ¿deberíamos estar haciendo todas estas cosas todo el tiempo? Sigue escuchando este episodio para descubrir cómo puedes ahorrarte muchísimo tiempo eliminando o reduciendo algunas de las actividades de tu rutina PM que puede que no necesites para cada proyecto.
Vamos a hablar sobre cómo puedes recuperar algo de tu vida, pasar menos tiempo en la oficina o en tu escritorio, cortando seis cosas en las que podrías estar perdiendo tiempo. Este pódcast realmente trata de liberarse de esas cadenas del "deberías" y algunos de los "debes", y volverse un poco más eficiente en la manera en que hacemos las cosas.
Hoy me acompaña Patrice Embry que es, de hecho – y tengo que elogiarla por esto – probablemente la participante más activa en nuestro equipo en Slack, y si aún no te has unido, podrías estar hablando con Patrice ahora mismo. Si entras en la sección de comunidad de Digital Project Manager puedes inscribirte allí. Patrice casi siempre está ahí y siempre está conversando, así que es una buena persona a la que conocer.
Por una breve introducción, Patrice es una PM digital freelance. Es máster certificada en Scrum también. Lleva mucho tiempo trabajando en la industria en todo tipo de agencias y empresas. Escucha algunos de nuestros otros podcast para entender mejor el tipo de cosas que ella ha hecho. Ha trabajado en todo, así que es genial tenerla aquí.
Así que bienvenida, Patrice.

Patrice Embry:

Hola. Gracias por invitarme.

Ben Aston:

De nada. Patrice, ¿puedes contarnos si desde la última vez que hablamos tienes algún proyecto interesante en el que estés trabajando ahora?

Patrice Embry:

Bueno, acabo de terminar una app en la que estaba trabajando que ayuda a personas que buscan trabajos realmente rápidos y a corto plazo. Es como un Care.com pero aún más rápido, para personas que de verdad necesitan hacer trabajos puntuales. Fue una app muy interesante. Todavía está en beta, así que no está completamente lanzada al mundo, pero fue un proyecto muy llamativo porque trabajé con gente de todo el mundo.
Nunca había trabajado con nadie de Nigeria, así que fue la primera vez que dije hola en igbo y fue divertido.

Ben Aston:

Suena como un proyecto de estafa. O sea, no digo que lo sea. Solo que hay esas típicas bromas de estafas nigerianas. ¿El equipo de desarrollo estaba allá?

Patrice Embry:

¿Perdón?

Ben Aston:

¿Era el equipo de desarrollo el que estaba en Nigeria?

Patrice Embry:

Sí.

Ben Aston:

¿De verdad?

Patrice Embry:

Sí. El front-end developer estaba en Nigeria. El back-end developer estaba en México y nuestro líder técnico en Suecia. Luego estaba yo cerca de Philadelphia y el cliente en Boston. Estábamos todos en diferentes lugares.

Ben Aston:

Son muchas zonas horarias con las que trabajar.

Patrice Embry:

Sí, lo es.

Ben Aston:

Eso no debe ser divertido. ¿Cómo lograste que funcionara?

Patrice Embry:

Encontré un horario con el que todos más o menos podían vivir: eran las 8:00 AM hora del Este, así que para nuestros amigos europeos era algo tarde, bastante tarde para nuestro amigo nigeriano, y México tuvo que levantarse más temprano, pero lo logramos.

Ben Aston:

¿Es tipo start up la app o es para...?

Patrice Embry:

Sí. Creo que fue una idea que surgió de una mujer que hacía esto para algunas personas y otras le decían, “Oye, ¿puedes hacer esto para mí?” y ella pensó, “Esto ya no lo puedo coordinar yo sola”, así que dijo, “Hagamos una app.” Está aún en su infancia y prefiero esperar un poco para contar más, pero cuando salga, se los haré saber. Creo que será un servicio muy útil.

Ben Aston:

Parece un proyecto interesante. ¿Qué grandes retos encontraste? ¿Fue sencillo o hubo obstáculos?

Patrice Embry:

Fue un poco complicado porque la clienta realmente no era muy experta en computación, ni en apps. Sabía lo básico, como cualquier persona promedio. Como sabes, en el ramo tech tendemos a tener un poco más de comprensión de cómo funcionan las cosas, así que tuve que explicarle muchas cosas.
Era como explicarle a un amigo que no trabaja con ordenadores todos los días cómo funcionan. Hay cosas en las que no caes hasta que te metes de lleno en un proyecto así. Las pruebas, por ejemplo – por eso está en beta – fueron intensas porque íbamos descubriendo caminos nuevos cada vez. Eso lo hizo desafiante, pero también divertido. Me gustó mucho la idea.

Ben Aston:

¿Qué herramientas usaste para gestionar a tantas personas en diferentes zonas horarias? ¿Cómo gestionaste los requerimientos al principio, que parecían un poco vagos, y luego cómo manejaste el proyecto?

Patrice Embry:

Era muy ambiguo. No había mucho dinero extra, lo cual encaja con el tema de hoy. No podía gastar muchas horas en ciertas cosas. Tenía que elegir en qué invertir mi tiempo para no excederme del presupuesto y dejar horas para el desarrollo.
Usamos Slack porque es gratis, Chelo porque es gratis y Google Docs porque también es gratis. Tuvimos que hacer funcionar todo eso sin funciones de pago porque necesitábamos ser lo más eficientes posible para sacarlo adelante.

Ben Aston:

¿Cómo encontraste ese proyecto? ¿Por un conocido? Porque suena a start-up...

Patrice Embry:

Sí. Como mencionaste, estoy siempre en Slack, y no solo en tu Slack. Como freelance, debes mantener tus canales abiertos para conseguir información y proyectos. Hablo con muchas personas sobre diversos temas.
No recuerdo exactamente cómo llegué a ese proyecto, pero fue de esas redes de contactos… “Oye, conozco a alguien que hace esto, ¿alguien conoce a alguien?” Así fue. Yo hago mucho networking y me llegan proyectos de formas muy extrañas.

Ben Aston:

¿Tú reuniste al equipo de proyecto?

Patrice Embry:

No.

Ben Aston:

¿Eso fue algo que hiciste tú?

Patrice Embry:

No. Simplemente me colocaron en un grupo y entre todos vimos qué le tocaba a cada quién. No tuve que buscar recursos esa vez. Estaba feliz con el equipo y seguiré en contacto con ellos para futuros proyectos.

Ben Aston:

Está bien. Es interesante trabajar en proyectos donde el cliente quizás no sea tan experto, pero hay flexibilidad, que también es genial: te dan confianza y tú decides, “Esto es lo que debemos hacer.” Y es el mejor momento.
El lado negativo es que tienes que explicar detalles técnicos.

Patrice Embry:

Sí, eso pasó mucho. Pero es bueno recordar que cuando haces una app para el público general, no todos tienen el mismo nivel de conocimiento. Nos obligó a volver a lo básico, tanto en la explicación como en la app en sí. No puedes dar por sentado que la gente sabe deslizar el dedo en la pantalla, por ejemplo.
Tuvimos que dejarlo clarísimo, y funcionó bien para el proyecto.

Ben Aston:

Bien. Hablemos de lo que mencionaste antes. Conversábamos en Slack sobre cómo realmente gestionamos proyectos. Hay una diferencia entre la teoría y la práctica diaria, especialmente si tienes formación formal en gestión como PMP, sabes del PMBOK, los procesos, los registros, los informes de estado. Puede ser una pesadilla administrativa.
Pero realmente hay sobrecarga y documentación que podrías estar actualizando, cosas que podrías estar haciendo pero… ¿Vale la pena el esfuerzo? Hablamos antes de la idea de empezar, parar y continuar. ¿Qué deberíamos comenzar a hacer, qué dejar de hacer, qué seguir haciendo?
Me gustaría oír tu perspectiva desde lo alto. ¿Cuáles son los no-negociables? Cuando llegas a un proyecto, tal vez como el que mencionabas, ¿cuáles son esas cosas mínimas que tienes que asegurar sí o sí, o el proyecto no avanzaría o se descarrilaría antes de empezar?

Patrice Embry:

Para mí siempre son el cronograma y los requerimientos. Tras eso, el presupuesto. El presupuesto es importante, pero varía según el proyecto. El cronograma es imprescindible. Tampoco puedes avanzar sin requerimientos, porque si no sabes qué estás haciendo, el equipo tampoco sabrá. Esos son los dos pilares que para mí no son negociables.

Ben Aston:

Solo para aclarar, cuando hablas de requerimientos… ¿Te refieres a un alcance de trabajo? ¿En qué formato presentas esos requerimientos?

Patrice Embry:

Buen punto, porque no necesariamente deben estar en un documento formal, pero hay que definir el alcance y, mejor aún, saber qué tiene que hacer ese producto o proyecto. El statement of work suele asumir cosas, pero siempre hay otra capa más profunda de detalles y necesidades para poder cumplir el alcance. Esas son las cosas que menciono.
Deben estar claras. La gente tiene que conocerlas. Esto guía lo que se hace. De otro modo, nadie sabría lo que está construyendo. Esos son los requerimientos a los que me refiero.

Ben Aston:

Totalmente de acuerdo. Para mí es estimación, cronograma, alcance, cuando llego a un proyecto y toca nivelar todo. Porque si no sabes el cronograma y los requerimientos, no puedes gestionar ni controlar nada. No sabes si vas bien o mal.

Patrice Embry:

¿Cómo sabrás si está terminado? ¿Cómo sabrás si hay que parar? Exacto.

Ben Aston:

Típicamente, al heredar un proyecto, encuentras que algo siempre está desactualizado, especialmente los requerimientos o el statement of work. Todos han acordado cosas nuevas. ¿Cómo, si esos son los no-negociables, los mantienes actualizados para que todos estén alineados?

Patrice Embry:

Recuerdo a la gente el cronograma cada semana o cada vez que hablamos del proyecto. A veces es más de una vez por semana, a veces cada dos. Depende del proyecto, pero siempre recuerdo en qué parte del cronograma estamos. Cuál es el siguiente hito y el siguiente tras ese, así todos sabemos el objetivo.
Recalco la fecha final, no necesariamente la de lanzamiento, sino la de QA o UAT. Si eso cambia, aviso. Si estamos en peligro de fallar una fecha, ahí hablo más.
Con los requerimientos, intento mantenerlos actualizados. Es bueno si están en un sistema tipo Trello o Jira, donde puedes discutir qué se debe hacer y ver la evolución del tema.
Si no usas esas herramientas, se trata de mantener la documentación al día: decisiones con el cliente, ahorros de tiempo, anexos para más adelante. Es un trabajo continuo de actualizar lo que tienes.

Ben Aston:

Sí, ciertamente. A menudo redacto un statement of work y luego hago cambios, o doy actualizaciones cada vez que hay un giro. Así tengo la firma del cliente y una evidencia escrita. Es importante, sobre todo si hay varios clientes o no está claro quién manda.

Patrice Embry:

Totalmente.

Ben Aston:

Ahora hablemos de cosas que no son imprescindibles, como la declaración de alcance, requerimientos, cronograma, estimación, pero quizá podamos simplificar.
Uno de los temas que tocas en el artículo es la desglosada detallada de presupuestos y proyectos. ¿Quieres comentar sobre esto?

Patrice Embry:

Sí. Mi experiencia comenzó en un entorno muy estructurado. Todo era exactamente así y era una pieza más en un engranaje enorme, con otros PMs haciendo todo igual. Había reglas para todo.
Hasta que trabajé en agencias pequeñas y como freelance, me di cuenta de que no siempre puedes hacer todo igual, porque si lo haces, el presupuesto se dispara o no tienes el tiempo. En mi anterior agencia, una de las obligaciones era el presupuesto ultra detallado. Era algo muy clásico. Sigo haciendo mis presupuestos a la antigua: en una hoja de cálculo, con tablas dinámicas, formatos condicionales, referencias de celdas, porcentaje completado y lo que falta respecto al presupuesto, etc. Análisis semanales por rol.
Eso puede servir porque da respuestas concretas rápido, pero si hacerlo me exige gastar muchas horas míos y el cliente no lo valora o la agencia no lo requiere, no compensa.
Sugeriría preguntarse: ¿Necesito hacer todo esto? ¿Puedo hacerlo menos? ¿Afecta al presupuesto si lo hago más? ¿Perjudica al proyecto si lo hago menos? No desglose el presupuesto por inercia, sino porque agrega valor de verdad.

Ben Aston:

Es útil. Pero, ¿tú fijas tu tiempo de gestión de proyecto como un porcentaje del total de horas del equipo o lo asignas tarea por tarea?

Patrice Embry:

Solía hacerlo por porcentaje, y en agencias grandes, sirve bien si puedes absorber cualquier incidencia. Pero yo reviso cada tarea; soy bastante detallista con las estimaciones.
Normalmente hago el desglose de todas las tareas y, si hago un porcentaje, lo aplico sobre la tarea, no sobre el total. Ya no hago porcentaje del global.
Si a ti te sirve, sigue así. A mí últimamente no me cubría.

Ben Aston:

¿Te quedabas corta de horas?

Patrice Embry:

Sí, o…

Ben Aston:

¿Qué porcentaje usabas?

Patrice Embry:

Solía trabajar junto a Account Managers, y proponía agregar 20% del total para account management y otro 20% adicional para project management. Es mucho.

Ben Aston:

Eso es mucho, un 40%.

Patrice Embry:

Sí. Porcentaje no siempre cubre todo. Si el precio base es erróneo, el porcentaje tampoco servirá.
Suele fallar más por un presupuesto base mal hecho que por el reparto porcentual.

Ben Aston:

Eso veo. Suelo calcular 20% para project management y algo menos para account management. El punto es adaptar el detalle del presupuesto según cliente y necesidades reales.
A veces el cliente quiere todo desglosado y eso consume recursos. Hay softwares que lo automatizan, pero en la mayoría de los proyectos es manual. Hay que sacar las horas del timesheet, ponerlas en una hoja de cálculo y hacer los cálculos. Toma tiempo y cuesta.
Si decides ir por un enfoque más ligero y no das todo el desglose, ¿cómo aseguras que vas bien? ¿Cuál es tu método más liviano?

Patrice Embry:

Antes, yo desglosaba las horas, el presupuesto por rol, y actualizaba proyecciones cada semana. Si dedicaba muchas horas, eso era lo primero que recortaba si el proyecto lo requería.
El primer paso era no ajustar cada proyección cada vez que actualizaba el presu en la hoja. Eso puede tomar mucho tiempo.
Lo bueno de hacerlo así es que ves los problemas antes y puedes alertar, pero cuesta tiempo. Hay otros modos de ver señales de alarma. Eso sería lo primero que dejaría de hacer.
También eliminaría los cálculos extra: review detallado, análisis por todos lados… Volvería a lo básico: ¿estamos en presupuesto? ¿Tenemos horas para lo que falta? ¿El % de completado se parece al % del presu usado? Sí, ok.
Sin complicar la hoja, solo usando lo esencial.

Ben Aston:

De acuerdo. Pero si gestionas un proyecto grande, con muchos recursos, hay que considerar el ritmo de consumo de presupuesto. Con un burn rate alto, cualquier desvío puede costar mucho en poco tiempo.
En equipos pequeños, esperar más antes de revisar los datos no es tan grave.

Patrice Embry:

Sí, igual reviso todo cada semana, pero no analizo al detalle; lo tomo más a valor nominal. Hay clientes o agencias para las que trabajas que simplemente te pagan y no les importa si te pasas. Eso parece genial, pero si no tienes parámetros, todo se puede desbordar. Aunque no lo pidan, hago mi propio presupuesto. Es responsable y muestra a todos lo que se hace y cómo. Incluso si dicen que el dinero no importa, yo tengo que saber que todo va bien.

Ben Aston:

Sí, esas frases de “el dinero no importa”, o “no pasa nada si nos pasamos del presupuesto”, son peligrosísimas.

Patrice Embry:

Sí, luego ya ni te das cuenta, y todo el mundo sigue sumando horas y puede ser caótico. He estado en proyectos así y es terrible.

Ben Aston:

El punto en que el equipo dice, “nos pasamos hace tres meses.”

Patrice Embry:

Entonces, ¿qué más da?

Ben Aston:

Y la gente sigue sumando horas y la situación empeora. Cuando quedan cero al presupuesto, ¿pongo números negativos?
Alguien tiene que llevar el control. Tocamos el tema de informes de estado en tu artículo: ¿cuán exhaustivo debe ser un informe de estado? Normalmente pongo info sobre presupuesto, lo que se hizo, lo próximo, riesgos. Puedes poner cualquier cosa en un status report.
¿Cómo decides qué incluir?

Patrice Embry:

Creo que a veces sentimos que los informes reflejan nuestro valor. Si el informe no es robusto, ¿no soy buen gestor?
No quiero que me digan: “¿Qué haces con tantas horas?”. Por eso, a veces sobrecargamos informes para demostrar nuestro valor o el de la agencia, pero lleva tiempo y quizá no sea necesario.
En el proyecto de la app, a mi clienta solo le importaba si todo iba bien, si llegaríamos a la fecha y si estaba atrasando algo. Ni siquiera iba a las reuniones porque estaba ocupada. Así que yo hacía informes completos y pensé, “¿para qué hago esto?” Escribía secciones de lo que hicimos, lo que haríamos, pero a ella no le importaba.
Me gusta pensar que confiaba en mí, pero creo que solo estaba ocupada. Pero confiaba en que yo manejaba todo.
Ese es solo un tipo de cliente. El punto es pensar qué quiere tu cliente en ese proyecto y no llenar el informe solo para mostrar tu valía. Puedes omitir muchas cosas si te centras solo en lo esencial.

Ben Aston:

Muy buen consejo. A veces, partimos de un informe anterior y solo cambiamos el nombre y fecha, y vamos reusando y sumando cosas que pidieron clientes viejos. El status report se infla y el cliente nuevo quizás ni quiera tanta información.
Hay que pensar en lo mínimo desde el inicio. Si piden más, se agrega. Pero confiar en que con lo básico basta. Si te toma horas hacer un informe, es señal de que algo está mal.

Patrice Embry:

A veces me piden agregar info, y yo aclaro: presupuesto mi tiempo para estos informes y si quieres que agregue cosas, será mínimo media hora o una hora más por informe. No parece mucho, pero a largo plazo suma muchas horas y reduce tiempo del proyecto. ¿De verdad quieres eso? Casi siempre dicen, “Hazlo una vez y vemos” o “no es tan importante solo tenía curiosidad”. Así puedes convencerlos.

Ben Aston:

Totalmente. Si explicas la consecuencia: “si quieres una hora más a la semana durante 25 semanas…”

Patrice Embry:

¿De verdad lo quieres?

Ben Aston:

“…¿sabías que eso costará cinco mil?” “Ah, no vale tanto.”

Patrice Embry:

Exacto.

Ben Aston:

Ok, mejor no lo hagamos. Eso sí, si es un proyecto riesgoso o difícil, no hay que recortar tanto como para no cubrirse.
Si algo sale mal, hay que tener evidencia de que advertimos.

Patrice Embry:

Absolutamente.

Ben Aston:

Eso es importante.

Patrice Embry:

Creo que la regla para eso es que solo elimines algo si tienes confianza total, si puedes volverlo a poner fácilmente y si tu experiencia lo justifica. La confianza viene de conocer al cliente, el tipo de proyecto, tu experiencia. Deja que tu criterio te guíe para no omitir algo esencial.

Ben Aston:

Correcto. Ahora, hablas de ceremonias scrum. Cuando hacemos scrum, hay ceremonias: planning, review, retros. Pero si en cada iteración, cada semana, dedicas un día o dos a estas ceremonias, consume mucho tiempo.
Mencionas que no tenemos que hacerlas todas siempre o que pueden fusionarse.

Patrice Embry:

Hay puristas de Scrum que se molestan si sugieres cambios. Pero incluso los scrum masters certificados creen que solo hay que hacer lo necesario.
Si tienes grooming, luego planning, luego revisión, en días distintos, puede volverse pesado rápido si no tienes presupuesto.
Si tienes tiempo y recursos, ok, hazlo. Si no, intenta juntar grooming, planning y revisión. Puede ser útil porque aprovechas la inercia de una para la siguiente.
Si parece que gastas tres horas en algo que se puede resolver en una hora y cuarto, revisa eso.

Ben Aston:

Ese consejo de juntar ceremonias según convenga es útil. Sobre las retrospectivas, la idea es mejora continua y adaptación. Has mencionado en tu artículo la importancia de mantenerlas ligeras. Yo he hecho retros donde se manda encuesta y se saca estadísticas: “el 49% cree que fue un desastre, el 25%…” pero, ¿realmente sirve?
Vale más fusionar y hacer lo justo. Si todo fue bien, sigue adelante.

Patrice Embry:

Todo bien, pulgar arriba.

Ben Aston:

Exacto. No tiene sentido sobre-diseñar informes si vas bien.

Patrice Embry:

Sí.

Ben Aston:

Mejor sé pragmático: “Vamos a terminar el proyecto.”

Patrice Embry:

Sí. Así como los informes parecen justificar nuestro valor ante el cliente, las retros parecen justificarlo ante directivos u otros internos. Así que, pregúntate: “¿Esto vale cinco horas de mi trabajo, o dos, o treinta minutos?” Si solo tienes media hora, identifica lo esencial y sigue.

Ben Aston:

Genial. Por último, hablemos de reuniones de arranque. En tu artículo sugieres que, a veces, un email basta. Nunca lo hice, pero, ¿cómo te funcionó enviar solo un correo diciendo: “Esto es lo que hay que hacer”?

Patrice Embry:

Sí.

Ben Aston:

¿Nos vemos en una semana?

Patrice Embry:

Sí. Sé que suena raro, pero empecé a hacerlo cuando trabajaba en una agencia farmacéutica, donde hacíamos muchas veces el mismo tipo de proyecto para diferentes clientes. No era fórmula, pero tampoco había muchas novedades. Funcionaba bien para proyectos impresos.
Los equipos casi siempre eran los mismos: dos diseñadores, un programador, dos account managers, todos sabían su función. Eso es algo que haría normalmente en una reunión inicial, pero ya era sabido.
Todos conocían al cliente y el proceso. Así que, en vez de perder 30 minutos en una reunión repitiendo lo mismo, enviaba los puntos críticos por email: qué diferencia este proyecto de otros iguales, el cronograma, y los primeros pasos.
Era más eficiente para todos y a nadie le incomodaba no tener que oír lo de siempre.
Si tienes proyectos así de repetibles y el equipo es siempre el mismo, quizá puedas reemplazar el kick off por un correo. Lo hice muchas veces y funcionó bien.

Ben Aston:

Creo que puede funcionar cuando el proceso es repetible. En mi caso, casi siempre hay alguien nuevo o algún elemento extra. Pero lo importante es pensar: “¿Hacemos esto solo porque siempre se hace?”; en vez de eso, preguntarse qué necesita saber el equipo para comenzar.
A veces los templates de briefing hacen que copiemos y peguemos lo mismo de la semana anterior, cambiando tres palabras.
Si tienes el mismo equipo, revisa cómo los informas y duda de invertir tiempo repitiendo información que ya se sabe.

Patrice Embry:

Correcto.

Ben Aston:

Enfócate en: “Esto queremos lograr. Esto tienes que hacer. Estas son las tareas.” Sin ser excesivamente rígidos ni repetir proceso por costumbre. Para mí, la gran enseñanza de hoy es: trata cada proyecto como algo único. Solo porque antes dedicaste esfuerzo y rigor, no tienes que aplicarlo igual siempre. Se puede personalizar según el proyecto.

Patrice Embry:

Totalmente.

Ben Aston:

Muy bien, Patrice. Muchas gracias por acompañarnos. Si quieres sumarte a la conversación, comenta en el post de Patricia o ve a la sección de comunidad de thedigitalprojectmanager.com para debatir allí. Hasta la próxima, gracias por escuchar.