สอนงานน้องฝึกงาน

feature

ออกตัวก่อนว่าไม่เคยสอนงานจริงจังครับ เคยแต่ได้คุยบ้างนิด ๆ หน่อยๆ ครับ

ในออฟฟิศเก่าผมนี่ มีพนักงานสิบคน รับน้องฝึกงานมาหนึ่งคน ไม่ได้สอนงานอะไรเลยครับ จับโยนลงโปรเจคเลย 555 คือเราเป็นบริษัทเล็กแล้วก็ไม่มีใครว่าง ก็เลยจับโยนเข้าโปรเจคงานจริงที่จะเอาไปขายให้ลูกค้าเลยครับ (น้องฝึกงานคนนี้มีเงินเดือนนะครับ บอกก่อน) ก็เป็นการสอนงานแบบถีบลูกสิงโตตกภูเขานั่นเอง

ส่วนออฟฟิศปัจจุบันผมนี่ ใช้วิธีให้ทำโปรเจคที่ไม่เกี่ยวข้องกับโปรดักท์หลัก เป็นการให้ทำทูลที่มาช่วยให้ dev ทำงานได้สบายขึ้น (ส่วนทำไม dev ไม่ทำเองตั้งแต่แรกนี่ผมขออนุญาตไม่ออกความเห็นนะครับ 🙂 ) อย่างคนล่าสุดก็เพิ่งจบออกไปเมื่อวันศุกร์นี้เอง

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

และผมเชื่อพื้นฐานที่นักพัฒนาโปรแกรมควรจะมีก็คือ Version Control

Version Control

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

คิดว่าบางคนน่าจะเคยทำงานแบบนี้นะครับ

version control แบบทำมือ

ก็คือ การก็อปปี้แบ็คอัพไฟล์งานออกมาเป็นเวอร์ชัน ๆ เก็บไว้ตามเวลา บางครั้งเราอยากจะทดลองอะไรกับไฟล์งาน ก็สร้างโฟลเดอร์ออกมาทดลอง แล้วก็รวมกลับเข้าไปในโฟลเดอร์หลัก ฯลฯ

น้องฝึกงานคนที่ผมคุยด้วยล่าสุดทำแบบนี้เป๊ะเลยครับ ขนาดอุตส่าห์บอกว่า ลองศึกษาเรื่อง VCS มานะ นี่เป็นคำแนะนำเดียวที่ผมให้ไปเลยนะเนี่ย 555

การทำ Version Control ก็การทำแบบที่ว่านี้เป๊ะเลยครับ เพียงแต่ว่า ในปัจจุบันเราไม่ควรใช้วิธีการเก็บแยกโฟลเดอร์แบบนี้แล้ว เพราะว่า

  1. มันทำลำบาก ต้องปิดโปรแกรม เซฟงาน ก็อปปี้โฟลเดอร์ เปิดโฟลเดอร์ใหม่ …
  2. ถ้าทำผิด ทุกอย่างก็สูญ
  3. มีโอกาสที่จะทำงานกับไฟล์ผิดที่ เซฟทับงานเก่า แบ็คอัพหาย
  4. พอมีเวอร์ชันเยอะ ๆ เราก็งงเองว่า จะต้องใช้โฟลเดอร์ไหนกันแน่ ??

ซึ่ง ในปัจจุบันเราควรใช้ VCS อย่างเช่น subversion หรือ git (แล้วแต่อยากทำ centralize หรือ distributed แต่แนะนำให้ทำ distributed เพราะมันง่ายกว่าครับ) แทนการมาจัดการด้วยมือ ที่โอกาสเกิดหายนะนั้นสูงกว่ามาก

ทำไมผมถึงแนะนำให้สอนเรื่องนี้ในสถานที่ฝึกงาน

ข้อแรกเลย ในคอร์สของ Computer Science หรือ Computer Engineering เราแทบไม่มีการสอนเรื่องนี้ครับ อาจจะมีแซม ๆ อยู่สองบรรทัดในวิชาอย่าง Software Engineering (วิชานี้สอนกันแบบคร่าว ๆ ราว ๆ กับมองวงการนี้ในระดับห้าหมื่นฟุต เพราะรายละเอียดมันเยอะจนเปิดเป็นสาขาวิชาเฉพาะได้เลย) ทั้งๆ ที่ในชีวิตจริงนี่คือสิ่งที่โปรแกรมเมอร์จะต้องใช้อยู่ทุกวัน (ใครไม่ commit โค๊ดเลยในแต่ละวันนี้ ผมถือว่า productivity ท่านแย่มากเลยนะครับ) เป็นเรื่องปฎิบัติที่สำคัญมาก

