Cómo sacar a tu equipo del infierno de la documentación de procesos usando IA y automatización

Lee la transcripción:

Estamos probando la transcripción de nuestros podcasts con un programa de software. Por favor, disculpa cualquier error tipográfico, ya que el bot no es 100% exacto todo el tiempo.

Galen Low: Bienvenidos a nuestro panel sobre cómo sacar a tu equipo del infierno de la documentación de procesos usando automatización, IA y otras tecnologías. Hacemos eventos como estos una vez al mes para que nuestros miembros e invitados VIP puedan interactuar directamente con los expertos que contribuyen y colaboran con nosotros en The Digital Project Manager.

Para quienes no me conocen, mi nombre es Galen Low. Soy cofundador de The Digital Project Manager y su anfitrión de hoy. Y también me acompaña un increíble trío de expertos en operaciones de agencias — Alyson Caffrey, Gray Mackenzie y Brian Kessman. Empecemos.

Hoy exploramos las realidades prácticas de si la automatización con IA y otras tecnologías pueden ayudar a eliminar ese dolor de documentar y reforzar tus procesos para que tus equipos puedan finalmente funcionar de manera consistente, predecible y eficaz, todos esos buenos adverbios. Diría que la mayoría de los equipos en agencias, y también en otras organizaciones, son realmente malos estandarizando procesos operativos y de proyectos y documentándolos.

Quizás es porque ven cada proyecto o miembro del equipo como algo diferente, como copos de nieve únicos. Quizás porque quieren fomentar una cultura de construir el avión mientras lo vuelan. O tal vez tengan una especie de alergia interna a la estandarización. Muchas veces, las intenciones son buenas y el mayor bloqueo es el tiempo. Para las agencias, es tiempo no facturable que deja dinero sobre la mesa.

Para los pequeños negocios es un costo de oportunidad. Para cualquier equipo, es tedioso, aburrido y repetitivo. Sí, casi siempre hay algo, ¿verdad? Usualmente hay una wiki, pero a lo mejor no está actualizada, o hay un montón de grabaciones de pantalla esperando ser transcritas, mejoradas o convertidas en documentos completos.

Y a veces, el proceso honestamente es sólo tradición oral que pasa de persona a persona sin ningún registro escrito. Pero el problema es: sin una buena documentación de los procesos, tu equipo estará perdido, tus interesados estarán confundidos y tu organización no podrá escalar hacia sus objetivos.

Así que realmente la pregunta que quiero debatir y explorar hoy, no como una lección, sino como una conversación, es ¿por qué no existe una mejor manera en esta era de tecnología impulsada por IA y automatización de procesos para que la documentación de procesos y su adopción sean más mágicas o automáticas? ¿No hemos llegado ya a ese punto? Sospecho que la respuesta es sí y no, pero me gustaría que profundizáramos.

Comencemos con la gran pregunta, que es ¿por qué resulta tan doloroso crear documentación de procesos y procedimientos operativos estándar en agencias y otras organizaciones? Aly, ¿quieres empezar tú? Tú tratas con muchas personas con dolor de procesos.

Alyson Caffrey: Oh sí, hacemos mucho trabajo de documentación en Operations Agency. Creo que lo que a la gente le cuesta entender es que no es un proyecto de una sola vez, ¿verdad? No puedes simplemente abordar este proyecto una vez y pensar que no tendrá que actualizarse, refinarse o mejorarse con el tiempo. Así que normalmente hay un proceso de tres fases en el que suelo evaluar si un proceso es bueno o no.

La primera es que necesitamos entender que podemos estar en estas tres fases. Y sólo cuando sabemos en cuál estamos, podemos crear documentación de forma efectiva o trabajar para pasar a la siguiente categoría. Así que el ciclo es: primero pruebas algo. Digamos que uno de los procesos clave de cualquier negocio es ¿cómo generamos clientes potenciales? Usemos ese ejemplo. Lo primero es preguntarnos, ¿estamos en la fase de pruebas de este proceso? ¿Estamos lanzando ideas a ver cuál nos da los mejores leads y prospectos de mayor calidad?

