Business Analyst (BA) ทำอะไรกันบ้างน้า…?

สวัสดีค่า วันนี้เมย์จะมาแชร์การทำงานของ Business Analyst ให้ฟังกันนะคะ

บางคนอาจจะสงสัยว่า BA เนี่ย ทำงานยังไง ต้องมี Scope of work อะไรบ้าง

ขอท้าวความก่อนว่า ในแต่ละองค์กร Process การเป็น BA อาจจะไม่เหมือนกันนะ

BA ทั่วๆไป ทำอะไรกันบ้าง…?

ขอเริ่มจากชื่อตำแหน่ง คือ Business Analyst ในวงการเรียกสั้นๆ ว่า BA

ปกติงานหลักของ BA คือการเป็นเหมือนคนที่เป็นตัวกลางระหว่าง User กับ Dev หรือถ้าจะให้เรียกง่ายๆ ก็คือ เราเป็นล่ามแปลภาษาสิ่งที่ user ต้องการ ออกมาให้ Dev ให้เข้าใจ ซึ่งสิ่งต่างๆที่จะไปถึง Dev จะต้องมีการกลั่นกรองวิเคราะห์ ซึ่งคนที่จะทำ Role นี้ จะต้องมีทักษะที่เข้าใจในฝั่ง Business และ Develop ได้ ซึ่งในแง่ความเป็นจริง พวก Business ทางฝั่ง user เราไม่มีทางรู้ทั้งหมดมาก่อนได้ ดังนั้น ทักษะหลักที่ต้องมีของ BA คือ ทักษะที่เราทำยังไงก็ได้ ให้เราเรียนรู้ข้อมูลจาก user ให้ได้มากที่สุด และ เร็วที่สุด

Process การทำงาน BA ในทีมของเรา

เดี่ยวจะขอลง Detail แบ่งเป็นหัวข้อหลักๆตามนี้...

1) เก็บ Requirement หา As-Is ระบบปัจจุบัน

“เริ่มต้นดี มีชัยไปกว่าครึ่ง“

การเก็บ Requirement เป็นขั้นตอนแรกในการทำงานของ BA ซึ่งโจทย์ของ Business Analyst คือ ทำยังไงก็ได้ในเวลาอันจำกัดให้สามารถเข้าใจระบบ และเก็บ Requirement กลับมาให้ได้มากที่สุด

หลังจากที่เก็บ Requirement แล้ว สิ่งที่ BA ต้องทำต่อไปก็คือการทำสรุป As Is (กระบวนการทางธุรกิจในปัจจุบัน) และนำเสนอ To Be (ระบบที่จะทำ) เพื่อนำไปใช้ไปร่างหน้าจอระบบ

Output ที่ได้จะมี Gap Analysis Document และ Wireframe เบื้องต้น

ตอนนี้เราเจอโควิด ทำให้การเก็บ requirement เป็นไปได้แค่การ video call หรือ เก็บ requirement ผ่าน meet

แต่ถ้าสมมุติจบช่วงโควิดแล้ว อยากแนะนำ ให้เราไปเก็บ Requirement แบบ Onsite เจอแบบ Face on Face เลย มันจะทำให้เรา เข้าใจ และสามารถลงลึกไปดูการทำงานของแต่ละส่วน จะดีมากกว่า call Meeting เฉยๆนะ

เมื่อมีการเก็บ requirement เบื้องต้นแล้ว ก่อนที่จะลงมือทำ user story อยากให้เราเอา wireframe หรือ พวก requirement ที่มี ไปคุยกับทีม Developer เพื่อ ประเมินว่าทำได้ ทำไม่ได้ หรือ ใช้เวลามากน้อยแค่ไหน เพื่อที่จะได้มี info ไปคุยกับ BU หรือ PM นะ

“ก่อนไปเก็บ Requirement อะไร ควรทำการบ้านมาให้ดีก่อน ถ้า User ไม่พูด เราต้องเป็นฝ่ายจี้ถาม ซึ่งแน่นอนว่าถ้าเราไม่ทำการบ้านมาก่อน เราก็ไม่รู้ว่าจะถามอะไร และสุดท้ายก็ไปแบบไม่ได้อะไรกลับมา”

2) การออกแบบ Wireframe เบื้องต้น

อีกหน้าที่นึงของ BA หลังจากการเก็บ Requirement คือการนำ requirement ที่ได้ ไปทำ wireframe screen ก่อนไปคุยกับทีม User หรือ UX/UI หรือ Developer

“แน่นอนว่าการเห็นภาพย่อมดีกว่าตัวหนังสือ ซึ่งสิ่งนี้แหละจะเป็นสิ่งที่ทำให้ทุกฝ่ายเริ่มเห็นภาพระบบเป็นภาพเดียวกัน”

Tools ที่ใช้ สามารถใช้ miro ได้เลยยยย

