การเลือกเมตริกที่เหมาะกับโปรเจ็กต์ของคุณ

คู่มือนี้มีไว้เพื่อช่วยให้องค์กรเข้าใจว่าเอกสารประกอบที่ดีขึ้นอาจช่วยแก้ปัญหาประเภทใดได้บ้าง และวิธีเลือกเมตริกที่เหมาะสมสำหรับโปรเจ็กต์เอกสารประกอบ

ระยะปัจจุบัน:
ประกาศผลลัพธ์แล้ว ดูไทม์ไลน์

ระบุปัญหาของคุณ

ก่อนเลือกเมตริก ให้ตรวจสอบว่าคุณเข้าใจปัญหาที่ต้องการแก้ปัญหาเป็นอย่างดี โปรดระบุให้เฉพาะเจาะจงที่สุด

  • "การดึงคำขอสำหรับเอกสารประกอบการเริ่มต้นใช้งานใช้เวลานานเกินไปในการรวม ผู้มีส่วนร่วมจึงเลิกพยายามและจากไป"
  • "เราพบว่ามีปัญหาเกิดขึ้นมากเกินไปสำหรับความช่วยเหลือในการทําความเข้าใจรหัสข้อผิดพลาด"
  • "ไปป์ไลน์ CI/CD ของเราทำงานไม่เสถียร มีการทดสอบที่ล้มเหลวมากเกินไปด้วยเหตุผลที่ไม่เข้าใจ"
  • "ดูเหมือนว่าทุกคนจะหงุดหงิดในการประชุมรายสัปดาห์"

สร้างสมมติฐาน

มองหาสาเหตุและผลกระทบ ปัญหาที่คุณแจ้งมาอาจเกิดจากสาเหตุใด โปรดทราบว่าปัญหาอาจมีหลายสาเหตุหรือทับซ้อนกัน

  • "การผสานคำขอดึงสำหรับเอกสารประกอบเกี่ยวกับการเริ่มต้นใช้งานใช้เวลานานมากเนื่องจากเราไม่มีคำแนะนำที่ชัดเจนเกี่ยวกับรูปแบบ ผู้ตรวจสอบจะเลื่อนการตรวจสอบ PR ออกไปเพราะไม่รู้จะทำอย่างไร หรือโต้ตอบกับผู้มีส่วนร่วมเกี่ยวกับการจัดรูปแบบอยู่ตลอด"
  • "ผู้ใช้ต้องเปิดปัญหาเนื่องจากไม่พบข้อมูลเกี่ยวกับรหัสข้อผิดพลาดในเอกสารประกอบ"
  • "การทดสอบ CI/CD ของเราล้มเหลวเนื่องจากเราพบข้อจำกัดของแพ็กเกจและหมดเวลาจากผู้ให้บริการ"
  • "ผู้คนไม่พอใจกับการประชุมรายสัปดาห์ของเราเนื่องจากจัดขึ้นตอน 05:30 น. ตามเขตเวลาของสมาชิก"

เสนอวิธีแก้ปัญหา

ปัญหานี้แก้ไขได้ด้วยเอกสารประกอบใหม่หรือที่ดีขึ้นไหม

  • "หากเรามีคู่มือสไตล์ ผู้ทำคอมมิตจะตรวจสอบคู่มือก่อนส่ง PR ได้ ผู้ตรวจสอบจะรู้ว่าต้องตรวจสอบอะไร ผู้ตรวจสอบและผู้มีส่วนร่วมจะไม่ต้องโต้แย้งเรื่องการจัดรูปแบบ โทน และสไตล์อีกต่อไป"
  • "หากเรามีเอกสารประกอบเกี่ยวกับรหัสข้อผิดพลาด ผู้ใช้ก็จะพบคำตอบในเอกสารประกอบนั้นแทนที่จะต้องเปิดปัญหา"
  • "อืม ดูเหมือนว่าเอกสารประกอบที่ดีขึ้นจะแก้ปัญหา CI/CD ไม่ได้"
  • "เราน่าจะเริ่มการประชุมแต่ละครั้งด้วยมุกขำๆ ก็ได้นะ การสร้างคอลเล็กชันมุกตลกช่วยทำให้เราเริ่มการประชุมด้วยรอยยิ้มได้"

ระบุให้ชัดเจน

