รูปที่ 1 ภาพร่าง (เครดิตภาพจากเว็บ johnlovett.com)
การแก้ปัญหาเชิงสถาปัตยกรรมและปัญหาในการออกแบบซอฟต์แวร์ถือเป็นทักษะสำคัญของนักออกแบบ, นักวิเคราะห์ระบบ และสถาปนิกซอฟต์แวร์ คนเหล่านี้จำนวนไม่น้อยที่ไม่ได้ให้ความสำคัญกับพื้นฐานเหล่านี้ อาจเพราะไม่ทราบว่าเป็นสิ่งจำเป็น หรืออาจพึงพอใจแก้ปัญหาด้วยเทคโนโลยี, เฟรมเวิร์ก และสิ่งสำเร็จรูปต่างๆ นานา มากกว่า
อาจเพราะระบบการศึกษาของประเทศไทยเราที่บิดเบี้ยว และวัฒนธรรมบริโภคนิยมที่ทำให้ผู้คนฉาบฉวยมากขึ้นๆ การก้าวข้ามบันไดขั้นพื้นฐานเพื่อไต่ขึ้นไปสู่ขั้นสูงๆ ด้วยการใช้วิธีการแบบฉาบฉวย รวบรัด รวดเร็ว จึงเป็นสิ่งที่ผู้คนจำนวนมากพึงใจกระทำ เมื่อแก้ปัญหาได้ก็หลงผิดเกิดอุปาทานว่า ‘นั่นแน่ะ…แก้ได้จริงๆ ด้วย’ แล้วยึดติดไปว่าโซลูชั่นนั้นสามารถแก้ปัญหานั้นได้จริง แท้จริงแล้วเป็นเพียงการแก้ปัญหาที่ปลายเหตุ แก้ได้ชั่วประเดี๋ยว…เดี๋ยวเดียวปัญหามันก็พุพองดั่งฝีที่แตกจนหนองไหลเยิ้ม…
การแก้ปัญหาต้องแก้ที่เหตุ-ไม่ใช่แก้ที่ปลาย แม้การแก้ที่ปลายจะรวดเร็ว แต่ไม่มีทางแก้ให้หายขาด คนจำนวนมากที่ทำงานด้านนี้ เมื่อทำงานไปสักระยะใหญ่ๆ จะพบว่าเมื่อถึงจุดหนึ่งเขาจะไม่สามารถไต่ขึ้นบันไดขั้นสูงๆ ต่อไปได้แล้ว เพราะพื้นฐานความรู้และทักษะที่มีอยู่เปราะบางเหลือเกิน ไม่แน่นพอที่จะ ‘up level’ ได้ คราวนี้ล่ะทั้งเงินเดือนก็อาจจะขึ้นยาก และตำแหน่งหน้าที่ก็อาจจะขึ้นยาก หลายคนทนภาวะกดดันไม่ไหวก็หาทางออกให้ตัวเองง่ายๆ ด้วยการเปลี่ยนสายงาน โดยมากมักหันหัวเปลี่ยนทิศไปสายบริหาร ไม่ก็หันไปทำอาชีพอื่น หรือไปทำธุรกิจอื่นกันไปเลย
หากคุณยังหลงใหล (passion) ในงานออกแบบระบบและสถาปัตยกรรม ต้องการเติบโตไปในสาย ‘specialist’ อย่างแท้จริง ลองทบทวนตัวเองดูครับ ว่าทักษะพื้นฐานการแก้ปัญหาเชิงสถาปัตยกรรมและปัญหาในการออกแบบซอฟต์แวร์ของตนเองนั้น ‘แน่น’ และ ‘แข็ง’ พอไหม? หากไม่หรือยังไม่แน่ใจ ลองมาปรับพื้นฐานกันครับ ไม่ต้องอาย ไม่ต้องกลัว ใครๆ ก็เป็นกันได้ ผมเองยังเคยเป็น อ่านเพิ่มเติม