ผลงานจากการแก้ปัญหาที่ไม่ได้เกิดขึ้น และไม่มีใครจดจำได้ (2001) [PDF]

 (web.mit.edu)
1 คะแนน โดย GN⁺ 2024-02-23 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • บริษัทต่าง ๆ ใช้เงินจำนวนมากเพื่อไล่ตาม ความสามารถในการปฏิบัติการ เช่น ความสามารถด้านการผลิตแบบ Toyota, คุณภาพแบบ six-sigma และซัพพลายเชนแบบ Dell แต่โปรแกรมปรับปรุงมักไม่ค่อยนำไปสู่ผลงานที่ยั่งยืน
  • TQM เป็นกรณีที่เคยถูกใช้อย่างแพร่หลายแล้วถูกแทนที่อย่างรวดเร็ว โดยในกลุ่ม Fortune 1000 มีบริษัทที่มี โปรแกรม TQM ที่พัฒนาอย่างดี น้อยกว่า 10%
  • สาเหตุของความล้มเหลวไม่ได้อยู่ที่การเลือกเครื่องมือใดเครื่องมือหนึ่ง แต่อยู่ที่วิธีที่โปรแกรมใหม่เชื่อมเข้ากับโครงสร้างทางกายภาพ เศรษฐกิจ สังคม และจิตวิทยา ทำให้การปรับปรุงกลายเป็น ปัญหาเชิงระบบ ในท้ายที่สุด
  • เมื่อช่องว่างด้านผลงานกว้างขึ้น องค์กรต้องเลือกระหว่าง Work Harder คือทำงานให้นานขึ้น กับ Work Smarter คือพัฒนาความสามารถ แต่แนวทางหลังมักถูกเบียดตกไปเพราะมีความล่าช้าและความเสี่ยงที่จะล้มเหลว
  • Shortcuts ที่ลดเวลาสำหรับการปรับปรุงดูน่าดึงดูดเพราะเพิ่มผลผลิตระยะสั้นได้ แต่เมื่อความสามารถที่ถดถอยซึ่งปรากฏช้าสะสมมากขึ้น องค์กรอาจติดอยู่ใน Capability Trap

ปรากฏการณ์ย้อนแย้งของโปรแกรมปรับปรุงที่ล้มเหลว

  • บริษัทต่าง ๆ ลงทุนอย่างจริงจังในการปรับปรุงกระบวนการเพื่อพัฒนา ความสามารถในการปฏิบัติการ เช่น การผลิต คุณภาพ ความเข้าใจลูกค้า และการจัดการซัพพลายเชน
  • ในปี 1997 ค่าใช้จ่ายรวมของบริษัทสหรัฐฯ สำหรับที่ปรึกษาด้านการจัดการและการฝึกอบรมอยู่ที่ มากกว่า 100,000 ล้านดอลลาร์ และส่วนใหญ่ถูกใช้เพื่อไล่ตามความสามารถในการปฏิบัติการของบริษัทชั้นนำ
  • แม้จะมีความสำเร็จอย่างน่าทึ่งบางกรณี แต่โปรแกรมปรับปรุงจำนวนมากไม่สามารถสร้างผลลัพธ์ที่มีนัยสำคัญได้
  • TQM แสดงให้เห็นปรากฏการณ์ย้อนแย้งนี้ได้ดี
    • จากแรงกระตุ้นจากความสำเร็จของบริษัทญี่ปุ่นในทศวรรษ 1980 ทำให้ TQM ได้รับความนิยมอย่างมากในหมู่บริษัทสหรัฐฯ
    • ช่วงกลางทศวรรษ 1990 ความสนใจจากแวดวงวิชาการและสื่อธุรกิจลดลง และถูกนวัตกรรมใหม่อย่าง re-engineering เบียดแทน
    • บริษัทที่มุ่งมั่นอย่างจริงจังต่อวินัยและวิธีการของ TQM ทำผลงานได้สูงกว่าคู่แข่ง
    • งานวิจัยหนึ่งพบว่า ในกลุ่ม Fortune 1000 มีบริษัทที่มีโปรแกรม TQM ที่พัฒนาอย่างดี น้อยกว่า 10%
    • งานวิจัยอีกชิ้นพบว่า TQM เป็นเครื่องมือธุรกิจที่ถูกใช้มากเป็นอันดับ 3 ในปี 1993 แต่ตกลงมาเป็น อันดับ 14 ในปี 1999
  • เทคนิคการปรับปรุงในอดีตบางอย่างกลับมาอีกครั้งภายใต้ชื่อใหม่
    • วินัยหลักของการควบคุมกระบวนการเชิงสถิติและการลดความแปรปรวนสืบต่อมาเป็น six-sigma
    • quality circle ถูกเรียกใหม่ว่า high-performance work team

สิ่งที่ยากกว่าเครื่องมือคือโครงสร้างการนำไปใช้

  • เครื่องมือและเทคนิคสำหรับปรับปรุงผลงานเพิ่มขึ้นอย่างรวดเร็ว และด้วยการเพิ่มขึ้นของเทคโนโลยีสารสนเทศกับที่ปรึกษา ทำให้เรียนรู้ได้ง่ายขึ้นว่าใครใช้เทคนิคใดบ้าง
  • สำหรับผู้จัดการส่วนใหญ่ อุปสรรคที่ใหญ่กว่าไม่ใช่การรู้จักวิธีใหม่ แต่คือการ นำไปใช้ให้สำเร็จ ในงานประจำวัน
  • ความสามารถอย่างโปรแกรมคุณภาพ six-sigma ไม่สามารถซื้อได้เหมือนผลิตภัณฑ์แบบ turnkey แต่ต้องพัฒนาขึ้นภายในองค์กร
  • ตลอดกว่า 10 ปี มีการทำ กรณีศึกษาเชิงลึกมากกว่า 12 กรณี ในอุตสาหกรรมโทรคมนาคม เซมิคอนดักเตอร์ เคมี ปิโตรเลียม ยานยนต์ และสินค้าเพื่อการพักผ่อน
    • ใช้การสังเกต การสัมภาษณ์ผู้มีส่วนร่วม เอกสารบันทึก และตัวชี้วัดเชิงปริมาณ
    • มีการพัฒนาโมเดลควบคู่กันไปเพื่อจับพลวัตของการนำไปใช้และการปรับปรุง
  • เหตุผลที่องค์กรส่วนใหญ่ไม่ได้รับประโยชน์จากนวัตกรรมการปรับปรุงอย่างเต็มที่ แทบไม่เกี่ยวข้องกับการเลือกเครื่องมือปรับปรุงใดเครื่องมือหนึ่ง
  • โปรแกรมปรับปรุงใหม่ทำงานในจุดที่เครื่องมือ อุปกรณ์ พนักงาน ผู้จัดการ และโครงสร้างทางกายภาพ เศรษฐกิจ สังคม และจิตวิทยาเชื่อมโยงกัน จึงกลายเป็น ปัญหาเชิงระบบ

