อยากรู้ว่า Software Engineer ในไทย เขาทำอะไรกันบ้าง ?

ตามหัวข้อกระทู้เลยครับ อยากรู้ว่า  Software Engineer ในไทย เขาทำอะไรกันบ้าง ?
หรือมันก็คือ อีกชื่อหนึ่งของ Programmer ครับ

สุดยอดความคิดเห็น
ความคิดเห็นที่ 1
เอาอะไรมากครับ บางที่เอาโปรแกรมเมอร์ มานั่งลงวินโดว์ ต่อกล้องวงจรปิด ก็มี
บางคนเป็นถึงระดับ ผจก. ยังแยกไม่ออกด้วยว่า โปรแกรมเมอร์ ต่างจาก ไอทีซัพพอร์ตยังไง
หลายๆบริษัทก็ยังแยกไม่ออก ว่า ช่างไฟ ช่างแอร์ ช่างมือถือ ต่างจากไอทียังไง

ส่วนใหญ่รับรู้แค่ว่า จบคอม เหรอ งั้น ลงวินโดว์ให้หน่อย ลงแอปเกมให้หน่อย สมัครไลน์สมัครเฟสให้ที ติดกล้องวงจรปิดเป็นมั้ย ซ่อมแอร์ได้ด้วยใช่มั้ย บลาๆๆๆ

สรุป สังคมส่วนใหญ่รับรู้ว่า จบด้านคอมพิวเตอร์ ต้องทำทุกอย่างที่มีสายไฟได้
ความคิดเห็นที่ 3
จะเล่าให้ฟัง แต่ยาวหน่อยนะ
(มันเป็นความเห็นส่วนตัวล้วนๆ จากที่อยู่ในวงการนี้มา)

สมมติที่ 1 ตัดเรื่อง การต่อทุกอย่างที่มีไฟ ยาวไปถึงท่อน้ำปะปา ออก...ไปก่อน (บางคนมันต้องทำได้ทุกอย่างจริงๆ)
สมมติที่ 2 เหตุการณ์สมมตินี้เกิดในบริษัท Software House  เล็กๆ แห่งหนึ่ง ที่รับงานด้านการพัฒนาซอฟต์แวร์ ที่องค์กรต่างๆ ต้องการ
สมมติที่ 3 มีองค์กรหนึ่งจ้างงาน Software House เล็กๆ นั่น ให้ทำระบบ ABC



คำว่า System Engineer อาจะเรียกว่ารวมๆ วิศวกรระบบ หรือ วิศวกรซอฟต์แวร์ อาจจะเป็นคนที่รู้ทุกเรื่องในการพัฒนา ABC ที่ว่านั่น



เล่าต่อ..

(1)
บ. อาจจะส่งคนที่มีตำแหน่งเป็น System Business Analyst (BA) ตำแหน่งนี้ (อาจ) จะไม่รู้เรื่องการเขียนโค้ดเลย
แต่เค้าสามารถรีดความต้องการ (Requirement) ของระบบจากองค์กรนั้นๆ ได้
เขียนออกมาได้เป็นฉากๆๆ ว่าระบบนี้คืออะไรมี Flow การทำงานยังไง

และบางที จะมี System Analyst (SA) ไปด้วย และคนนี้กับ BA (อาจจะเป็นคนๆ เดียวกัน แต่ส่วนมากจะคนล่ะคน)
SA ที่ไปรับฟังความต้องการขององค์กรนั้นๆ ด้วย

แต่ SA จะเข้าใจในเชิงลึกขึ้น (จนถึงขั้นมันคนเดียวก็ทำเองทั้งหมดได้) หรือ บางทีอาจประสานงานกันกับ BA ว่าถ้า Flow มาเป็นฉากๆๆ แบบนี้
มันจะโอเคไหม, ในเชิงเทคนิคแล้ว ทำได้ไหม จะได้เป็น Requirement document



(2)
คือ SA ทำหน้าที่วิเคราหะ์ระบบ ว่า Requirement ที่ได้มานั้น วิเคราะห์แล้ว สามารถทำได้นะ แบบนี้ทำไม่ได้นะ แต่เอาแบบนี้แทนได้ไหม บลาๆๆ
ให้เหมาะสมที่สุด และมีการเขียนสรุปในเชิงเทคนิค ในทุกๆ ด้านทาง Software Development ออกมาได้เอกสารที่ 2 ที่เรียกว่า Design Specification (ชื่อเอกสารผมเอาคราวๆนะ มันไม่ได้มาตราฐานเท่าไรว่าจะต้องใช้ชื่อๆ นี้เท่านั้น)



(3)
เอกสาร Design Specification นี้คือ พิมพ์เขียวที่อธิบายทุกสิ่งทุกอย่าง ที่ คนธรรมดาอ่านแล้วเกือบไม่เข้าใจ และจะถูกส่งต่อไปให้กับ
ทีม Programmer นั่นเอง..  หรือ ทีมกรรมกร ระดับล่างสุด นั่นเอง

(ในบางครั้ง Programmer มันก็คือคนเดียวกับ SA และเผลอๆ ก็ BA นั่นแหละครับ)

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