La segunda fase es la de ajuste. A lo mejor ya encontramos una forma bastante buena, pero tenemos que trabajar en el texto o en la plataforma donde lo publicamos. Entonces, ¿estamos en la fase de ajuste? Y la tercera fase es la de operacionalización y la de amplificación. Así que primero lo operacionalizas y luego puedes escalarlo, ¿verdad?

Creo que mucha gente piensa que ya está en la fase de operacionalización, se pone a documentar su proceso y luego se da cuenta: en realidad estoy en la fase de pruebas. Por eso, cuando vi que mencionaron “vida útil” en el chat, pensé: sí, la vida útil sufrirá si estás en fase de pruebas porque tendrás que actualizar constantemente las mejores prácticas y las formas de hacer las cosas.

Por eso, antes de ponerte a documentar, debemos ver los cuatro procesos principales del negocio: ¿cómo conseguimos prospectos? ¿cómo los convertimos? ¿cómo cumplimos con las promesas que hacemos a los clientes? ¿cómo mejoramos? Esos son los cuatro grandes ejes.

No hay que complicarlo. Luego nos preguntamos: ¿estamos probando cómo conseguir leads? ¿estamos probando mecanismos de conversión? Si la respuesta es sí, entonces quizá tengamos que trabajar un poco más antes de escribirlo todo.

Galen Low: Me encanta eso. Y lo veo mucho, soy culpable también.

A veces pienso: estamos probando esto, mejor lo anoto para que podamos... no sé, hacerlo mejor. Y luego, seis meses después, veo el documento y ni siquiera terminé una frase. Era una buena intención, pero no era el momento adecuado. Me gusta que lo hayas desglosado en partes del negocio, no para simplificar demás, sino para reducir la sobrecarga de “documentemos hoy todo lo que hacemos en la empresa”.

Alyson Caffrey: Sí. Porque si documentas hasta la temperatura de la sala en una llamada de ventas, ya es demasiado. Hay que limitar. Así que ánimo, mi respuesta sería: primero evalúa en qué etapa estás y si la documentación es solo un sueño o en realidad puedes hacerla. Y por supuesto, no te extremes en ningún sentido.

Porque si eres nuevo en esto de documentar procesos, debes mantener las cosas ligeras y ágiles como recurso.

Galen Low: Brian, me pregunto si tienes algo que añadir. Sé que trabajas sobre todo en modelo operativo y estrategia para agencias. ¿Dónde encaja la documentación de procesos y cómo lo planteas a tus clientes sobre cuándo es importante, cuándo será doloroso o quizá cómo no lo será?

Brian Kessman: Cuando un cliente me contacta y empezamos a hablar de procesos, tengo que devolverle la conversación a la estrategia general de su organización porque es el proceso lo que realmente hace vivir esa estrategia.

Y entonces hay varias cosas. Creo que al principio preguntaste: ¿por qué resulta tan doloroso? La documentación de procesos es tan dolorosa en las agencias porque hay ciertas piezas que deben ponerse en su lugar siquiera para que sea posible. Lo veo constantemente: si la estrategia del negocio de una agencia es que “somos una firma para todo tipo de clientes y hacemos todo tipo de trabajos”, nunca va a haber un proceso estandarizado en ese entorno, ¿verdad? Lo he visto muchísimas veces. Porque pasa que los servicios se reinventan una y otra vez, cada proyecto es diferente, se reinventa la rueda, todo eso. ¿Cómo podrías tener un proceso para eso?

Incluso si lo intentas, va a cambiar igual. Eso solo genera frustración, agotamiento y todo lo que ya sabes. Pero hay más factores, como el propio modelo de negocio de las agencias, que en realidad a veces va en contra del éxito propio. Si la agencia sigue usando un modelo basado en horas de trabajo, vendiendo horas facturables, la cultura y prioridades estarán influidas por la utilización facturable.

Siempre se trata de sacar el trabajo adelante, no de procesos internos, priorizando las necesidades del cliente. Otro asunto es la estructura de equipo, que complica aún más. La estructura tradicional que veo frecuentemente favorece la mentalidad y comportamientos equivocados.