ฟิสิกส์พื้นฐานของการปรับปรุง: เวลาและความสามารถ

  • ผลงานจริงของกระบวนการถูกกำหนดโดย เวลาที่ใช้ทำงาน (Time Spent Working) และ ความสามารถของกระบวนการ (Capability) ในการทำงานนั้น
    • ในการผลิต ผลผลิตสุทธิที่ใช้ได้ถูกกำหนดจากผลคูณของชั่วโมงแรงงานต่อวันกับผลิตภาพ หรือผลผลิตที่ใช้ได้ต่อชั่วโมงแรงงาน
  • ผลงานสามารถเพิ่มได้ด้วยการทำงานมากขึ้นหรือลงทุนในการปรับปรุงมากขึ้น แต่ผลลัพธ์ของสองวิธีนี้ต่างกัน
    • หากเพิ่มชั่วโมงทำงานต่อสัปดาห์ 20% ผลผลิตอาจเพิ่มขึ้น 20% ตราบเท่าที่ยังคงทำโอทีต่อไป
    • การปรับปรุงความสามารถของกระบวนการจะเพิ่มผลผลิตของชั่วโมงทำงานทั้งหมดที่ถูกใส่เข้าไปหลังจากนั้น
    • การทำโอทีเพื่อแก้ไขสินค้ามีตำหนิเพิ่มผลผลิตเฉพาะตอนที่ยังทำโอทีอยู่ แต่การกำจัดสาเหตุรากของตำหนิจะลดความจำเป็นในการทำงานซ้ำอย่างต่อเนื่อง
  • ความสามารถถูกมองเป็น สินทรัพย์สะสม (stock) ที่สะสมตามเวลา
    • เวลาที่ใช้กับการปรับปรุงเพิ่มการลงทุนในความสามารถ
    • เนื่องจากต้องใช้เวลาในการค้นหาสาเหตุราก ค้นพบ ทดสอบ และนำแนวทางแก้ไขไปใช้ จึงมี ความล่าช้า ระหว่างกิจกรรมปรับปรุงกับการเปลี่ยนแปลงของความสามารถ
    • ความสามารถที่ไม่ได้รับการบำรุงรักษาเป็นประจำจะเสื่อมถอยจากการสึกหรอของเครื่องจักร การเบี่ยงเบนของกระบวนการ การออกแบบที่ล้าสมัย และขั้นตอนที่ตกยุค
  • ความล่าช้าของการปรับปรุงขึ้นอยู่กับความซับซ้อนทางเทคนิคและองค์กรของกระบวนการ
    • ความล่าช้าในการปรับปรุงกระบวนการที่ค่อนข้างเรียบง่าย เช่น yield ของเครื่องจักรใน job shop อยู่ในระดับหลายเดือน
    • ความล่าช้าในการปรับปรุงกระบวนการที่ซับซ้อน เช่น การพัฒนาผลิตภัณฑ์ อาจกินเวลาหลายปีขึ้นไป
    • ในองค์กรที่มีอัตราการเปลี่ยนแปลงของผลิตภัณฑ์และบุคลากรสูง อายุของความสามารถที่ปรับปรุงแล้วก็สั้นลงด้วย

ความตึงเครียดระหว่าง Work Harder กับ Work Smarter

  • ผู้บริหารกำหนดเป้าหมาย เช่น ความต้องการของลูกค้า ปริมาณการประมวลผลเคลมประกัน หรือจำนวนผลิตภัณฑ์ใหม่ที่ออกในแต่ละไตรมาส เป็น Desired Performance
  • ความต่างระหว่างผลงานจริงกับเป้าหมายกลายเป็น Performance Gap และในองค์กรที่ศึกษาแทบไม่พบกระบวนการที่ทำได้เกินความคาดหวัง
  • ในองค์กรที่ไม่อยากเพิ่มทรัพยากรหรือจ้างคนเพิ่ม ทางเลือกพื้นฐานในการปิดช่องว่างด้านผลงานมีสองแบบ

  • ลูป Work Harder

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

  • ลูป Work Smarter

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

ลูปการลงทุนซ้ำและกับดักความสามารถ

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

  • ลูป Reinvestment

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

  • ลูป Shortcuts

    • ทางลัด เช่น ข้ามประชุมปรับปรุง เลื่อนการบำรุงรักษาเชิงป้องกันตามกำหนด หรือไม่สนใจข้อกำหนดด้านเอกสาร เพิ่มเวลาทำงานได้ทันที
    • เพราะความสามารถที่ถดถอยไม่ปรากฏทันที ทางลัดจึงดูมีประสิทธิผลและน่าดึงดูดในระยะสั้น
    • ผู้จัดการที่เลื่อนการบำรุงรักษาเชิงป้องกันจะได้ ช่วงผ่อนผัน จากการหลีกเลี่ยง downtime ตามแผนและประหยัดค่าใช้จ่ายบำรุงรักษา แต่ภายหลัง yield และ uptime จะลดลงจากอุปกรณ์ที่เก่าและสึกหรอ
    • วิศวกรซอฟต์แวร์ที่ข้ามการทำเอกสารอาจจบโปรเจกต์ได้ตรงเวลา แต่ต้องจ่ายต้นทุนเมื่อแก้บั๊กที่พบในการทดสอบในอีกหลายสัปดาห์หรือหลายเดือนให้หลัง

  • Capability Trap

    • ในช่วงแรก Work Harder เพิ่ม throughput รวมได้ทันที และต้นทุนจากเวลาปรับปรุงที่ลดลงปรากฏช้า จึงเกิดสถานการณ์ better-before-worse
    • Work Smarter ลดผลผลิตระยะสั้น แต่เมื่อเวลาผ่านไปความสามารถที่เพิ่มขึ้นจะชดเชยความพยายามในการทำงานที่ลดลงและยกระดับผลงาน เป็นพลวัตแบบ worse-before-better
    • ปฏิสัมพันธ์ระหว่าง Shortcuts กับ Reinvestment อาจสร้าง Capability Trap ที่ขังองค์กรไว้ในวงจรอุบาทว์ของความสามารถที่ลดลง

