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

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

ระยะปัจจุบัน:
เผยแพร่กรณีศึกษาแล้ว ดูไทม์ไลน์

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

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

  • "คำขอดึงข้อมูลสำหรับเอกสารประกอบเกี่ยวกับการเตรียมความพร้อมใช้เวลาผสานนานเกินไป ผู้ร่วมให้ข้อมูลจึงเลิกพยายามและจากไป"
  • "เราพบว่ามีคำขอความช่วยเหลือเกี่ยวกับรหัสข้อผิดพลาดเข้ามาเป็นจำนวนมาก"
  • "ไปป์ไลน์ 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%"