คนๆ นี้ก็จะ หลับหู หลับตาเขียนโปรแกรมตาม เอกสาร Design Specification อย่างเดียวเลย
แบบว่า พิมพ์เขียวว่ามายังไง ก็ว่าไปแบบนั้น SA เขียนอะไรมา Programmer ก็ว่าตามไปอย่างไม่ต้องสงสัยใดๆ

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


หรือ Programmer ประสบการณ์โชกโชน พอจะรู้ว่า Design Spec มาแบบนี้ มันไม่ใช่ มันควรจะเป็นแบบนี้ต่างหากนะ
ก็ตีเอกสารนี้ย้อนกลับไปให้ SA แก้ไข Design ใหม่ พอแก้เสร็จ ก็ส่งกลับมา มันจะโยน ไปโยนมาแบบนี้ ระหว่าง (2) <---> (3)

ในบางครั้ง Design ผิด เพราะ Requirement มันผิดตั้งแต่แรก ดังนั้น ต้องโยนกลับไป (1) ก็มีเพื่อให้ไปคุยกับลูกค้าใหม่ ก็มี
สุดท้าย (1) <---> (2) <---> (3) มันวนไปๆ มาๆ เรื่อยๆๆๆ จนกว่า ระบบนี้ทั้งระบบจะสมบูรณ์ ตรงตามต้องการของ ลูกค้าในที่สุด

จากตำแหน่งที่เล่ามา BA, SA, Programmer นั้นจะเห็นว่า บางที BA, SA ก็อาจจะเป็นคนๆ เดียวกัน หรือ
SA, Programmer ก็อาจจะเป็นคนๆ เดียวกันได้

ส่วนใหญ่ในบางครั้ง SA ที่เก่งกาจ อาจจะเคยเป็น Programmer ที่ผ่านงานมาเยอะ เค้าก็จะรู้เรื่องเยอะ ก็เป็นได้ครับ
SA ที่ทำหน้าที่ Programmer ด้วย บางทีเราอาจจะเรียกเขาว่า Software Developer หรือ นักพัฒนาซอฟต์แวร์ นักพัฒนาระบบ



แต่เหนือสิ่งอื่นใด การทำโปรเจ็คร่วมกันระหว่าง ลูกค้า กับ บ. มันจะต้องมีคนๆ นึงที่เรียกว่า Project Manager (PM)
ทั้งสองฝ่าย ทั้งฝ่าย บ.ซอฟ์แวร์ และ ลูกค้า เพื่อให้ มัน 2 คนนี้คอยตัดสินใจ ตัดสินอย่างเด็ดขาด และคอยสั่งการให้ทีมของตนเอง ช่วยกัน
ให้การพัฒนาระบบในครั้งนี้จบอย่างสมบูรณ์

PM ฝั่ง นักพัฒนา ต้องคุม Requirement ให้อยู่ อย่าได้ วันนี้เอาแบบนี้ พรุ่งนี้เอาอีกแบบ แบบนี้โครงการไม่จบไม่สิ้น ไม่มีที่สิ้นสุด
PM ฝั่ง ลูกค้า ต้องมอบงานให้พนักงานตนเองทำในสิ่งที่ ระบบต้องใช้ เป็นฉากๆ ได้ (จะมีระบบได้ ต้องมี Data และ PM ฝั่งลูกค้าเนี่ยแหละต้องสั่งการให้ได้ว่า อยากได้ข้อมูลตรงนี้ๆๆ ไปทำมานะ เดียวต่อไปเราจะมาใช้ ระบบสารเทศกันแล้ว ฯลฯ) อะไรทำนองนี้เป็นต้น



คำว่าระบบ นั่นคือ มีระบบย่อยๆ หรือ โมดูลย่อยๆ เยอะแยะมากมาย มารวมๆ กัน ออกมาเป็นระบบใหญ่ 1 ระบบ
บางที อาจจะมีเรื่อง Network, ตั้ง Server  ต่างๆ เข้ามาเกี่ยวข้อง มี environment อื่นๆต่างๆ มารวมๆ กันเยอะแยะมากมาย

บางที คนๆ นึงที่รู้เรื่องทุกอย่าง ช่วย design ช่วย Analyst ช่วยคิด ช่วยทำ และ เผลอๆ รับตังเองด้วย (มันเป็นเจ้าของ บ.)
รวมไปถึง programmer ผู้เก่งกาจ ที่ขึ้นมาช่วยคิด วิเคราะห์ ออกแบบบ้าง

อาจจะเรียกกลุ่มๆนี้ว่า Software Engineer ก็ได้ (มั้ง) หรือทั้งทีม ทุกคนใน Software House แห่งนี้ ก็จะเรียกว่า Software Developer ก็ได้

งานพัฒนาระบบ คืองานศิลป์..... ตอบยากว่าอะไรคือยังไง ก็เหมือนกับ จิตกรจะวาดรูป เค้าก็บอกไม่ได้หลอกว่า รูปนี้จะ ตวัดพู่กันแบบไหน

สุดท้าย ตกลงใครคือ SE ครับ ตอบยากนิดหน่อยครับ

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