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