De objetivos e indicadores

Ahora que vamos a empezar el año, posiblemente te plantees los objetivos del año que entra, pues además de plantearte objetivos, tanto a nivel personal como profesional, te animo a que les sigas la pista, a que determines unos indicadores de éxito.

Hay infinidad de lecturas y herramientas sobre este tema… qué atributos deberían tener los objetivos que te marques, cómo han de ser los identificadores (KPIs), cómo crear un cuadro de mandos, etcétera. Este post no pretende ser una uber-recopilación de recursos relacionados, tan solo dar mi opinión y y algunos ejemplos por si alguien se anima a definirse no solo objetivos, si no también indicadores para 2014 😉

Aunque también aplica al terreno personal, voy a centrarme en el terreno profesional, y me da igual que tu empresa no te ponga objetivos e indicadores… te los puedes poner tu mismo 😉  Decide cómo vas a medir tu contribución y a mantener tus acciones alineadas con el negocio. Además, posiblemente, cuando socialices los objetivos con tu equipo alguien más se suba al carro 😉


Cuando hablo con amigos del mundillo sobre indicadores, encuentro opiniones que se mueven en torno a estos temas:

     No sabe no contesta
     Sensación de ‘tufillo’ a multinacional
     Sensación de que los indicadores creados por negocio no van a reflejar adecuadamente el trabajo en desarrollo

Tengo la impresión de que sobre métricas e indicadores se ha hablado mucho más de las perversiones que de los éxitos y personalmente creo que es una pena. Para poder comentar sobre algo en concreto, pongamos un o unos??? ejemplo:

     Objetivo: Que los desarrolladores que utilicen un determinado servicio permanezcan activos. Entendiendo por ‘activos’ que tengan una frecuencia relativa de uso del servicio. Vamos… que lo usen para algo más que darlo de alta y ocupar una línea en la tabla de usuarios.

     Indicador: Vamos a tener un reporte  que muestre el % de usuarios que acceden al menos 3 veces por semana a hacer una transacción.
Y al rededor de este ejemplo concreto vamos a ver algunos de los que, en mi opinión, son los principales inconvenientes y beneficios.

Principales inconvenientes 

     – Perder el norte y dedicar más tiempo a crear el modelo y las herramientas de seguimiento que a trabajar.
          Ej. Invertir más tiempo en el trabajo de BI para generar el reporte que en crear iniciativas que mantengan a los usuarios interesados.
          Consecuencia… el indicador va a salir con números nefastos en un reporte precioso.

     – Confundir el medio con el fin y convertir los indicadores en los objetivos del negocio.
          Ej. Olvidarnos de que el usuario este interesado y en tener información de calidad y centrarnos en buscar que realicen las transacciones que nos cuentan a toda costa. 
          Consecuencia… si eres bueno, posiblemente acabarás con un buen número, pero no será sostenible pq no has ‘cultivado’ un acceso orgánico motivado por el interés en el servicio.

Principales beneficios 

     – Predictibilidad a.k.a las ves venir, una vez tengas el patrón del indicador vas a poder anticipar comportamiento. 
          Ej. Ves que durante las últimas 2 semanas tus usuarios activos decrecen en número.
          Conclusión: qué esta pasando? tal vez sea el momento de preguntarles que ha cambiado, de cambiar el modelo de negocio… sabes que ha llegado el momento de hacer algo más de lo que tenías en mente.

     – Saber dónde reforzar la inversión, porque al medir el impacto, vemos lo que funciona y lo que no.
          Ej. Sacamos una nueva aplicación móvil para acceder al servicio que reduce la necesidad de estar delante del PC y vemos que la frecuencia de uso                aumenta.
          Conclusión. Genial! tenemos una nueva linea de trabajo que incorporar.
          
     – Nos mantiene enfocados en las áreas clave 
          Ej. Al pensar y hablar sobre los mejores indicadores y objetivos vamos a descubrir nuevas formas de mejorar el servicio. 
          Si uno de tus pilares es la ‘actividad’ vas a tener a los equipos pensando en cómo mejorar el servicio para impactar.


Algunos ejemplos de Malos vs Buenos indicadores

