สวัสดีค่า วันนี้ มิ้นต์ กับจูนจากทีม Business Analyst หรือเราเรียกกันสั้นๆว่า BA จะมาเล่าขั้นตอนการทำงานคร่าวๆของทีม ให้ทุกคนเข้าใจและเห็นภาพกันมากขึ้นค่ะ

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

หากคิดถึงการพัฒนาระบบโดยทั่วไปแล้ว ทุกคนอาจจะนึกถึงการเริ่มลงมือเขียนโปรแกรม แต่แท้จริงแล้วก่อนที่จะเริ่มพัฒนาระบบด้วยการเขียนโปรแกรมนั้น กระบวนการที่สำคัญไม่แพ้กันนั่นก็คือ การเก็บ Requirement เพราะถ้าเรายังไม่ทราบว่าระบบที่เราจะสร้างนั้น จะถูกใช้เพื่อแก้ไขปัญหาอะไร มีใครเป็นผู้ใช้งาน หรือ มีข้อจำกัดทาง Technology อะไรบ้าง อาจจะทำได้ระบบที่ถูกพัฒนาขึ้นมาไม่ตรงกับความต้องการที่แท้จริงของผู้ใช้งานได้ 

การเก็บ Requirement สามารถเริ่มจาก Product Manager และ Business Analyst เก็บรวบรวม ปัญหาที่ Users พบ, แนวคิดจาก Stakeholder (Business Direction) หรือความต้องการของ User

หลังจากนั้นทาง BA จะมีการสำรวจเพิ่มเติมว่า Product ของเรานั้นมีเป้าหมายอะไร มีข้อจำกัดอะไร มีแนวทางหรือมุ่งเน้นไปในทิศทางใด ทำเพื่อแก้ปัญหาใด เพื่อตอบโจทย์ทางด้านการตลาดอย่างไร มีข้อจำกัดจาก Business Direction ใดบ้างที่ส่งผลต่อการออกแบบระบบ ที่กล่าวมาทั้งหมดนี้เพื่อให้ได้มาซึ่งภาพรวมคร่าวๆก่อนการเริ่มลงรายละเอียดของ Requirement และ Condition ก่อนที่จะนำไปให้ทาง Developer ได้วางแผนพัฒนา Product ต่อไป

เริ่มเก็บ Requirement ยังไงดีนะ?

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

• การสัมภาษณ์ (Interview)

  • สอบถามผู้ใช้งานโดยตรงว่ามีความต้องการอย่างไร โดยสามารถทำตัวต้นแบบ (Prototyping) หรือ การทำแผนภาพการทำงาน (Use Case Diagram) มาประกอบการสอบถามได้เพื่อให้เห็นภาพการใช้งานได้มากขึ้น

• การระดมสมอง (Brainstorming)

  • คือการนำแนวคิด หรือข้อมูลจากผู้ที่มีส่วนเกี่ยวข้องที่นึกขึ้นได้ในขณะนั้นเอามารวบรวมไว้บนกระดานหลัก เพื่อให้ทุกคนเห็นแนวทางที่เสนอทั้งหมด โดยไม่มีการตัดสินว่าความคิดของผู้ที่เข้าร่วมถูกต้องหรือไม่ โดยแนวทางทั้งหมดนี้จะถูกใช้ในการประเมินผลภายหลังว่าสามารถใช้งานได้จริงและ เหมาะสมกับ Product ที่ทำหรือไม่

• การรายงานปัญหา และการวิเคราะห์ข้อเสนอแนะ (Problem Reports and Suggestion Analysis)

  • ดูจาก Feedback จากผู้ใช้งานว่ามีความต้องการอะไรเพิ่มเติมหรือไม่ และจะปรับแก้จากเดิมที่ออกแบบมาได้อย่างไร

  • ดูจาก Report ท่ีทำออกมาเป็นสถิติว่า Product ควรจะมีทิศทางในการปรับปรุงระบบอย่างไร 

• การวิจัย (Research)

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

การ Scope ข้อมูลความต้องการของผู้ใช้งานเพื่อช่วยให้ผู้เกี่ยวข้องเข้าใจตรงกัน สามารถทำได้ โดยการเริ่มต้นจากการตั้งคำถามดังนี้

• เราจะทำระบบนี้ไปเพื่ออะไร (Why)

  • จุดประสงค์ของ Feature หรือ ระบบนั้นๆ เพื่อใช้ระบุปัญหาของผู้ใช้งานที่เราต้องการจะแก้ไข

• ระบบจะทำอะไรได้บ้าง (What)

  • ระบบประกอบไปด้วย Feature อะไรบ้าง และมีระบบอื่นๆที่ได้รับผลกระทบหรือไม่

• ระบบจะถูกใช้งานโดยใคร มีใครเป็นผู้มีส่วนได้ส่วนเสีย มีใครได้รับผลกระทบจากระบบ (Who)

  • เพื่อระบุผู้ใช้งานหลัก และ ผู้ใช้งานที่ได้รับผลกระทบเมื่อมีการเพื่อ ระบบหรือ Feature ใหม่

• ระบบจะถูกใช้งานเมื่อไร (When)

  • เพื่อระบุความเร่งด่วนหรือความสำคัญ ในการใช้งานของระบบหรือ Feature นั้นๆ

