จากเจ็ดสิบสี่วันถึงขีดจำกัดทางกายภาพ: แนวคิด "ความเร็วแสง" ของ Jensen Huang เปลี่ยนอะไรในงานวิศวกรรม

บทนำ: ทำไมต้องปรับปรุงกำหนดเวลาก่อนเข้าใจมัน?

ทีมหนึ่งบอกว่ากระบวนการใช้เวลาเจ็ดสิบสี่วัน และเสนอให้ลดเหลือเจ็ดสิบสองวัน ข้อเสนอดูเหมือนความก้าวหน้า แต่ถ้าการจัดการอีกแบบหนึ่งทำให้งานพื้นฐานเสร็จในหกวันได้ล่ะ?

ตัวเลขเหล่านี้เป็นตัวอย่างอธิบายวิธีคิด ไม่ใช่คำมั่นเกี่ยวกับโครงการใดโครงการหนึ่ง Jensen Huang ใช้แนวคิด "ความเร็วแสง" อธิบายการค้นหาขีดจำกัดพื้นฐานก่อนยอมรับกระบวนการเดิมเป็นจุดเริ่มต้น

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

1. กระบวนการที่มีอยู่เป็นหลักฐาน ไม่ใช่กฎธรรมชาติ

กำหนดเวลาที่ใช้กันมาอาจประกอบด้วยหลายสิ่งที่ต่างกัน ทั้งงานจริง การรอ การอนุมัติ การส่งต่องาน การทำงานเป็นชุด [Batching] และการประนีประนอมที่เกิดจากเหตุผลซึ่งใช้ไม่ได้แล้ว

การปรับปรุงอย่างต่อเนื่อง [Continuous Improvement] เริ่มจากการจัดการที่มีอยู่นั้น โดยถามว่าจะทำให้กระบวนการดีขึ้นอีกเล็กน้อยได้อย่างไร

การใช้เหตุผลจากหลักการแรก [First-principles Reasoning] ถามคำถามก่อนหน้านั้นว่า จริง ๆ แล้วอะไรจำเป็นต้องเกิดขึ้น และอะไรขัดขวางไม่ให้เกิดขึ้นในวิธีอื่น?

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

2. ค้นหาขีดจำกัดของแต่ละมิติที่สำคัญ

"ความเร็วแสง" เป็นคำย่อแทนขีดจำกัดของสิ่งที่เป็นไปได้ภายใต้ข้อจำกัดที่เกี่ยวข้อง ไม่ได้หมายความว่ากิจกรรมธุรกิจทุกอย่างถูกจำกัดโดยความเร็วที่แสงเดินทางตามตัวอักษร

ในการประมวลผล มิติต่าง ๆ อาจรวมถึงการเคลื่อนย้ายข้อมูลในหน่วยความจำ [Memory Movement] พลังงาน ความหน่วง [Latency] อัตราปริมาณงาน [Throughput] ต้นทุน และเวลาผลิต การออกแบบอาจใกล้ขีดจำกัดในมิติหนึ่ง แต่ยังเหลือช่องว่างมากในอีกมิติ

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

ก่อนรวมทุกอย่างเป็นแบบสุดท้าย ทีมควรเข้าใจว่าแต่ละเป้าหมายต้องการอะไร

3. กำหนดฐานอุดมคติ แล้วอธิบายช่องว่าง

ตัวอย่างหกวันจะมีคุณค่าก็ต่อเมื่อมีการตรวจสอบอีกหกสิบแปดวันที่เหลือ

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

แบบฝึกนี้ทำให้ทางเลือกเหล่านั้นปรากฏชัด แทนที่จะเถียงว่าลดได้สองวันหรือไม่ ทีมสามารถคุยกันว่าทำไมจึงยอมรับช่องว่างที่ใหญ่กว่ามากจากฐานพื้นฐาน

ดังนั้น ค่าต่ำสุดทางกายภาพคือจุดอ้างอิงสำหรับใช้วิจารณญาณ ไม่ใช่เส้นตายเชิงพาณิชย์ที่เหมาะสมโดยอัตโนมัติ

4. ความเรียบง่ายคือการกำจัดความซับซ้อนที่ไม่จำเป็น

ระบบประมวลผลที่ก้าวหน้าอาจมีชิ้นส่วนปฏิสัมพันธ์มากมาย แต่ยังมีจุดประสงค์เรียบง่าย ความซับซ้อนกลายเป็นปัญหาเมื่อมีอยู่โดยไม่ตอบสนองจุดประสงค์นั้น

แนวทางของ Huang คือถามว่าองค์ประกอบ ขั้นตอน หรือการพึ่งพา [Dependency] จำเป็นหรือไม่ ถ้าจำเป็น ให้เข้าใจมัน ถ้าไม่จำเป็น ให้ถามว่าทำไมยังคงอยู่

นี่ต่างจากการตัดส่วนต่าง ๆ ออกจากระบบจนทำงานไม่ได้อีก การจ่ายไฟ การระบายความร้อน การทดสอบ และความเชื่อถือได้ ไม่ได้กลายเป็นตัวเลือกเพียงเพราะทำให้แผนภาพซับซ้อน

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

5. ผู้นำต้องเข้าใจจุดที่เกิดการลงมือทำ

รายงานโครงการอาจอธิบายความล่าช้าแต่ซ่อนสาเหตุ ในสถานที่ทำงานจริง คำอธิบายอาจชัดเจนกว่ามาก

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

ความเร่งด่วนมีประโยชน์เมื่อขจัดอุปสรรคจริง การย้ำเส้นตายที่เข้มงวดขึ้นโดยไม่เข้าใจงานไม่ได้สร้างความก้าวหน้าทางวิศวกรรม

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

บทสรุป: ตั้งคำถามกับฐานก่อนฉลองการปรับปรุง

จุดแข็งของแนวคิด "ความเร็วแสง" คือวินัยในการถามว่าทำไม ทำไมต้องลำดับนี้? ทำไมต้องรอนานเท่านี้? ทำไมต้องออกแบบอย่างนี้? ข้อจำกัดใดมาจากฟิสิกส์ และข้อใดมาจากทางเลือก?

เมื่อคำตอบชัดเจน การปรับปรุงอย่างต่อเนื่อง [Continuous Improvement] ก็มีฐานที่ดีขึ้น ทีมปรับปรุงกระบวนการที่เข้าใจได้ แทนที่จะขัดเงากระบวนการที่รับทอดมา

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

By Keshavan Thiagaraja

นักพัฒนาโมเดลปัญญาประดิษฐ์ส่วนตัว [Private AI Model Developer] และที่ปรึกษาด้านความปลอดภัยของปัญญาประดิษฐ์ [AI Security Consultant] ผู้ช่วยเหลือบริษัทขนาดเล็ก ขนาดกลาง และขนาดใหญ่ในการสร้างโซลูชันปัญญาประดิษฐ์ที่ปลอดภัย ซิดนีย์ ออสเตรเลีย

(B.Sc. Computer Science, Mathematics and Statistics)

(M.Sc. Information Technology)

(E-Commerce Professional)