Si te vas a animar a probar, es importante que tengas una buena definición de indicadores-objetivos, porque en esta definición estamos marcando el ámbito de trabajo y estamos abriendo la puerta a la posibilidad de pervertir el modelo. Por ejemplo (intento hacer ejemplos genéricos para que se vea la idea)
     

Indicador Perversión Indicador mejorado
Número total de usuarios en el servicio Como no pedimos usuarios cualificados podemos hacer campañas a través de canales con gran número de audiencia y obtener un montón de nuevos usuarios…que no van a hacer nada. Número total de usuarios activos en el servicio
Facturación media por usuario Entonces tu numero puede ser alto porque tengas una serie de cuentas ‘premium’ que suben la media… pero si unas cuantas de esas cuentas se van? Qué pasa con el resto de segmentos, los tienes controlados? Facturación media por tipo de cliente
Facturación en ventas Vender esta muy bien, es genial, pero si luego el cliente no usa lo que le has vendido, no consume las funcionalidades, no despliega… pues va a ser difícil fidelizarle o hacerle crecer como cliente Facturación (hay que medirla) pero también hay que perseguir el despliegue
Seguidores en twitter Esta me crispa enormemente… QUE MÁS TE DA!?!?! los usuarios que tengas en twitter-facebook-su-red-social-aqui dan igual si no van a enriquecer el ecosistema o adquirir el servicio. Es como si hace unos años te valorasen mejor por tener más amigos en messenger.  Medir el rendimiento de twitter como canal y ver para que merece la pena utilizarlo ( soporte?, branded content?, presencia?) así le dedicarás la inversión adecuada



La perversion es mala… pero no malvada

Solo los malvados hacen las cosas mal a posta =) La perversión ocurre por dos tres grandes razones… la primera y más importante es el desconocimiento, no sabemos que lo estamos haciendo mal porque no nos hemos planteado a fondo la situación. Porque estamos corriendo, porque tenemos entregas, por lo que sea… La segunda razón es derivada de confundir el indicador con el objetivo, si como jefe de equipo estás midiendo e incentivando al equipo por el número de líneas cubiertas por tests…. pues…. tendrás un montón de ellas, aunque igual no reducen el número de bugs en los 3 primeros meses tras el despliegue x) Y la tercera razón… los malvados, que haberlos, haylos.


A si que personalmente te animo a que te marques una serie de indicadores para tus objetivos, y que los revises frecuentemente!  Feliz año nuevo / Urte Berri On! 😉

Si tienes alguna sugerencia sobre mejores ejemplos o algo que añadir al post coméntala aquí o mencióname en twitter (@davidsb) para que la incluya 😉 


Happy hacking!

PS -> Aunque para mi esto es fundamental y necesario, hay empresas que no lo hacen y les va de perlas =) Todo depende del modelo de trabajo que se siga.

Sprints de Marketing

Es frecuente oir a desarrolladores y a teóricos 😉 hablar de las bondades de las metodologías ágiles, pero no he encontrado muchas referencias de otros roles en una organización que den fé de que las utilizan y les funciona, así que me he animado a contar nuestra experiencia desde el punto de vista de un equipo de Marketing en una multinacional.

En mi división hacemos product marketing management, estamos en un punto intermedio entre desarrollo, marketing y negocio.

Para hacernos una idea de donde estamos dejadme que os cuente las interesecciones que tenemos con otros equipos. Con ingeniería compartimos algunos de los escenarios que van a implementarse, mercado y competencia ó BI. Con business planning tratamos temas relacionados con modelos de negocio, precios, cogs… y con marketing outbound colaboramos en programas de relationship marketing, posicionamiento, menajes, audiencias, canales o ventas. La mayoría de personas de mi división tenemos background técnico, damos charlas, hacemos demos…. pero no somos desarrolladores, nuestro día a día está centrado en documentos de word, powerpoint, reuniones y excel. Nuestras horas de desarrollo a la semana son reducidas así que aunque me duela mi corazoncito… no soy un developer, pero aun así os quiero contar como las parácticas ágiles nos aportan beneficios a nivel de equipo y organización.