คุณคำนวณโจทย์ในเชิงปริมาณได้ไหม

  • ""การผสาน PR ใช้เวลานานเกินไป" หมายความว่าอย่างไร 2 เดือน หรือ 2 สัปดาห์ ผู้มีส่วนร่วมต้องรอการตรวจสอบนานแค่ไหนก่อนที่จะยอมแพ้"
  • "ปัญหาเกี่ยวกับรหัสข้อผิดพลาดที่ถือว่า "มีมากเกินไป" มีจำนวนเท่าใด"
  • "อืม … "ไม่พอใจ" มากแค่ไหนถึงเรียกว่า "ไม่พอใจเกินไป"

ตรวจสอบความสามารถในการวัดผล

คุณจะตรวจสอบเมตริกที่เสนออย่างไร วัดผลได้อย่างง่ายดายและแม่นยำไหม การวัดผลขึ้นอยู่กับผู้ที่ทําการวัดหรือไม่

  • "เราวัดระยะเวลาที่คำขอดึงข้อมูลเปิดอยู่และระยะเวลานับตั้งแต่ขอรับการตรวจสอบได้ง่ายๆ เราไม่สามารถวัดได้อย่างแน่ชัดว่าผู้มีส่วนร่วมเลิกทำเมื่อใด"
  • "เราสามารถนับจํานวนปัญหาที่ติดแท็ก "error-code" หรือค้นหาข้อความรหัสข้อผิดพลาดภายในปัญหาได้"
  • "เราไม่สามารถวัดความหน้าบึ้งของผู้คนอย่างมีชั้นเชิงหรือแม่นยำได้จริงๆ"

เพิ่มเมตริกรอง

มีเมตริกอื่นๆ ที่ช่วยให้คุณทราบว่าเอกสารประกอบช่วยแก้ปัญหาได้หรือไม่ เมตริกเป้าหมายเหมือนกันในทุกกรณีไหม

  • "PR ที่ยาวขึ้นต้องใช้เวลาตรวจสอบนานขึ้น เราจึงควรมีเกณฑ์ที่แตกต่างกันสำหรับ PR แต่ละขนาด เราต้องการวัดเวลาในการผสาน PR ขนาดเล็ก กลาง ใหญ่ และขนาดใหญ่"
  • "เราสามารถตรวจสอบจำนวนการเข้าชมที่เอกสารรหัสข้อผิดพลาดของเราได้รับ และดูว่าตัวเลขจำนวนดังกล่าวสัมพันธ์กับปัญหาที่เปิดอยู่น้อยลงหรือไม่"

เลือกระยะเวลา

  • "เราคิดว่า 2 สัปดาห์เป็นช่วงเวลาที่สมเหตุสมผลในการรวมศูนย์ PR ขนาดเล็กถึงขนาดกลางเข้าด้วยกัน และควรรวม PR ทั้งหมดภายใน 1 เดือน ดังนั้นเราจะวัดทุก 2 สัปดาห์"
  • "การอัปเดตจํานวนปัญหาที่เกี่ยวข้องกับรหัสข้อผิดพลาดเป็นรายวันนั้นไม่สมเหตุสมผล เนื่องจากเวลาโดยเฉลี่ยในการแก้ไขปัญหาคือ 1 สัปดาห์ เราจะวัดผลเป็นรายสัปดาห์"

ตั้งเป้าหมาย

คุณต้องทำการเปลี่ยนแปลงมากน้อยเพียงใดในเมตริกที่เลือกจึงจะบอกว่าโปรเจ็กต์นี้ประสบความสำเร็จ ลองตั้งเป้าหมายเชิงปริมาณสําหรับเมตริกที่เลือก

  • "หากเราบรรลุเป้าหมายในการปิด PR ใหม่ทุกรายการภายในเวลาไม่ถึง 1 เดือน แสดงว่าเราประสบความสำเร็จ หากเวลาเฉลี่ยในการปิด PR ขนาดใหญ่ลดลง 2 สัปดาห์ แสดงว่าเราประสบความสำเร็จอย่างมาก"
  • "ตามหลักการแล้ว เราไม่ควรพบปัญหาใหม่เกี่ยวกับข้อผิดพลาด แต่เราจะถือว่าโปรเจ็กต์ของเราประสบความสำเร็จหากปัญหาที่เกี่ยวข้องกับข้อผิดพลาดที่เปิดอยู่ลดลง 50%"