Por ejemplo, en las firmas tradicionales entra trabajo nuevo y se asignan personas de distintas disciplinas: se busca a quién está disponible o es ideal para el proyecto, el modelo de “casting de Hollywood”. Pero cada proyecto tiene sus propias reuniones, que se multiplican y con ellas la carga en comunicación. Mientras, en equipos fijos —o modelo pod— el equipo se mantiene junto de un proyecto a otro, lo que genera mayor sentido de equipo y enfoque en trabajar mejor juntos.

Así hay menos resistencia al proceso que en equipos temporales. Se genera mayor involucramiento y propiedad. Porque van a seguir trabajando juntos. ¿Cómo logramos mejorar nuestra dinámica? Todos invierten en eso.

Creo que esos son algunos elementos clave y esa es mi perspectiva.

Galen Low: Me encanta porque he trabajado en agencias y organizaciones de todo tamaño. Lo más complicado es implementar un proceso de manera general.

Y habría que hacerlo si los equipos fueran siempre temporales, cambiantes. ¿Cómo conseguimos que todos hagan las cosas igual? La respuesta es: en ese modelo, nadie lo hace realmente. Pero si el proceso lo define el equipo, es responsabilidad de todos cumplirlo, documentarlo, ejecutarlo.

Y no hace falta evangelizar al resto de la organización: es algo más local y menos doloroso de definir.

Brian Kessman: Sí, aunque sigue habiendo una capa básica en la estructura de la agencia, como que todos tengan que usar el mismo sistema de gestión de proyectos para colaborar, pero luego está la cultura y proceso a nivel de equipo. ¿Cómo se crea esto?

Galen Low: Me encanta.

Me imagino que los tres se encuentran con clientes o conocidos que simplemente quieren luchar, les da pereza invertir tiempo en su ecosistema de procesos.

¿Cómo explican el valor de esta inversión de tiempo a los escépticos? Sé que sale mucho en conversación: “no necesitamos esto, Gray, parece una pérdida. ¿No podemos enchufar la máquina, encenderla y empezar a ganar más?”

¿Cómo comunican el valor de este esfuerzo?

Gray Mackenzie: La razón por la que esto parece un infierno o no encontramos tiempo es porque no le sacamos valor. Rara vez los dueños dicen: “estas llamadas de ventas llevan mucho tiempo, no tengo tiempo para ellas”. No, porque vemos el valor de una llamada de ventas. Pero la mayoría nunca ha experimentado el valor de procesos bien hechos, donde realmente puedes delegar cosas. Aly, quiero volver a ti con la pregunta de cuándo sabemos que estamos en la fase operacional/amplificadora. Tenemos ideas sobre cómo identificar si podemos escalar o no. Pero esa es la razón por la que cuesta valorar esto, porque no han experimentado el beneficio de tener procesos fáciles de desplegar, de delegar rápidamente y ahorrar tiempo.

Al final, si se hace bien, obtienes valor en dos frentes. Por eficiencia: podemos hacer las cosas más rápido, o aunque más lento, con una estructura laboral más rentable. Y la otra es: ¿cuál es el resultado? No eficiencia sino eficacia, es decir, cuán efectivo es lo que hacemos. Es evitar el dolor de perder un cliente porque repetimos errores pasados.

Así que al exponer el valor, me enfoco en alguna de esas dos áreas, o ambas. Todos experimentan componentes diferentes, por eso trato de indagar con ellos cuál es el que más duele y así motivarlos.

De cualquier forma tienes un proceso. El proceso está, sólo que no documentado. Todos tienen procesos distintos, pero existe. Estás pagando el precio de no hacerlo por adelantado o pagas con consecuencias después. Puedes elegir dónde quieres el dolor y el pago, pero pagarás igual. Y realmente, no se trata de si tienes que hacer esto con ZenPilot o no, sino que el proceso tiene sentido para ti y decides qué te motiva.

Intento ayudar a que la gente se motive para que tome ese paso e invierta donde corresponde.

Galen Low: Sabía que irías al tema de atribución: la gente no ve el beneficio directo de procesos bien diseñados y documentados, pero no había pensado en lo otro: muchos nunca hemos visto cómo es el “bien hecho”, aunque el dolor lo sentimos.

