I’m not an answering machine
ไม่ควรให้โปรแกรมเมอร์ออกแบบโครงสร้างของระบบเอง
ไม่ควรให้โปรแกรมเมอร์ออกแบบอินเตอร์เฟสและการตอบสนองเอง
ไม่ควรให้โปรแกรมเมอร์ออกแบบโครงสร้างฐานข้อมูลเอง
ควรให้งานที่ถูกออกแบบแล้ว มีผลลัพธ์ที่ต้องการแน่นอน และสามารถตรวจสอบความถูกต้องได้ง่าย ให้กับโปรแกรมเมอร์เหล่านั้น
มันเหมือนเป็นวงจรการสร้างโปรแกรมที่ผิดทิศผิดทาง ให้โปรแกรมเมอร์แต่ละคนออกแบบมา แล้วเอามารวมกัน ตรวจสอบนิดหน่อย จากนั้นแต่ละคนก็เริ่มลงมือเขียนโปรแกรม … ไม่รู้ว่าคิดได้อย่างไร … นี่มันสูตรสำเร็จของหายนะชัดๆ
ถึงจะมีการตรวจสอบก่อน แต่การตรวจสอบนี่มันก็เสียเวลาแบบซ้ำซาก เสียเวลาออกแบบไปแล้ว คนตรวจซึ่งเป็นคนละคน ก็ต้องมาเสียเวลาทำความเข้าใจอีก แถมยังต้องมานั่งคอยตอบคำถามต่างๆนาๆ จากระบบที่ออกแบบมาจากแต่ละคน ต้องมานั่งตรวจ มานั่งควบคุม แทนที่จะเป็นแบบให้งานไป แล้วรอผลลัพธ์ อย่างนี้มันเสียเวลาทำการทำงานของคนอื่นหมด
หลักการทำโปรเจคของผมจะเหมือนกับการสร้างตึก คือมีสถาปนิก วิศวกร และคนงานก่อสร้าง … ไม่มีใครให้คนงานสร้างตึกออกแบบแต่ละส่วนแล้วเอามาประกอบกัน ทุกอย่างถูกออกแบบและทดสอบเป็นอย่างดีแล้วถึงมีการสร้าง คนงานก่อสร้างก็มีภาพของผลลัพธ์ที่ชัดเจนอยู่ในหัว รู้เป้าหมายแน่นอน ทำงานได้เต็มที่
ใครที่บอกว่าควรให้โปรแกรมเมอร์มีส่วนร่วมในการออกแบบ เพื่อเป็นการเรียนรู้ ตรงนี้จริงๆผมก็เห็นด้วย แต่มันต้องเป็นแบบ “มีส่วนร่วม” ไม่ใช่ “รับหน้าที่”
เมื่อไหร่จะมีอำนาจเยอะๆซะทีนะ เบื่อจริงๆ
แต่ผมคิดอีกแง่นึงนะ โปรแกรมเมอร์บางคนก็มีหัวทางด้านการออกแบบได้ ถ้ามีโอกาสที่ให้แสดงความสามารถหน่ะ อีกอย่างการที่จะมาออกแบบได้มันก็คงต้องเคยเขียนมาบ้าง อืม ผมว่ามันอยู่ที่แต่ละคนนะผมว่าพอถึงจุดๆนึงมันก็คงต้อง “รับหน้าที่” กันบ้าง
หนึ่ง
21 Apr 08 at 10:28 am
หนึ่ง – นั่นก็เป็นหน้าที่ของหัวหน้าที่จะต้องคอยให้โอกาส และคอยสังเกตุว่าใครมีความสามารถ หรือใครพอจะพัฒนาได้ แต่ไม่ใช่อยู่ดีๆก็ให้ลองเลย มันต้องทำในสภาพแวดล้อมที่ถูกควบคุมเป็นอย่างดี มีการเลือกว่าจะให้ลองทำอะไร ได้ผลเป็นอย่างไรก็ต้องมาวัดประสิทธิภาพ ฯลฯ
จริงอยู่ที่พอถึงจุดหนึ่ง หน้าที่คนเราก็เปลี่ยน แต่การที่คนๆนึงจะขึ้นไปถึงจุดนั้นเนี่ย มันต้องเป็นแบบ “ความสามารถ” ถึง ไม่ใช่ “เวลา” ถึง อย่างที่หลายๆที่จะชอบใช้ แบบว่าทำงานมาซักพักแล้วก็โปรโมตตำแหน่งให้ โดยที่ไม่ดูว่าคนนั้นเหมาะกับตำแหน่งที่ถูกโปรโมตรึเปล่า
โปรโมตช้าก็ว่าถ่วงเวลา โปรโมตเร็วก็เป็นที่อิจฉาของคนอื่น … ก็ต้องทำให้เป็นที่เข้าใจกันทั้งบริษัทเลยว่า คนๆนึงจะถูกโปรโมตได้เนี่ย เพราะอะไร
และมันก็ไม่ควรจะเป็นแบบตัดฉับด้วย แบบโปรโมตทันทีเลย มันควรจะเป็นแบบคาบเกี่ยวกัน นั่นคือคนๆนั้นเข้าไปมีส่วนร่วมในหน้าที่อีกหน้าที่หนึ่งมาซักพักแล้ว และทุกคนก็เห็นว่าทำได้ดี จึงโปรโมต … อะไรอย่างนี้
บริษัทบางที่ๆแบ่งชัดเจนว่าคนนี้ต้องทำอันนี้ คนนั้นต้องทำอันนั้น อย่างโปรแกรมเมอร์ธรรมดานี่ไม่ควรมีส่วนในการออกแบบ หรือการเก็บ requirement อะไรแบบนี้นี่เป็นเรื่องที่ “ผิด” … ควรให้ทุกคนมีโอกาสเลือก side-experience ที่ตัวเองอยากเรียนรู้ และให้ลองพัฒนาตัวเองเป็นเวลาซักพัก อาจจะปีสองปี ซึ่งอาจจะไม่ต้องนานขนาดนั้นถ้าคิดว่าตัวเองไม่เหมาะ ซึ่งก็ลองเปลี่ยนไปเป็นอย่างอื่นก็ได้ที่คิดว่าเหมาะกว่า แต่สำคัญคือไม่ควรปิดกั้นการก้าวล้ำหน้าที่ตรงนี้
ที่เขียนข้างบนว่าไม่ควรให้โปรแกรมเมอร์ออกแบบเองเนี่ย นั่นคือไม่ให้ไปทำกันเอง เรื่องพวกนี้มันสำคัญขนาดที่ไม่ควรให้คนที่ไม่รู้ว่ามีประสบการณ์แค่ไหนมาลอง ควรจะจับกลุ่มกับคนที่มีหน้าที่เฉพาะ แล้วค่อยๆดูว่าทำได้แค่ไหน
… จริงๆน่าจะเขียนเป็นอีก entry นึงเลยนะเนี่ย
panuta
21 Apr 08 at 1:47 pm
เห็นด้วยอย่างยิ่งค่ะ เคยเจอปัญหาเดียวกัน แต่ถ้าเป็นทีมเล็กๆ ก็ไม่มีทางเลือกเหมือนกันค่ะ
mameou
7 May 08 at 9:04 pm
As an afterthought, are you talking about the working environment at Accenture? Because if you are, I am not applying there for internship next year.
mameou
8 May 08 at 10:06 pm
mameou – no, it has nothing to do with Accenture
It’s from my current part-time actually. A large and renowned organization like Accenture usually has a good separation of responsibility. It’s not perfect but it’s way better than what I’m in right now haha
panuta
8 May 08 at 11:20 pm