ข้ามไปยังเนื้อหา
QC/QA สู่ BA

Stakeholder และการเก็บ Requirement

ในบทนี้
  1. Why this matters
  2. 7.1 Stakeholder
  3. 7.2 Requirement Gathering
  4. What a BA needs to know

Why this matters

Requirement ที่ดีไม่ได้เกิดจากการนั่งคิดคนเดียว แต่เกิดจากการฟังคนที่ถูกต้องด้วยวิธีที่ถูกต้อง — ก่อนเขียนอะไรต้องรู้ก่อนว่า ใครเกี่ยวข้องบ้าง

7.1 Stakeholder

ระบุว่าใครเกี่ยวข้องกับระบบหรือปัญหาที่กำลังแก้:

Customer
QA Support
QA Engineer
Production
Engineering
Manager
IT
Developer
Security

จุดสำคัญ: แต่ละคนต้องการไม่เหมือนกัน — QA Support อยากค้นเร็ว, Manager อยากเห็นภาพรวมและตัวเลข, IT/Security สนใจสิทธิ์เข้าถึงและความปลอดภัยของข้อมูล, Developer ต้องการความชัดเจนว่าจะสร้างอะไร ถ้าเก็บความต้องการจากกลุ่มเดียว requirement จะเอียงและไปเจอแรงต้านทีหลัง

7.2 Requirement Gathering

วิธีเก็บความต้องการที่ BA ควรฝึกใช้ให้เป็น:

  • Interview — คุยเจาะรายคน เหมาะกับการขุดปัญหาเชิงลึก
  • Observation — ไปดูหน้างานจริงว่าเขาทำงานอย่างไร (สิ่งที่คนทำจริงมักต่างจากที่เล่า)
  • Workshop — รวมหลายฝ่ายมาตกลงร่วมกัน เหมาะกับเรื่องที่ต้องหาข้อสรุปข้ามทีม
  • Document analysis — อ่าน SOP, รายงาน, complaint history ที่มีอยู่
  • Existing system analysis — ศึกษาระบบที่ใช้อยู่ว่าทำอะไรได้/ไม่ได้ตรงไหน
  • Questionnaire — แบบสอบถามเมื่อต้องการข้อมูลจากคนจำนวนมาก

What a BA needs to know

คน QC/QA ได้เปรียบในข้อนี้มาก: การสอบสวน complaint ก็คือ requirement gathering รูปแบบหนึ่ง — คุณสัมภาษณ์คนหน้างาน สังเกตกระบวนการ และไล่อ่านเอกสารเป็นประจำอยู่แล้ว แค่เปลี่ยนเป้าหมายจาก “หาสาเหตุของเสีย” เป็น “หาความต้องการที่แท้จริง”