บทความที่เกี่ยวข้อง

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

 
GN⁺ 2024-02-23
ความคิดเห็นจาก Hacker News

  • จำได้เลือน ๆ แต่มีตัวอย่างที่ดีอยู่
    ในองค์กรหนึ่งมีการ ประมวลผลคำสั่งซื้อ ที่สำคัญ แต่เป็นสถานการณ์ที่ไม่อาจเชื่อได้ว่าข้อมูลที่จำเป็นจะมาครบหรือมาถูกต้องเสมอไป จึงสร้าง logic ตรวจสอบเพื่อปรับแต่ง input และเปลี่ยนวิธีประมวลผล พร้อมบันทึก metric ไว้ว่า validation ใดถูก trigger ในแต่ละคำสั่งซื้อ ถ้าเพิ่ม validation ใหม่ก็ใส่วันที่กำกับไว้ด้วย
    พอเปิดเผย metric นี้และแชร์เป็นครั้งคราว เวลาใครถามว่า “ถ้าเป็น XYZ จะเกิดอะไรขึ้น?” ก็สามารถตอบได้ว่า “จัดการไปแล้ว และป้องกันไม่ให้คำสั่งซื้อ #### รายการติดขัดเพราะ XYZ”
    สิ่งนี้ทำให้เห็นว่าทีมทำงานอย่างรอบคอบ งานแบบนี้จำเป็นเพื่อให้ระบบทำงานได้ดีต่อเนื่อง และสามารถมีข้อมูลรองรับได้ ด้วยเหตุนี้ บทสนทนาในองค์กรจึงเปลี่ยนจาก “ทำไมถึงคิดไม่ถึง” ไปเป็น “ตอนนี้ควรทำอะไรต่อ” และการยอมรับต่อคุณภาพเชิงป้องกันก็ไต่ขึ้นไปถึงระดับบนด้วย

    • แนวคิดเรื่องการวัดว่า validation ใดถูก trigger กี่ครั้งนั้นเรียบง่าย แต่มีความอัจฉริยะที่ปฏิเสธไม่ได้
      ทีมส่วนใหญ่คงดูแค่ metric อย่าง อัตราความสำเร็จของคำสั่งซื้อ แล้วจบ แต่ถ้าใช้ จำนวนครั้งที่จัดการข้อมูลไม่ดี เป็น metric ก็จะหลุดพ้นจากกับดักที่งานดี ๆ มักไม่เป็นที่สังเกตได้

  • ที่ทำงานล่าสุดเจอเรื่องเดียวกันเป๊ะ
    ในฐานะ tech lead/architect ขององค์กร ผม/ฉันได้ตรวจสอบโปรเจกต์ที่เพิ่งปล่อยไป และพบจุดที่ต้องปรับปรุงอย่างจำเป็นเพราะมี ปัญหาด้าน reliability/performance ร้ายแรง release หลายตัวของทีมหนึ่งอยู่บนสุดของรายการ แต่ PM และ engineering manager ของทีมนั้น รวมถึงผู้บริหารด้านบน ต่างเพิกเฉยต่อความกังวลทั้งหมด โดยบอกว่าต้องให้ความสำคัญกับการอัปเดตฟีเจอร์ก่อน
    ไม่กี่เดือนต่อมาระหว่างลาพักร้อน เรื่องก็ระเบิดขึ้น มี sev 1 escalation ลูกค้าหลายรายโกรธ และ CEO/CTO ก็เข้ามาเกี่ยวข้อง ทีมเดียวกันที่เขียนโค้ดหยาบ ๆ นั้นและเพิกเฉยต่อคำเตือน กลับทำงานหามรุ่งหามค่ำเพื่อกู้บริการ และตอนนี้พวกเขากลายเป็นฮีโร่ โดยเฉพาะ manager คนนั้น ชื่อเสียงในบริษัทดีขึ้นเพราะสื่อสารอย่างแข็งขันและแสดง leadership ระหว่าง incident

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

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

    • ระบบการศึกษาที่ผม/ฉันผ่านมา ถูกออกแบบมาให้สอนว่าผลลัพธ์แทบจะแปรผันเชิงเส้นกับความพยายามและเวลา บทเรียนแรกหลังเรียนจบคือมันไม่ใช่แบบนั้น
      บ่อยครั้งเมื่อทุ่มความพยายามและเวลามากขึ้น รางวัลกลับตามไม่ทัน ขณะที่ถูกคาดหวังให้ทุ่มความพยายามและเวลามากขึ้นไปอีก คุณค่าและโอกาส เป็นกระบวนการที่ใกล้กับความโกลาหลมากกว่าต่อความพยายามและเวลา
      สุดท้ายจึงควรรักษาปริมาณงานให้อยู่ในระดับที่จิตใจยังปลอดโปร่งพอจะคว้าโอกาสเมื่อมันปรากฏขึ้น เพื่อนร่วมงานที่ซื่อสัตย์และสมดุลช่วยได้ แต่ท้ายที่สุดก็เป็นสิ่งที่ต้องทำด้วยตัวเอง
    • มีกรณีที่แย่กว่านั้นด้วย คนมักติดขัดและรีบมาขอความช่วยเหลือทันที พอช่วยปลดล็อกให้ทุกคน งานของตัวเองก็ล้าหลัง และเมื่อหัวหน้าของหัวหน้าขอ metric ของ developer จำนวน point ที่ผม/ฉันทำได้ก็น้อย บรรทัดโค้ดที่เปลี่ยนก็น้อย
      ต่อให้หัวหน้าพยายามอธิบาย ตอนปลดพนักงานรอบถัดไป คนที่โดนตัดอาจเป็นผม/ฉันก็ได้
    • เคยทำงานแบบนั้นในฐานะ contractor รายชั่วโมง วันแรกก็แก้ ปัญหา 6 เดือน ของพวกเขาได้ และหลังจากนั้นหวังว่าเขาจะจ้างต่อในงานอื่น แต่เขาบอกว่า “สิ่งที่ต้องการก็มีแค่นั้น”
      เขาบอกบริษัทอื่น ๆ ให้ว่าผม/ฉันเก่งเรื่องแบบนี้ แต่ก็ไม่มีอะไรตามมา งานสัญญาจ้างกับบริษัทเล็ก ๆ ครั้งนั้นจึงเป็นครั้งแรกและครั้งสุดท้าย
    • หัวหน้าที่ดีจริง ๆ จะชดเชยปัญหานี้ได้ แม้จะผลักดัน teamwork และ collaboration แต่ก็รู้รายละเอียดว่าแต่ละคนทำอะไรและมีส่วนช่วยต่อภาพรวมอย่างไร และโดยทั่วไปสามารถตัดสินเรื่องรางวัล เลื่อนตำแหน่ง และเลิกจ้างได้อย่างแม่นยำ
      ดังนั้น morale ของสมาชิกทีมจึงไม่ตก สมาชิกทีมจำเป็นต้องได้รับการยอมรับในเชิงจิตวิทยาว่ามี contribution ส่วนตัว
      หัวหน้าแบบนี้มักเคยเป็น individual contributor ที่เก่งแล้วกลายมาเป็น team lead และเพราะตัวเองเป็นผู้เชี่ยวชาญในทักษะนั้น จึงอยู่ในตำแหน่งที่ดีที่สุดในการประเมิน individual contributor ที่ตนบริหาร
    • วิธีที่ถูกประเมินต่ำในการรับมือปรากฏการณ์นี้ ผม/ฉันคิดว่าคือ การโปรโมตตัวเอง อย่างเหมาะสม ต้องพูดซ้ำ ๆ ว่าทำอะไรไปบ้างเพื่อป้องกันหายนะ
      ต้องบรรยายหายนะที่หลีกเลี่ยงไปได้อย่างมีชีวิตชีวา เพื่อให้คนเห็นภาพชัดเจน

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

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

  • นึกถึงที่ทำงานเก่าขึ้นมา ทุกครั้งที่ขอ feedback เขาจะพูดซ้ำ ๆ ว่า “ที่นี่ไม่มีอะไรได้เป็น priority ถ้าไม่มี PIR (post-incident response)”
    ช่วงท้าย ๆ พอมี ticket เกี่ยวกับ PIR โผล่ขึ้นมา ผมก็ทำเครื่องหมายว่ามันซ้ำกับ ticket จริงที่นอนตายอยู่ใน backlog ทั้งที่ ticket นั้นสามารถป้องกันเหตุได้ การที่เราไม่มีอิทธิพลใด ๆ ในการป้องกันปัญหาที่คาดการณ์ได้ในพื้นที่ที่ทีมรับผิดชอบ ทำลายขวัญกำลังใจของทีมอย่างหนัก
    สมาชิกทีมส่วนใหญ่เลิกเสนอการปรับปรุงไปเลย เพราะฝ่ายบริหารไม่อนุญาตให้เราดึง ticket เข้ามาทำเอง

  • อธิบายได้ดีมากว่า Scrum แบบองค์กรกำลังกลายเป็นนรกแบบไหน
    Agile เดิมทีหมายถึงการทำงานให้เร็วและพัฒนาความสามารถเป็นรอบสั้น ๆ แต่ Scrum กลับกลายเป็นเวอร์ชันที่แย่กว่ากระบวนการวางแผนที่มันตั้งใจจะมาแทน
    วิธีที่ Scrum แยกงานออกเป็นปัญหาเฉพาะหน้ากลับทำให้วงจรนี้แย่ลง ระยะยาวมันกลายเป็นระบบ ticket ที่ไฟถูกดันขึ้นไปข้างบน ส่วน หนี้ทางเทคนิค ถูกดันลงไปข้างล่าง
    แถมยังคายตัวเลขประสิทธิภาพที่ติดตามง่ายแต่ไร้ความหมาย ซึ่งเหมาะให้ consultant และผู้บริหารเล่นเกม optimization อีกด้วย

    • ที่บอกว่า “Scrum เป็นเวอร์ชันที่แย่กว่ากระบวนการวางแผนที่มันตั้งใจจะมาแทน” พูดเหมือนมันเป็นเรื่องบังเอิญเลยนะ
      พูดแบบนี้ได้ เพื่อนสนิทผมบางคนก็เป็น Scrum Master
    • สุดท้าย Agile ดูเหมือนจะลงเอยเป็นวิธีให้ PM รายงานต่อผู้บริหารระดับสูง และให้ผู้บริหารระดับสูงรายงานต่อขึ้นไปอีก
      ผมเข้าใจว่าทำไม ในบรรดางานจำนวนมหาศาลที่ทำได้ ต้องมีใครสักคนตัดสินใจว่าจะทำอะไร ฟีเจอร์นี้จะทำเงินได้ไหม? แล้วงานที่ไม่ใช่ฟีเจอร์แต่ลดต้นทุนทรัพยากรล่ะ? แล้ว หนี้ทางเทคนิค ที่ทำให้การส่งมอบฟีเจอร์ช้าลงล่ะ?
      ผมไม่ใช่ผู้บริหารระดับสูง แต่สุดท้ายใครสักคนข้างบนก็มีหน้าที่ให้บริษัทอยู่รอด ทำเงิน และจ่ายเงินเดือนเราได้ พวกเขาก็ต้องตัดสินใจจากข้อมูลน้อย ๆ ที่หาได้เหมือนเรา ดังนั้นจึงต้องมีวิธีเปรียบเทียบว่า “อันนี้ต้นทุนเท่าไรและมีมูลค่าเท่าไร” กับ “อันนั้นต้นทุนเท่าไรและมีมูลค่าเท่าไร”
      พวกเขาต้องการวิธีประเมิน และเมื่อวงการเทคโนโลยีโปรโมต Agile ว่าเป็นเครื่องมือนั้น พวกเขาก็ยึดมันไว้ แล้วเป็นความผิดของใครกัน?
      จากนั้นการประเมินบ่อย ๆ การติดตามกำหนดการ และพิธีกรรมต่าง ๆ ก็พ่วงตามมา บางคนไม่เชื่อว่าสิ่งเหล่านี้ควรตามมาโดยธรรมชาติ และผมก็เห็นด้วย แต่ไม่ว่าอย่างไรพิธีกรรมเหล่านั้นก็กลายเป็นส่วนหนึ่งของลัทธิไปแล้ว
      เราเลิกใช้ Scrum แล้ว เลิกประชุม refinement เลิกประเมิน story และเลิกใช้ story point ด้วย ตอนนี้เดือนละครั้งเราจะพบ PM อย่างเป็นทางการ และดูสถานะปัจจุบันระดับทีมด้วยการ ประเมินแบบขนาดเสื้อยืด เท่านั้น นอกนั้นก็อัปเดตเมื่อ PM ขอ หรือเมื่อเรารู้สึกว่าจำเป็น วิธีนี้ทำให้สิทธิ์ตัดสินใจอยู่กับเรา แต่ก็หมายความว่าเราต้องรับผิดชอบมากขึ้นและแจ้งให้ทันเวลาถ้าสถานการณ์ดูไม่น่าไว้ใจ เรายังต้อง “ประเมิน” อยู่ดี เพราะสุดท้ายผู้บริหารระดับสูงต้องตัดสินใจ แต่โดยรวมแล้วมันค่อนข้างเบา และรู้สึกปลดปล่อยจริง ๆ
    • ความคิดที่ว่า Scrum จะมีประสิทธิภาพถ้าดำเนินการอย่างถูกต้องนั้นเคยเป็นจริงในบริษัทหนึ่ง
      ทุกคนทุ่มเทกับกระบวนการ และทีม Scrum จัด 20% ของแรงงานไว้เป็น priority สำหรับจัดการหนี้ ความเร็วของแต่ละคนก็ค่อนข้างแม่นยำ จึงสามารถใส่งานตามความสนใจส่วนตัวเพิ่มอีก 20% ได้ และ priority ของผู้มีส่วนได้ส่วนเสียเติมส่วนที่เหลือ 60%
      ในบาง sprint ถ้าต้องรวมพลังเพื่อปิด epic หรือเป้าหมายทีม หรือมีเหตุฉุกเฉิน/บั๊กที่ต้องเปลี่ยน priority ก็หันทางกันได้
    • วิธีที่ได้ผลดีกว่าคือค่อย ๆ ต่อเติม กระบวนการขึ้นไปจนเป็น Scrum เมื่อเห็นปัญหา และผ่อนกระบวนการลงเมื่อทุกอย่างเดินได้ดี
      การเพิ่มกระบวนการจำนวนมากเพียงเพราะอยากเพิ่ม ไม่ได้สร้างคุณค่า
    • ผมนึกว่า Scrum หมายถึงการที่ทุกคนกรูกันเข้ามาเพื่อปิดงานในการ standup รายสัปดาห์เสียอีก

  • นึกถึงการ์ตูนเรื่องนี้ที่แปะไว้ในออฟฟิศ: https://naksecurity.medium.com/the-detriments-of-hero-cultur...
    ดังนั้นในวัฒนธรรมองค์กรจำนวนมาก ถ้าปัญหาไม่ได้อยู่ในขอบเขตรับผิดชอบโดยตรงของตัวเอง ต่อให้รู้วิธีแก้ ก็จะได้รางวัลมากกว่าถ้าไม่ป้องกันไว้ล่วงหน้า ปล่อยให้ปัญหาเผยตัว ปล่อยให้มันกลายเป็นเหตุฉุกเฉินของใครสักคน แล้วค่อยแก้
    แน่นอนว่าในระยะยาวองค์กรแบบนั้นไม่มีทางไปได้ดี จึงควรวางแผนย้ายออกด้วย

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

  • นึกถึงบทความ “ไม่มีใครได้รับการยกย่องจากการแก้ปัญหาที่ไม่เคยเกิดขึ้น” (2001) [pdf]
    ความคิดนี้ยังคงอยู่ทุกครั้งที่ยูทูบเบอร์หรือคลิกเบตบนโซเชียลมีเดียอ้างว่า บั๊ก Y2K ไม่ได้เป็นเรื่องใหญ่อะไร
    เหตุผลที่มันไม่ใช่เรื่องใหญ่ก็เพราะมีทหารผ่านศึกจำนวนมากอย่างผมอดหลับอดนอนกันมาตั้งหลายเดือนก่อนหน้าเพื่อทำให้ทุกอย่างทำงานได้
    ยังจำความตึงเครียดตอนนับถอยหลังเที่ยงคืน UTC ได้อยู่เลย จากนั้นก็ตึงเครียดอีกครั้งตอนนับถอยหลังตามเวลาฝั่งตะวันออก และอีกครั้งตามเวลาท้องถิ่น กว่าจะผ่อนคลายได้จริง ๆ ก็ตอนเวลาแปซิฟิกเข้าสู่ปี 2000 แล้ว

    • ก็ขึ้นอยู่กับว่าหมายถึงบั๊ก Y2K แบบไหน แต่เรื่องแบบนี้เกิดขึ้นจริง และเป็นสถานการณ์ที่น่าเชื่อถือพอสมควร ผมไม่คิดว่าเป็นสถานการณ์ที่เทียบกันได้
    • ผมยังไม่ค่อยเชื่อสนิทใจอยู่ดี คอมพิวเตอร์ส่วนใหญ่ไม่ได้ใช้ epoch time สำหรับวันที่ แทนที่จะเป็น dd/mm/yy หรอกหรือ?
      เดี๋ยวคงได้รู้กันในปี 2038

  • ถ้าเป็นช่วงเวลาเดียวกัน Y2K ก็เป็นตัวอย่างที่ดีมากเช่นกัน แทบไม่มีอะไรที่เห็นได้ชัดเกิดขึ้น แต่ถ้าผู้คนแค่เพิกเฉย ก็คงมีเรื่องเกิดขึ้นมากมาย

    • ไม่ใช่แค่ “เป็นไปได้” ผมเคยแก้โค้ดที่ BP เองในปี 1998 บอกได้เลยว่าจะต้องมีเรื่องเลวร้ายเกิดขึ้นแน่
      ไม่ใช่เพราะเงินเดือนผมขึ้นอยู่กับเรื่องนั้นหรอก โอกาสไปทำงานอื่นมีมากอยู่แล้ว แต่มันเป็นปัญหาที่ทำให้อุตสาหกรรมพลังงานเป็นอัมพาตได้จริง และจะส่งผลต่อบริษัทใหญ่ ๆ รวมถึงองค์กรจำนวนมากที่พึ่งพาบริษัทเหล่านั้น จากประสบการณ์นี้ ผมคิดว่าอุตสาหกรรมหลายด้านอย่างการเงินหรือการพัฒนาทรัพยากรก็คงได้รับแรงกระแทกแบบเดียวกันทั้งทางตรงและทางอ้อม
      เพราะฉะนั้นมันเป็นตัวอย่างที่ดี ทุกวันนี้ผมยังเจอคนที่จำ Y2K ว่าเป็นแค่เรื่องตื่นตูมไร้สาระอยู่เลย ไม่ใช่แบบนั้น ที่มันไม่เป็นปัญหาสำหรับคุณก็เพราะมีคนจำนวนมากทำงานหนักเพื่อกันไม่ให้มันเกิด
      ปัญหาเหล่านั้นไม่ได้ซับซ้อนมหาศาล แต่กระจายกว้าง สำคัญ และต้องใช้แรงงานจำนวนมาก มันไม่ใช่ปัญหาวิศวกรรมระดับลงจอดบนดวงจันทร์ที่มนุษยชาติจะเอามาอวดเป็นความสำเร็จยิ่งใหญ่ แต่ใกล้เคียงกับการแก้ปัญหา Challenger O-ring โง่ ๆ นับไม่ถ้วนก่อนมันระเบิดมากกว่า
    • เป็นกรณีศึกษาที่สำคัญมาก มีการลงทุนมหาศาลในการแก้ Y2K และเริ่มกันตั้งนานก่อนถึงวันที่จริง เช่น ผลิตภัณฑ์ทางการเงินที่มีวันครบกำหนดหลัง Y2K ต้องถูกแก้ก่อนจะถึงวันครบกำหนด
      ดังนั้นพอถึงวันจริงจึงเหลือแค่บั๊กตกค้างเล็กน้อยนิดหน่อย หนังสือพิมพ์มีมุกตลกอยู่บ้าง แต่สาธารณชนโดยรวมก็ผ่านมันไปเฉย ๆ
      ผมทำงานด้านภูมิอากาศ และเคยหวังหรือยังคงหวังให้เกิดแบบเดียวกัน แต่ดูเหมือนว่าอีกไม่นานมันจะต้องดึงความสนใจของทุกคนอย่างหลีกเลี่ยงไม่ได้
    • นี่คือ ปฏิทรรศน์ของการเตรียมพร้อม
      ถ้าเตรียมพร้อมไว้ ก็จะไม่มีอะไรน่าสนใจเกิดขึ้น ชีวิตก็ดำเนินต่อไป และผู้คนจะจำได้แค่ว่าเราเปิดแล็ปท็อปแล้วกดปุ่มไม่กี่ปุ่ม
      ถ้าไม่เตรียมพร้อม กริดไฟฟ้าเท็กซัสก็แข็งตัว ผู้คนเสียชีวิต สูญเสียเงินออม และกลายเป็นว่า “ไม่มีใครจินตนาการได้ว่ามันจะเลวร้ายขนาดนี้”
    • ผมเคยเห็นแม้กระทั่งคนที่ควรจะรู้ดีกว่านั้นพูดว่า Y2K ไม่ได้เป็นเรื่องใหญ่ และความพยายามป้องกันปัญหาเป็นการ ผลาญภาษี โดยสิ้นเชิง
      สารภาพว่าผมก็มีส่วนร่วมในงานนั้นด้วย เรื่องตลกคือผมถูกเรียกกลับไปยังลูกค้าเก่า เพื่อแก้ปัญหาที่งานของผมในอดีตสร้างขึ้นมาอย่างแท้จริง ผมเห็นปัญหาแล้วแก้ได้ภายใน 20 นาที จากนั้นก็มีประโยค “ในเมื่อคุณมาแล้ว ช่วยดูอันนี้ด้วยได้ไหม…” ตามมา และยืดไปอีกราว 2 ปีจนกระทั่งแผนกนั้นถูกปิดและย้ายไปนิวยอร์ก
      อย่างน้อยก็ได้รับการยอมรับในรูปของชั่วโมงที่เรียกเก็บเงินได้

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

    • ผมรู้จักปัญหาแบบนั้นหลายเรื่อง ผมเองก็ทำให้ คะแนนสูงสุด ในวิดีโอเกมที่กำลังทำอยู่ทำงานได้ถูกต้อง
      สิ่งที่น่าหงุดหงิดคือ ในกรณีการเปลี่ยนแปลงสภาพภูมิอากาศ สถานการณ์ที่ดีที่สุดก็เป็นแบบเดียวกันนี้ ถ้าเราประสบความสำเร็จในการหลีกเลี่ยงหายนะได้จริง ๆ บรรดา “ผู้ปฏิเสธเรื่องภูมิอากาศ” ทั้งหมดก็จะรู้สึกว่าตัวเองเป็นฝ่ายถูก
 
