เฮ้ น้องใหม่ เราไม่ได้จ้างคุณมาแค่ให้ทำงานที่ได้รับมอบหมายให้เสร็จ

(newsletter.kentbeck.com)

12 คะแนน โดย GN⁺ 2 시간 전 | 4 ความคิดเห็น | แชร์ทาง WhatsApp

คุณค่าของวิศวกรน้องใหม่ (N00b) ไม่ได้ตัดสินจากจำนวนงานที่ทำเสร็จ แต่ตัดสินจาก ศักยภาพในการเติบโต เป็นวิศวกรที่จะช่วยเพิ่มผลิตภาพของคนรอบตัวได้ในอนาคต
วิศวกรอาวุโสจะแบ่งน้องใหม่เป็น A ที่เปลี่ยนองค์กร / B ที่สร้างผลงานได้อย่างมั่นคง / C ที่มีแนวโน้มจะลาออกภายใน 1 ปี และน้องใหม่ต้องส่ง สัญญาณ ว่าตนอยู่ในกลุ่มที่ต้องการ
หากต้องการเป็น B โค้ดต้องทำงานได้ / แชร์ความคืบหน้า / ทำเสร็จในเวลาที่สมเหตุสมผล เช่น ไม่เกิน 3 เท่าของเวลาที่คาดไว้ / และไม่สร้างงานที่ไม่จำเป็นให้ reviewer กับผู้ดูแลระบบ
A ไม่ใช่คนที่ทำงานเสร็จเยอะ แต่คือ คนที่เรียนรู้ได้มากขึ้นจากทุกงาน เช่น ตัดงานที่ไม่จำเป็นออก / หา 10% ที่ให้ผลลัพธ์สูง / ปรับปรุงการออกแบบ / ส่งการเปลี่ยนแปลงเล็ก ๆ ต่อเนื่อง
กิจกรรมที่แสดงผลงานโดดเด่นใช้เวลามากกว่าการปิดงานเฉย ๆ แต่ไม่ควรปล่อยให้หลงไปกับประเด็นข้างเคียงไม่รู้จบ และควรนำเวลาที่ประหยัดได้ไปลงทุนในรูปแบบที่ช่วยทั้งตนเองและเพื่อนร่วมงาน

เราจ้างวิศวกรในอนาคต ไม่ใช่ผลิตภาพในปัจจุบัน

เกณฑ์ที่วิศวกรอาวุโสใช้มองน้องใหม่แบ่งได้เป็น 3 กลุ่มใหญ่ ๆ
- A กลายเป็นผู้ขับเคลื่อนการเปลี่ยนแปลงที่ยกระดับผลิตภาพของคนรอบตัวได้อย่างมาก
- B สร้างผลงานได้อย่างมั่นคงและค่อย ๆ เติบโต
- C มีแนวโน้มว่าจะไม่ได้อยู่ในองค์กรหลังผ่านไป 1 ปี
วิศวกรอาวุโสต้องทำงานของตนเองไปพร้อมกับประเมินว่าน้องใหม่แต่ละคนอยู่ในกลุ่มใด
- สำหรับ A จะให้การสนับสนุนมากที่สุดเท่าที่ทำได้
- สำหรับ B จะสนับสนุนให้มากพอที่จะเติบโตเป็นวิศวกรที่เป็นผู้ใหญ่
- สำหรับคนที่ไม่น่าจะอยู่ต่อในองค์กร จะพยายามใช้ความพยายามให้น้อยที่สุด
งานที่มอบให้น้องใหม่ หากผู้จัดการหรือ technical lead ทำเองจะเสร็จได้เร็วและง่ายกว่า
หากสิ่งสำคัญมีแค่ผลิตภาพระยะสั้น ก็ไม่มีเหตุผลต้องจ้างน้องใหม่ บริษัทจึงจ่ายเงินเดือนปัจจุบันในฐานะ option premium เพื่อให้ได้วิศวกรที่น้องใหม่จะกลายเป็นในอนาคต
หากการบ่มเพาะสำเร็จ จะได้วิศวกรรุ่นถัดไปที่แข็งแกร่ง แต่หากล้มเหลว วิศวกรอาวุโสก็จะยังต้องทำงานวิศวกรรมแบบเดิมต่อไปอีก 10 ปี

ประเมินน้องใหม่จากจำนวนงานอย่างเดียวไม่ได้

ระหว่างน้องใหม่ที่ทำงานเสร็จ 40 งานในหนึ่งไตรมาส กับน้องใหม่ที่ทำเสร็จ 20 งาน ไม่อาจตัดสินได้จากจำนวนงานอย่างเดียวว่าใครดีกว่า
แม้งานทุกงานจะมีความยากเท่ากัน ข้อมูลที่จำเป็นในการแยก A/B/C ก็ยังไม่เพียงพอ
เป้าหมายของการประเมินไม่ใช่การเปรียบเทียบผลผลิตระยะสั้น แต่คือการตรวจดูว่าน้องใหม่กำลังเติบโตเป็นวิศวกรประเภทใด

สัญญาณพื้นฐานที่แยก B ออกจาก C

