System Analyst ต้องทำอะไรบ้าง ในแต่ละ Sprint?
ใคร ๆ ก็บอกว่า “วิเคราะห์ระบบ” แล้วเราต้องทำอะไรบ้างล่ะ?
ในโลกของการทำงานด้านการพัฒนาซอฟต์แวร์ คนที่ทำตำแหน่ง System Analyst หรือที่เรียกกันสั้น ๆ ว่า SA ถือว่าเป็นสมาชิกในทีมที่ขาดไปไม่ได้ แต่รู้หรือไม่ น้อยคนที่จะเข้าใจว่า System Analyst นั้นต้องทำอะไร เพราะส่วนใหญ่ก็จะตอบกันแบบสั้น ๆ ว่า
“ทำหน้าที่วิเคราะห์ระบบ”
ว่าแต่ต้องทำอะไรบ้างล่ะ? บทความนี้ออมจะมาเล่าให้ฟังว่าในแต่ละวัน SA เขาทำอะไรกันบ้าง
หมายเหตุ — การทำงานของบริษัทที่ออมทำงานอยู่จะเป็นแบบ Agile ที่แบ่งช่วงเวลาในการทำงานเป็น Sprint ที่มีระยะเวลา 2 สัปดาห์ ดังนั้นเรื่องราวต่อไปนี้จะเป็นเรื่องราวของออมที่ต้องทำงานในแต่ละ Sprint
โดยสิ่งที่ SA อย่างออมจะต้องทำในแต่ละ Sprint จะแบ่งออกมาเป็นขั้นตอนได้ทั้งหมดประมาณนี้
- เก็บ Business Requirement
- วิเคราะห์ Business Requirement เพื่อทำเป็น Technical Requirement
- วิเคราะห์ผลกระทบที่เกิดจาก Technical Requirement
- ทำเอกสาร Technical Requirement ให้กับคนในทีม
- Support การทำงานของคนในทีมและลูกค้า
- จัดทำเอกสารสำหรับส่งมอบงานให้ลูกค้า
เก็บ Business Requirement
สิ่งที่ออมทำเป็นอย่างแรกของแต่ละ Sprint คือ การไปหาลูกค้า เพื่อเก็บ Business Requirement บางโปรเจคไปครึ่งวัน บางโปรเจคไปเต็มวัน ขึ้นอยู่กับรายละเอียดของงานว่ามากน้อยแค่ไหน
แต่อย่าลืมว่าการที่จะไปหาลูกค้า เราต้องนัดประชุมลูกค้าก่อนล่วงหน้า และให้ลูกค้ายืนยันการนัดหมายกลับมาด้วยนะ ไม่งั้นเราจะไปเก้อ หลังจากเก็บ Requirement เสร็จ เมื่อกลับแล้วหรือในวันถัดไป เราต้องเขียนสรุปการประชุม และส่งสรุปการประชุมไปทางอีเมล์ให้ลูกค้าด้วย เพื่อยืนยันข้อมูลว่าข้อมูลที่เรากับคุยกับลูกค้านั้นตรงกันทั้งสองฝ่าย
วิเคราะห์ Business Requirement เพื่อทำเป็น Technical Requirement
หลังจากที่ลูกค้ายืนยันสรุปการประชุมกลับมา ว่าเข้าใจตรงกันแล้ว ขั้นต่อไปเราจะเอา Business Requirement ที่ได้จากลูกค้ามาวิเคราะห์ เพื่อแบ่งออกมาเป็น Technical Requirement เช่น รอบนี้เราไปเก็บ Business Requirement เกี่ยวกับ การเข้าสู่ระบบด้วย Facebook เราต้องเอามาวิเคราะห์ว่าต้องทำอะไรบ้าง ถึงจะเข้าสู่ระบบด้วย Facebook ได้ เป็นต้น
วิเคราะห์ผลกระทบที่เกิดจาก Technical Requirement
แต่ ๆ นอกจากเราดูเรื่อง Technical แล้ว เรายังต้องวิเคราะห์ด้วยว่า Business Requirement ที่เรารับมา มันเป็น New Feature (ยังไม่เคยมีระบบนี้มาก่อน) หรือ Enhancement Feature เก่า (มีระบบเก่าอยู่แล้ว และต้องการเพิ่มการทำงานบางอย่างเข้าไปในนั้น)
Business Requirement ที่เรารับมาส่งผลกระทบกับส่วนไหนที่เราทำมาแล้วบ้าง เพื่อดูว่ามีโอกาสเกิดปัญหาอะไรขึ้นมาบ้าง เช่น Flow เก่ามีเข้าสู่ระบบด้วย Username และ Password อยู่แล้ว ถ้าเราจะเพิ่ม เข้าสู่ระบบด้วย Facebook เข้าไป จะต้องเปลี่ยน Design ใหม่ หรือจะต้องแทรก Flow เพิ่มเข้าไปจากของเก่า
ทำเอกสาร Technical Requirement ให้กับคนในทีม
เมื่อวิเคราะห์ Requirement คร่าว ๆ แล้ว หลังจากนี้ เราต้องเตรียมข้อมูลและเอกสารเพื่ออธิบาย Business Requirement ที่ได้รับมาจากลูกค้า และ Technical Requirement ที่เราวิเคราะห์ออกมาให้กับคนในทีม รวมถึงปัญหาที่เราเจอ เพื่อให้ทีมช่วยกันคิดว่าจะแก้ปัญหานี้ได้ยังไงบ้าง หลังจากเราอธิบายให้คนในทีมฟังเรียบร้อยแล้ว เราต้องมาเตรียมข้อมูลต่าง ๆ เช่น Flow, API หรือ Wording ที่ต้องใช้ในการทำงาน เป็นต้น
Support การทำงานของคนในทีมและลูกค้า
สุดท้ายเราจะมีหน้าที่ Support ทั้งลูกค้า และทีม เกี่ยวกับปัญหาต่าง ๆ เพื่อให้สามารถส่งงานออกมาได้
อาจจะฟังดูเหมือนว่าช่วง Support ลูกค้าและคนในทีมจะมีช่วงเวลาว่างอยู่บ้าง แต่จริง ๆ แล้วเราไม่ได้ว่างนะ เช่น
- ลูกค้าอยากเปลี่ยน Wording
- ในทีมมีคำถามเกี่ยวกับ Flow อยากให้คุยกับลูกค้าอีกรอบ
- ลูกค้ามีการเปิด Issue ที่ไม่ได้อยู่ใน Scope มาให้ทำ
- เตรียมข้อมูลสำหรับการ Deliver งานให้ลูกค้า หรือเข้าไป Deploy ระบบ
จัดทำเอกสารสำหรับส่งมอบงานให้ลูกค้า
สำหรับบางคนอาจจะต้องทำเอกสารเพื่อส่งลูกค้าในแต่ละ Sprint ด้วย ซึ่งเป็นเอกสาร SRS ที่เกี่ยวกับ Requirement ใน Sprint นั้น ๆ ซึ่งอาจจะต้องไปอัพเดทเอกสารเก่า หรือทำเอกสารเพิ่มขึ้นมาใหม่ แต่กรณีของออมจะไม่ค่อยทำส่งภายใน Sprint หรอก จะทำส่งหลังจบโปรเจคไปแล้วมากกว่า เพื่อลดขั้นตอนที่ต้องแก้เอกสารซ้ำไปซ้ำมาในแต่ละ Sprint
สุดท้ายนี้ทุกคนได้ทราบถึงกระบวนการการทำงานของ System Analyst ที่มากกว่าคำว่า “วิเคราะห์ระบบ” แล้ว ถ้าใครอยากลองหรือ อยากรู้อะไรเพิ่มเติมลองถามมาได้นะคะ