El dolor es real y podríamos llegar a lo bueno que lo resuelve. Me gusta esa orientación de medición: todos tenemos historias de clientes que se fueron, pero ¿medimos el beneficio de las mejoras de proceso?

Me gusta que se lo hayas lanzado a Aly y quiero llevar la conversación ahí antes de entrar en lo más práctico. Me interesa la pregunta del umbral: ¿cuándo pasas de prueba a la siguiente fase y luego a la operacionalización? ¿Cuándo es el momento para escribirlo?

Alyson Caffrey: Gran pregunta, Gray. Sinceramente, me la hacen mucho. Voy a contar una historia primero y luego seré un poco más táctica.

En el instituto, llevaba las estadísticas del equipo de baloncesto. Aprendí mucho porque nunca fui jugadora, mido 1,57m, nunca fui buena jugando. Siempre quise, me encanta mirar baloncesto y participar. Tomábamos las estadísticas, se las pasaban a los entrenadores y ellos luego ajustaban el modo de entrenar al día siguiente.

Creo que es una gran analogía: si pasamos de pruebas a ajustes en el proceso, primero necesitamos medir el impacto de esos cambios. Ya sea reducir el coste por lead, aumentar el valor vitalicio o el margen bruto en los proyectos.

Esos son tres componentes clave: si pruebo algo y hago cambios, vigilo esos tres grandes números (o los que quiera que mi proceso afecte). Y cuando veo que este modelo en particular ayuda a retener clientes o aumentar beneficio, ahí toca documentarlo porque ya he comprobado la mejora con los indicadores del negocio.

Otra cosa importante: Kobe Bryant decía: nunca te aburras de lo básico, hay que hacer las repeticiones. Muchos creemos que si el cambio no funciona al principio es porque no le dimos suficiente tiempo, no vimos si cambia la agencia con el tiempo.

El síndrome del objeto brillante: todo parece mejor fuera. Pero siempre animo a los dueños a conectar mejora de procesos con métricas reales y luego darte suficiente margen de tiempo para ver si funciona.

Suelo usar 90 días. Es un período elegante, un trimestre; así suelen medirse las cosas. Soy fan de “dale 90 días y observa”.

Galen Low: Me gusta la idea de que todos tenemos proceso porque hacemos algo, pero no deberíamos documentarlo hasta saber si funciona.

Y para saberlo: dar tiempo suficiente y ser intencionados con la métrica antes de dedicarnos compulsivamente a escribir procesos sin saber su eficacia.

Quizá podríamos hablar de consejos y buenas prácticas, pero antes ¿qué herramientas y tecnología usan ustedes con sus clientes para eliminar el dolor de crear procesos?

¿Funcionan esas herramientas o a veces los frenan y es mejor no usarlas? Aly, empiezo contigo porque vi el webinar la semana pasada donde dijiste algo interesante: "Graba tu pantalla". Ya lo decías hace tres años. Y ahora la IA lo está cambiando todo: ya no es sólo grabar la pantalla. ¿Puedes contarnos cómo funciona para tus clientes tomar una grabación de pantalla y convertirla en un proceso usable y consultable?

Alyson Caffrey: Sí. Y Loom, si me escuchan, patrocínenme. Soy superfan de Loom. Loom acaba de lanzar hace pocos meses una función de IA para crear documentos y demás. Personalmente, es mi lugar favorito para documentar procesos, al menos al principio.

Las dos razones que amo: permiten acotar la experiencia de documentar. Primero: si no tienes procesos ni tiempo para crearlos, seguramente trabajas en tu negocio. Si puedes aprovechar ese tiempo grabando la pantalla para mostrar cómo consigues resultados, aunque el proceso no sea perfecto, alguien puede tomar ese vídeo y replicarlo.

O puedes conseguir que la IA genere un documento y que después otros puedan replicarlo, aunque no sea perfecto ni aún escalable, si seguimos en fase de pruebas. Ese es el primer extremo. El otro extremo, igual de importante, es que al usar IA para crear procesos —usamos mucho Scribe—, yo uso Loom con IA porque se ajusta a mi flujo, pero al escribir procesos creo que la IA organiza y categoriza muy bien los pasos, haciéndolos fáciles de leer y seguir. Pero el verdadero secreto, sobre todo para agencias que quieren crecer rápido, es mantener la calidad como prioridad.

