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 se podrían resolver con una mejor documentación y cómo elegir las métricas adecuadas para los proyectos de documentación.

Fase actual:
Se anunciaron los resultados. Consulta el cronograma.

Indica cuál es el problema

Antes de 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 para nuestra documentación de integración tardan demasiado en fusionarse. Los colaboradores se dan por vencidos y desaparecen”.
  • “Vemos demasiados problemas abiertos para obtener ayuda para comprender los códigos de error”.
  • “Nuestra canalización de CI/CD es inestable. Demasiadas pruebas fallan por motivos poco comprendidos”.
  • “Las personas parecen gruñonas en nuestras reuniones semanales”.

Desarrollar una hipótesis

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

  • “Lleva mucho tiempo combinar las solicitudes de extracción para la documentación de integración porque no tenemos una guía clara sobre el estilo. Los revisores posponen la revisión de la PR porque no saben qué hacer o se comunican con los colaboradores sobre el formato”.
  • “Los usuarios tienen que abrir problemas porque no pueden encontrar información sobre los códigos de error en la documentación”.
  • “Nuestras pruebas de CI/CD fallan porque nos encontramos con limitaciones de planes y tiempos de espera de nuestro proveedor”.
  • “Las personas están de mal humor en nuestras reuniones semanales porque se realizan a las 5:30 a.m. en su zona horaria”.

Proponer una solución

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

  • “Si tuviéramos una guía de estilo, los responsables de confirmación podrían revisarla antes de enviar sus solicitudes de cambios. Los revisores sabrían qué verificar. Los revisores y colaboradores no tendrían que discutir sobre el formato, el tono y el estilo”.
  • “Si tuviéramos documentación de códigos de error, los usuarios podrían encontrar sus respuestas allí, en lugar de problemas de apertura”.
  • “Hmm, no parece que una mejor documentación resolvería nuestro problema de CI/CD”.
  • “Podríamos comenzar cada reunión con un chiste de knock-knock”. Crear una colección de chistes de “pregunta y respuesta” nos ayudaría a comenzar nuestras reuniones con una sonrisa”.

Sé específico

¿Puedes cuantificar el problema?

  • "¿Qué significa realmente "tarda demasiado en combinar las PR"? ¿dos meses?, ¿Dos semanas? ¿Cuánto tiempo esperarán los colaboradores la revisión antes de darse por vencidos?”
  • "¿Cuántos problemas relacionados con códigos de error son "demasiados problemas"?"
  • “Mmm… ¿qué tan malhumorado es ‘demasiado malhumorado’?”

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 fácilmente cuánto tiempo lleva abierta una solicitud de extracción y cuánto tiempo pasó 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 el texto del código de error dentro de los problemas".
  • "No podemos medir el mal humor 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 tu documentación resuelve el problema? ¿Tu métrica objetivo es la misma en todos los casos?

  • “Las PR más largas tardan más tiempo en revisarse. Deberíamos tener diferentes umbrales para diferentes tamaños de PR. Queremos medir el tiempo de combinación para las PR pequeñas, medianas, grandes y gigantescas”.
  • “Podríamos verificar cuántas visitas recibe nuestra documentación de códigos de error y ver si esa cantidad se correlaciona con menos problemas abiertos”.

Elige un período

  • "Creemos que dos semanas son un plazo razonable para fusionar las relaciones de pequeñas y medianas empresas, y todas las relaciones públicas deben fusionarse en un mes. Por lo tanto, lo mediremos cada dos semanas”.
  • “No tiene sentido actualizar la cantidad de problemas relacionados con códigos de error a diario, ya que nuestro tiempo típico 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 cumplimos con nuestro objetivo de cerrar cada nueva PR en menos de un mes, eso sería un éxito. Si el tiempo promedio para cerrar acuerdos de ventas importantes se redujera en dos semanas, sería un gran éxito".
  • "Idealmente, no veríamos nuevos problemas relacionados con errores. Sin embargo, consideraríamos que nuestro proyecto fue un éxito si viéramos una disminución del 50% en los problemas relacionados con errores que se abrieron”.