ความหมายที่แท้จริงของการ "ทำงานเสร็จแล้ว (Done)" ในบริษัท Big Tech

• ใน Big Tech การ ทำงานให้เสร็จจริงๆ หมายถึง ทำให้งานไปถึงจุดที่บริษัทพึงพอใจ แล้วจึงจากมา ภายในระบบที่สามารถปรับปรุงต่อได้ไม่สิ้นสุด
• วิศวกรที่เก่งแต่ ขาดความเป็นเจ้าของและความริเริ่ม มักจะวนอยู่กับการปรับปรุงเล็กๆ น้อยๆ ซ้ำๆ จนพลาดผลงานที่แท้จริง
• ต้องส่งมอบ ผลลัพธ์ที่ชัดเจนและมองเห็นได้ ให้ผู้มีอำนาจตัดสินใจ จึงจะได้รับการยอมรับว่าเป็นการ “ทำงาน”
• ควรตรวจสอบอยู่เสมอว่าสิ่งที่ตนทำอยู่ อยู่ในรูปแบบที่ผู้บริหารระดับสูงสามารถอ่านและประเมินได้หรือไม่
• ไม่ใช่ทุกงานที่จะจัดการให้เรียบร้อยได้ทั้งหมด และเมื่อถึงจุดหนึ่ง "ความสามารถในการประกาศชัยชนะแล้วจากไป" จะกลายเป็นทักษะสำคัญ

---

'งาน' มีคุณสมบัติที่ไม่อาจปิดจบได้อย่างสมบูรณ์

• ต่างจากโจทย์คณิตศาสตร์หรือการบ้าน งานในโลกความเป็นจริงคือ ระบบเปิดที่สามารถปรับปรุงได้อย่างไม่สิ้นสุด
• การพัฒนาบริการก็เหมือนการปลูกต้นไม้ เป็นกระบวนการที่ ยังต้องดูแลต่อเนื่องหลังจากนั้น

วิศวกรฝีมือดีที่ติดกับดัก

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

ความหมายที่แท้จริงของการ ‘ทำให้เสร็จ’

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

ทำให้งาน ‘อ่านได้’

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

‘การทำให้เสร็จ’ คือแนวคิดทางสังคม

• ในเชิงปรัชญา แม้แนวคิดว่า 'เสร็จแล้ว' จะเป็น สิ่งประกอบสร้างทางสังคม แต่ในโลกความเป็นจริงมันมี พลังอย่างยิ่งในทางปฏิบัติ
• หากมองข้ามเรื่องนี้ คุณอาจไม่ได้รับการประเมิน และ ท้ายที่สุดอาจถูกเลิกจ้างได้

สรุป

• แค่กำลังทำงานอยู่ ไม่ได้แปลว่าได้ทำมันเสร็จแล้ว
• งานส่วนใหญ่ไม่มีวันจบ และสามารถดำเนินต่อไปได้เรื่อยๆ
• อย่าเป็นคนสวน แต่จงเป็น นักวางกลยุทธ์ที่ยึดผลลัพธ์เป็นศูนย์กลาง
• เกณฑ์ของคำว่า “เสร็จแล้ว” คือ ความพึงพอใจของบริษัท/ผู้จัดการ
• "ประกาศชัยชนะ → จากไป → ไปสู่งานถัดไป" คือกลยุทธ์สำคัญ

[aer0700]

ดูเหมือนว่าการเลือกงานที่สามารถประกาศชัยชนะได้ว่า "เสร็จแล้ว (Done)" ก็เป็นทักษะสำคัญอย่างหนึ่งเช่นกัน

[elbanic]

การจำกัดขอบเขตของงานเรียกว่า scoping ความสามารถก็คือการทำ scoping ให้ดีเพื่อให้ชนะได้

[bakyeono]

ฮันชิน vs โซฮา

[doolayer]

ไม่ใช่รายละเอียด แต่เป็นผลลัพธ์ที่มองเห็นได้ซึ่งวัดเป็นตัวเลขได้

[GN⁺]

ความคิดเห็นจาก Hacker News

