Caso Digix (con Repensar Educativo)

Contexto

Digix fue el aliado principal en el curso de Design Ops de Repensar Educativo. En el curso, se nos encargó aprender sobre sus procesos de trabajo y diseñar una solución que les ayude a agilizar su producción. Ellos son una agencia de marketing, enfocada principalmente en el sector salud. Hace unos meses, implementaron por primera vez la práctica de Design Ops dentro de su equipo, y necesitaban ayuda escalando la iniciativa y unificando los diversos procesos que trabajan para sus clientes.

Figura 1:

Investigación

Para entender más la necesidad del aliado Digix, mi equipo y yo tuvimos tres sesiones con diferentes miembros del equipo. En nuestra primera entrevista, conversamos con Heads y Líderes de Diseño y Contenido, quienes compartieron con nosotros los desafíos más apremiantes que enfrentan en su área.

En la segunda etapa de investigación, nos sumergimos en el mundo operativo, donde conversamos con diseñadores gráficos, expertos en UX, copywriters y directores de arte sobre su día a día en el trabajo. Durante estas conversaciones, emergieron nuevas oportunidades de mejora relacionadas a los entregables, fechas límite y la comunicación con otros equipos como los Project Managers.

Finalmente, cerramos este ciclo de entrevistas con los Project Managers, quienes desempeñan un papel crucial en la comunicación entre el cliente y el equipo de diseño.

A partir de toda la información que recopilamos, detectamos problemas en la entrega de información de equipo a equipo - desde el pedido inicial del cliente hasta la entrega del producto final. En general, los roles operativos en el área de diseño expresaron la necesidad de ciertos recursos previo a iniciar un proyecto e insatisfacción con la claridad de las directrices para iniciar sus labores. Por otro lado, las Project Managers transmitieron su satisfacción con el equipo de diseño, señalando que solucionan los problemas “sin entender cómo lo logran”, y en ocasiones, la falta de comunicación proviene del lado del cliente.

Entonces, ¿por qué esa discrepancia?

Figura 1:

El problema

Resumimos el problema en dos ideas principales: Cortocircuitos en la comunicación entre equipos, los cuales estaban causando pérdida y falta de información entre equipos en el momento de desarrollar proyectos.

Figura 2:

La propuesta

Para sellar las fugas de información que ocurrían durante el proceso, decidimos que debíamos atacar el problema desde el inicio con momentos durante el mismo para asegurar que no hayan habido problemas. La solución que ideamos consistió en implementar Definitions of Ready y Definitions of Done dentro del proceso de trabajo de Digix, además de documentación específica por cuenta. Debido a que el proceso de trabajo de Digix no es 100% ágil, decidimos que las definiciones podían ser implementadas en momentos clave del proceso ya existente.

El alcance

Debido a que el tiempo que tuvimos para desarrollar una propuesta era limitado, cerramos el alcance a solo la primera etapa del flujo de trabajo común de Digix. El flujo completo es confidencial, pero esta primera etapa cubría todos los pasos desde la entrega del cliente hasta la creación de la primera versión del entregable final. También, debido a la gran variabilidad de los proyectos que maneja Digix, elegimos su producto más común: Parrillas de contenido para redes sociales. Nos centramos en este por que pequeñas mejoras a este proceso representarían un alto retorno si implementadas.

Por otro lado, decidimos que cualquier solución que propongamos debería ser fácil de replicar y escalar por el equipo de DesignOps. Para asegurarlo, consideramos que la entrega incluiría documentación sobre cómo llegamos a crear el producto final y la gobernanza de cada etapa.

Definition of Ready & Definition of Done

Segun la empresa Atlassian,

Una Definition of Ready (DoR) le permite evaluar el trabajo antes de que el equipo comience a realizarlo. Este, define una tarea, historia de usuario o punto de historia para el equipo. Solo cuando todo el equipo comprenda el alcance del proyecto, este se podrá mover del backlog a un estado activo.

Obtenido de “What is Definition of Ready” en Atlassian.com

Un DoD es un conjunto de criterios que debe cumplir un incremento de producto para que el equipo lo considere completo y listo para los clientes. Al definir claramente lo que significa «hecho» para el proyecto, un equipo puede centrarse en ofrecer valor en cada sprint y minimizar el retrabajo.

Tomado de “Definition of Done” en Atlassian.com

Nuestra propuesta se basó en la implementación de estas dos definiciones dentro del proceso de trabajo de la empresa. Primero por los P.Ms del proyecto, antes de asignar las tareas al equipo de diseño seleccionado, y después como parte del checklist usado para finalizar una tarea. Esta organización y asignación se podría realizar mediante la plataforma Cor, a la cual el equipo ya estaba adaptado. Según nuestra propuesta, el dia a dia incluiría estas tareas:

  1. P.M revisa tareas por asignar y se asegura que cumplan con los requerimientos del DoR (con Notion y Cor, su plataforma de seguimiento de tareas).
  2. Diseñadores, Copywriters, etc., reciben tareas y recursos necesarios para cumplirlas eficientemente.
  3. Leads y Directores revisan entregables con un checklist de finalización (DoD) y lo registran en Cor.
  4. Q.As reciben entregables que ya han pasado una revisión inicial - envían menos observaciones.
  5. Equipos finalizan entregables y reciben menos re-trabajos debido a las tareas mejor establecidas.

