คู่มือนี้มีไว้เพื่อช่วยองค์กรต่างๆ เข้าใจว่าปัญหาประเภทใดบ้างที่อาจแก้ไขได้ด้วยเอกสารประกอบที่ดีขึ้น และวิธีเลือกเมตริกที่เหมาะสมสำหรับโปรเจ็กต์เอกสารประกอบ
ระยะปัจจุบัน:
เผยแพร่กรณีศึกษาแล้ว ดูไทม์ไลน์
ระบุปัญหาของคุณ
ก่อนเลือกเมตริก ให้ตรวจสอบว่าคุณเข้าใจปัญหาที่ต้องการแก้ปัญหาเป็นอย่างดี โปรดระบุให้เฉพาะเจาะจงที่สุด
- "คำขอดึงข้อมูลสำหรับเอกสารประกอบเกี่ยวกับการเตรียมความพร้อมใช้เวลาผสานนานเกินไป ผู้ร่วมให้ข้อมูลจึงเลิกพยายามและจากไป"
- "เราพบว่ามีคำขอความช่วยเหลือเกี่ยวกับรหัสข้อผิดพลาดเข้ามาเป็นจำนวนมาก"
- "ไปป์ไลน์ 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%"
ข้อมูลที่เกี่ยวข้อง
- อ่านคู่มือผู้ดูแลระบบองค์กรเพื่อขอความช่วยเหลือเกี่ยวกับงานที่เกี่ยวข้องกับรายงาน