ข้อที่สอง เพราะว่าระบบ VCS มันจะช่วยให้เราทำงานได้เร็วขึ้น และป้องกันความเสียหายของเราได้ อย่างที่บอกว่า version control ก็พอจะทำด้วยมือได้ แต่มันไม่มีประสิทธิภาพ และโอกาสการมีปัญหาก็สูงด้วย ถ้าเราใช้ VCS จะทำให้เราทำงานได้อย่างมั่นใจมากขึ้น เพราะเรารู้ว่าถึงเราจะทำเวอร์ชันปัจจุบันพังเราก็ยังมีของเก่าที่ใช้งานได้ ไม่ใช่ว่าต้องมาซ่อมของใหม่ให้ใช้ได้ ซึ่งเป็นการเสียเวลา

ข้อที่สาม นักพัฒนาทุกคนจะต้องใช้งาน VCS อยู่แล้ว ยังไงก็เป็นเรื่องที่จะต้องเรียน ก็สอนไปเลยมันก็ไม่มีปัญหาอะไร และมันเป็นประโยชน์กับการใช้งานในการเรียนอีกด้วยเหมือนกัน (ทำโปรเจคก็ต้องเขียนโค๊ด ว่าไหมครับ

ดังนั้นผมว่า เรื่องนี้ สอน ๆ ไปเถอะ ใช้เวลาไม่นาน และก็ได้ผลลัพท์ดีขึ้น

เทรนนิ่งเด็กจบใหม่

feature image

ช่วงนี้หลาย ๆ ที่น่าจะเริ่มใกล้จะจบเทรนนิ่งพนักงานใหม่ที่เพิ่งจบหมาด ๆ กัน หรือไม่ก็เลิกเทรนกันไปนานแล้ว (ฮา) จริง ๆ ผมชอบงานเทรนพนักงานโดยเฉพาะพนักงานใหม่นะครับ แต่ก็มีหลาย ๆ อย่างที่อยากทำแต่ทำไม่ได้เหมือนกัน

อันนี้เป็นข้อแนะนำ/ความคิดเห็นที่ผมพอจะนึกออกนะครับ

ก่อนจะลงรายเอียดในตัวงานที่เขาจะต้องรับผิดชอบ

เมนเตอร์

ผมเชื่อว่า พนง.ใหม่ควรมี Mentor หรือ คนที่มีประสพการณ์ที่สามารถที่จะช่วยชี้แนะเรื่องต่าง ๆ ให้กับพนักงานใหม่ได้ ผมคิดว่า เมนเตอร์ควรเป็นคนที่เข้าหาเด็กใหม่มากกว่าจะรอให้เขาเข้ามานะครับ (เพราะว่าในตอนแรกก็คงไม่มีใครกล้าเดินเข้าไปหาคนที่ไม่รู้จักที่อยู่สูงกว่าหรอกครับ) ผมคิดว่าถ้าเป็นไปได้ควรตั้งไปเลย 1:1 ทั้งนี้ถ้าเกิดมี พนง.ใหม่มาขอให้เป็นเมนเตอร์เราก็สามารถรับเพิ่มได้เหมือนกันนะครับ

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

เริ่มจากเรื่องพื้นฐานก่อน

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

และ ถ้ามองกันตามจริง สายโปรแกรมเมอร์เนี่ยหลาย ๆ คนก็เรียน Computer Science มาบ้าง Computer Engineering บ้าง น้อยมากที่จะเรียนมาทาง SE (Software Engineering) ในขณะที่ในตลาดงาน งานสายโปรแกรมเมอร์ที่เป็น CS เนี่ยมีน้อยมาก (พวกงานสายนักวิจัยน่ะครับ) ใน CS เรียนเขียนโปรแกรมมาประมาณนึง แล้วก็ไปทางคณิตศาสตร์ซะเยอะ ส่วน CE ก็ได้ยินว่าต่อกับ HW เป็นหลักมากกว่า ซึ่งไอ้เรื่องการทำงานในเชิงวิศวกรรมซอฟต์แวร์ส่วนมากจะเรียนมาแค่คอร์สเดียว

ผมก็เลยคิดว่าเราควรจะเริ่มจากตรงนี้ก่อน พวกขั้นตอนในการทำงาน วิธีการเขียนโค๊ด (คนที่เรียนจบสายคอมมาเขึยนเป็นหมดล่ะครับ แต่การเขียนส่งการบ้านมันใช้โค๊ดที่ไม่เหมือนกับที่ส่งให้ลูกค้าน่ะครับ) พวก concept อย่าง Extreme Programming, Agile และอื่น ๆ เป็นเรื่องสำคัญที่คนที่เรียนจบใหม่ควรเรียนรู้ครับ

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

ภาพรวมธุรกิจองค์กรณ์

คือ ถ้าเราทำงานในหน่วยงาน Enterprise IT ให้กับบริษัทเนี่ยเราก็ควรรู้ว่าบริษัททำธุรกิจอะไร หรือถ้าเราพัฒนาสินค้าเราก็ต้องรู้ว่าสินค้าที่เราทำเป็นอะไรครับ คือรู้ภาพรวมๆ ว่าทำอะไร มีองค์ประกอบอะไรบ้าง มีใครทำงานอะไร และเราจะเข้าไปซัพพอร์ทในส่วนไหน เป็นต้น

รายละเอียดกว้าง ๆ ของโปรดักท์ และเทคโนโลยีที่ใช้

ในขั้นนี้ เราก็จะเริ่มลงรายละเอียดกว้าง ๆ ว่า เรามี product เป็นอะไร ออกแบบมาอย่างไร มี architecture แบบไหน และพัฒนาด้วยเทคโนโลยีอะไร ถ้าเกิดว่าเราใช้เทคโนโลยีที่ชาวบ้านเขาไม่ใช่กันนี่ อย่าเพิ่งสอนวิธีใช้เทคโนโลยีนั่น ณ. จุดนี้ครับ ให้ภาพกว้างมันชัดเจนก่อนแล้วค่อย ๆ ลงรายเอียดทีละจุด

ให้ลองเป็น User ดูก่อน

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

สอนงานจริงจัง

พื้นฐานของแพลตฟอร์ม

ตรงนี้ถ้าเกิดว่าเราใช้ภาษาในการพัฒนาที่ชาวโลกเขาไม่นิยมกัน เราอาจจะต้องสอนใหม่หมดตั้งแต่ศูนย์ครับ เพราะว่ามหาวิทยาลัยก็คงไม่สอนมาให้ (แหงล่ะ) หรือบางครั้งเราก็ต้องปรับพื้นฐานเขาให้มีความรู้มากพอที่จะทำงานพื้น ๆ ได้ครับ

ผมไม่อยากให้ลงรายะเอียดว่า ขั้นตอนการทำงานทีละขั้นนั้นเป็นอย่างไรในจุดนี้ เพราะว่าหลาย ๆ ครั้งมันก็ไม่มีประโยชน์อะไร เรียนไปไม่เห็นภาพสักพักก็ลืม ผมเชื่อว่าลองเข้าใจจากวิธีการทำงานเป็นภาพกว้าง ๆ ของตัวโปรดักท์ก่อนจะดีกว่า

เริ่มให้ทำงานแรงงานก่อน

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

สอนไป ทำงานไป สลับกัน

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

ผมคิดว่าสอนงาน สลับกับทำงานสักปีหนึ่ง พนง.ใหม่ก็น่าจะทำได้ระดับเดียวกับคนที่อยู่มานานหลาย ๆ ปีได้แล้ว แค่การตัดสินใจอาจจะยังไม่ดีพอเท่านั้นเอง

ทั้งนี้ถ้าเกิดเป็นหน่วยงานที่ต้องทำงานกับหลาย ๆ โปรดักท์ ผมคิดว่า ค่อย ๆ สอนทีละตัว สลับกัน แต่ละตัวสอนในความยากระดับเดียวกัน สลับไปเรื่อย ๆ น่าจะดีกว่าสอนแบบรวดเดียว 1 เดือน 8 โปรดักท์ครับ

ถ้าเป็นพวกงานที่มีหลาย ๆ business area ก็ทำเหมือนกัน ค่อย ๆ เวียนทำ ค่อย ๆ เวียนรู้ น่าจะทำให้ได้ผลมากกว่ายัดทีเดียวหลาย ๆ ตัวต่อ ๆ กันครับ เรียนอาทิตย์นึก ทำงานสองอาทิตย์ ทำพรีเซนต์แล้วเรียนเรื่องใหม่ต่อ ก็น่าจะเป็นวัฐจักรที่ดีกว่าเรียนรวดเดียว ในความคิดผมนะครับ 🙂

วัดผล

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

การเรียนรู้อย่างต่อเนื่อง

เราอยู่ในสายงานที่มีเรื่องให้เรียนรู้ตลอดเวลาครับ ดังนั้นคนทำงานก็ต้องเรียนรู้ตลอดเวลาเช่นกัน เราควรจะฝึกให้คนเรียนรู้ไปเรื่อย ๆ อย่างไม่สิ้นสุดด้วยครับ ไม่อย่างนั้นพอถึงจุดนึงก็จะเริ่มหยุดนิ่งและกลายเป็นภาระให้คนอื่น กลายเป็น Legacy Coder ไป

เรื่องนี้สำคัญที่สุดครับ ผมเลยหยิบมาวางไว้เป็นเรื่องสุดท้าย

ทิ้งท้าย

ผมเชื่อว่า เราควรพัฒนาคนไปตามศักยภาพของแต่ละคน เราต้องวัดผลและติดตามไปเรื่อย ๆ มีการปรับเปลี่ยนไปเรื่อย ๆ ตามาสิ่งที่แต่ละคนเป็นครับ การปั้นคนไม่ใช่เรื่องง่ายครับ และผมเองก็ทำพลาดไปหลายรอบแล้วเหมือนกัน (ฮา) ครั้งนี้ผมก็ต้องพยายามกันอีก (ถึงจะไม่ค่อยได้มีส่วนร่วมกับเขาเท่าไหร่ก็ตาม)

ทั้งนี้ก็ขอให้ทุก ๆ ท่านโชคดี มีพนักงานใหม่ที่ทำได้ดีสมกับที่คาดหวังไว้กันถ้วนหน้านะครับ