ซึ่งข้อดีของ Miro คือ เราสามารถ comment ใส่ Post-it หรือ แชร์ให้คนอื่นๆเห็นได้เลย ทำงานร่วมกันได้แบบคูลๆ

3) ทำ Prototype UX/UI

ขั้นตอนนี้จะเป็น Step ที่ทีม UX/UI เข้ามาทำ Prototype ที่ได้รับ Wireframe มาจาก BA หลังจากที่ได้ Prototype มาแล้ว หน้าที่ของ BA ก็คือ เข้าไปดูหน้าจอ ความถูกต้อง รวมถึงการเก็บ Happy case และ negative case ต่างๆ ตามตัวอย่างรูปด้านล่าง

4) การทำ User Story

ขั้นตอนนี้จะเป็น Main หลักของงาน BA เลยก็ว่าได้ เป็นขั้นตอนที่ทางทีม BA จะนำพวก Wireframe/Prototype และพวก Requirement มาจัดสรรเขียนเรื่องราวไว้ในเล่มทั้งหมด เพื่อส่งต่อให้ทาง Dev และ Tester ไปทำงานต่อ

การเขียน User Story นี้ก็เป็นทักษะสำคัญของ BA เช่นกัน โดยโจทย์ของ BA คือ ทำให้ยังไงก็ให้เขียนออกมาแล้วทุกฝ่ายเข้าใจให้ได้มากที่สุด โดยก็จะมี PO เป็นคน Review และ Approve User Story

5) การทำ SIT (System Integration Test)

SIT เป็นขั้นตอนการ Test ระบบภายใน หลังจากที่ Dev พัฒนาเสร็จเรียบร้อย ซึ่งขั้นตอนนี้จะเป็นหน้าที่ของหลักของ Tester, Dev และ BA ค่ะ โดยทาง Tester ก็จะอ่านรายละเอียดระบบที่พัฒนาจาก User Story ของ BA และ Test ตามนี่แหละ ซึ่งถ้าไม่ได้ตาม Story ทาง Dev ก็ต้องทำการแก้เพิ่มเติมนะ

“ทุกฝั่งควร Communicate กันให้เยอะที่สุด อย่าแยกเป็นทีม Dev ทีม Test ทีม BA เราควรมองว่าทุกทีมอยู่ใน Project เดียวกัน”

6) การทำ UAT (User Acceptance Test)

Step นี้ จะเป็นการให้ user หรือ TQA มาลองใช้ระบบที่พัฒนา ถ้ามีระบบส่วนไหนพอใช้แล้วตรงตามเงื่อนไข หรือไม่ตรงกับ User Story ก็ต้องมีการกลับไปแก้ไขก่อนจะนำขึ้น Production จริง

Step นี้ BA จะไม่ได้ลงไป execute เองนะ แต่จะ support ในขาของ Requirement หรือ ช่วยคุยกับทีม Dev ให้

7) จะจบ Project แล้ว เตรียมขนของขึ้น Go Live

ส่วนใหญ่แล้ว BA จะช่วยดูในเรื่องของ PVT Testcase รวมไปถึง Implementation Plan ด้วย ถ้าเป็นโปรเจคใหญ่ๆ อาจจะเริ่มทำ Requirement ของ Phase ถัดๆไปเลย กรณีที่ Project ที่ขึ้นไปไม่เรียบร้อย ก็ต้องมานั่งเก็บ defect หรือ CR ต่อจากระบบเดิมที่ขึ้นไปนะ

BA mindset for my Team

• ทำการบ้านให้ดี ก่อนไปเก็บ Requirement
• BA ต้องไปเก็บ requirement กับ user เอง + พาทีม UX/UI เข้าไปฟังด้วย
• ใน Task ที่ BA เป็น owner เช่น User Story, ทำ Wireframe >> BA ควรเป็น Lead และให้ฝ่ายอื่น Support
• Communicate กันให้เยอะที่สุด อย่าแยกเป็นทีม BA, Design, Dev, Test เราควรมองว่าทุกทีมอยู่ใน Project เดียวกัน รวมถึงฝั่ง User ด้วย
• พยายาม Design ให้ดี ไม่มั่นใจ ให้ถาม Lead และ Dev Team
• พยายามทำทีมให้มี Power และมีความน่าเชื่อถือ เป็นมิตรจากการ Communicate กับทุกฝ่ายให้ดีตั้งแต่ต้น
• อย่าเขินอายที่จะถาม ถามไปเถอะ ไม่รู้ก็ถามไป… ^_^

เอาละคะ ตอนนี้ทุกคนน่าจะพอเข้าใจกันถึง scope of work ของ BA กันมากขึ้นเนอะ ไว้คราวหน้าจะหา Topic ที่น่าสนใจมาเล่าให้ฟังใหม่ ขอบคุณที่อ่านกันจนจบค่า ^^