SA ที่หมายถึง System Analyst ยังสามารถแบ่งออกเป็น 2 ประเภท
1.) System Analyst
2.) Bussiness Analyst
ถ้าเป็นลักษณะที่ 1. ก็รู้ Business และเข้าใจ Requirement ในระดับที่สามารถออกแบบระบบ หรือ ส่วนใหญ่กระบวนทางธุรกิจก็มักจะหมายถึง Table ใน Database รวมไปถึงสามารถอธิบาย Business Flow ให้พวก Developer ทำโปรแกรมออกมาให้ตาม Requirement ของลูกค้า
เข้าใจว่างานหลักๆคือเน้นการสร้างระบบจึงต้องมี ความรู้ด้าน Program ด้วย ไม่อย่างนั้นจะคุยกะโปรแกรมเมอร์ไม่ค่อยรู้เรื่องเหมือนพูดกันคนละภาษา
แต่ คนพวกนี้จึงอาจโดนเกณฑ์ไป coding ถ้าโปรเจคไม่เสร็จ
ถ้าเป็นลักษณะ ที่ 2. เข้าใจว่าต้องเป็นพวกที่มีประสบการณ์ด้าน Business สูง สามารถวิเคราะห์ข้อมูลหรือ Requirement จากลูกค้าได้ พวกนี้อาจจะต้องหนักด้านการติดต่อกับลูกค้าเป็นหลัก , design table , หน้าจอ เข้าใจ flow งานทั้งหมดแต่อาจจะไม่ต้อง Programming เป็นเลยก็ได้
แต่ ในโลกตวามจริง โปรเจคอาจจะไม่จำเป็นต้องจ้าง SA ที่เป็น 2 แบบนี้พร้อมกันเพราะทำให้ต้นทุนสูงก็เลยจ้างมาคนเดียวแล้วก็รับหน้าที่ทั้ง 2 เรื่องนี้ไปพร้อมๆกัน เพราะ Phase Design มันไม่ได้ต้องทำกันตลอดทั้ง Project และเมื่อ SA วางระบบเสร็จแล้ว ขั้นตอนในการ implement หรือ tuning ระบบให้เข้ากับความต้องการ
อีกอย่างนึงที่มักจะเห็น SA ชอบทำตกไปคือ การให้ความเข้าใจกับลูกค้า SA ควรจะ minimize scope ของงานให้ได้ตาม requirement แต่ไม่ได้ทำให้งานไปตกอยู่ที่ Programmer ทั้งหมด ดังนั้นในขั้นตอนการ design จึงเป็นเรื่องสำคัญว่าจะทำอย่างไรให้ระบบทำงานได้ครบตามความต้องการ และ งานไม่ใหญ่มากนักเพื่อให้ส่งมอบงานได้ตรงเวลา
ส่วน SA ที่เป็น Software/System Architect
เน้นหนักไปที่การ design software / system ให้มี Quality หรือ Best Performance มากกว่าอะครับ แช่นทำอย่างไรโปรแกรมจะทำงานได้เร็ว , โปรแกรมไม่ Error บ่อย , ปรับระบบให้รองรับต่อการเปลี่ยนแปลง ต้องเข้าใจก่อนนะครับว่าในส่วนของ Architect นี้ไม่ได้เกี่ยวข้องกับ Requirement เพราะ Analyst เป็นคน design ให้ตรงกับ Requirement
ไม่มีความคิดเห็น:
แสดงความคิดเห็น