Elige las métricas adecuadas para tu proyecto

El objetivo de esta guía es ayudar a las organizaciones a comprender qué tipos de problemas podrían resolverse con una mejor documentación y cómo elegir las métricas adecuadas para los proyectos de documentación.

Fase actual:
Desarrollo de la documentación. Consulta el cronograma.

Indica el problema

Antes de pasar a elegir una métrica, asegúrate de comprender bien el problema que intentas resolver. Brinda la mayor cantidad posible de detalles.

  • “Las solicitudes de extracción de nuestra documentación de integración tardan demasiado en combinarse. Los colaboradores se dan por vencidos y se van".
  • "Vemos demasiados problemas abiertos para ayudar a comprender los códigos de error".
  • “Nuestra canalización de CI/CD es inestable. Demasiadas pruebas fallan por motivos que no se entendieron”.
  • “Las personas parecen de mal humor en las reuniones semanales”.

Desarrollar una hipótesis

Busca la causa y el efecto. ¿Cuál podría ser la causa del problema que indicaste? Ten en cuenta que los problemas pueden tener causas múltiples o superpuestas.

  • "Lleva mucho tiempo combinar solicitudes de extracción para la documentación de integración porque no tenemos una orientación clara sobre el estilo. Los revisores posponen la revisión de las publicaciones de RR.PP. porque no saben qué hacer, o bien intervienen con los colaboradores sobre el formato”.
  • "Los usuarios deben abrir los problemas porque no pueden encontrar información sobre los códigos de error en la documentación".
  • “Nuestras pruebas de CI/CD fallan porque nuestro proveedor tiene limitaciones y tiempos de espera de nuestro plan”.
  • “Las reuniones semanales están de mal humor porque son a las 5:30 a.m. de su zona horaria”.

Proponer una solución

¿Es un problema que se podría resolver con documentación nueva o mejor?

  • “Si tuviéramos una guía de estilo, los confirmadores podían consultarla antes de enviar sus RR.PP. Los revisores sabrían qué buscar. Los revisores y colaboradores no tendrían que discutir sobre el formato, el tono y el estilo".
  • "Si tuviéramos documentación de código de error, los usuarios podrían encontrar las respuestas allí, en lugar de informar problemas".
  • “Mmm, no parece que una mejor documentación resolvería nuestro problema de CI/CD”.
  • "¡Podríamos empezar cada reunión con un chiste de toc toc! Crear una colección de chistes toc toc nos ayudaría a empezar las reuniones con una sonrisa".

Brinda información específica

¿Puedes cuantificar el problema?

  • "¿Qué significa realmente “lleva demasiado tiempo fusionar las relaciones públicas”? ¿dos meses?, ¿Dos semanas? ¿Cuánto tiempo esperarán los colaboradores para que se revise antes de renunciar?".
  • “¿Cuántos problemas relacionados con códigos de error tienen “demasiados problemas”?”.
  • “Mmm... ¿qué tan gruñón es ‘demasiado gruñón’?”

Cómo verificar la capacidad de medición

¿Cómo verificarías la métrica propuesta? ¿Se puede medir de forma fácil y precisa? ¿La medición depende de quién la realiza?

  • "Podemos medir con facilidad cuánto tiempo ha estado abierta una solicitud de extracción y cuánto tiempo transcurrió desde que se solicitó una revisión. No podemos medir exactamente cuándo un colaborador se da por vencido".
  • “Podemos contar cuántos problemas están etiquetados como “código de error” o buscar dentro de los problemas el texto del código de error”.
  • "No podemos medir el malhumor de las personas de forma discreta o precisa".

Cómo agregar una métrica secundaria

¿Hay otras métricas que te ayuden a comprender si la documentación resuelve el problema? ¿Tu métrica objetivo es la misma en todos los casos?

  • “Las PR tardan más en revisarse. Deberíamos tener diferentes umbrales para los distintos tamaños de PR. Queremos medir el tiempo de fusión para PR pequeños, medianos, grandes y gigantes".
  • "Pudimos verificar cuántas visitas recibe nuestra documentación de códigos de error y ver si ese número se relaciona con menos problemas abiertos".

Elige un período

  • "Creemos que dos semanas es un tiempo razonable para fusionar las relaciones públicas pequeñas y medianas, y todas las relaciones públicas deben combinarse en el plazo de un mes. Lo medimos cada dos semanas".
  • "No tiene sentido actualizar la cantidad de problemas relacionados con códigos de error a diario, ya que el tiempo habitual para cerrar un problema es de una semana. Lo mediremos semanalmente”.

Fija objetivos

¿Cuánto cambio necesitarías ver en la métrica seleccionada para decir que el proyecto fue un éxito? Considera establecer objetivos cuantitativos para las métricas que elegiste.

  • "Si cumpliéramos nuestro objetivo de cerrar todas las relaciones públicas nuevas en menos de un mes, sería un éxito. Si el tiempo promedio para cerrar las relaciones públicas de gran tamaño disminuyera en dos semanas, sería un gran éxito".
  • "Idealmente, no veríamos problemas nuevos relacionados con errores. Sin embargo, consideraríamos que nuestro proyecto fue exitoso si viéramos abierto una disminución del 50% en los problemas relacionados con errores".