• ฉันไม่ได้คัดค้านข้อโต้แย้งของบทความนี้ทั้งหมด แต่จากประสบการณ์ที่เคยทำงานทั้งในบิ๊กเทค สตาร์ทอัพหลายแห่ง และบริษัทยูนิคอร์น รู้สึกว่ามันไม่ใช่คำแนะนำที่ใช้ได้จริงนัก ตลอด 10 ปีที่ผ่านมา งานของนักพัฒนาถูกทำให้เฉพาะทางมากเกินไป จนห่างไกลจากความต้องการของผู้มีอำนาจตัดสินใจและลูกค้า ปรากฏการณ์นี้เกิดขึ้นเพราะ Product Manager เข้ามาคั่นกลางระหว่างวิศวกรกับส่วนที่เหลือของบริษัท ฉันอยากสร้างผลลัพธ์ที่มีคุณค่าอยู่เสมอ แต่ถ้าจะทำแบบนั้นจริง ๆ ก็ต้องยอมรับความเครียดอย่างต่อเนื่อง ผลงานของฉันต้องถูกปรับผ่านอีโก้ของคนที่เป็นผู้คุยกับผู้มีอำนาจตัดสินใจเสมอ ช่วง 5 ปีที่ผ่านมา ครั้งเดียวที่รู้สึกถึงความสำเร็จจริง ๆ คือช่วงที่ได้รับบทบาท Product Manager ชั่วคราว 9 เดือน ในช่วงนั้นทีมของเราส่งมอบ 3 โปรเจ็กต์ได้สำเร็จ ทั้งที่ก่อนหน้านี้ทีมอื่นพยายามมาหลายครั้งแล้วไม่สำเร็จ เคล็ดลับคือการคุยกับผู้มีส่วนได้ส่วนเสียโดยตรงเพื่อเข้าใจความต้องการ ไม่ใช่การพยายามทำในแบบของฉันเอง เพราะงั้นต่อไปฉันก็คงส่งมอบแค่สิ่งที่ถูกขอ ถูกตำหนิเรื่องบั๊ก และไม่ได้รับเครดิตเรื่องฟีเจอร์ อย่างน้อยค่าตอบแทนก็โอเคอยู่ ยังมองหาที่ที่ฉันจะมีส่วนร่วมได้อย่างเหมาะสมต่อไป

  • ส่วนที่ว่า “อย่างน้อยค่าตอบแทนก็โอเค” นี่ติดอยู่ในหัวเป็นพิเศษ ตอนทำงานในบิ๊กเทค ฉันมีมุมมองของตัวเองว่า การอยู่ในสภาพ “นิ่งค้าง” ก็ไม่ได้แย่ขนาดนั้น เช่น ถ้าได้เงินเดือน 300,000 ดอลลาร์ต่อปีที่ Google หรือ MS แล้วทำโปรเจ็กต์น่าเบื่อเดิม ๆ อยู่ 10 ปี ประวัตินั้นก็ยังได้รับการยอมรับจากที่ไหนก็ได้ ตัวฉันในอดีตที่ทะเยอทะยานอาจจะไม่พอใจเรื่องนี้ แต่ถ้าเป็นคนแบบนั้นก็คงย้ายไปบริษัทเล็กกว่าเอง พออายุมากขึ้น ความสนใจก็ย้ายจากบริษัทไปสู่ครอบครัวและเพื่อนมากขึ้น ถ้ามีใครบอกฉันว่าจะไม่ได้เลื่อนตำแหน่ง ฉันก็คงตอบว่า “แล้วไง?” ฉันหาเงินให้ครอบครัวได้พอ และยังมี work-life balance ด้วย พูดตรง ๆ ส่วนที่ดีที่สุดของบริษัทก็คือเงินเดือน และสิ่งที่มันทำให้ชีวิตส่วนที่เหลือดีขึ้น
  • ฉันก็เคยเจอเหมือนกันว่าในความเป็นจริงสายงาน Product Manager ไม่ได้เป็นอย่างที่ถูกอธิบายไว้อย่างสวยงาม แต่กลับกลายเป็นคนคั่นกลางที่เป็นตัวแทนทั้งสองฝั่งได้ไม่ดี ผลคือฉันต้องไปพัฒนาทักษะการจัดการผลิตภัณฑ์ด้วยตัวเอง ซึ่งทักษะนี้มีประโยชน์มากในการหลีกเลี่ยงงานเสียเปล่า เลยทำให้สงสัยว่าสำหรับวิศวกรระดับใหญ่แล้ว product management ควรเป็นทักษะจำเป็นด้วยหรือไม่
  • อีกเรื่องที่ต้องคิดคือ ถ้าดำเนินต่อไปแบบนี้ก็กำลังเดินตรงไปสู่ภาวะหมดไฟ
  • ฉันได้ตระหนักว่าการสื่อสารคือชุดทักษะที่สำคัญที่สุดในทุกองค์กร การทำงานชั่วคราว 9 เดือนยังไม่พอจะเห็นคุณค่าที่แท้จริงของมัน ตัวบทความเองก็อ่านแล้วให้ความรู้สึกเหมือนนักวิศวกรที่หงุดหงิดมาก ๆ และคิดว่าตัวเองฉลาดกว่าคนอื่นในองค์กร ซึ่งบ่อยครั้งก็ไม่จริง และ mindset แบบนี้ส่งผลเสียต่อการทำงานร่วมกัน
  • เบื้องหลังเว็บแอปพลิเคชันที่ทำงานได้ดี มักจะมีคนสักคนที่ทำหน้าที่เหมือนคนสวนอยู่เสมอ
  • สงสัยว่าทำไมถึงไม่ทำ Product Manager ต่อไป
  • มันต่างกันมากจริง ๆ แล้วแต่บริษัท หลายแห่งวิศวกรมีอิทธิพลมากกว่า โดยเฉพาะแม้จะเป็นบิ๊กเทคก็ยังมีกรณีที่ไม่ได้แยกขาดจากลูกค้า
  • นี่หมายความว่าควรไล่ Product Manager ออกงั้นหรือ?
  • ฉันก็เคยทำหน้าที่ Product Manager คือคอยไกล่เกลี่ยระหว่างวิศวกรกับบริษัท และเป็นความจริงที่ผลงานของฉันเองก็ถูกกรองผ่านอีโก้ของตัวเองเหมือนกัน แต่ฟังดูเหมือนคุณบอกว่านั่นเป็นงานที่น่าพึงพอใจมาก… ก็คงน่าพึงพอใจจริง ๆ