Podemos describir un proceso, pero alguien puede hacerlo de cualquier manera; hace falta, usando la definición de Tony Robbins, especificar el "definido como terminado", es decir, cómo debe quedar el resultado final. Un vídeo ayuda mucho a mostrar cómo debe verse —por ejemplo, un wireframe de sitio web. Tener ejemplos da contexto de calidad a la agencia. Así que Loom todo el día.

Cuando tengas dudas, usa Loom, es mi opinión.

Galen Low: ¿Limita en algún sentido Loom? Pienso en: a) la parálisis de no documentar hasta tener el wireframe perfecto que sirva de benchmark en Loom; b) gente que no quiere salir en cámara o ser grabada. ¿Qué pasa entonces?

Alyson Caffrey: No hace falta salir grabado, puedes grabar solo la pantalla y hablar.

Otra cosa: la operación no existe para llenarnos de trabas, sino para mostrar cómo rebotamos y arreglamos lo que rompemos para que nada se pierda, dejar una base sólida. Porque es absurdo pensar que por años no encontraremos una forma mejor de hacer algo. Siempre buscaremos mejorar, los procesos se actualizan y cambian. Por eso prefiero cambiar un Loom cuando encuentro una mejora, en vez de todo el proceso de actualizar un procedimiento, llevarlo a la base de conocimiento y hacerlo rodar al equipo.

Eso es para los procesos en fase tres, los que queremos amplificar y entrenar como buenas prácticas. Loom sirve como incubadora para compartir ideas y que otros colaboren.

Galen Low: Me encanta.

Brian, ¿alguna otra herramienta o truco tecnológico que recomiendes para que tus clientes capturen sus procesos?

Brian Kessman: En mi caso, ayudo de dos formas. Primero, configurando un consejo de IA en la agencia para definir su estrategia y política tecnológica, expectativas de calidad, seguridad de datos y elegir las herramientas adecuadas.

Segundo, no documento el proceso por ellos, sino organizo sesiones de trabajo para captarlo del equipo, promoviendo así el sentido de pertenencia, y oriento a alguien para que construya la documentación.

Hay dos categorías: ¿es documentación para personas o para máquinas (automatización)? Para personas, debe ser fácil de consumir. Aquí usamos GPTs personalizados o asistentes de OpenAI, que son muy útiles para redactar procesos a partir de sesiones de trabajo o entrevistas, organizando análisis e ideas. Hay plataformas como ClickUp, Monday.com, Notion, todo tiene IA integrada ya. ¿Hace falta realmente más herramientas?

Por el lado de vídeo, Loom es excelente. No conozco todas sus posibilidades, pero otra herramienta útil es Tango: grabas pantalla y genera capítulos y documentación. Scribe también, alguien lo mencionó en el chat. Si eres product manager, ChatPRD sirve para requerimientos de producto y puede usarse para otros fines. Jasper es para marketing. Todo eso es para personas. Pero luego está el lado de máquinas. OpenAI y otros publicarán agentes autónomos a fin de año o a inicios del próximo. Los agentes pueden seguir flujos de trabajo y combinarse para completarlos.

Copy AI es excelente para ventas y marketing. Make.com es para flujos generales y writer.com también automatiza flujos. Todas son herramientas potentes. Así lo clasifico.

Puedo seguir contando...

Galen Low: Nunca los había agrupado mentalmente así: procesos para humanos y para máquinas. La automatización es documentar pasos, pero me gusta esa idea de crear la experiencia tanto para quien ejecuta (humano) como para “quien” ejecuta (máquina).

Y sí: ahora la red se llena con lo de los agentes que van a quitarte el trabajo, etc. Pero me gusta pensar cómo prepararse para alimentar esos agentes.

Brian Kessman: Y lo bueno es que en realidad no es tan diferente, ¿verdad?

Al hablar o escribir para la IA, lo haces igual que para un humano: defines expectativas, das insumos, muestras ejemplos de calidad. Es natural. Lo más complicado es cómo dividir las tareas entre agentes. Y hay que aprender la interfaz, pero es sencillo: en medio día se domina.

