He estado involucrado en marketing prácticamente toda mi vida. Antes de comenzar a promover canales de YouTube en One2, había estado gestionando el departamento de servicio al cliente en la agencia PROMO. Las innovaciones siempre me han atraído, así que encontrar la metodología Scrum era cuestión de tiempo.
Mi camino hacia la gestión de proyectos
En la agencia de publicidad, me convertí en el líder de un departamento compuesto por gerentes de cuentas. No había un sistema de gestión de proyectos. No estábamos a tiempo para cumplir con nuestras obligaciones contractuales o realizábamos trabajos de mala calidad. Así que me convertí en un solucionador de problemas para abordar las críticas negativas de los clientes. Era un camino sin salida: al no poder prevenir un problema, manejaba sus consecuencias.
Comencé a buscar un conjunto de herramientas para abordar la situación. En ese momento, no estaba al tanto de Agile o Scrum, por no mencionar las formas de usar la metodología Scrum en equipos no IT.
Me convertí en un solucionador de problemas para abordar las críticas negativas de los clientes.
Cómo elegimos la metodología de gestión de proyectos
Al principio, miramos Kanban. Es particularmente bueno para problemas de flujo como la corrección de errores o el procesamiento de solicitudes en un centro de llamadas. Pero para introducir Kanban, se necesita un equipo altamente motivado y bien organizado. No era nuestro caso.
También consideramos Waterfall. Es bueno para equipos de IT porque la secuencia clara de etapas requiere menos códigos, y estás en ascenso. El mismo proyecto en Scrum se verá completamente diferente:
una cosa funcional —>ajuste —>optimización
La fiabilidad de Waterfall oculta su desventaja: un alto riesgo de interrumpir los plazos. Las empresas quieren obtener resultados lo más pronto posible en lugar de esperar un año entero para convencerse de que la estrategia elegida no funciona. Scrum no está libre de este “problema”.
Qué herramientas Scrum se adaptarán a una agencia de marketing
Scrum ofrece muchas herramientas para aumentar la motivación:
- Tableros Scrum. Los tableros Scrum muestran los estados de las tareas y pueden guiarte hacia los puntos problemáticos (por ejemplo, demasiadas tareas están en la etapa de discusión con los clientes). Hicimos que los tableros Scrum estuvieran disponibles para nuestros clientes, permitiéndoles rastrear el estado de las tareas. Alivió profundamente la carga de nuestros gerentes de cuentas.
- reuniones diarias. Todos los miembros del equipo se turnan para presentar los resultados del día anterior, hacer una promesa para el día actual y compartir problemas. Gracias a estas reuniones diarias, puedes entender qué está sucediendo en la empresa y encontrar la manera de hacer el trabajo más eficiente.
- planificación. Hace que el proceso de trabajo sea transparente para el gerente y para el cliente. Invitamos a clientes específicos y decidimos juntos qué tareas establecer para los siguientes sprints.
- retrospectiva. Podemos entender los errores que hemos cometido y cómo corregirlos (por ejemplo, cómo aumentar el número de tareas simultáneas en progreso sin comprometer la calidad).
- demostración del producto. Presenta el progreso del equipo realizado durante el sprint. Cada miembro del equipo muestra su parte del producto. La demostración del producto hace posible realizar modificaciones rápidamente, mejorar el producto y no perder tiempo en presentaciones anticipadas del producto terminado.
Mi trabajo solía consistir principalmente en analizar críticas negativas de clientes. Después de que se introdujo Scrum, comenzamos a preguntar a los clientes su opinión para entender si nuestra dirección de movimiento era la correcta. Hemos mejorado el índice de soporte al consumidor (NPS).
¿Cuáles son las desventajas de Scrum para equipos no IT?
Scrum tiene tres principales desventajas:
- Los procesos comerciales se vuelven más costosos. Hemos introducido el puesto de propietario del producto, ya que ningún miembro del equipo podría asumir un rol tan importante. Tal especialista es caro. Ni el propietario del producto ni el Scrum master crean valor directamente; están fuera del equipo, de hecho, pertenecen à la categoría de gastos generales.
- No hay un servicio de gestión de proyectos conveniente en Scrum para equipos no IT. Solíamos utilizar Jira, pero su ajuste a menudo requiere la participación de un especialista.
- La terminología de IT en Scrum no está adaptada para empresas no IT. Para las empresas de IT, hay guías detalladas que describen cómo hacer que Scrum funcione. Explican la terminología: incremento es un producto funcional, demo es demostrar cómo funciona el producto. En nuestro caso, no estaba claro cómo la redacción de contenido afectaba la operación del producto. ¿Y qué es un incremento en SEO? Si hemos escrito un texto y lo hemos publicado en el sitio web, ¿es un producto funcional? Nos tomó más de tres meses adaptar la terminología de IT a nuestras necesidades.
Cómo fallamos en introducir Scrum
Comenzamos a introducir Scrum formando equipos. Y de inmediato cometimos dos errores.
Error No.1. Incluimos especialistas de publicidad contextual y SEO en un mismo equipo. La lógica es la siguiente: todos ellos generan tráfico hacia los sitios web de los clientes y aumentan las ventas, lo que significa que están bienvenidos a trabajar juntos. El equipo está unido alrededor de un cliente.
Cómo resolvimos el problema: después de un tiempo, dividimos a los especialistas por valores y productos. Algunos clientes obtuvieron varios gerentes de cuentas y equipos à la vez.
Lo que entendimos: un equipo debe estar unido alrededor de un propósito comercial. Tal equipo es autosuficiente y puede crear valor para el cliente por sí mismo.
Error No.2. No logramos definir de inmediato quién debía actuar como Scrum master y propietario del producto.
Cómo resolvimos el problema: complementamos el puesto de contador existente con la función de Scrum master. Antes de eso, estaba a cargo de la productividad del equipo y de la entrega continua de valores al cliente. Empleamos a una persona separada para ser el propietario del producto.
A menudo me encuentro con dos errores en empresas que también introducen Scrum:
- Los equipos se combinan en torno a una función. Un departamento simplemente se renombra como un equipo. El problema es que si un cliente necesita un sitio web, el equipo debe tener un programador, un diseñador y un gerente. Ningún departamento de marketing compuesto por gerentes de marca creará un sitio web.
- Las empresas temen destruir la estructura existente. El siguiente ejemplo fue real. Un gerente de cuentas manejaba varios proyectos, cada uno de los cuales era apoyado por diferentes especialistas SEO. Los proyectos se distribuían según la carga de trabajo de los especialistas SEO. Supongamos que un especialista haObtained 10 proyectos para trabajar con diferentes prioridades. Las prioridades son establecidas por el gerente del proyecto, y esta empresa tenía varios de ellos. En el mejor de los casos, el especialista SEO cumplía la tarea más comprensible; en el peor, la tarea del gerente de cuentas que más gritaba.
Unirse en “los equipos correctos” es un proceso doloroso.
¿Por qué necesitamos un Scrum master?
Toyota tiene un caso interesante para ejemplificar el papel del Scrum master. En la fábrica, algunos trabajadores fueron asignados para ayudar a un ingeniero mecánico a optimizar el trabajo. El ingeniero mecánico era pagado por hora, lo cual era bastante alto, así que el rendimiento debía ser incrementado y los costos debían ser reducidos. Se notó que el ingeniero mecánico buscaba la llave adecuada, por lo que se le asignó un aprendiz para proporcionarle llaves. Se concibió facilitar aún más el proceso: se pintaron plantillas para las herramientas en el suelo, y el aprendiz las colocaba por la mañana antes del trabajo.
Así que, un buen Scrum master asegura el 80% del éxito en la introducción de Scrum. Si te falta una persona que pueda asumir este rol, busca a alguien que esté interesado en trabajar más en este campo. Como último recurso, busca un Scrum master en empresas de IT.
El Scrum master tiene las siguientes funciones no obvias:
- Sentir dónde el equipo tiene un rendimiento deficiente, dónde se puede acelerar y dónde es mejor desacelerar. Es como un escudo contra plazos ajustados y caos.
- Ser responsable del sentido de seguridad del equipo. Esto incluye protección contra un cliente que quiere “hacer todo para ayer”. Por ejemplo, nos encontramos con tal problema: los gerentes de cuentas estaban compilando informes para los clientes durante mucho tiempo. A instancias del Scrum master, establecimos informes automatizados generados en tiempo real. Ahora el cliente no tiene que esperar hasta fin de mes para entender cómo van las cosas. Todas las partes están satisfechas.
- Mejorar el nivel del equipo para utilizar Scrum por elección voluntaria.
- Comunicación uno a uno con cada miembro del equipo. Acerca de los problemas y dificultades del empleado. De esta manera, los especialistas junior alcanzarán el nivel medio más rápido y los especialistas medios crecerán a seniors. La rotación de personal disminuirá.
¿Por qué necesitamos un propietario del producto?
No entendíamos de inmediato quién debía convertirse en el propietario del producto y de qué sería responsable. Llegamos à la conclusión de que el propietario del producto es un especialista técnico que tiene un buen conocimiento del producto y capaz de elaborar estrategias contextuales y de SEO, transmitiéndolas al cliente. En otras palabras, este es un estratega que dice qué necesita hacerse.
¿Qué hace nuestro propietario del producto?
- forma backlogs;
- elimina y establece prioridades de tareas;
- ajusta estrategias basadas en los datos obtenidos del equipo;
- es responsable ante los clientes por el resultado.
La forma en que introdujimos Scrum en una empresa no IT
Los especialistas solían trabajar por separado: redactores y editores, constructores de enlaces y analistas SEO. Al introducir Scrum, los mezclamos entre sí. Cada equipo tiene también un gerente de cuentas que entrega valor a los clientes.
Se formaron equipos para cada una de las tres áreas de SEO:
- gestión de la masa de enlaces
- creación de contenido
- reforma del sitio web.
El trabajo se dividió en sprints que subyacen à la planificación mensual. Mientras planificábamos, intentamos reducir el riesgo de no obtener un resultado al final del mes.
Experimentamos con la duración de los sprints. Cuando comenzamos a introducir Scrum, los sprints eran de una semana. Un sprint semanal hace posible ejecutar rápidamente un proceso y darse cuenta de dónde te has equivocado, enseñar a los empleados y entender cómo funciona todo.
Consejo clave para la duración de los sprints de Scrum en marketing: selecciona un plazo que sea suficiente para hacer algo útil.
Los sprints se ven como sigue:
planificación —>reuniones diarias —>demostración —>retrospectiva.
Redirigimos a parte de los equipos para tener sprints de dos semanas. Ten en cuenta que cuanto más largo es el sprint, más arriesgas perder los plazos.
Usamos las siguientes herramientas en nuestro trabajo:
- planificación en poker. La técnica permite evaluar la complejidad y el alcance de las tareas que deberán ser abordadas mientras se crea el producto. Todos los miembros del equipo participan en la planificación en poker. Usando cartas, evalúan las tareas y toman decisiones colectivas;
- análogo de programación en pareja basado en programación extrema. Varias personas trabajan en una tarea en el mismo lugar de trabajo. Es un ejemplo demostrativo de la regla: “Dos cabezas piensan mejor que una”. Lo usamos en momentos críticos;
- ciclos HADI. Son algoritmos para verificar hipótesis controvertidas que ayudan a ganar la confianza del cliente. Lee más sobre los ciclos HADI a continuación.
¿Qué son los ciclos HADI y cómo usarlos?
¿Qué es? Un ciclo HADI es un algoritmo para verificar una hipótesis que se ve de la siguiente manera:
hipótesis —> verificación —> resultado —> conclusiones.
Los ciclos HADI son similares al bucle Lean Startup:
construir —> medir —> aprender
¿Cómo funciona?
Generas hipótesis cuya viabilidad se cuestiona. Si una tarea es comprensible y necesaria, no tiene sentido procesarla en un ciclo HADI. Después de verificar la hipótesis, determines si ha funcionado o no, y en qué grado de eficiencia. Si ha funcionado, la lanzas en un sprint; si no, simplemente la descartas.
¿Cómo se ve?
Por ejemplo, hay una hipótesis: “Si hago interenlaces en los productos, generará un crecimiento del tráfico del triple”. Verificas la hipótesis en un producto, estableciendo enlaces manualmente dentro del sitio web. Si la hipótesis ha funcionado, le das una tarea a los programadores: “Proporciona interenlaces en todo el sitio web”.
¿Cuál es la ventaja de los ciclos HADI?
Puede parecerle al cliente que tu nueva solución no funcionará bien. En respuesta, muestras el ejemplo real basado en un elemento.
Documenta tus hipótesis, incluso si no han funcionado. En el siguiente sprint, puedes probar otra. Además, asegúrate de que tus experimentos no causen un conflicto de interés (por ejemplo, para que las hipótesis relacionadas con la misma página web no se prueben simultáneamente). De lo contrario, no será claro qué hipótesis ha tenido éxito.
7 consejos para introducir Scrum si no eres una empresa IT
- Comienza con formación. Lee literatura especializada, asiste a sesiones de capacitación.
- Determina quién es tu interesado (parte interesada). Y luego trabaja para entregar valor al cliente y al interesado.
- Los sprints deberían permanecer inalterados. No tengas miedo de cambiar el resto de las cosas.
- No redirijas a todo el equipo a Scrum, solo porque “es genial”. Por ejemplo, nuestros redactores trabajan con Kanban porque los textos no tienen prioridades, solo necesitan hacerse lo más rápido posible.
- Determina el tamaño óptimo de tu equipo. Según mi experiencia, son cinco a siete personas en empresas no IT.
- Organiza un área de trabajo aislada para cada equipo. Si tienes una oficina de espacio abierto, añade tableros Scrum offline.
- Toma la iniciativa en implementar Scrum. Si la dirección desconoce el propósito de una nueva metodología, no se hará nada.