• ฉันมีข้อคัดค้านเชิงหลักการต่อการใช้แค่การทำให้ผู้มีอำนาจพอใจเป็นเกณฑ์ของความสำเร็จ เราอาจถูกผูกไว้กับโครงสร้างสถานะที่น่าขัน แต่ฉันไม่คิดว่าการเปลี่ยน ticket ใน Jira เป็น “เสร็จแล้ว” หรือกำจัด compiler warning ออกไปคือทุกอย่าง ไม่มีใครพูดว่า “ฉันไม่เสียใจเลย เพราะตลอด 40 ปีฉันเอาแต่ทำให้หัวหน้าพอใจทุกครั้ง”

  • ฉันทำงานมา 30 จาก 40 ปีแล้ว และการทำให้หัวหน้าและหัวหน้าของหัวหน้าพอใจก็มีคุณค่าอย่างชัดเจน แม้มุมมองแบบประชดประชันจะไม่ใช่ทั้งหมดของชีวิต แต่การรู้มุมมองแบบประชดนี้ก็หมายถึงเข้าใกล้ความจริงมากขึ้น
  • ที่จริงฉันคิดว่า “การทำให้หัวหน้าและหัวหน้าของหัวหน้าพอใจ” ก็คือนิยามของการจ้างงาน คุณทำสิ่งที่มีคนสั่งแล้วก็รับเงิน

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

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