GN⁺ 2024-02-23
ความคิดเห็นจาก Hacker News

  • เห็นหัวข้อแล้วนึกถึงเกร็ดเล่าจากจีนโบราณขึ้นมาได้ เรื่องที่ Toyota เพิ่งพัวพันกับเรื่องอื้อฉาวก็ชวนให้รู้สึกย้อนแย้งอยู่นิดหน่อย: https://www.bbc.com/news/articles/c1wwj1p2wdyo
    เมื่อกษัตริย์เหวินแห่งแคว้นเว่ยถามเปี่ยนเชวี่ยว่า “ถ้าพี่น้องสามคนล้วนเป็นหมอ ใครเก่งที่สุด?” เปี่ยนเชวี่ยตอบว่า “พี่ชายคนโตเก่งที่สุด พี่ชายคนรองรองลงมา และข้าแย่ที่สุด”
    พี่ชายคนโตมองโรคออกตั้งแต่ก่อนมันจะก่อตัวและกำจัดมันอย่างเงียบ ๆ จึงเป็นที่รู้จักแค่ในบ้าน พี่ชายคนรองรักษาโรคตอนที่มันเพิ่งเริ่มแสดงอาการ ชื่อเสียงจึงไม่ออกไปไกลเกินตรอกในหมู่บ้าน ส่วนตัวเปี่ยนเชวี่ยเองใช้การเจาะเส้นเลือด ใช้ยารุนแรง และผ่าตัดเนื้อ จึงมีชื่อเสียงในหมู่เจ้านายเพราะเป็นการกระทำที่มองเห็นได้ชัด

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

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

    • ต้องใส่สัญญาณความเจ็บปวดไว้ในระบบ เหมือนถ้ามือบาดเจ็บแต่ไม่ส่งความเจ็บไปที่สมอง เราก็จะไม่เปลี่ยนพฤติกรรมหรือเปลี่ยนลำดับความสำคัญที่ก่ออันตราย องค์กรก็เช่นกัน การแก้ทุกปัญหาแบบเงียบ ๆ และกันไม่ให้มันไหลขึ้นไปข้างบนไม่ใช่ทางที่ดีที่สุดเสมอไป
      บางปัญหาควรส่งสัญญาณความเจ็บขึ้นไปก่อนซ่อม เพื่อให้ผู้นำได้เรียนรู้จากมัน
      แต่การออกแบบแรงจูงใจนั้นยาก และต้องไม่ทำให้ผู้บริหารระดับสูงสุดสร้างโครงสร้างที่บังคับให้ลูกน้องและหน่วยงานแสดงความเจ็บปวดหรือปัญหาไม่ได้ คนที่ปิดสัญญาณด้วยเจตนาดีก็มีอยู่บ่อย จึงต้องโค้ชกันว่าในองค์กรใหญ่ บางครั้งการปล่อยให้บางปัญหาคลี่ตัวออกมา และไม่ตอบสนองแบบรีบเร่งเกินไป อาจมีประสิทธิภาพกว่า
    • ตลอดเวลากว่า 35 ปีในสาย IT นิสัยที่ผมเกลียดที่สุดอย่างหนึ่งคือการทำตัวเป็นฮีโร่ ตรงกันข้าม ผมคิดว่าทีมควรมีวิศวกรสาย “ตัวทำลาย” อยู่เสมอ
      ในขณะที่ทุกคนออกแบบโดยตั้งอยู่บนสมมติฐานว่าสภาพแวดล้อมปกติและการปฏิบัติการจะสมบูรณ์แบบ คนที่คอยหาว่าจะทำให้การออกแบบ บริการ อินฟรา และแอปพังได้อย่างไรนั้นสำคัญมาก
    • ที่ทำงานเก่า CEO ซึ่งเป็นเจ้าของบริษัทเองเคยเสนอไอเดียว่าจะให้โบนัสราว 20% ของมูลค่าที่ประหยัดได้ในปีแรก หากใครหาแนวทางลดต้นทุนได้
      เพื่อนร่วมงานในแผนก IT คนหนึ่งน่าจะได้เงินมากกว่าสองพันยูโรนิดหน่อยจากการเปลี่ยนใบรับรองเชิงพาณิชย์มาใช้ Let’s Encrypt และตัดข้อกำหนด EV ออก แต่สุดท้ายก็ไม่ได้ เพราะเรื่องแบบนั้นถูกนับว่าเป็น “งานตามหน้าที่”
    • เคยเห็นผู้จัดการที่ล้มเหลวกลับได้เลื่อนตำแหน่งต่อเนื่อง จนในทางปฏิบัติกลายเป็นคนดูแลงานวิศวกรรมทั้งหมด โปรเจกต์ล้มเหลวทุกตัว แต่ก็ได้งบและนักพัฒนาเพิ่มเพื่อขยายและเริ่มใหม่ สุดท้ายเลยได้คุมทุกอย่าง
      ส่วนทีมที่สร้างบริการซึ่งใช้งานได้จริงกลับโดนแช่งบไว้และแม้แต่จำนวนคนก็ถูกลด
    • จุดเริ่มต้นที่ดีน่าจะเป็นการติดตามและรายงานทุกอย่างที่ทำไปแบบเชิงรุก อย่างน้อยก็เพิ่มโอกาสให้มีคนเห็นว่าที่มันเงียบ เพราะเราคาดการณ์ปัญหาและกันมันไว้ก่อนเริ่มแล้ว
      เมื่อทีมอื่นมีปัญหา เราจะชี้ให้เห็นได้ว่าทำไมทีมเราไม่เจอปัญหาเดียวกัน ด้วยรายการงานที่ทำเสร็จไปแล้ว งานเหล่านั้นทำไปแล้ว เพียงแค่ทำในช่วงเวลาที่ดีกว่าเพื่อหลีกเลี่ยง downtime

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

    • คำพูดของ Blaise Pascal ที่ว่า “ที่เขียนมายาวกว่าปกติ เพราะไม่มีเวลาทำให้สั้นกว่านี้” เข้ากันพอดี
    • รู้สึกว่าการเขียนโค้ดด้วย AI กำลังผลักงานของทุกคนไปสู่ความซับซ้อนของวิธีแก้ที่มากขึ้น คนเลยดูจะไม่ได้ทึ่งกับความซับซ้อนของคนอื่น แต่กลับตั้งการ์ดและไม่อยากแตะมากกว่า
      บริษัทใหญ่อาจยังตามไม่ทันและยังประทับใจกับความซับซ้อนอยู่ แต่สำหรับคนที่ต้องรับผลลัพธ์จาก AI ไม่ทางตรงก็ทางอ้อม ความซับซ้อนก็ดูไม่น่าประทับใจเท่าเมื่อก่อนแล้ว
    • ในทางกลับกัน ผมเลิกช่วยคนอื่นแก้ปัญหาคอมพิวเตอร์ไปแล้ว ยิ่งปัญหายาก ไม่ว่าจะกู้ข้อมูลหรืออะไรก็ตาม ก็ยิ่งใช้เวลามาก แต่ยิ่งใช้เวลานาน คนก็ยิ่งไม่ทึ่ง
      ถ้ากู้กลับมาได้แบบปาฏิหาริย์ พวกเขากลับเล่าเรื่องว่า “หลานชายแก้ปัญหาเล็ก ๆ ได้ทันที” เหมือนจะย้ำว่าผมทำแบบนั้นไม่ได้
    • ไม่นานมานี้ใน HN มีเธรดเกี่ยวกับบทความของ Claude Shannon ที่เต็มไปด้วยคำอธิบายชัดเจน มีคนเล่าว่า บางคนสามารถอธิบายวิธีแก้ปัญหาอันงดงามให้สั้นและสวยจนเด็กมัธยมยังเข้าใจได้ หรือจะอธิบายแบบยืดยาวและซับซ้อนก็ได้
      หัวหน้ากลับแนะนำให้ใช้วิธีที่ซับซ้อน เพราะแบบนั้นถึงจะได้ตีพิมพ์ ไม่ใช่เพราะมันฉลาดกว่า แต่เพราะวิธีแก้ต้องฟังดูซับซ้อนถึงจะได้รับการยอมรับ
      มันตรงกับความจริงที่ว่าคนมักชื่นชมกระบวนการที่ซับซ้อนมากกว่าวิธีแก้อันงดงาม และระบบราชการก็คงเกิดขึ้นมาในลักษณะนี้เหมือนกัน
    • ผู้จัดการรับรู้ความซับซ้อนจากระดับความสับสนของตัวเอง พอมาอยู่ช่วงปลายอาชีพ ผมกลับคิดว่าเวลามหาศาลที่ใช้ไปกับการทำโค้ดให้สะอาด เป็นมิตรกับผู้ใช้ และดูแลรักษาได้ง่ายนั้นสูญเปล่า
      โค้ดนั้นถูกลืมหลังปล่อยจริงไป 15 นาที ไม่มีใครกลับมาอ่านอีก แต่ถูกใช้งานต่ออีกหลายปี เพราะอย่างนั้นผมจึงคิดว่า AI อาจแย่งงานได้เร็วมากกว่าที่หลายคนคิด
      สิ่งที่เราใช้เวลามากที่สุดอย่างโค้ดสะอาด การแยก concerns และความสามารถในการบำรุงรักษา จริง ๆ แล้วไม่ค่อยถูกให้คุณค่า แค่ “ดีพอใช้” ผู้จัดการก็พอใจแล้ว และถ้ามีปัญหา AI ก็แพตช์แบบสปาเกตตีก็ได้

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

    • มันคล้ายกับว่าถ้า Radar O’Reilly ถูกย้ายออกไป 4077th MASH จะกลายเป็นแบบไหน

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

    • ถ้าคุณจ้างคนในครอบครัวหรือเพื่อน อย่างน้อยก็ควรจ่าย เท่าที่เขาปกติได้รับ ถ้าเป็นเพื่อนกันจริง คุณก็ควรอยากให้เขาไปได้ดี ซึ่งปกติก็แปลว่าต้องจ่ายตามเรตของเขา ไม่งั้นก็อย่าไปรบกวนเขาเลย ไปหาคนอื่นดีกว่า
    • ก่อนเข้ามาในสายนี้เมื่อราว 5 ปีก่อน ผมเคยมองว่าการเขียนโปรแกรมและเทคโนโลยีเป็นโลกมหัศจรรย์และเคารพนักพัฒนามาก พอเข้ามาจริง ๆ เวทมนตร์นั้นหายไปหมด และผมก็เจอคนที่ทนคุยด้วยในชีวิตจริงแทบไม่ไหวอยู่เยอะมาก
      สิ่งที่คนยอมรับกลับเป็นเรื่องง่าย ๆ อย่างซ่อมเครื่องพิมพ์ แก้ปัญหาคอมพิวเตอร์ A/B/C หรือ Android Sudoku ไม่มีโฆษณาที่ทำให้เพื่อน ๆ
      แต่งานหลักที่ทำเป็นอาชีพกลับไม่ค่อยได้รับการยอมรับ ดูเหมือนว่าในหลายอุตสาหกรรม พอมีเรื่องเงินเข้ามา การทำหน้าที่ตามสัญญาก็กลายเป็นเรื่องที่ถูกมองว่าควรทำอยู่แล้ว เลยมีคำขอบคุณน้อยลง
      คนที่ไม่รู้เรื่องเทคโนโลยีมักคิดว่านักพัฒนาทำงานจากบ้านและทำงานวันละแค่ 30 นาที และ AI ก็ยิ่งทำให้ภาพลักษณ์นั้นแย่ลง

  • Ian Rush พูดไว้ดีว่า “กองหน้าดีที่สุด พลาดไปห้าครั้งแต่ยิงประตูชัยได้ก็เป็นฮีโร่ ผู้รักษาประตูเซฟสวยแค่ไหน พอพลาดเสียไปลูกเดียวก็กลายเป็นผู้ร้าย”
    ทุกที่ที่ผมเคยทำงานมาจะให้รางวัลกับ นักผจญเพลิง มากกว่าคนที่ทำให้ไฟไม่ลุกตั้งแต่แรก ที่แย่กว่านั้นคือทุกคนรู้ดีอย่างชัดเจนว่าระบบคิดแบบนี้ ยกเว้นคนที่เป็นคนตั้งอินเซนทีฟ

    • ถ้าอย่างนั้นจะออกแบบอินเซนทีฟยังไง? มันแทบเป็นนิยามอยู่แล้วว่าการให้รางวัลกับงานที่มองไม่เห็นนั้นยาก
      อีกด้านหนึ่งก็มีเหมือนกัน คือมีคนที่ใช้เวลาทั้งหมดไปกับการกังวลเรื่องที่ไม่มีวันเกิดขึ้น ดังนั้นมันไม่ใช่เรื่องที่จะแก้ได้ด้วยการให้รางวัลกับท่าทีตั้งรับอย่างเดียว

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

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

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

    • สำนวนที่ได้ยินกันตลอดคือ “ล้อที่ส่งเสียงเอี๊ยดอ๊าดจะได้จาระบี”

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

  • พอรู้จัก กับดักความสามารถ แล้วจะเริ่มเห็นมันทุกที่
    หลังบทความนี้ Sterman, Repenning และผู้ร่วมงานคนอื่น ๆ ก็เขียนงานตามมาอีกหลายชิ้น ทุกชิ้นน่าสนใจ แต่เกือบทั้งหมดชวนหดหู่
    ยิ่งไปกว่านั้น MIT Sloan ซึ่งเป็นที่ที่ system dynamics ตั้งหลักเป็นศาสตร์ขึ้นมาครั้งแรก อยู่ใกล้กับ Harvard Business School มาก ซึ่งก็เป็นที่ที่ system dynamics ถูกเมินเป็นแห่งแรกด้วย

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