เงื่อนไขต่อไปนี้สำคัญกว่าการปิดงานให้เร็วที่สุด
- โค้ดที่เขียนทำงานได้จริง
- แจ้งให้คนอื่นรู้ว่ากำลังทำอะไรอยู่
- ทำงานให้เสร็จในเวลาที่สมเหตุสมผล เช่น ภายใน 3 เท่าของเวลาที่คาดไว้ครั้งแรก
- ไม่สร้างงานเพิ่มเติมให้ผู้อื่นมากเกินควร
การขอความช่วยเหลือที่ทำให้ผู้อื่นต้องใช้เวลาเป็นสิ่งที่ยอมรับได้ แต่สถานการณ์ต่อไปนี้เป็นสัญญาณที่ไม่ดี
- ทำให้ reviewer ต้องเสียเวลาโดยไม่จำเป็นเป็นจำนวนมาก
- ทำให้ผู้รับผิดชอบ on-call ต้องเข้ามารับมือเพราะข้อผิดพลาด
- ทำให้เจ้าหน้าที่ DevOps ต้องออกโรงเพราะ incident ที่ตนก่อขึ้น
พฤติกรรมที่พยายามบิดเบือนระบบประเมิน เช่น โกหกว่าได้ทำสิ่งที่ไม่ได้ทำ จะกลายเป็น สัญญาณ C ทันที
ใคร ๆ ก็อาจส่งสัญญาณ C โดยไม่ตั้งใจได้ แต่ไม่ควรส่งสัญญาณ C แบบเดิมซ้ำเป็นครั้งที่สอง และโดยรวมต้องมีสัญญาณที่เข้าข่าย B มากกว่า

ความเร็วในการเรียนรู้ที่แยก A ออกจาก B

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

พฤติกรรมที่เข้าข่าย A

พฤติกรรมต่อไปนี้เป็นสัญญาณ A ที่ก้าวข้ามระดับการจัดการงาน ไปสู่การขยายการเรียนรู้และผลิตภาพขององค์กร
- สร้างเหตุผลที่น่าเชื่อถือว่างานนั้นไม่จำเป็นต้องทำเลย
- วิเคราะห์ข้อมูลเพื่อค้นหา 10% ของงานที่สร้างประโยชน์ 90% ของทั้งหมด
- ลอง implement งานเดียวกันหลายวิธี
- ค้นพบการออกแบบที่ดีกว่า และส่งชุด diff ที่ไม่เพียง implement งาน แต่ยังทำให้โค้ดรอบ ๆ เรียบง่ายขึ้นด้วย
  - หากทำให้การเปลี่ยนแปลงที่ยากกลายเป็นเรื่องง่ายก่อน implement แล้วจึงทำการเปลี่ยนแปลงที่ง่ายขึ้นนั้น จะได้รับการประเมินที่ดีกว่า
- ส่ง diff เล็ก ๆ หลายรายการต่อเนื่อง แทนที่จะส่ง diff ใหญ่รายการเดียว
  - การส่ง diff ทุกวันมีข้อดีเพิ่มเติม
- เขียนเครื่องมือภายในที่ทำให้งานลักษณะคล้ายกันง่ายขึ้น
  - หากไม่มีงานคล้ายกันที่จะเกิดขึ้นอีก กลับจะกลายเป็นปัจจัยลบ
- ส่ง diff ที่เป็นประโยชน์ต่อทีมอื่นหรือพื้นที่โค้ดอื่น โดยไม่กระทบต่อการทำงานทางการให้เสร็จ
- จัดทำเอกสารสิ่งที่เรียนรู้ให้น่าสนใจ / มีประโยชน์ / และโน้มน้าวใจได้
- review อย่างมี insight และตอบสนองต่อ feedback อย่างรวดเร็ว
- ใส่ unit test ที่แข็งแรง
วิธีแสดงผลงานที่โดดเด่นมีหลากหลายกว่าวิธีหลีกเลี่ยงความผิดพลาดมาก

เวลาที่สมเหตุสมผลสำคัญกว่าเวลาขั้นต่ำ

กิจกรรมที่เป็นสัญญาณ A ใช้เวลามากกว่าการทำแค่ implementation ขั้นต่ำที่จำเป็นต่อการปิดงาน
นี่ไม่ใช่การอนุญาตให้ใช้เวลาไม่จำกัดกับประเด็นข้างเคียงที่น่าสนใจ
งานทางการควรเสร็จภายในเวลาที่สมเหตุสมผลเสมอ แต่ไม่จำเป็นต้องเสร็จในเวลาขั้นต่ำแบบสัมบูรณ์เสมอไป

นำเวลาที่ประหยัดได้กลับมาลงทุนในตนเองและเพื่อนร่วมงาน

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

4 ความคิดเห็น

loblue 2 시간 전

น่าจะต้องพูดถึงวิธีคัดเลือกเด็กใหม่ที่มีศักยภาพจะเป็น A
และการฝึกอบรมที่จะทำให้เด็กใหม่ที่มีศักยภาพกลายเป็น A
มากกว่านะ...
เนื้อหาในบทความดูยั่วยุมากเลยครับ..

kimjoin2 1 시간 전

เข้าใจที่แบ่ง A / B ออกจากกันได้ แต่ C นี่ก็น่าจะมีเยอะที่เป็นทั้ง A, B และ C ด้วยเหมือนกัน...
ดูท่าจะเป็นบริษัทที่สะท้อนเงินเดือนตามผลงานและอิทธิพลได้อย่างรวดเร็ว แถมยังมีความพึงพอใจของพนักงานสูงมากด้วยนะครับ

cartwheel8815 1 시간 전

พฤติกรรมที่พยายามบิดเบือนระบบการประเมิน เช่น หลอกว่าได้ทำงานที่ไม่ได้ทำ จะกลายเป็นสัญญาณ C ทันที

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