• ผู้เขียนบอกว่า “จำเป็นต้องสร้างผลลัพธ์ที่มองเห็นได้สำหรับผู้มีอำนาจตัดสินใจ” และฉันเข้าใจ mindset แบบ “ธุรกิจ” ของเขา นักพัฒนาหลายคนลำบากเพราะไม่รู้จะอธิบายอย่างไรว่างานของตัวเองมีประโยชน์เชิงธุรกิจอย่างไร เรื่อง refactoring ก็เข้าข่ายนี้ การปรับปรุงโค้ดอาจดูเหมือนไม่มีความหมายอะไรเลยในระยะสั้น แต่ขึ้นอยู่กับสถานการณ์ มันอาจสร้างประโยชน์มหาศาลให้องค์กรได้ สุดท้ายประเด็นสำคัญคือ ต้องคิดว่างานของตัวเองเชื่อมโยงกับรายได้หรือการประหยัดขององค์กรอย่างไร และจะสื่อสารเรื่องนั้นอย่างไร

  • นักพัฒนาต้องเรียนรู้ภาษาของธุรกิจ และจัดกรอบปัญหาในแบบที่คนฝั่งธุรกิจเข้าใจและใส่ใจ การตัดสินใจทางธุรกิจส่วนใหญ่สุดท้ายก็เป็นเรื่องต้นทุนเทียบกับผลประโยชน์ ที่จริงแล้วคนทำธุรกิจจำนวนมากยังมองซอฟต์แวร์เป็นเพียงต้นทุนด้วยซ้ำ กล่าวคือ ต่างจากความคิดที่นักพัฒนามองว่า “ซอฟต์แวร์คือศูนย์กลางของการสร้างรายได้ไม่ใช่หรือ” ฝั่งธุรกิจไม่ได้สนใจซอฟต์แวร์ในตัวมันเอง ถ้าขายฟรีได้ ต้นทุนทั้งหมดก็เป็น 0 และ margin ก็เป็นอนันต์ นี่คือความคิดจริงของคนธุรกิจ ฝ่ายขายก็เป็นพื้นที่ที่ดีลสำเร็จได้ด้วยบรรยากาศ ความสัมพันธ์ หรือแม้แต่สินบน มากกว่าเหตุผล ฟังดูไม่สมเหตุสมผล แต่ก็จำเป็นต้องเข้าใจมัน

• ฉันสงสัยว่า “mindset แบบนี้คือเหตุผลที่วิศวกรจำนวนมากไม่สนใจคุณภาพโค้ด การทดสอบ และเอกสารหรือเปล่า?” ถ้าสนแค่ความพึงพอใจทันทีของผู้ใหญ่ ใครจะพยายามเขียนโค้ดที่ดูแลรักษาได้ในระยะยาว? อาจไม่จำเป็นต้องมีคุณภาพเกินมาตรฐาน แต่แค่ลงทุนขั้นต่ำก็ประหยัดเงินได้เป็นพันล้าน

  • ผู้คนจำนวนมากขึ้นเรื่อย ๆ ไม่สนใจงานฝีมือและคุณภาพเลย มีเสียงแนว “ฉันทำงานเท่าที่ได้เงินเดือนจ่ายมา” มากขึ้น เมื่อก่อนมีความรู้สึกว่าต่อให้ค่าจ้างเท่าไร งานก็ควรทำอย่างตั้งใจ แต่ดูเหมือนสิ่งนั้นจะหายไปมากแล้ว
  • ทุกคนมีเหตุผลที่ได้รับมอบหมายบทบาทของตัวเอง เหมือนในกองถ่ายภาพยนตร์ วิศวกรแต่ละคนก็อาจมีเป้าหมายต่างกัน ถ้าคุณปิดกั้นไม่ให้วิศวกรได้ใช้ความหลงใหล สุดท้ายก็จะเหลือแต่คนที่ขับเคลื่อนด้วยเงินอย่างเดียว ซึ่งเสี่ยงมาก
  • ฉันไม่คิดว่ามีใครตั้งใจเขียนโค้ดแย่ ๆ ความไม่ใส่ใจหรือภาวะหมดไฟเกิดขึ้นเมื่อสภาพแวดล้อมไม่ให้รางวัลกับความพยายามซ้ำ ๆ ไม่มีใครอยากทุ่มแรงเพิ่ม และนักพัฒนาจำนวนมากก็มีฝีมือพื้นฐานไม่สูงอยู่แล้ว มันไม่ใช่อาชีพที่แข่งขันเข้มข้นระดับนักคณิตศาสตร์ประกันภัย ใครก็เข้ามาได้จากแทบทุกพื้นฐาน และแต่แรกก็เก่งได้ยากอยู่แล้ว
  • Product Manager จำนวนมากต้องการแค่ความเร็ว เราอยากได้การทดสอบและเอกสาร แต่ CFO มองว่างานพวกนี้ “ไม่ใช่ฟีเจอร์ จึงไม่จำเป็น” และถือว่าเป็นของฟุ่มเฟือย
  • วิศวกรไม่ได้ตั้งอยู่บนสมมติฐานว่าจะอยู่กับบริษัทนานพอ จึงไม่คิดจะแบกรับความรับผิดชอบในอนาคต เมื่อย้ายงานบ่อย ๆ ก็ไม่เคยต้องเผชิญปัญหาจากโค้ดที่ตัวเองเขียนไว้ในที่ทำงานก่อนหน้า จึงไม่เคยได้เรียนรู้จากความล้มเหลว และก็ทำซ้ำอีก ฉันอยู่บริษัทเดิมมาเกือบ 20 ปี และเห็นความผิดพลาดแบบเดิมวนซ้ำตลอด ฉันเริ่มเบื่อกับการเปลี่ยนแปลงที่เปลี่ยนแค่เปลือกแต่ปล่อยปัญหาแก่นแท้ไว้เหมือนเดิม ถ้าไม่แก้ปัญหาจริง การเปลี่ยนแปลงก็ไม่มีความหมาย ฉันมีเป้าหมายคือแก้ปัญหาจริง