Pero, ¿cómo lo ponemos en práctica?

Plan de implementación

Junto al proyecto, creamos un plan de implementación para que Digix pueda empezar a usar las DoR y DoD en sus procesos de trabajo. El plan tenía 6 etapas:

Fase 1: Comprensión y planificación

Reunión inicial

Convocar a una reunión con todos los miembros del equipo para presentar la propuesta y explicar la importancia del DoR y DoD en la mejora de la calidad del trabajo.

Análisis de procesos actuales

Evaluar los procesos actuales de trabajo, identificando los puntos débiles y las áreas donde se producen con mayor frecuencia retrabajos.

Ajustes en la plantilla

Ajustar la plantilla para el Definition of Ready y Definition of Done, adaptada a las necesidades específicas de los equipos.

Gobernanza: PM, DesignOps, Art Directors, Content Leader

Tiempo estimado: 3 semanas

Fase 2: Capacitación y concientización

Sesiones de capacitación

Organizar sesiones de capacitación para todo el personal, explicando en detalle el propósito y la aplicación de las plantillas DoR y DoD.

Mentoría y apoyo
  • Designar mentores para brindar apoyo individualizado a los miembros del equipo mientras implementan las plantillas en sus proyectos.
  • Fomentar un entorno donde se sientan cómodos solicitando ayuda o aclaraciones.

Gobernanza: DesignOps

Tiempo estimado: 3 semanas

Fase 3: Implementación piloto

Selección de proyectos piloto
  • Elegir proyectos piloto representativos para implementar las plantillas DoR y DoD.
  • Asegurarse de que los equipos asignados estén dispuestos a participar y colaborar en la implementación.
Recolección de retroalimentación

Recopilar retroalimentación constante de los equipos piloto para identificar posibles obstáculos y realizar ajustes en las plantillas si es necesario.

Gobernanza: PM, DesignOps

Tiempo estimado: 3 semanas

Fase 4: Implementación generalizada

Escalada gradual
  • Escalar la implementación de las plantillas a muchos más proyectos de digix de manera gradual, proporcionando apoyo continuo a medida que los equipos se adaptan.
  • Monitorear el impacto en la calidad del trabajo y en la reducción de retrabajos.
Retroalimentación continua:

Establecer un sistema continuo de retroalimentación y mejora para ajustar las plantillas según sea necesario.

Gobernanza: DesignOps

Tiempo estimado: 4 semanas

Fase 5: Plan de seguimiento, evaluación

Evaluación de resultados
  • Evaluar los resultados obtenidos después de la implementación generalizada.
  • Comparar la métrica IRPE propuesta, antes y después de la implementación.
Ajustes

Realizar ajustes en las plantillas DoR y DoD según los comentarios y la experiencia acumulada.

Documentación y estándares

Documentar las mejores prácticas y lecciones aprendidas durante el proceso de implementación.

Gobernanza: DesignOps

Tiempo estimado: 4 semanas

Métricas

Para poder evaluar si las definiciones y su implementación sean exitosas, planteamos evaluar una métrica importante: Los retrabajos. Para tener medidas reales, decidimos establecer una linea base antes de seguir. Esto se logró mediante una encuesta a los trabajadores de Digix, aunque idealmente esta data debería existir cuantitativamente.

Primero, establecimos qué consideramos un retrabajo y cuánta carga ocupa cada uno. Planteamos la siguiente definición:

Un re-trabajo es cualquier ajuste o modificación que surja por diversas razones y que requiera más de 30 minutos de ejecución - convirtiéndolo así en una tarea adicional.

Actualmente, bajo esa métrica, nuestra línea base demostró que cada entregable acarrea 2.5 retrabajos en promedio - es decir 75 minutos de trabajo extra en promedio.

La meta que planteamos es reducir el Índice de Retrabajos Post-Entrega (IRPE) EN 20% en los 3 meses posteriores a la implementación de las definiciones. El IRPE se mide dividiendo el número de retrabajos despues de una entrega entre el número total de entregas en un proyecto.

Resultados

La propuesta fue bien recibida por el equipo de Digix. Al final del curso, recibí, junto con mi equipo, una mención especial por el producto presentado. Sin embargo, no fue implementada en su totalidad.

De todas formas, llegamos a entregar diversas recomendaciones a Digix para poder implementar esta o cualquier otra iniciativa para escalar el alcance e impacto de Design Ops - particularmente la data cuantitativa que tienen sobre las entregas, los retrabajos y a los procesos de trabajo que usan:

Estandarizar la medida de retrabajos en los equipos.

Esto se puede lograr incluyendo los retrabajos como “subtareas” en Cor, y permitirá tener mejor data de performance para hacer seguimiento y tomar decisiones.

Establecer documentación clara por proceso y por cliente.

Permitirá ahorrar tiempo y pérdidas en el traspaso de información para crear DoRs. Evidenciamos que existe “proto-documentación” informal creada por algunos miembros individuales del equipo, que se debería socializar.

Iterar el proceso de creación de DoD y DoR.

Sobre todo cuando se tenga data más clara. El proceso debe mutar junto con la empresa.