Galen Low: ¿Sigues algún criterio para decidir lo que debe ser proceso humano y lo que debe automatizarse?

Brian Kessman: Sí, empiezo pensando quién seguirá el proceso: ¿Es predecible? ¿No requiere orientación? ¿Puedes definir insumos y resultado claramente? Si sí y se puede completar de principio a fin, veamos si se puede automatizar. Siempre hay revisión humana, pero puedes crear un agente que haga una revisión inicial y luego te lo pase. Y lo otro: ¿requiere confianza? ¿Experiencia única? ¿Matices o sensibilidad? Así decides qué conviene automatizar.

Galen Low: Cambio de enfoque: ya que Brian mencionó la mejora continua y la adopción, ¿cómo logran que la gente acceda y use la documentación cuando la necesitan? ¿Alguien tiene un chatbot de procedimientos? Gray, ¿tú qué opinas sobre tener la documentación a mano para facilitar adopción y uso?

Gray Mackenzie: Ese es uno de los grandes motivos de la falta de valor. Es: “lo escribí, lo guardé en una carpeta y ni lo revisé después”. Soy fiel creyente de que el proceso debe convivir donde se hace el trabajo. Uno de los pilares de nuestra metodología en ZenPilot es que, si asignamos un trabajo, el procedimiento debe estar enlazado directamente en la tarea (por ejemplo, en ClickUp). Así que enlazar procesos en las tareas ayuda mucho. Lo demás es cuestión de hábitos. Puedo hablar de un GPT personalizado, pero mucho es cultura: toleramos lo que permitimos y celebramos.

Si permites que alguien haga las cosas en otro orden, o pregunta por Slack en vez de revisar el sistema de gestión de proyectos, toleras la no adopción, y vendrá más. Todos los hábitos cuestan al principio y después se automatizan; hay que dejar de tolerar el no uso y celebrar la consistencia.

Y evaluar por qué no se sigue: ¿es que el proceso es malo, complejo? Hay que hacerlo simple y útil (Aly y Brian también lo decían). Si me dan un Loom de seis minutos, la primera vez lo veo, pero después sólo quiero puntos clave y marcas de tiempo. Así que usar Loom para documentar inicialmente está bien, para la primera vez o si ha pasado tiempo, pero combínalo con puntos rápidos y la marca de tiempo. Hazlo accesible, que viva donde se trabaja, y celebra los avances, sobre todo si el proceso mejora el margen bruto (clave en casi todos nuestros clientes).

Galen Low: Yo soy esa persona. Me siento aludido… celebro la inteligencia del equipo aunque no sigan el proceso, pero eso no significa que no sean inteligentes por seguirlo.

Quiero proceso para que, cuando crezca el equipo, no haya caos. Y debo resistirme a celebrar sólo el instinto, pensando a largo plazo, pues si tengo 27 personas brillantes que hacen lo mismo de 27 formas, sí que será un problema.

¿Podemos hablar del GPT personalizado? Ahora me interesa. Lo mencionaste.

Gray Mackenzie: Sí. Hay varios útiles para nosotros, pero uno sencillo es ayudar a transformar procesos en flujos accionables en ClickUp. Por ejemplo, el entregable es una tarea padre y los pasos son sub-tareas, con un método para gestionar carga de trabajo, capacidad, asignaciones y estimaciones de tiempo. Así que creamos un GPT personalizado: le pasas una captura de plantilla y te pone una nota del 1 al 10 y te dice qué cambiar.

Las convenciones de nombres son muy importantes: el entregable debe ser un sustantivo, cada tarea comienza con un verbo, debe haber estimación de tiempo y dependencias. El GPT señala las incoherencias y mejora lo que sea necesario. Así puedes formar a varias personas para crear procesos, no sólo hacer una revisión global cada seis meses y que quede obsoleto; el equipo puede aportar y aunque no lo hagan perfecto al primer intento, el GPT ayuda a mejorar.

Galen Low: Me gusta mucho.

¿Y para los demás panelistas? ¿Cómo garantizan que la documentación se actualiza y siempre refleja la realidad?

