Historia de la vida real sobre el uso de números, datos y gráficos como una herramienta útil para los gerentes.
Por Diego Sierra, director de operaciones de Digital Beings.
Todos hemos estado allí. Ya sea de su cliente o de su jefe, muchas veces enfrenta esa incómoda declaración: “No creo que estemos haciendo un gran trabajo” o “el equipo no es tan productivo como debería ser”. Sientes que tu equipo está funcionando bien (o no) y lo sientes en tus entrañas. Ese sentimiento probablemente sea correcto. Si hay algo que he aprendido después de muchos años en TI es que no hay nada mejor que lo que su estómago le dice cuando se trata de averiguar si está en el camino correcto o no. Pero, ¿no sería genial si pudieras demostrar eso empíricamente y sostenido por datos sólidos como una roca? ¡Por supuesto que sí! Y ahí es donde surgen las métricas como la respuesta definitiva a todas esas declaraciones no deseadas.
Se han escrito toneladas de artículos y documentos sobre métricas, por lo que no entraremos solo en la enumeración de métricas, cuál es su propósito y cómo calcularlas. En cambio, compartiremos una experiencia de la vida real de un proyecto verdadero y cómo las métricas nos ayudaron a gestionar la ejecución de forma controlada, lo que resultó en un mejor rendimiento general y un proyecto más predictivo.
Establecer el escenario
El objetivo del proyecto era reconstruir una plataforma web que respalde el negocio de un operador turístico en línea que vende viajes a múltiples destinos aprovechando las experiencias sociales para crear una comunidad de viajeros leales que se unen para organizar aventuras en todo el mundo.
Al configurar el proyecto, definimos los KPI que queríamos rastrear para medir el rendimiento de nuestro equipo. Esto a veces se omite en las primeras etapas del proyecto, cuando toda su energía generalmente se enfoca en hacer que las cosas funcionen lo más rápido posible, y ese es probablemente el primer error que cometen la mayoría de los Gerentes de Proyecto. Debe asegurarse de que la forma en que medirá la productividad se establece desde el principio, de esta manera puede:
- Defina las métricas para usar y, igual de importante, cuáles NO usar.
- Comience a recopilar datos desde el primer día.
Simplemente usando una herramienta basada en SCRUM para administrar tareas, JIRA, Redmine o Trello, por nombrar algunas, obtendrá acceso a las métricas ágiles estándar como el diagrama Sprint Burndown, el diagrama de velocidad o el flujo acumulativo. No nos centraremos en esas métricas listas para usar, sino que elaboraremos dos métricas personalizadas que definimos para cosas específicas que buscamos rastrear:
- Precisión de estimación -> determine cuán precisas son las estimaciones de nuestro equipo.
- Curva de aprendizaje -> calcule cuándo un nuevo miembro del equipo se incrementó por completo.
Precisión de estimación
Esto fue específicamente importante en nuestro caso porque el cliente estaba extremadamente orientado a la fecha. Por lo tanto, como gerente, quería asegurarme de que los cronogramas con los que nos comprometíamos como equipo fueran realistas y alcanzables, y vigilar la tendencia de las brechas de estimaciones para garantizar que nuestro equipo mejorara la previsibilidad. Se nos ocurrió este informe que muestra la distribución de tickets por desarrollador (John, Mary, Peter) en una escala de -20% a + 20% de desviación entre la estimación original y el esfuerzo real por tarea.
Peter estaba siendo realmente predecible, para la mayoría de los casos estaba alcanzando sus estimaciones o incluso golpeándolas. Alerta de precaución: no es bueno tener un ingeniero que entregue regularmente el trabajo por debajo de la estimación original, puede ser una señal de que alguien está amortiguando mucho y siendo demasiado conservador.
En este punto, teníamos un porcentaje promedio de desviación para todo el equipo de + 22%.
Mary y John tuvieron que retomar si los comparamos con Peter (nuestra línea de base), como resultado tomamos la acción obvia para hacer que Peter verifique dos veces las estimaciones de Mary y John, lo que finalmente nos llevó a ser mucho mejores en el porcentaje general de desviación , reduciendo el% promedio de desviación a + 13%, lo cual fue bastante bueno para nuestro contexto.
Curva de aprendizaje
Otro desafío que el proyecto tenía para nosotros estaba relacionado con la reducción de cualquier tiempo de aceleración al mínimo. A pesar de que tratamos de evitar la rotación de personas en los proyectos, sucede con más frecuencia de la que nos gustaría. En este caso, en un equipo de 5 desarrolladores asignados por un período de alrededor de 6 meses, es probable que tarde o temprano tengamos que traer nuevos muchachos al equipo. Así que definimos una regla, si la nueva gente no alcanzaba el ritmo de sus compañeros en 1 Sprint, simplemente lo reasignaríamos a otra cosa y trataríamos de traer de vuelta a la persona con ramificación (es decir, si el miembro del equipo original fue enviado para ayudar a apagar un incendio en otro lugar). Nuevamente, necesitábamos medir esto lo más preciso posible y definir una forma de medir el tiempo de la curva de aprendizaje. Los tickets se clasificaron en una escala de complejidad del 1 al 5 y, ya en el primer Sprint, definimos la línea de base tomando la cantidad ponderada de tickets resueltos por desarrollador (número de tickets cerrados x complejidad del ticket). El siguiente cuadro muestra la métrica que utilizamos para ver cuán “listo” estaba un nuevo desarrollador en comparación con el resto. Puedes ver que Jack se unió al equipo en Sprint 4 reemplazando a John, y fue capaz de retomarlo muy pronto terminando el Sprint con un valor similar al resto. Incluso logró aumentar su productividad y se convirtió en uno de los miembros más efectivos del equipo. ¡Bien por él!
Conclusiones
Al pensar en las métricas, es muy importante seguir un objetivo de gestión claro y ser franco al determinar lo que queremos lograr midiendo un cierto aspecto de las operaciones. Ya sea “aumentar la previsibilidad del equipo”, “evitar largas curvas de aprendizaje” o cualquier otro propósito final, los datos que recopila y los informes que produce deben estar totalmente en línea con ese espíritu. ¡Desea evitar meterse en lo que yo llamo la “enfermedad del tablero” cuando tiene un buen informe lleno de gráficos y estadísticas que realmente no utiliza! La mayoría de los proyectos que he ejecutado no necesitaban más de 3 métricas principales para garantizar el éxito y un seguimiento cercano. Por lo tanto, la próxima vez que abra su herramienta de administración y vea todos esos gráficos de tendencias, pasteles y barras hermosos (aún no utilizados), tómese un momento para repensar simplemente cuáles de ellos reflejan datos valiosos que están directamente vinculados a los objetivos comerciales más importantes que usted están tratando de abordar
