โปรแกรมเมอร์ที่แย่ที่สุดเท่าที่ผมเคยรู้จัก
(dannorth.net)- ทีมที่ปรึกษาของธนาคารใหญ่แห่งหนึ่งพยายามวัดผลิตภาพรายบุคคลด้วย จำนวนสตอรี่/สตอรี่พอยต์ที่ทำเสร็จ และ Tim Mackinnon ได้คะแนน 0 ซ้ำแล้วซ้ำเล่าในตัวชี้วัดนี้
- สาเหตุที่ได้ 0 ไม่ใช่เพราะเขาไม่ทำงาน แต่เพราะเขาไม่รับสตอรี่ไว้ในชื่อของตัวเอง และใช้เวลาส่วนใหญ่ของวันไปกับ pair programming
- เมื่อทำงานกับนักพัฒนาที่มีประสบการณ์น้อยกว่า เขาจะไม่ให้คำตอบตรง ๆ แต่ใช้ คำถามแบบโสเครติส เพื่อทำให้เกิดการเรียนรู้ และเมื่อทำงานกับซีเนียร์ก็ใช้มุมมองที่ต่างกันเพื่อค้นหาวิธีแก้ที่ดีกว่าร่วมกัน
- ทีมทำงานได้มีประสิทธิภาพ มีผลิตภาพ และสอดประสานกันมากขึ้นเมื่อ Tim ทำงานด้วย และท้ายที่สุดผู้จัดการก็ยกเลิกตัวชี้วัดผลิตภาพรายบุคคลอย่างเงียบ ๆ โดยยังคงให้ Tim อยู่กับทีมต่อไป
- การวัดผลงานโดยแยกเป็นรายบุคคลอาจทำให้การมีส่วนร่วมแบบ Tim ถูกนับเป็นศูนย์ได้ ดังนั้นควรมองผลิตภาพผ่าน ผลกระทบทางธุรกิจ และการไหลของงานในระดับทีม
“โปรแกรมเมอร์ 0 คะแนน” ที่เกิดจากตัวชี้วัดรายบุคคล
- ทีมหนึ่งของ Big Bank ได้นำ ตัวชี้วัดผลงานรายบุคคล มาใช้เพื่อการประเมินผลงานและการพัฒนานักพัฒนา
- ผู้จัดการหลีกเลี่ยงตัวชี้วัดที่บิดเบือนได้ง่าย เช่น จำนวนบรรทัดโค้ดหรือจำนวนบั๊ก และเลือกวัดจากสตอรี่หรือสตอรี่พอยต์ที่ทำเสร็จ เพราะมองว่าเป็นตัวแทนของคุณค่าทางธุรกิจ
- เนื่องจากแต่ละคนใส่ชื่อลงบนสตอรี่ในเครื่องมือคล้าย Jira จึงสร้างตัวชี้วัดผลิตภาพรายบุคคลได้ง่าย
- คะแนนของ Tim Mackinnon ไม่ได้แค่ต่ำ แต่เป็น 0 แบบตามตัวอักษร ในทุกสัปดาห์และทุก iteration
- ผู้จัดการมองว่าควรเอา Tim ออกจากทีมแล้วแทนที่ด้วยคนที่ “ส่งมอบ” สตอรี่จริง ๆ แต่หัวหน้าทีมปฏิเสธ
สิ่งที่ Tim ส่งมอบจริง ๆ
- Tim ไม่ได้รับสตอรี่ไว้ในชื่อของตัวเอง แต่เลือกทำงานแบบ pairing กับสมาชิกทีมคนอื่นในแต่ละวันแทน
- เมื่อทำงานกับนักพัฒนาที่มีประสบการณ์น้อยกว่า เขาจะปล่อยให้พวกเขาเป็นคนขับเอง และค่อย ๆ ชี้นำไปสู่ทางออก
- ไม่ยัดเยียดคำตอบหรือกดดัน
- ใช้คำถามอย่าง “what if”, “how else” และ Socratic questions เพื่อสร้างช่วงเวลาแห่งการเรียนรู้
- เมื่อทำงานกับนักพัฒนาซีเนียร์ รูปแบบการทำงานจะใกล้เคียงกับการร่วมสร้างสรรค์หรือการ sparring โดยต่างฝ่ายนำกรอบคิดคนละแบบมาใช้กับปัญหา จนได้ผลลัพธ์ที่ยากจะคิดออกได้เพียงลำพัง
- แทนที่จะส่งมอบซอฟต์แวร์ด้วยตัวเอง Tim กลับช่วยพัฒนา ทีมที่ส่งมอบซอฟต์แวร์
- ทั้งทีมขยับได้อย่างมีประสิทธิภาพและมีผลิตภาพมากขึ้น
- ทำงานได้สอดประสานกันดีขึ้น และยืดหยุ่นต่อกันมากขึ้น
- ประสบการณ์การทำงานร่วมกันก็น่าสนุกมากขึ้น
- เมื่อผู้จัดการเข้ามาสังเกตทีม Tim มักกำลังทำ “งานของคนนั้น” ร่วมกับคนอื่นอยู่เสมอ และผลลัพธ์ที่ได้ก็มีคุณภาพดีขึ้นพร้อมกับใช้เวลาส่งมอบคุณค่าน้อยลง
- สุดท้ายทีมเลือกเก็บ Tim ไว้ และเลือก ความรับผิดชอบในระดับทีม แทนตัวชี้วัดผลิตภาพรายบุคคล
- ติดตามและเฉลิมฉลองผลกระทบทางธุรกิจที่ทีมส่งมอบให้องค์กรในฐานะหน่วยงานที่มีผลงานสูง
ควรมองผลิตภาพที่ตรงไหน
- การวัดผลิตภาพยังคงจำเป็น และหากต้องการความรับผิดชอบ ผลกระทบทางธุรกิจที่วัดได้ คือสิ่งที่เหมาะสมที่สุด
- เงินที่ประหยัดได้
- เงินที่สร้างได้
- เงินที่ปกป้องไว้ได้
- หากวัดผลกระทบทางธุรกิจโดยตรงได้ยาก ก็สามารถใช้ตัวชี้วัดทางธุรกิจแบบตัวแทนได้
- ในระบบเชิงปรับตัวที่ซับซ้อน สมมติฐานตั้งต้นที่ว่าจะสามารถแยกวัดผลงานของบุคคลเพียงคนเดียวออกมาได้ เองก็สั่นคลอน
- ตัวชี้วัด DORA ไม่ได้วัดการมีส่วนร่วมของลูกสูบรายบุคคล แต่เป็นการวัด วิธีการทำงานของระบบงาน
- มองได้ว่าเป็นตัวชี้วัดวัฒนธรรมแบบ Westrum
- หรือมองได้ว่าเป็นตัวชี้วัดที่ดูว่าการเปลี่ยนแปลงทางเทคนิคไหลไปสู่โปรดักชันอย่างไร
- ตัวชี้วัดรายบุคคลอาจทำให้การมีส่วนร่วมที่แท้จริงของคนอย่าง Tim ถูกนับเป็นศูนย์ และแนวทางที่เหมาะสมกว่าคือการดูผลงานระดับทีมและการไหลของงานในระดับระบบ
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ราว 20 ปีก่อน ผมทำงานที่บริษัทซอฟต์แวร์ขนาดกลางแห่งหนึ่งที่ขายแอปเดสก์ท็อปสำหรับ Mac และ Windows แต่ทีมส่วนใหญ่มีประสบการณ์เฉพาะกับ Mac และกำลังเพิ่งเรียนรู้ Windows กันอยู่ เวอร์ชัน Windows เลยมีปัญหาเยอะ
ตอนนั้นผมเป็นที่รู้จักในฐานะ ผู้เชี่ยวชาญ Windows จึงถูกจ้างมาเพื่อปรับปรุงเวอร์ชันนั้น และช่วยให้ทีมคุ้นเคยกับการเขียนโปรแกรมบน Windows
ช่วงต้นของวันส่วนใหญ่ผมจะทำเหมือน “ออกตรวจตามบ้าน” เดินไปตามห้องของนักพัฒนาคนอื่น ๆ เพื่อทำ pair programming, สืบหาบั๊ก และคุยกันเรื่องแนวปฏิบัติที่ดีของ Windows API แล้วภายหลังเพื่อนร่วมงานก็ถามว่า “ทำไมถึงมีเวลาเหลือเฟือได้ขนาดนั้น”
ไม่กี่เดือนต่อมาในการประเมิน ผมได้รับความเห็นว่า “ประสิทธิภาพการทำงานยังไม่เป็นไปตามที่คาด โดยเฉพาะเมื่อพิจารณาว่าช่วงหลังประสิทธิภาพของทีมที่เหลือเพิ่มขึ้น” ซึ่งผมก็คิดว่านั่นแหละคือเหตุผลที่พวกเขาจ้างผมมา
การแบ่งปันความรู้คือประโยชน์ที่ยิ่งใหญ่ที่สุดอย่างหนึ่งที่มอบให้ developer คนอื่นได้ แต่คนที่เลือกเส้นทางนั้นกลับได้รับผลตอบแทนน้อยเกินไป
ถ้าไม่มี developer แบบนี้ โลกซอฟต์แวร์ในปัจจุบันคงมาไม่ถึงจุดใกล้เคียงนี้เลย และแม้พวกเขาจะไม่ได้รับคำขอบคุณโดยตรง แต่ก็มีคุณค่าอย่างแน่นอน
งานซ่อมทุกอย่างมีลำดับความสำคัญเท่ากัน แต่ความยากต่างกัน พอผมได้เรียนอยู่หนึ่งเดือนและไม่มีใครอยากทำ เลยรับหน้าที่ ซ่อมสถานีฐาน ซึ่งใช้เวลานานกว่า แต่สำคัญต่อการดำเนินงานมากกว่ามาก
ในการประชุมสิ้นเดือน มีการแสดงกราฟวงกลมอัตราการใช้ทรัพยากรออกมา และผมดูแย่กว่ารุ่นพี่ที่มีฝีมือมาก ๆ
ตอนนั้นผมได้เรียนรู้ว่าทำไมรุ่นพี่ถึงเลือกแต่งานเร็ว ๆ ง่าย ๆ และได้รู้ว่าการเมืองในองค์กรมีอยู่จริง การได้เจอหัวหน้าห่วย ๆ ตั้งแต่ต้นอาชีพกลับถือว่าโชคดีเสียด้วยซ้ำ
หัวหน้าคนใหม่ยอมรับว่าในการประเมินครั้งแรก เดิมทีเขาเขียน แผนปรับปรุงผลงาน ไว้ให้ผมแล้ว แต่พอย้ายมาเป็นออฟฟิศแบบเปิดและเห็นคนมาต่อคิวขอความช่วยเหลือจากผม รวมถึงเห็นว่าผมไม่เคยไล่ใครกลับไป เขาก็ทิ้งแผนนั้นไป
การเสียที่นั่งแบบคอกกั้นไปก็น่าหงุดหงิดอยู่บ้าง แต่เรื่องนั้นทำให้ผมมองออฟฟิศแบบเปิดในแง่ดีขึ้น
แน่นอนว่าตอนนี้ผมไม่ได้ทำงานในออฟฟิศแบบไหนแล้ว และไม่คิดจะรับงานที่ไม่ใช่งานจากบ้านอีก
ต้องสร้างชื่อเสียงขึ้นมาก่อน ถึงค่อยเปลี่ยนอะไรบางอย่างได้ ก่อนหน้านั้นทำได้ยาก
มีคนมากเกินไปที่พยายาม optimize เพื่อ “ทีม” แล้วถูกไล่ออกหรือพลาดการเลื่อนตำแหน่งเพราะผู้บริหารมองในแง่ลบ ในทางกลับกัน คนที่สร้างชื่อเสียงดีจากเกณฑ์ที่บริษัทให้ความสำคัญอยู่ในตอนนั้น ก็มักได้รับการยอมให้มี พฤติกรรมแย่ ๆ ได้นานพอสมควร
เขาออกไปที่ที่ดีกว่าทันทีหรือเปล่า เริ่มแบ่งเวลาให้น้อยลงเพื่อให้เข้ากับตัวชี้วัดผลงานของบริษัทหรือเปล่า หรือไปโน้มน้าวคนที่อยู่สูงพอในผังองค์กรได้สำเร็จว่าเขาถูกจ้างมาเพื่อทำบทบาทแบบนั้นจริง ๆ หรือเปล่า
ทำให้นึกถึงเกร็ดของ Bell Labs
มีคนคำนวณหาพนักงานที่มี productivity สูงที่สุดตามเกณฑ์อย่างจำนวนสิทธิบัตร แล้วพบว่าหลายคนในกลุ่มนั้นกินข้าวกลางวันกับคนคนเดียวกัน
ตัวคนคนนั้นเองไม่ได้มี productivity ส่วนตัวสูงนัก แต่เขามักถามคำถามที่ลึกซึ้งและชวนให้เชื่อได้เสมอ จนทำให้เพื่อนร่วมงานมี productivity สูงขึ้นอย่างวัดผลได้
ทนายความของแผนกสิทธิบัตรที่ Bell Labs พยายามหา principle เชิงองค์กรที่จะอธิบายว่าทำไมบางคนจึงมี productivity สูงกว่า และจุดร่วมเดียวที่พบคือพนักงานที่มีสิทธิบัตรจำนวนมากมักกินข้าวกลางวันหรืออาหารเช้ากับวิศวกรไฟฟ้า Harry Nyquist บ่อย ๆ
Nyquist ไม่ได้ให้ไอเดียที่เฉพาะเจาะจง แต่ดึงให้ผู้คนเปิดใจและคิด ที่สำคัญที่สุดคือเขาถาม คำถามที่ดี
กลุ่มคนเป็นโครงสร้างที่ละเอียดอ่อน บรรยากาศทีมที่ดีและคำถามที่ดีสามารถทำให้สถานการณ์ดีขึ้นได้อย่างมองไม่เห็น
ไม่อย่างนั้นยากที่จะได้รับค่าจ้างที่ยุติธรรม
ส่วนผมไม่คิดว่าได้
ในบริษัทที่ผมทำงานอยู่หลายปี ถ้าทำให้ได้ไม่ถึง 10 พอยต์ต่อสัปดาห์ ก็จะถูกจัดให้อยู่ในกลุ่มต้องปรับปรุงผลงาน ไม่ว่าจะเป็นจูเนียร์หรือซีเนียร์ก็ตาม
ผมย้ายผ่านมาหลายทีม และแค่ดูระดับความเครียดของนักพัฒนาก็รู้ได้ทันทีว่าทีมนั้นวัดพอยต์กันอย่างไร
ทีมที่พยายามวัดพอยต์ด้วยเจตนาดีจะเครียด ส่วนใหญ่มีสัญญาณของภาวะหมดไฟ และทำงานสัปดาห์ละ 60 ชั่วโมง
ในทางกลับกัน ทีมที่ปฏิบัติกับระบบเหมือนเกมและเข้าใจว่านี่เป็นภารกิจที่เป็นไปไม่ได้ จะให้พอยต์กับ ticket ให้สูงที่สุดเท่าที่ทำได้ หรือแตกเป็น ticket เล็ก ๆ เพื่อสะสมคะแนนต่อไป และพวกเขาก็มีความสุขโดยไม่เครียด
ในสภาพแวดล้อมแบบนั้น การทำตามกฎคือ กลยุทธ์ของคนยอมให้เอาเปรียบ และเมื่อสุดท้ายผมลาออก วิศวกรซีเนียร์ 7 คนของบริษัทก็ลาออกตามไปหมดภายใน 4 เดือน
เป้าหมายคือการแบ่งเรื่องใหญ่ที่มีความไม่แน่นอนและความเสี่ยงสูง ออกเป็นเรื่องที่ทำให้สำเร็จได้อย่างต่อเนื่องโดยไม่เครียด
ไม่ได้หมายความว่าสถานที่ทำงานนั้นดูดี แต่ดูเหมือนว่านักพัฒนาที่ถูกมองว่าเล่นเกมกับระบบ โดยรวมแล้วกลับทำตามแนวทางที่ Scrum พยายามส่งเสริม
อย่างไรก็ตาม การบังคับพอยต์ขั้นต่ำต่อสัปดาห์จนกระตุ้นให้ปั่นพอยต์นั้นคือ การบริหารที่เลวร้าย
เพราะบีบเอางานจากคนเดิมได้มากกว่าตอนที่ไม่ได้กดดัน
เจ้านายเก่าของผมเคยพูดอย่างโจ่งแจ้งว่าเพื่อปิดโปรเจกต์ เขาจะ “จ้างคนมาแล้วเผาทิ้ง” และวางแผนไว้ว่าขอแค่ทำงานให้เป็นประโยชน์ได้ 6 เดือนก็พอ
ถ้าทนความเครียดกับค่าตอบแทนต่ำ ๆ แล้วยังอยู่ต่อ สำหรับบริษัทก็เหมือนเป็นของแถม และผมเองก็ไม่ได้ทนอยู่นาน
ถ้าสัปดาห์นั้นทำไม่เสร็จ ก็ทำเครื่องหมาย ticket ว่าเสร็จแล้ว แล้วเปิดงานที่เหลือเป็นบั๊กใหม่แทน
“เมื่อค่าที่วัดได้กลายเป็นเป้าหมาย ค่านั้นก็เลิกเป็นค่าชี้วัดที่ดี”
ในบางที่ การรู้ว่าผู้จัดการคาดหวังอะไรได้สำคัญกว่าผลิตภาพแท้จริงที่มุ่งสู่เป้าหมาย
คนที่ประเมินด้วยเจตนาดีอาจคิดว่าผู้บริหารก็ทำด้วยเจตนาดีเช่นกัน แต่หลายโปรเจกต์ถูกสร้างขึ้นจากความหวังลม ๆ แล้ง ๆ หรือกำหนด deadline ให้สั้นเกินจริงเพื่อ “จูงใจ” ผู้คน
ความเครียดนั้นอาจแทบไม่ได้สร้างคุณค่าอะไรเลย นอกจากความพึงพอใจทางอารมณ์ของผู้จัดการ
เมื่อผลงานของวิศวกรซอฟต์แวร์ถูกประเมินโดยคนที่ไม่ใช่สายเทคนิค ผลลัพธ์อาจออกมาสุดโต่งได้
เพื่อนของผม “Tommy” เป็นเจ้าหน้าที่ IT ที่เก่งด้านเครือข่ายมาก และไม่กี่สัปดาห์หลังย้ายไปบริษัทพลังงานของรัฐ เขาก็ต้องปรับโครงสร้างเครือข่ายทั้งหมดใหม่ด้วยอุปกรณ์สมัยใหม่ รวมถึงทุกอาคารของสำนักงานใหญ่
บริษัทตั้งใจจะจ้างผู้รับเหมาภายนอก แต่เมื่อ Tommy เห็นงบที่ฝ่ายการเงินตั้งไว้ เขาก็ตกใจ และบอกว่าถ้ามีแค่อุปกรณ์กายภาพอย่าง router, switch, สายเคเบิล และคนเดินสาย 2 คน เขาก็ทำเองได้
เขาทำงานเสร็จภายในไม่กี่สัปดาห์ด้วยค่าใช้จ่ายไม่ถึงหนึ่งในสิบของงบตั้งต้น แต่สิ่งที่ได้รับมีเพียงคำพูดจากหัวหน้าว่า “ขอบใจ ทำได้ดี”
สำหรับคน IT ในยุคที่หัวหน้า ๆ ล้าสมัยจนไม่เข้าใจ คุณค่าที่แท้จริง นี่เป็นเรื่องขมขื่นจริง ๆ
หลังจากนั้น Tommy คงเข้าไปเป็น contractor และได้รับค่าตอบแทนเพิ่มได้
นักพัฒนาที่เก่งมากคนหนึ่งที่ผมเคยทำงานด้วย เขียนได้ทั้งโค้ดที่ยอดเยี่ยม และโค้ดแย่มากที่ควรถูกรื้อทิ้งทันที แต่ทั้งสองแบบกลับเป็นปัจจัยที่ทำให้ร่วมงานกับเขาได้ดี
คุณค่าของโค้ดที่ดีไม่จำเป็นต้องอธิบาย และเป็นไปได้ว่าตอนนี้เรายังใช้โค้ดของเขาอยู่
แต่เขายังยอดเยี่ยมใน สถานการณ์ฉุกเฉิน ด้วย
เมื่อลูกค้าหยุดชะงักทั้งหมดและอาจเป็นความผิดของเรา เขาจะโผล่มาทันที เข้าใจปัญหาอย่างรวดเร็ว แล้วรีบเขียนและติดตั้งโค้ด spaghetti สกปรก ๆ ที่ทำให้ลูกค้ากลับมาเดินงานได้
มันเป็นโค้ดที่แสบตา ทั้ง check in ก็ไม่ได้ refactor ก็ไม่ได้ แต่ช่วยหลีกเลี่ยงวิกฤตเฉพาะหน้า ระหว่างที่ใครสักคนต้องไปแก้ให้ถูกต้องในภายหลัง
ผมกลับชื่นชมความสามารถแบบหลังนี้มากกว่า เพราะเหนือสิ่งอื่นใด มันเป็นทักษะที่หาได้ยาก และเขาก็เป็นคนดี ทุกคนเลยชอบเขา
ถึงอย่างนั้นผมก็ทำงานให้เสร็จได้เร็ว และโค้ดประหลาด ๆ ของผมก็เคยกู้สถานการณ์มาหลายครั้ง ไม่ว่าจะเป็นการแก้เหตุฉุกเฉินหรือช่วยให้ชนะ bid
ผมสื่อสารกับนักพัฒนาสาย “มุ่งความสมบูรณ์แบบ” ได้ยาก และสำหรับพวกเขา ต่อให้เข้าใจว่าต้องใช้ความเร็ว หากโค้ดยังไม่ได้ออกแบบมาดีพอ มันก็ดูไร้คุณค่า
แน่นอนว่าพวกเขาก็คงคิดกลับกันเกี่ยวกับผมเช่นกัน
ตอนนี้เราจัดประชุมทุกสัปดาห์เพื่อบรรเทาปัญหา และมันก็ได้ผลค่อนข้างดี
สิ่งที่ยากที่สุดคือการตัดสินใจว่าแนวทางแบบไหนเหมาะสม เมื่อไม่ใช่เหตุฉุกเฉิน แต่ตารางเวลาแน่นและสเปกไม่ชัด อย่างน้อยตอนนี้เราก็ตัดสินใจร่วมกัน
ไม่ใช่ว่าเรียนรู้เองไม่ได้ แต่แนวทางที่ต้องจำปัญหาและวิธีแก้ที่พบบ่อยจนพิมพ์ออกมาได้แบบอัตโนมัตินั้น สำหรับผมแล้วเป็นเรื่องทรมานจริง ๆ
ตราบใดที่คุณไม่ได้เป็นเจ้าของบริษัท คุณจะถูกประเมินจาก คุณค่าที่มองเห็นจากภายนอก เสมอ
ถ้านายจ้างมองไม่เห็นคุณค่าของคุณด้วยตา โอกาสที่คุณจะอยู่รอดที่นั่นก็ต่ำ
ระบบผลงานแบบ meritocracy เต็มรูปแบบอาจเป็นอุดมคติ แต่ถ้าการจ้างงานหรือการประเมินอยู่ในมือคนอื่น ความสำเร็จขึ้นอยู่กับ 100% ว่าคนนั้นมองคุณอย่างไร
การรับรู้นั้นเกิดจากภาพที่เห็นภายนอก ไม่ว่าสิ่งนั้นจะมีคุณค่าจริงต่อบริษัทหรือไม่ก็ตาม
สิ่งที่พูดถึงตรงนี้ไม่ใช่ทักษะการเขียนโปรแกรมหรือคุณค่าจริง แต่เป็นการจ้างงานและการประเมิน และก็มีคนจำนวนมากที่ผลิตภาพสูงพร้อมกับบริหารชื่อเสียงได้ดีด้วย
โดยส่วนตัวแล้ว ผมอยากให้ซีเนียร์ในทีมทำงานที่ยากจริง ๆ ให้สำเร็จ
การช่วยให้จูเนียร์ทำงานได้ก็เป็นเรื่องดี แต่สำหรับงานที่ยากและซับซ้อน ซึ่งจูเนียร์ที่ยังขาดความรู้ ประสบการณ์ และทักษะการสื่อสารระหว่างบุคคลทำไม่ได้ ก็ยังต้องอาศัยคนที่ชำนาญอยู่ดี
การ pair programming แบบไหนก็ทดแทนสิ่งนั้นได้ไม่หมด
ควรหลีกเลี่ยงสถานการณ์ที่ฟีเจอร์มูลค่าต่ำถูกทำออกมาได้ดีมาก แต่ งานที่มีผลกระทบสูงและมีลำดับความสำคัญสูง กลับไม่เสร็จ เพราะคนที่มีประสบการณ์มากที่สุดมัวไปช่วยคนที่ชำนาญน้อยกว่าในเรื่องอย่างการเขียน unit test
การที่จูเนียร์เป็นคนรับผิดชอบไม่ได้แปลโดยปริยายว่าปัญหานั้นต้องง่าย มิฉะนั้นแล้วจะพัฒนาวิศวกรให้เติบโตได้อย่างไร
ซีเนียร์ทุกคนไม่ควรใช้เวลาไปกับการเมนเทอร์จูเนียร์และการทำงานร่วมกันทั้งหมด แต่ถ้าในทีมมีคนแบบนี้สักไม่กี่คน เขาจะทำหน้าที่เป็น ตัวคูณพลัง และเป็นประโยชน์ต่อทั้งทีม
แม้ตอนรับเข้ามาจะไม่รู้มาก่อน แต่ถ้าเขาพบบทบาทเฉพาะทางที่มีประโยชน์ บริษัทก็ควรเปลี่ยนสิ่งนั้นให้เป็นบทบาทอย่างเป็นทางการ
เขาเป็น โค้ช และถ้าจ้างมาเพื่อบทบาทนั้นก็ไม่เป็นไร แต่ถ้าต้องการโค้ชจริง ๆ ก็คงจ้างแยกต่างหากไปแล้ว
ฟีเจอร์ยาก ๆ บางครั้งจูเนียร์ก็ทำไม่เสร็จแม้จะให้เวลาไม่จำกัด เพราะยังไม่มีทักษะ และทักษะนั้นต้องใช้เวลาหลายปีกว่าจะเกิดขึ้น
บางครั้งก็ต้องการความช่วยเหลือจากซีเนียร์ แต่ถ้าเพราะอย่างนั้นแล้วซีเนียร์ไม่ได้สร้างอะไรเลย สำหรับบริษัทก็มีความหมายไม่มากนัก
ฟีเจอร์ยากควรมอบให้คนที่เป็นซีเนียร์พอ และถ้าอยากพัฒนาจูเนียร์ ก็ควรแบ่งส่วนที่ง่ายของงานนั้นมาทำร่วมกัน แล้วให้ซีเนียร์อธิบายว่าตัวเองกำลังทำอะไร
ท่าทีของ Tim ที่ช่วยทุกคนเป็นเรื่องยอดเยี่ยม แต่ก็แปลกเหมือนกันที่โปรแกรมเมอร์คนอื่น ๆ ต้องการความช่วยเหลือมากขนาดที่ Tim ไม่มีเวลาเหลือทำผลงานของตัวเองเลย
ปัญหาไม่ใช่ Tim แต่เป็นการบริหารที่มองว่าโครงสร้างซึ่งผู้เชี่ยวชาญต้องการความช่วยเหลืออยู่ตลอด และมี Tim แบบอาสาสมัครคอยช่วยได้ทุกเมื่อเป็นเรื่องโอเค
ถ้าซีเนียร์คนใดคนหนึ่งสร้างมันไว้อย่างถูกต้องตั้งแต่แรก จูเนียร์ก็ควรแก้ไขได้
หากซีเนียร์คนนั้นสร้างมันขึ้นมาแล้ว แต่โครงสร้างยังทำให้ยากและซับซ้อน ก็ชวนสงสัยว่าทำไมถึงเรียกเขาว่า ซีเนียร์
ถึงอย่างนั้น งานของซีเนียร์ทุกคนก็ไม่อาจมีแต่การช่วยจูเนียร์ได้
ทุกวันนี้การเป็นคนแบบนั้นทำได้ยาก
ทุกอย่างเน้นผลงานที่มองเห็นได้จากภายนอก คนแบบนั้นจึงมักกลายเป็นเป้าหมายของการปรับลดได้ง่าย และผมก็เคยเจอกับตัว
team player, mentor และ software architect ถูกผลักออกไปเรื่อย ๆ ส่วน coder ที่ผลิตโค้ดออกมามาก ๆ กลับเข้ามาแทนที่
แม้ technical debt จะทำให้ความสามารถในการส่งมอบฟีเจอร์และบำรุงรักษาลดลงเมื่อเวลาผ่านไป ผู้จัดการก็ยังชอบดีเวลลอปเปอร์ที่เขียนได้สม่ำเสมอเกิน 5,000 บรรทัดต่อสัปดาห์ โดยไม่สนว่าฟีเจอร์ที่ออกจริงหรือจำนวนบั๊กเป็นอย่างไร
ในฐานะ team lead และวิศวกรที่เคยบริหารโปรเจกต์ซับซ้อน ผมรู้สึกกลัวคนที่เขียนโค้ดเกิน 2,000 บรรทัดต่อสัปดาห์
นั่นคือโค้ดเกิน 100,000 บรรทัดต่อปี และต้องคิดถึงความซับซ้อนที่ไม่จำเป็นด้วย
มีโอกาสสูงที่จะทำฟีเจอร์เดียวกันได้ด้วย 10,000 บรรทัด บั๊กน้อยกว่า และใช้เวลาเพียงครึ่งเดียว แต่ถ้าเป็นแบบนั้นก็จะเหลือแค่ 380 บรรทัดต่อสัปดาห์ ซึ่งผู้จัดการคงไม่ชอบ
ผมมักมองว่าดีเวลลอปเปอร์ที่ผลิตโค้ดออกมาทีละหลายพันบรรทัดไม่ได้คิดลึกพอเกี่ยวกับทิศทางระยะยาวของโปรเจกต์ และรู้สึกว่าโค้ดส่วนใหญ่นั้นใกล้เคียงกับ โค้ดที่จะถูกทิ้ง
Google ทำให้สิ่งนี้เป็นระบบอยู่บ้างในบทบาท Tech Lead และคาดหวังว่าวิศวกรคนนี้จะทำตัวเป็นคนที่ทวีพลังให้ทีมและเป็นเมนเทอร์ มากกว่าจะเป็น individual contributor
มันไม่ได้ทำงานตามที่ออกแบบไว้เสมอไป และอาจทำงานได้แค่ไม่บ่อยนักด้วยซ้ำ TL อาจจมอยู่กับการประสานงานคน การวางแผน และข้อถกเถียงเล็ก ๆ น้อย ๆ จนไม่สามารถทำงานเป็นวิศวกรได้
ถึงอย่างนั้น เจตนาของบทบาทนี้ก็ถือว่าโอเค
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
แนวคิดที่จะวัดทุกอย่างและทำตามตัวเลขที่ได้มา มีมาตั้งแต่ศตวรรษที่ 19
ผู้จัดการทำแนวปฏิบัติแบบเดิมซ้ำ ๆ มาตั้งแต่นั้น และผลลัพธ์ก็ออกมาค่อนข้างคงที่ในแบบเดียวกัน
เจ้าของบริษัทแห่งหนึ่งที่ผมเคยทำงานอยู่ช่วงสั้น ๆ ต้องการเขียนเว็บเซอร์วิสใหม่ตั้งแต่ต้นทุก 6 เดือน เพื่อให้ตามเว็บเฟรมเวิร์กและกระแสล่าสุด
ถ้ามีฮีโร่สาย 5,000 บรรทัดต่อสัปดาห์ เขาคงรับเข้าทำงานทันที
ในโปรเจกต์บำรุงรักษา บางสัปดาห์ผมอาจผ่านไปโดยไม่ได้เขียนเพิ่มแม้แต่บรรทัดเดียว และบางครั้งก็ใช้เวลาทั้งสัปดาห์ไปกับ การลดจำนวนบรรทัดของโค้ด ด้วยซ้ำ
ยอดเยี่ยม
ในกีฬาเรือพายมีการฝึกที่เรียกว่า seat racing โดยจะใส่และสลับคนในตำแหน่งต่าง ๆ ของเรือแปดที่นั่งหลาย ๆ แบบ เพื่อหาชุดที่เร็วที่สุด
พละกำลังของแต่ละคนก็เป็นตัวชี้วัดอย่างหนึ่ง แต่คนที่จะได้ขึ้นเรือแข่งจริงถูกตัดสินด้วยความเร็วของทีม
สุดท้ายแล้ว ชุดที่เร็วที่สุดมักไม่ใช่การเอาแปดคนที่แข็งแรงที่สุดมาใส่ตรง ๆ และบ่อยครั้งจะมีคน “มหัศจรรย์” หนึ่งหรือสองคนที่ต่อให้บนกระดาษดูไม่ได้โดดเด่นกว่า แต่พอใส่ลงเรือลำไหนก็ทำให้ลำนั้นเร็วขึ้น
พวกเขาปรับสมดุล จังหวะ และพลังของคนอื่น ๆ ให้ดีขึ้นอย่างละเอียดอ่อน
โค้ชบางคนไม่เต็มใจยอมรับสิ่งนี้และต่อต้าน ผลลัพธ์คือชนะน้อยลง
คล้ายกับทีมซอฟต์แวร์มาก และท้ายที่สุด สิ่งสำคัญคือ องค์ประกอบของทีมและผลลัพธ์
เมื่อมีคนขอให้ช่วยโค้ชเรื่อง “ภาวะผู้นำทางเทคนิค” ผมมักบอกเสมอให้จับตาดู พนักงานสายผู้เอื้ออำนวย อย่างใกล้ชิด
ความช่วยเหลือของคนเหล่านี้ทำให้พนักงานคนอื่นมีผลิตภาพและประสิทธิผลมากขึ้น และบางคนได้ความพึงพอใจในงานมากกว่าจากการช่วยให้ผู้อื่นทำผลงานได้ยอดเยี่ยม แทนที่จะลงมือทำสิ่งน่าทึ่งด้วยตัวเองแล้วรับเครดิตทั้งหมด
คนแบบนี้มักได้คะแนนต่ำ แต่ถ้าสูญเสียพวกเขาไป ผลิตภาพของทีมจะลดลงสุทธิ
ดังนั้นจึงพยายามให้เครื่องมือเพื่อแยกแยะระหว่างคนที่ไม่ได้มีผลิตภาพจริง ๆ กับคนที่ผลิตภาพของเขาปรากฏผ่านความสำเร็จของผู้อื่น
การวัดเพียงตัวชี้วัดเดียวแล้วบริหารตามนั้นไม่ใช่เรื่องดีอย่างเด็ดขาด
เพราะคนที่เล่นกับตัวชี้วัดจะ “ชนะ” และพฤติกรรมแบบนั้นจะนำไปสู่การเลื่อนตำแหน่ง
ผมเคยบอกประเด็นนี้กับผู้นำของ Google ด้วย แต่ Laszlo บอกว่า “นี่คือระบบที่เรามี และมันไม่สมบูรณ์แบบ แต่เราจะเดินหน้าด้วยระบบนี้ จะทำงานอยู่ในกรอบนั้นหรือไม่ก็เป็นทางเลือกของคุณ”
แค่การประชุมครั้งนั้นก็เพียงพอแล้วที่จะรู้ว่าผู้นำระดับสูงตั้งใจจะสร้างสภาพแวดล้อมทางวิศวกรรมที่ดีกว่านี้หรือไม่
ผู้จัดการใหม่จำนวนมาก โดยเฉพาะคนที่เคยเป็นวิศวกรผู้ลงมือทำงานรายบุคคลมาก่อน คิดว่าถ้าเก็บสมาชิกที่ “เก่งที่สุด” ไว้และปล่อยสมาชิกที่ “แย่” ออกไป ขวัญกำลังใจและผลผลิตของทีมจะดีขึ้นทั้งคู่
แต่ “เก่งที่สุด” ในความเข้าใจของพวกเขาไม่ได้อิงจากเกณฑ์การบริหารคน แต่อิงจากเกณฑ์ที่เคยใช้ทำงานของตัวเองให้ดี
ดังนั้นพวกเขาจึงมักชอบคนที่มีทักษะและนิสัยคล้ายตัวเอง และมองคนที่มีทักษะและนิสัยต่างออกไปต่ำกว่า
ช่วงเวลาที่ทำให้พวกเขาตระหนักเรื่องนี้แล้วตาโตขึ้นมานั้นน่าสนใจเสมอ
นโยบายดอกเบี้ยเป็นศูนย์ ทำให้บทบาทอย่าง senior director ที่ดูแลบอร์ด Jira และรายการงานเพิ่มขึ้น และทำให้ขาดแคลนคนที่ทำงานจริงได้
ผมไม่ได้คัดค้านแนวคิดที่ว่าอาจมีคนที่ช่วยส่งเสริมผลิตภาพของคนอื่นได้ แต่ท้ายที่สุด หากจะให้อะไรสักอย่างเสร็จ ก็ต้องมี “คนอื่น ๆ” เหล่านั้น
ไม่เช่นนั้นองค์กรก็จะเกิดเนื้อตาย