Brian Kessman: Sobre la actualización: hace falta un proceso de mejora continua y cultura para sostenerlo. ¿Conocen el NotebookLM de Google? Se puede subir muchísima documentación y te permite crear, entre otros, un índice o una guía de estudio, incluso un podcast (!) sobre tus procesos. Es útil, es un sistema RAG (generación aumentada por recuperación) y permite con facilidad desactivar lo viejo y activar nuevas versiones, etc. Muy útil para ese propósito.

Galen Low: Aly, pensando en el lado Loom y los “bookends”: cuando toca actualizar ¿es otro Loom o editar texto? ¿Cuál es la fuente de verdad para ajustar documentación basada en vídeo?

Alyson Caffrey: Siempre es ideal grabar un vídeo nuevo, pues alguien estará haciendo el proceso de nueva manera. No tienes que ser tú. Puede ser una persona del equipo que lo hace mejor. Y eso aumenta la adopción, porque hay dos razones principales por las cuales los equipos no siguen o no actualizan cosas: una, nadie les recuerda con constancia (en un libro reciente de Patrick Lencioni se recomienda ser el “Chief Reminding Officer”); si no recae en el fundador, debe recaer en alguien: un responsable interno de SOPs o conocimiento. Así se asegura repasar y recordar la actualización, tanto de video como texto.

Segunda: no se ha pintado la posibilidad. Por ejemplo, medimos datos pero el equipo quizá no se preocupa por el margen de beneficio, sino por su calidad de vida, irse de vacaciones, no tener que entrenar a cada nuevo miembro uno a uno. Así que señalar esos beneficios es clave: si quieres ascender de colaborador a manager, o de manager a director, mucho pasa por la repetibilidad y documentar, tener tu propio “Google”.

El poder de Google es tener muchos contribuyentes, no sólo una opinión. Así tu base y procesos serán más sólidos con más aportes a medida que creces. Hasta que tienes unos 70 empleados (lo he visto en 10 años de agencias), documentar procesos es responsabilidad parcial de todos más que un solo departamento. Si tienes 30 en el equipo, que el 10% de tu rol implique mejorar o documentar procesos claves para tu puesto.

Galen Low: Me encanta lo del “Google de tu empresa” y tener muchos contribuyentes: que las buenas ideas sean visibles.

Vamos a preguntas. La primera trata sobre mantener la agilidad.

Pregunta: ¿Qué soluciones han emprendido para ser ágiles al mismo tiempo que establecen parámetros para que las nuevas contrataciones tengan un buen punto de partida? Me parece muy importante porque justo hablamos de tener un “Google” para la empresa: ¿cómo saber cuál es el proceso correcto? ¿Cómo queda claro? ¿Cómo ser ágiles sin caer en el caos?

¿Alguien quiere contestar?

Brian Kessman: Principios operativos. Hay que empezar por ahí: ¿cómo trabajaremos juntos? Se pueden adoptar muchos principios de Agile, adaptados al entorno creativo según las limitaciones de Agile para el proceso creativo. También se puede aprender de Lean: eliminar desperdicio, definir el proceso mínimo viable, priorizar sólo los que impactan ingresos o experiencia de cliente. Así se empieza.

A nivel de equipo, es útil tener una carta de equipo (team charter): una especie de acuerdo social informal sobre cómo trabajar juntos. Busca ejemplos en Internet; suelen tener 20 preguntas que el equipo puede responder, empieza por las cinco más importantes y tras cada retrospectiva evalúa si hace falta añadir más. Así mantienes agilidad y claridad.

Galen Low: Me gusta ese enfoque comunitario/chárter y enlaza con lo que decías sobre equipos dedicados en vez de temporales, y con lo que decía Aly sobre la copropiedad. Así, al incorporar a alguien, pueden repasar juntos valores y formas de colaborar.

Alyson Caffrey: Añadiría que, por lo que he visto, hay dos estándares clave para ser ágiles y tener resultados compartidos aunque el proceso sea difuso: establecer estándares de producción (por ejemplo, tiempos de respuesta, plazos) y de calidad (cómo se mide el resultado esperado). Muchos equipos lean sacan gran provecho de esto en vez de documentar todo el proceso intermedio. Definen estándares de producción y calidad y sobre eso trabajan.

