Elige las métricas adecuadas para tu proyecto

Esta guía está pensada para ayudar a las organizaciones a comprender qué tipo 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:
Datos anunciados cronograma.

Indica el problema

Antes de comenzar a elegir una métrica, asegúrate de comprender bien el problema que tratas de resolver. Sé lo más específico posible.

  • “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 que se abren demasiados problemas para ayudar a comprender los códigos de error”.
  • “Nuestra canalización de CI/CD es inestable. Demasiadas pruebas fallan por razones mal entendidas”.
  • “Las personas parecen estar 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 mencionaste? Ten en cuenta que los problemas pueden tener varias causas o que se superponen.

  • “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 RR.PP. porque no saben qué hacer, o van y vienen con los colaboradores sobre el formato”.
  • “Los usuarios deben 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 del plan y tiempos de espera de nuestro proveedor”.
  • “Las personas están de mal humor en nuestras reuniones semanales porque son a las 5:30 a.m. de su zona horaria”.

Proponer una solución

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

  • “Si tuviéramos una guía de estilo, los encargados podrían revisarla antes de enviar sus PR. 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 tener una mejor documentación solucionarí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".

Obtén información específica

¿Puedes cuantificar el problema?

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

Cómo verificar la capacidad de medición

¿Cómo revisarías la métrica propuesta? ¿Se puede medir de manera 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 desde que se solicitó una revisión. No podemos medir con exactitud cuándo un colaborador se da por vencido”.
  • “Podemos contar cuántos problemas tienen la etiqueta “código de error” o buscar dentro de los problemas el texto del código de error”.
  • "No podemos medir el gruñón de las personas con tacto o con precisión".

Agrega una métrica secundaria

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

  • “Las PR más prolongadas tardan más en revisarse. Deberíamos tener diferentes umbrales para los distintos tamaños de PR. Queremos medir el tiempo de fusión de PR pequeñas, medianas, grandes y gigantes.
  • “Pudimos verificar la cantidad de visitas que 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 se deben combinar 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. La 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 grandes PR se redujo en dos semanas, sería un gran éxito".
  • "Lo ideal sería que no veríamos problemas nuevos relacionados con errores. Sin embargo, consideraríamos que nuestro proyecto es exitoso si observamos una disminución del 50% en los problemas relacionados con errores”.