• ฉันเจอความจริงและปัญหานี้มานาน เข้าใจมัน แต่ก็ยังคงคัดค้าน หลายโปรเจ็กต์เริ่มต้นขึ้น มีเสียงว่า “แก้เสร็จแล้ว done!” แล้วทีมก็ถูกยุบ แต่ตัวผลิตภัณฑ์ยังมีปัญหาอยู่ ยังต้องเพิ่มฟีเจอร์ และบริษัทก็ยังเปลี่ยนแปลงต่อไป สุดท้ายก็มีแต่ technical debt สะสมเพราะขาดการดูแล ผู้จัดการคนใหม่เข้ามาแล้วสร้างโปรเจ็กต์เก่าซ้ำใหม่ ทำผิดพลาดแบบเดิมอีก วิธีนี้ไม่มีประสิทธิภาพ ถ้าอธิบายด้วยอุปมาแอร์ การรักษาอุณหภูมิให้คงที่มีประสิทธิภาพกว่าการปิดแล้วค่อยลดอุณหภูมิใหม่ เครื่องมือจัดการที่ฉันสร้างขึ้นจริง ๆ แล้วผู้บริหารไม่ได้สนใจ แต่ผู้ใช้ภายในมีมากกว่า 500 คน จึงเป็นสิ่งจำเป็นมาก สำคัญคือการรักษาความน่าเชื่อถือต่อเนื่องโดยไม่ต้องลงทุนเวลาดูแลมากนัก ถ้าปล่อยทิ้งไว้ มันก็จะกระจัดกระจาย และความน่าเชื่อถือของเครื่องมือก็หายไป ใช้เวลาแค่ไม่กี่นาทีก็รักษาความสม่ำเสมอไว้ได้

  • ที่จริงอุปมาแอร์นั้นผิดตามหลักอุณหพลศาสตร์ การปิดแล้วค่อยลดใหม่มีประสิทธิภาพกว่า

• ฉันมีความรู้สึกปะปนกันหลายอย่าง แน่นอนว่าในแง่ visibility และการเลื่อนตำแหน่ง สิ่งที่บทความนี้พูดก็ถูก แต่ในความเป็นจริงมันคือคำแนะนำแบบผู้จัดการเป็นศูนย์กลางที่บอกให้เอาแต่ทำให้ผู้จัดการพอใจ แล้วถ้าไม่มีทิศทางที่ชัดเจนและลำดับความสำคัญเปลี่ยนตลอดล่ะ? มันก็ยากที่จะสร้างผลลัพธ์ที่มีความหมาย และความสัมพันธ์ระหว่างผู้จัดการกับลูกน้องก็จะกลายเป็นโครงสร้างแบบ “yes-man” ไปโดยสมบูรณ์ ผลลัพธ์แบบนั้นไม่ดีเลย

  • คำตอบง่ายมาก ถ้ารู้สึกว่ากำลังทำงานใต้หัวหน้าโง่ ๆ ก็ลาออกไปเลย ความลำบากเป็นเรื่องชั่วคราว แต่สุดท้ายชีวิตจะดีขึ้น ดีกว่าเสียเวลาอธิบายงานของตัวเองให้คนโง่ฟัง
  • ในทางกลับกัน ถ้าได้ทำงานกับผู้จัดการที่ดีจริง ๆ แค่ “ทำให้ผู้จัดการพอใจ” ก็ช่วยให้ทั้งอาชีพและผลงานเติบโตได้เร็วมาก