Galen Low: Otra pregunta sobre herramientas: ¿qué piensan de Trainual o Scribe?

Gray Mackenzie: Conozco y aprecio a quienes crearon Trainual y Scribe. Son buenas herramientas de documentación, pero para la mayoría resulta ser una versión simplificada de una herramienta de gestión de proyectos con algunos añadidos. Creo que la mayoría de equipos debe elegir entre PM o gestión del conocimiento; hacerlas convivir suele causar problemas. Algunos equipos ligan desde la PM hacia la documentación y les funciona. Pero entre miles de equipos que hemos visto, los resultados (sobre todo en margen y eficiencia) son mejores cuando eligen uno u otro.

Galen Low: Yo sufro del “síndrome de demasiadas herramientas”, y es verdad que los PMs a veces ofrecen lo necesario, no hay que tener ambas necesariamente.

Brian, Aly, ¿qué opinan?

Alyson Caffrey: Soy partner en Trainual y lo adoro. Fuimos de los primeros socios certificados, llevo seis años trabajando con Trainual. Para empresas en rápido crecimiento, próximas a contratar o con fusiones y adquisiciones, ha dado un gran resultado porque todo se centra en acelerar la integración del personal. Cuando alguien se incorpora o fusionas organizaciones, hace falta un periodo de adopción y con Trainual usando tus procedimientos y centralizando info, es muy amigable.

Pero para pura documentación con IA, Loom y Scribe son excelentes si no vas a contratar masivamente. Scribe puede ser embebido en herramientas de PM, como decía Gray, y también creo en tener la documentación donde se realiza el trabajo. Debes estar a uno o dos clics de lo que necesitas en la organización. Si sabes que trabajas en cierta plataforma y desde allí se enlaza la documentación, genial. Estoy de acuerdo en separar PM para gestión de proyectos y documentación para documentación. Veo que tener ambas beneficia a muchos, pero hace falta establecer reglas claras sobre qué va a cada herramienta.

Galen Low: Me encanta. Eso enlaza con el tema de la carta equipo también. Vamos con dos preguntas rápidas. Una: ¿algún consejo de prompts para la IA que ayuden a construir procesos?

Gray Mackenzie: Yo solo indico el nivel de quien verá la documentación. Tomo lo que tengo y le pido: “si fuera un nuevo empleado en esta empresa que hace esto, ¿qué cambiarías en la documentación?” Eso ayuda en onboardings.

Galen Low: Me gusta. Brian, ¿tu recomendación?

Brian Kessman: No hay un prompt que sirva para todos. Depende del público y situación, como decía Gray. La clave son los principios: como si guiaras a alguien nuevo en tu oficina, sé específico sobre lo que quieres, para quién es, qué formato necesitas, da contexto y pide lo que buscas, incluso plantilla si tienes. Cuanto más concreto, mejores los resultados.

Galen Low: Me gusta que no sea un prompt para crear procesos de cero, estilo “actúa como agencia que quiere crecer”, sino uno adaptado al caso real.

Brian Kessman: Sirve mucho un prompt que ayude a escribir prompts para nuevos procesos, o que te pregunte lo que necesitas para crear el resultado adecuado, guiando tu pensamiento; eso sería práctico. Yo desarrollé uno como virtual chief pricing officer para ayudar a agencias con opciones de precios, y hacía justamente eso: preguntaba lo que necesitaba para cumplir la tarea. Así que apunten a eso.

Galen Low: Excelente. Finalizo aquí. Muchas gracias a nuestros panelistas por su tiempo y conocimiento hoy: Gray, Brian, Aly, fue un gusto, siempre disfruto conversar con ustedes. Feliz de tenerlos juntos en la misma sala. ¡Un placer!

Brian Kessman: Gracias por la invitación.

Alyson Caffrey: Gracias, Galen. Te lo agradezco.

Galen Low: Eso es todo, amigos. Si quieren unirse a la conversación con más de mil campeones de gestión de proyectos digitales, únete a nuestro colectivo en thedigitalprojectmanager.com/membership. Si te gustó lo de hoy, suscríbete y mantente en contacto en thedigitalprojectmanager.com. Hasta la próxima, gracias por escucharnos.