ในอดีต...

ผมเริ่มทำงานเป็นโปรแกรมเมอร์ แล้วเจอ SA ที่ไม่เข้าใจการเขียนโปรแกรม ในภาษาที่ผมเขียน เขาใช้หลักการเขียนโปรแกรมที่เขาเคยใช้ ดังนั้น แนวทางการเขียนผังงาน กับ การเขียนโปรแกรม จึงไม่สามารถเข้ากันได้

+ SA ควรที่จะเข้าใจวิธีการเขียนของโปรแกรม ที่เขาออกแบบด้วย

เมื่อทำงานไประยะหนึ่ง ความสามารถทางด้านโปรแกรมมีมากขึ้น แนวทางการพัฒนาโปรแกรมของผม จึงกลายเป็นการเขียนแบบสามารถนำกลับมาใช้ไหม่ได้ หรือ แต่ก่อนเรียน  OOP แต่ผมเขียนก่อนที่คำศัพท์นี้ออกมาเสียอีก แต่ว่า SA ทั้งหมด ไม่มีใครเข้าใจหลักการเลย...

+ SA ควรที่จะฟัง โปรแกรมเมอร์ว่า สามารถทำอะไรได้บ้าง และ รู้ว่า โปรแกรมเมอร์มีจุดเด่น ข้อดีอะไร แล้วนำเอาจุดแข็งมาพัฒนาต่อยอด

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

+ SA ควรจะเขียนแนวทางการวิเคราะห์ระบบ ที่เป็นรูปแบบ ใช้ Pseudo Code หรือ รหัสเทียมสำหรับการเขียนโปรแกรม รวมทั้งรูปแบบ หลักการต่างๆ ที่เป็นมาตรฐานร่วมกันในองค์กร รวมทั้ง เขียนเป็นสัญญาให้กับ ลูกค้า เซ็นต์รับ

หลังจากที่ผมใช้ 4th GL ผมพบว่างานของ SA กับ Programmer ไม่มีความแตกต่างกันเลย เขียน Pseudo Code เสร็จ โปรแกรมก็เสร็จเลย ดังนั้น ผมก็เลยไม่เห็นความแตกต่างระหว่าง SA กับ Programmer 4GL, และตอนนั้นผมก็ขึ้นไปเป็น IT Manager แล้วด้วย...

+ องค์กรที่เลือกใช้โปรแกรมที่เก่งๆ ไม่จำเป็นต้องใช้ SA หรือ ใช้ SA เขียนเป็นโปรแกรมได้เลย

เมื่อมองภาพรวมของหน่วยงานต่างๆมากขึ้น ผมพบว่า SA บางคนเก่งคุยแต่ไม่เก่งทำ บางคน ใช้เวลานานในการทำ บางคนมั่วระบบให้ลูกค้า

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

หลังจากนั้นผมก็ผันตัวมาทำงานเป็นผู้บริหาร ดังนั้น ผมจึงขอแนะนำการเป็น SA ไว้แค่นี้ละกันครับ