• "unagentic engineer" หมายถึงวิศวกรที่ขาดความเป็นตัวของตัวเองในการลงมือ ถ้าวิศวกรทำงานแบบนี้ ก็อาจนำไปสู่ความไร้ประสิทธิภาพและปัญหาร้ายแรง เช่น ค่าใช้จ่ายคลาวด์ที่สูงเกินไป เหตุการณ์ด้านความปลอดภัย หรือความไม่พอใจของลูกค้า ตัวอย่างของงานที่ไม่มีวันจบจริง ๆ ได้แก่ security patch การแก้ความผิดพลาด การปรับต้นทุนให้เหมาะสม และการตอบสนองต่อ feedback จากลูกค้า ถ้าบริษัทไม่เข้าใจคุณค่าเหล่านี้ คำตอบก็คือย้ายงาน

  • นี่แหละคือประเด็นของบทความ บางองค์กรยึดความเป็นจริงเป็นศูนย์กลาง บางที่ยึดสถานะเป็นศูนย์กลาง องค์กรที่ยึดความเป็นจริงจะมีเหตุผลในระยะยาว ส่วนองค์กรที่ยึดสถานะมีเป้าหมายแค่ทำให้หัวหน้าพอใจ ลำดับชั้นสำคัญกว่าคุณภาพผลิตภัณฑ์หรือความสัมพันธ์กับลูกค้า องค์กรแบบนี้อาจไม่จำเป็นต้องล่มสลาย แต่บางทีก็พังทลายลงในชั่วพริบตา
  • “Unagentic” หมายถึงพนักงานที่ไม่มี agency แม้จะอยากให้เขาแสดงความเป็นฝ่ายริเริ่มด้วยตัวเอง แต่ในทางปฏิบัติก็มีหลุมพรางที่ทำให้นักพัฒนากลายเป็นคนที่ตัวตนหายไป
  • ไม่จำเป็นต้องเป็นแบบนี้เสมอไป แต่ถ้าฝ่ายผู้บริหารไม่ใส่ใจ โดยพื้นฐานแล้ววัฒนธรรมแบบนี้ก็มักจะก่อตัวขึ้น ตัวอย่างเช่น ฉันสนุกกับการใส่ใจรายละเอียดของการออกแบบอินเทอร์เฟซ แต่จะได้รับผลตอบแทนก็ต่อเมื่อองค์กรยอมรับว่าสิ่งนี้มีคุณค่า หลายแห่งไม่ได้สนใจเลย
  • “unagentic engineer” คือคนประเภทที่ขาดคุณสมบัติในการตัดสินใจและขับเคลื่อนสิ่งต่าง ๆ ด้วยตัวเอง เอาแต่ปล่อยตัวไปตามกระแส
  • หมายถึงวิศวกรที่ไม่ค่อยมีอำนาจในการตัดสินใจด้วยตัวเอง
  • คือคนที่ไม่ใช่ “high agency” กล่าวคือแม้จะดูฉลาดและมีความสามารถ แต่ก็มักรอคำสั่งอยู่เสมอและไม่สามารถเป็นฝ่ายนำเองได้

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

• ต้นฉบับมีประโยชน์ แต่ดูเหมือนจะขาดประเด็นสำคัญกว่านี้ไป:

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

[heal9179]

ความเห็นฝั่งนี้ต่างหากที่ตรงประเด็นมากกว่า

[roxie]

จริงเลย 555