• ระบบจะมีกระบวนการการทำงานอย่างไร (How)

  • เพื่อระบุ Resource ที่ระบบหรือ Feature นั้นที่ต้องการใช้งาน เช่น Platform, ระยะเวลาที่ต้องใช้ในการพัฒนาระบบหรือ Feature หรือ จำนวนผู้พัฒนาระบบ (Developer)

  • เพื่อระบุวิธีการใช้งานระบบให้แก่ผู้ใช้งานหลัก และคำนึงถึงการออกแบบระบบว่ามีความเหมาะสมกับประสบการณ์การใช้งาน (User Experience) หรือไม่

แล้วเราจะรู้ได้อย่างไรว่าข้อมูลที่เราได้มาควรถูกใส่ไว้ใน Requirement ?

เนื่องจากข้อมูลที่เราได้มานั้น อาจจะมีทั้งความคิดเห็นส่วนตัว หรือเป็นความต้องการที่อาจจะต้องเก็บไว้ต่อยอดใน Release อื่นๆ ดังนั้น ขั้นตอนการเก็บข้อมูล หรือสรุปผลจึงมีความสำคัญเช่นกัน เพื่อให้ได้ Requirement ที่มี Scope ชัดเจนและตอบโจทย์ทั้ง Stakeholder, User และ ยังอยู่ใน Limitation ทาง Technical โดยเมื่อทุกฝ่ายเห็นภาพรวมตรงกันแล้ว จะทำให้ลดอุปสรรคการสื่อสารระหว่างทีมด้วยค่ะ โดยเราสามารถสรุป Requirement ที่เราได้มาโดยคำนึงถึงหัวข้อต่อไปนี้

1. อะไรคือปัญหาของผู้ใช้งาน (Pain Point)

เราสามารถวิเคราะห์ Pain point ของ User ที่ได้จากการเก็บ Requirement ที่เล่าไปแล้วด้านบน หรือ จากการสังเกตประสบการณ์จากผู้ใช้งานว่ามี Business process หรือ ข้อจำกัดของผู้ใช้งานเป็นอย่างไร เพื่อระบุ ปัญหาที่แท้จริงที่ต้องได้รับการแก้ไข

2. มี Corner Case หรือ Worst Case อะไรบ้าง

Corner Case คือ สถานการณ์ที่ไม่ปกติแต่อาจจะเกิดขึ้นได้ และทำให้ระบบทำงานได้ไม่เต็มประสิทธิภาพ

Worst Case คือ สถานการณ์เลวร้ายสูงสุดที่อาจจะเกิดขึ้นได้กับระบบ โดยอาจจะทำให้ระบบทำงานต่อไม่ได้และส่งผลกระทบกับการใช้งานของ User

การระบุ Corner Case และ Worst Case จะช่วยทำให้เราสามารถระบุวิธีการรับมือและรู้ว่ามีผลกระทบอะไรบ้าง เมื่อมีเหตุการณ์ที่ทำให้ระบบเราทำงานไม่ปกติ 

3. สร้าง User Stories 

การระบุ User Stories เป็นการเล่าความต้องการของUser  เป็นขั้นตอนเพื่อหาผลกระทบหรือสิ่งที่ต้องเพิ่มเติมใน Requirement เพื่อให้ได้คำตอบว่า Software ที่เรากำลังจะเริ่มต้นลงมือทำ ควรจะมี Feature ใดบ้าง เป็นความต้องการของใคร ทำเพื่ออะไร และ ต้องทำอย่างไร 

ถึงแม้ว่าเราจะสามารถระบุ Scope ได้ชัดเจนมากขึ้นจาก User Stories แต่ก็ยังไม่สามารถบอกรายละเอียดการ Implement ได้ทั้งหมด ดังนั้นจึงต้องมีเอกสาร Condition เพื่อใช้บอกเงื่อนไขการใช้งานว่าระบบทำงานอย่างไรอย่างละเอียดอีกครั้ง

เมื่อเราได้ภาพรวมคร่าวๆเกี่ยวกับ Requirement แล้ว Step ต่อไปจะเป็นการวิเคราะห์ Requirement ที่ได้มาในมุมมองอื่นๆ เพื่อระบุให้ Requirement ชัดเจนมากยิ่งขึ้น โดยสามารถติดตามได้ใน Blog Requirement Analysis งานเล็กๆ ที่ไม่ควรมองข้าม จากทีม BA ได้เลยนะคะ แล้วเจอกันค่ะ

References:

เนื้อหา

https://www.jamasoftware.com/requirements-management-guide/requirements-gathering-and-management-processes/what-is-requirements-gathering

https://asana.com/resources/requirements-gathering

https://nmgtechnologies.com/blog/requirement-gathering-solve-biggest-problems-consulting.html

https://aoteastudios.com/2011/03/analysing-business-process-pain-points-to-get-better-requirements/

https://orases.com/process-gathering-requirements-software-development/
https://www.atlassian.com/agile/project-management/user-stories

https://www.bridging-the-gap.com/53-tips-discover-all-the-requirements/

รูปภาพ

https://www.pexels.com/