En el equipo de product management somos unas 15 personas y llevamos diferentes productos relacionados con el stack de desarrollo de Microsoft, las más destacadas son: la plataforma .NET, las herramientas de la familia de Visual Studio, el programa de partners VSIP, la historia de ALM, devops y cómo no, mi ojito derecho, Visual Studio Online.

Más allá del equipo, a nivel de organización, Marketing Outbound, Product Marketing y Business Planning son equipos que están dentro de la división de Marketing (en la jerarquía de Tami Reller) e ingeniería (varios productos, decenas de feature teams, centenas de desarrolladores y testers) cae dentro de la organización de Satya. Diferentes equipos, diferentes edificios, diferentes organizaciones pero con objetivos en común.

Con tantos equipos diferentes en áreas diferentes esta claro que necesitamos una buena forma de organizarnos y colaborar sin perdernos en los procesos. Obviamente estamos alineados en la ‘visión’, en los ‘milestones’ en dónde queremos estar en 1 año, 6 meses… el gran reto es mantenerse alineado en las necesidades inmediatas, en estar seguro que si alguien tiene una dependencia en otro equipo, en otro edificio, este equipo es conscientes, tiene a un owner y la dependencia priorizada adecuadamente para no impactar negativamente en el otro equipo.

Lógicamente cada maestrillo tiene su librillo y cada equipo tiene sus trucos para mantenerse productivo, pero a nivel global optamos por alinearnos a nivel de sprints, así reducimos la mayoría de puntos de fricción (que no todos) derivado de diferentes organizaciones con diferente velocidad y necesidades. Compartimos sprints de 3 semanas y tenemos identificador único intra-organización (95% de los equipos).

Como es de esperar el backlog que tenemos en el área de Marketing no tiene que ver con lo que pueda tener un feature team de ingeniería, ellos tienen historias de usuario, bugs… en nuestro caso, la mayoría de items estan relacionados con generar drafts de documentos, llegar a acuerdos con proveedores, ejecutar determinadas iniciativas, user research o discutir escenarios. El hecho de tener un modelo de trabajo basado en backlogs, sprints, ecétera tra beneficios inmediatos al equipo, pero compartir el ritmo y backlogs nos ayuda a nivel de organización. Es tremendamente últil saber que todos estamos en el sprint 60, saber las fechas de los compromisos, compartir prioridades en el sprint y a 3 sprints, revisar escenarios juntos, etcétera…

Por ejemplo, en mi área en concreto hacemos product marketing de un servicio, hay muchas iniciativas de marketing que van dentro de código fuente (a/b testing, nurture, telemetría, contactabilidad, surveys, BI research…) y que han de estar reflejadas en los sprints de ingeniería, si no estas alineado adecuadamente o no hay acuerdo en las prioridades a nivel de organizaciones… tienes un problema.

¿Cómo lo hacemos?

Lo primero es compartir objetivos a nivel de organización (que los VPs, GMs y directories de las diferentes organizaciones tengan objetivos comunes y priorizados en el mismo orden) y ganas de trabajar juntos. Además, tenemos una serie de procesos y de herramientas compartidas.

Por la parte táctica de los procesos, a nivel inter-organización tenemos alineamientos a 3 meses, sincronización bimensuales y mail al final del sprint con historias resueltas y backlog (a grandes rasgos) del siguiente sprint.

A nivel intra-organización tenemos daily meeting en los equipos, sprint meetings y varios encuentros semanales para revisar el sprint backlog de los equipos virtuales.

En cuanto a las herramientas, intentamos mantenerlo sencillo:

    Tableros kanban (powered by Visual Studio Online) con diferentes areas de trabajo

    Un sharepoint de office 365 online para alojar los documentos

    Un One Note donde guardamos notas de las diferentes reuniones

    Lync para trabajar en remoto

    Mail para discusiones

Espero que sirva como ejemplo de que las metodologías ágiles no son sólo para equipos de 5 geeks. Nosotros las estamos utilizando en una multinacional para mantener alineadas y sincronizadas a cientos de personas distribuidas en equipos multidisciplinares en diferentes organizaciones … y funciona   😉

¿Preguntas? =)

Happy hacking!

ds