ตรวจสอบความจำเป็นของฟีเจอร์ก่อนสร้าง

กระบวนการ

ทำตามลำดับนี้

1. ระบุความสามารถที่เสนอ ผลลัพธ์ที่ต้องการ ผู้ใช้ที่ได้รับผลกระทบ กำหนดการตัดสินใจ ทางเลือกปัจจุบัน และหลักฐานที่จะเปลี่ยนการตัดสินใจ
2. รวบรวมพฤติกรรมผู้ใช้ หลักฐานฝ่ายสนับสนุน งานวิจัย ข้อมูลผลิตภัณฑ์ และบริบทธุรกิจ โดยแยกคำขอที่มีผู้พูดออกมาจากความต้องการที่สังเกตได้
3. เชื่อมโยงความต้องการกับงานของผู้ใช้ ความถี่ ความรุนแรง ความเหมาะสมเชิงกลยุทธ์ ข้อจำกัด และต้นทุนของการปล่อยให้ปัญหาค้าง
4. ออกแบบการทดสอบการค้นพบที่เล็กและปลอดภัยที่สุด เช่น ต้นแบบ การทดลองแบบบริการ กรวยที่มีการวัด หรือการสนทนากับลูกค้า พร้อมเกณฑ์สำเร็จและการหยุด
5. เปรียบเทียบการสร้าง การซื้อ การเปลี่ยนกระบวนการ การเลื่อน และการปฏิเสธ ตามมูลค่าที่คาด ต้นทุน ความย้อนกลับ ความเสี่ยง และมูลค่าการเรียนรู้
6. บันทึกการตัดสินใจ ความมั่นใจ เจ้าของงาน วันที่ สมมติฐาน หลักฐานที่หักล้าง และการทดสอบหรือตัวชี้วัดติดตามที่จะทำให้เกิดการเปลี่ยนแปลง
7. ส่งบันทึกตัดสินใจพร้อมหลักฐานและความเสี่ยงที่ยังไม่ได้แก้ไข และหยุดก่อนที่จะผูกค่าใช้จ่าย เปิดเผยผู้ใช้ หรือประกาศการตัดสินใจสร้าง

เตรียมสิ่งนี้

ข้อมูลที่แมวจะขอ

• ข้อเสนอฟีเจอร์และผลลัพธ์เป้าหมาย
• หลักฐานจากผู้ใช้และธุรกิจ
• ทางเลือกและข้อจำกัด
• เจ้าของการตัดสินใจและช่วงเวลาทดสอบ

เราเตอร์ + playbook เดียว

จัดเส้นทางก่อน เลือกอันเดียว

Cat Paw โหลด playbook เดียวต่องาน ไม่ผสมหลายอัน เริ่มที่เราเตอร์นี้ เส้นทางที่เหลือเป็นตัวเลือกเฉพาะ workflow

• เราเตอร์: minimal-code-pack
• skills/minimal-code-pack/feature-necessity-decision/SKILL.md

เสร็จหมายถึง

จุดจบที่ตรวจได้

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

แหล่งที่มา

กระบวนการนี้มาจากไหน

1. github.com/DietrichGebert/ponytail/tree/e3ba2aa6f1e6f0bc4d69eb09c9f0d0a93af56156/
2. www.gov.uk/service-manual/user-research
3. www.gov.uk/service-manual/service-assessments

แหล่งที่มาตั้งรูปแบบของ workflow โพสต์ Reddit และชุมชน ถ้ามี ให้ถือเป็นเรื่องเล่าจากผู้ปฏิบัติ ไม่ใช่ข้อเท็จจริงสากล