由七十四日到物理極限：Jensen Huang嘅「光速」思維會點樣改變工程
引言：點解未理解時間表，就先要改善佢？
一個團隊話流程要七十四日，提出縮短到七十二日。聽落似進步。但如果換一種安排，實際工作六日就做得完呢？
呢啲數字係用嚟說明方法，唔係對個別項目嘅承諾。Jensen Huang用「光速」思維形容一種做法：接受現有流程作起點之前，先搵出根本極限。
重要問題唔係點樣要求同一班人更努力，而係點樣分清必要工作同沿襲落嚟嘅延誤。
1. 現有流程係證據，唔係自然法則
既定時間表可能包含好多唔同內容：實際工作、等候、審批、交接、批次處理，同埋因為今日已經唔適用嘅理由而作出嘅妥協。
漸進改善 [Continuous Improvement] 由現有安排出發，問點樣令流程好少少。
第一性原理推理 [First-principles Reasoning] 問更前一步：究竟乜嘢必須發生？乜嘢阻住佢用另一種方式發生？
呢點唔代表經驗冇價值。有經驗嘅人往往清楚知道困難步驟點解存在。重點係搵返嗰啲理由，而唔係將時間表本身當成解釋。
2. 為每個重要維度搵出極限
「光速」係相關限制之下，可能性極限嘅簡稱。唔係話每項商業活動都真係受光傳播速度限制。
喺計算領域，維度可以包括記憶體資料移動、能源、回應時間 [Latency]、處理速率 [Throughput]、成本同製造時間。設計可能喺一個維度接近極限，但另一個仍然有好大空間。
將呢啲維度分開好有用。快速交一個答案嘅系統，同設計嚟有效處理大量請求嘅系統可以唔同。優化一個，唔會自動優化另一個。
將一切合成最終設計之前，團隊應該理解每個目標要求乜。
3. 建立理想基線，再解釋差距
六日嘅例子，只有檢視埋其餘六十八日先有價值。
部分差距可能合理。慢啲嘅流程可以較平、更公平使用稀缺設備，或者提供必要檢查。其他延誤可能來自重複決策，或者近期冇人質疑過嘅順序。
呢個練習令選擇變得睇得見。團隊唔使只爭論可唔可以慳兩日，而可以討論點解接受同根本基線之間咁大嘅差距。
所以物理最低值係判斷嘅參照點，唔會自動變成正確嘅商業期限。
4. 簡單即係去除唔必要嘅複雜性
精密嘅計算系統可以有好多互相作用嘅部分，同時仍有簡單目的。複雜性存在但唔服務呢個目的時，先成為問題。
Huang嘅方法係問部件、步驟或者依賴係咪必要。必要就理解佢；唔必要就問點解仲留低。
呢點唔同將系統削到做唔到本身工作。供電、冷卻、測試同可靠性，唔會因為令圖表複雜就變成可有可無。
有用目標係設計有足夠複雜性去符合要求，但冇只係維持習慣嘅額外複雜性。
5. 領導需要理解行動發生嘅現場
項目報告可以描述延誤，但隱藏原因。喺工作現場，解釋可能清楚得多。
一條電纜點樣裝？部件點解要等？邊項決定阻住下一項工作？呢啲問題將大系統同產生佢嘅細小行動連起嚟。
急切感移除真實障礙時先有用。唔理解工作，只係反覆提出更進取嘅期限，唔會帶來工程進步。
領導應該幫手揭示限制、集合適當專業知識，同決定邊啲取捨 [Trade-offs] 可以接受。
結語：慶祝改善之前，先質疑基線
「光速」思維嘅力量，係追問點解嘅紀律。點解用呢個順序？點解等咁耐？點解係呢個設計？邊啲極限來自物理，邊啲來自選擇？
答案清楚之後，漸進改善有更好基礎。團隊可以改善自己理解嘅流程，而唔只係打磨承接落嚟嘅流程。
方法唔承諾每個七十四日項目都變六日，而係要求團隊知道點解做唔到。呢種知識會改變之後每個決策嘅質素。
Powered By K7