โลกของการทำงานในบริษัทมักจะประกอบไปด้วยแผนกต่าง ๆ ที่คอยทำงานร่วมกันจนทำให้งานสำเร็จลุล่วงไปได้ด้วยดี ซึ่งทุกคนก็ทำสิ่งที่ตนเองถนัด เพื่อให้ได้ผลงานที่สมบูรณ์ที่สุด การพัฒนาระบบก็เช่นกันที่จะต้องประกอบไปด้วยคนหลายบทบาท เช่น Stakeholder, Product Manager (PM), Developer, Business Analyst (BA), Quality Assurance (QA) และอื่น ๆ

แต่ในที่นี้เราจะมาพูดถึงตำแหน่งงานไอทีที่น่าสนใจอีกหนึ่งตำแหน่งคือ Business Analyst (BA) ที่เป็นบทบาทในการทำหน้าที่วิเคราะห์ความต้องการของผู้ใช้งาน โดยอยู่บนพื้นฐานและความรู้ทางด้าน Business และ Technical ประกอบกัน ทำหน้าที่ในการสื่อสาร ประสานงาน และหาจุดกึ่งกลางระหว่าง Business, User และ Developer เพื่อให้ได้มาซึ่ง Requirement ที่ตอบโจทย์การใช้งาน ตลอดไปจนถึงดูแลเรื่องการส่งมอบงานและรับความคิดเห็นจาก User หรือผู้ที่เกี่ยวข้องทั้งหมดมาปรับปรุงต่อไป

แล้ว Business Analyst (BA) ที่ THiNKNET ทำงานกันอย่างไร เราได้แบ่งกระบวนการทำงานออกเป็น 6 ขั้นตอนดังนี้

ขั้นตอนที่ 1 การรวบรวมข้อมูล และ Idea เบื้องต้น

ก่อนที่ Business Analyst (BA) จะเริ่มดำเนินการทำงานได้ จะต้องทราบถึงที่มาที่ไปของความต้องการว่าเกิดจากปัญหาอะไร หรือมีจุดประสงค์ด้านใดบ้าง ผู้ใช้งานระบบคือใคร รวมไปถึง Business Model ต่าง ๆ 

หลังจากนั้นจะเข้าสู่กระบวนการรวบรวมข้อมูล  ซึ่งมีการรวบรวมได้หลายวิธี เช่น Research หรือ สัมภาษณ์ผู้ที่เกี่ยวข้อง เป็นต้น เพื่อให้ได้มาซึ่ง Requirement และ Idea เบื้องต้นที่จะสามารถนำไปวิเคราะห์และออกแบบในขั้นตอนถัดไปได้ 

สามารถอ่านบทความเกี่ยวกับการได้มาซึ่ง Requirement เพิ่มเติมได้ที่ การเก็บ Requirement คืออะไร? Requirement สำคัญอย่างไร?

ขั้นตอนที่ 2 การวิเคราะห์และออกแบบระบบ

เมื่อเราได้ Requirement และ Idea เบื้องต้นแล้ว ทาง BA จะเอาข้อมูลนั้นมาคิดวิเคราะห์ และออกแบบการทำงานของระบบ 

ซึ่งรูปแบบการออกแบบ Flow สามารถทำได้หลายแบบ มีทั้ง User Flow หรือ Context Diagram เป็นต้น โดยส่วนใหญ่แล้วในขั้นตอนนี้ เราจะเน้นไปที่การทำ User Flow มากกว่า ซึ่งการทำ User Flow จะมีการทำร่วมกับทีม UX/UI Designer เป็นหลัก ในกระบวนการนี้เราจะได้ User Interface (UI) สำหรับใช้ในการทำ Flow เพื่อส่งให้ผู้ที่เกี่ยวข้องทั้งหมดรับทราบและเข้าใจภาพรวมตรงกัน ก่อนที่จะเริ่มจัดทำเอกสาร Functional และ Non-Functional Requirement ในขั้นตอนถัดไป

สามารถอ่านบทความเกี่ยวกับการวิเคราะห์และออกแบบระบบ เพิ่มเติมได้ที่ Requirement Analysis งานเล็กๆ ที่ไม่ควรมองข้าม

ขั้นตอนที่ 3 การทำเอกสาร Functional และ Non-Functional Requirement

ในขั้นตอนนี้เป็นการจัดทำเอกสาร Functional และ Non-Functional Requirement โดยจะเราจะมาอธิบายให้เห็นภาพเกี่ยวความแตกต่างของทั้ง 2 เอกสารกัน

เริ่มกันที่เอกสารที่เรียกกันว่า Functional Requirement ก่อนเลย เอกสารนี้จะเกี่ยวกับความต้องการของระบบ  สิ่งที่ระบบจะต้องทํา หรือคาดว่าจะทํา ประกอบด้วยข้อมูลดังนี้ เช่น คำอธิบายเกี่ยวกับตัวระบบ, รายละเอียดเกี่ยวกับ Input ของระบบ, รายละเอียดของ Output ที่จะได้ รวมไปถึงรายละเอียดของข้อมูลที่จะต้องมีในระบบ

ต่อมาเป็นเอกสาร Non-Functional Requirement ที่เกี่ยวกับการกำหนดความต้องการที่นอกเหนือจาก Function การทำงานของตัวระบบ ซึ่งไม่ได้มาจากความต้องการของผู้ใช้โดยตรง เช่น สถิติการใช้งาน หรือการกำหนดเงื่อนไข Performance ต่างๆ โดยจะขอยกตัวอย่างหัวข้อที่เรามักจะนิยมพูดถึงบ่อยที่สุด ดังนี้

