Memilih metrik yang tepat untuk proyek Anda

Panduan ini dimaksudkan untuk membantu organisasi memahami jenis masalah yang mungkin bisa diselesaikan dengan dokumentasi yang lebih baik, dan cara memilih metrik yang sesuai untuk proyek dokumentasi.

Tahap saat ini:
Hasil diumumkan linimasa.

Nyatakan masalah Anda

Sebelum memilih metrik, pastikan Anda memiliki pemahaman yang baik tentang masalah yang Anda coba dipecahkan. Jelaskan sespesifik mungkin.

  • “Permintaan pengambilan untuk dokumentasi orientasi kami memerlukan waktu terlalu lama untuk digabungkan. Kontributor menyerah dan menyerah.”
  • “Kami melihat terlalu banyak masalah yang terbuka untuk membantu memahami kode error.”
  • “Pipeline CI/CD kami tidak stabil. Terlalu banyak pengujian yang gagal karena alasan yang kurang dipahami.”
  • “Orang-orang tampak pemarah dalam pertemuan mingguan kami.”

Mengembangkan hipotesis

Cari tahu sebab dan akibat. Apa kemungkinan penyebab masalah yang telah Anda nyatakan? Ingatlah bahwa masalah dapat memiliki beberapa penyebab atau penyebabnya.

  • “Penggabungan permintaan pull untuk dokumentasi orientasi memerlukan waktu begitu lama karena kami tidak memiliki panduan yang jelas tentang gaya. Peninjau menunda peninjauan PR karena tidak tahu apa yang harus dilakukan, atau mereka berunding dengan kontributor terkait pemformatan.”
  • “Pengguna harus melaporkan masalah karena mereka tidak dapat menemukan informasi tentang kode error dalam dokumentasi.”
  • “Pengujian CI/CD kami gagal karena kami mengalami batasan paket dan waktu tunggu dari penyedia kami.”
  • “Orang-orang sangat cemberut dalam rapat mingguan kami karena rapat dimulai pukul 05.30 di zona waktu mereka.”

Mengusulkan solusi

Apakah masalah ini dapat diselesaikan dengan dokumentasi baru atau yang lebih baik?

  • “Jika kami memiliki panduan gaya, penyedia dapat memeriksanya sebelum mengirimkan Humas mereka. Peninjau tahu apa yang harus diperiksa. Peninjau dan kontributor tidak perlu berdebat tentang pemformatan, nuansa, dan gaya.”
  • “Jika kami memiliki dokumentasi kode error, pengguna dapat menemukan jawabannya di sana, bukan membuka masalah.”
  • “Hmm, sepertinya dokumentasi yang lebih baik tidak akan memecahkan masalah CI/CD kita.”
  • “Kita bisa saja memulai setiap pertemuan dengan lelucon tak terduga! Membuat koleksi lelucon "tangkas" akan membantu kami memulai rapat dengan senyuman.”

Harus spesifik

Bisakah Anda mengukur masalahnya?

  • “Apa arti sebenarnya dari 'penggabungan PR memerlukan waktu terlalu lama'? Dua bulan? Dua minggu? Berapa lama kontributor akan menunggu peninjauan sebelum menyerah?”
  • “Berapa banyak masalah terkait kode error yang ‘terlalu banyak masalah’?”
  • “Hmmm ... seberapa cemberut 'terlalu cemberut'?”

Memeriksa keterukuran

Bagaimana cara memeriksa metrik yang diusulkan? Bisakah itu diukur dengan mudah dan akurat? Apakah pengukuran bergantung pada siapa yang melakukan pengukuran?

  • “Kami dapat dengan mudah mengukur berapa lama permintaan pull telah dibuka, dan berapa lama sejak peninjauan diminta. Kami tidak dapat mengukur dengan tepat kapan kontributor akan menyerah.”
  • “Kami dapat menghitung berapa banyak masalah yang diberi tag ‘error-code’ atau menelusuri teks kode error di dalam masalah.”
  • “Kami tidak bisa benar-benar mengukur sifat cemberut orang dengan cara yang bijaksana atau akurat.”

Menambahkan metrik sekunder

Apakah ada metrik lain yang akan membantu Anda memahami apakah dokumentasi tersebut memecahkan masalah? Apakah metrik target Anda sama dalam setiap kasus?

  • “PR yang lebih lama membutuhkan lebih banyak waktu untuk ditinjau; kita harus memiliki batas yang berbeda untuk ukuran PR yang berbeda. Kami ingin mengukur waktu penggabungan untuk PR kecil, menengah, besar, dan raksasa.”
  • "Kami dapat memeriksa jumlah kunjungan yang diterima dokumentasi kode error dan melihat apakah angka tersebut berhubungan dengan lebih sedikit masalah yang terbuka."

Pilih jangka waktu

  • “Menurut kami, dua minggu adalah waktu yang wajar untuk menggabungkan PR kecil hingga menengah; dan semua PR seharusnya digabungkan dalam waktu satu bulan. Jadi kami akan mengukurnya setiap dua minggu.”
  • “Tidak masuk akal untuk memperbarui jumlah masalah terkait kode error setiap hari, karena waktu umum kami untuk menutup masalah adalah satu minggu. Kami akan mengukurnya setiap minggu.”

Tentukan target

Berapa banyak perubahan yang perlu Anda lihat dalam metrik yang Anda pilih untuk mengatakan bahwa proyek itu berhasil? Pertimbangkan untuk menetapkan tujuan kuantitatif untuk metrik yang Anda pilih.

  • "Jika kami memenuhi sasaran untuk menutup setiap PR baru dalam waktu kurang dari sebulan, itu akan meraih sukses. Jika waktu rata-rata kami untuk menutup PR besar berkurang dua minggu, hal itu akan sangat sukses."
  • “Idealnya, kami tidak akan melihat masalah baru terkait error. Tetapi kami akan menganggap proyek kami berhasil jika kami melihat penurunan 50% dalam masalah terkait error yang terbuka.”