• SEO Requirement 
  เป็นเอกสารการกำหนด Meta Tag ต่างๆ เช่น Meta Title, Keyword, Description 

• Performance
  เป็นเอกสารการกำหนดประสิทธิภาพการทำงานของระบบ เช่น

• Core Web Vitals
  กำหนดให้ผ่านเกณฑ์ต่างๆของ Google ประกอบไปด้วย LCP, CLS, FID หรือคะแนน Pagespeed ต้องเป็น 90-100 (สีเขียว) เป็นต้น

• Response Time
  กำหนด Response Time ต่าง ของการทำงานในจุดต่าง ๆ เช่น ความเร็วในการค้นหาข้อมูลต้องแสดงผลลัพธ์ภายใน x วินาที เป็นต้น

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

โดยการทำเอกสารทั้งหมด จะต้องมีการตกลงร่วมกับทีมอื่นที่เกี่ยวข้องด้วย เช่น ทีม Data Science, Marketing หรือแม้กระทั่งทีม Developer เอง เมื่อเอกสารถูกจัดทำเสร็จและผ่านข้อตกลงเรียบร้อยแล้ว จะถูกส่งเข้าทีมพัฒนาต่อไป

สามารถอ่านบทความเกี่ยวกับ Non-Functional เพิ่มเติมได้ที่ ทำไมต้องมี Non-Functional Requirement

ขั้นตอนที่ 4 การส่งงานเข้าทีมพัฒนา

ทาง Project Manager จะเป็นคนรับ Requirement เข้าคิวงาน และคอยจัดสรรทีม เมื่อถึงคิวการทำงานแล้ว ทาง BA จะมีการเล่า Requirement ให้กับทีมที่เกี่ยวข้องฟัง หรือที่เรียกว่า “Grooming” เมื่อ Grooming เรียบร้อยแล้ว ทางทีม Development จะทำขั้นตอนที่เรียกว่า “Planning” ซึ่งจะเป็นขั้นตอนที่เกี่ยวกับการ Discuss User Flow อย่างละเอียด รวมไปถึงการจัดทำ Test Case ด้วย ถ้าหากทางทีมมีความคิดเห็นเกี่ยวกับการทำงานที่เป็นข้อจำกัดต่าง ๆ ก็จะมีการ Feedback กับทาง BA เพื่อปรับแก้ในระหว่างการ Planning โดยบางครั้ง  และบางส่วนงานอาจจะมีการนำกลับเข้าสู่ขั้นตอนที่ 2 อีกครั้ง 

หลังจากทางทีม Developer ทำ Planning เรียบร้อยแล้ว จะเริ่ม Implement และเมื่อทีม Implement ระบบเรียบร้อยแล้ว จะถูกส่งให้กับทาง QA และ BA ตรวจสอบตาม test case ที่ออกแบบไว้ในตอนต้นของระบบต่อไป

ขั้นตอนที่ 5 การตรวจสอบ และรับ Feedback 

ในขั้นตอนนี้จะมี QA และ BA ที่เป็นผู้เกี่ยวข้องหลัก โดย BA ตรวจสอบความถูกต้องให้ตรงกับ requirement ดูภาพรวมและประสานกับทาง QA เพื่อทดสอบเตรียมส่งมอบ Software ในส่วนการทำงานนี้ BA จะมีหน้าที่ทดสอบคล้าย ๆ QA แต่ อาจจะไม่ละเอียดเท่า QA  แต่ทั้งนี้การทำงานของทั้งคู่จะตรวจสอบความถูกต้องของระบบให้เป็นไปตาม Functional และ Non-Functional Requirement เหมือนกัน

ถ้าหากระบบไม่สามารถทำงานได้ตาม Requirement ทาง BA และ QA จะมีการแจ้ง Bug/Feedback ให้กับทางทีม Deverloper แก้ไข ก่อนที่ QA จะส่ง User Acceptance Test (UAT) ให้กับผู้ที่มีส่วนเกี่ยวข้องได้ทดสอบต่อไป เพื่อรับ Feedback การทำงานของระบบ 

ในบาง Product ไม่ได้มีแค่ UAT อย่างเดียว บางครั้งก็อาจจะเป็นการทำ Usability Test หรือการทำ A/B Testing เพื่อที่จะรับ Feedback ของ User มาปรับปรุงก่อนที่จะ Launch Product ออกไปจริงๆ 

อย่างไรก็ตามเมื่อผ่านกระบวนการทดสอบ รับ Feedback และแก้ไขครบเสร็จแล้ว จะมีการเข้าคิว Online ขึ้นให้ User ใช้งานจริง

ขั้นตอนที่ 6 การรับความคิดเห็นหลังจากส่งมอบ Product 

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

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

และนี่ก็คือ 6 ขั้นตอนการทำงานของ BA ที่ THiNKNET ทั้งหมด ถึงแม้เราจะไม่ได้เป็นคนลงมือพัฒนาระบบโดยตรง แต่เราก็เป็นคนที่อยู่กับ Product นั้นตั้งแต่เริ่มต้นการพัฒนาจนถึงส่งมอบให้ลูกค้า อาจจะดูไม่มีอะไรมาก แต่ทุกการดำเนินงานเราใส่ใจทุกฝ่ายเสมอ ถ้ามีพวกเราแล้วการพัฒนาระบบจะสมบูรณ์ขึ้นอย่างแน่นอน!

---
Photo by tirachardz on freepik