比「有效率」還重要的最高指導原則
這陣子都在找一個會讓不定流程，不定時間，讓系統崩潰掉的問題，動用了許多人力和時間，到現在還沒找到root cause，實在是件令人很灰心的事。
讓系統癱瘓掉是非常不容易，也很難以理解的狀況，因此我們一開始就嘗試在系統的log中，嘗試找出任何可能的線索。但很不幸，這次的狀況也非常惡劣：從app到system都沒有任何log會顯示出來，就像時間突然靜止一樣，整個系統就這麼"被石化"了。當我們跟專案討論後，鎖定了幾個有可能能把系統癱瘓掉的變數後，就開始了最土砲的方法，也就是交叉測試，嘗試去找出root cause在什麼地方。
由於這樣的測試法就像大海撈針一樣，預期會耗掉大把的時間去調查，因此在測試的過程中，我就很貪心的想要在每次的測試中，儘量含入夠多的變數，希望cover到有可能有root cause的地方。為了"加速"這個過程，我竟然僅借了40片板子，就開始了各種不同pattern的交叉測試。
在幾次重現問題後，又發現問題似乎都可以在24小時內重現。隨著專案趕著出貨的壓力越來越大，被"關注"的次數和程度也越來越大，我就越想趕快定位出root cause可能所在的範圍。
結果，終於在今天出現了"死亡交叉"。
我們關注的變數出現了互相矛盾的測試結果：我們這一陣子的測試中，一定有「偽陰性(False Negative)」的結果，不是測試的板子數量不夠大，就是測試的時間不夠久，一定有什麼組合其實是有問題的，只是還來不及重現，就被我們判定是"沒問題"的。
今天和組員想到抓破頭，也無法再想出新的變數。最終，品檢組也加入了討論和調查，我們討論的第一個行動，就是不管原先測試的結果為何，再重挑一次測試的pattern，把測試的板子數量放大，測試的時間也加長，務必確保測試的深度足夠，才能把沒有嫌疑的變數被劃掉排除。這受到部長的責難，投入了一個月的時間，結果"一事無成"。要不是專案自己找到了能出貨的組合先出了，重要的先機就會被這樣的粗心大意給錯失了。
面對這樣子的結果，那心中的苦自然是不好受。面對技術上未知領域的問題，不穩定的重現條件及時間，極度惡劣的調查環境(基本上就是沒得調查)，都不是「我們盡力了」就可以被接受。問題還得繼續找，但現在該做的就是把一些反省記錄下來。
當我們是組織的領隊，站在最前線時，自然就是承受著最大的壓力。越是急迫的要求，越是未知的事物，我們真的越是要深得住氣，告訴自己一定要守得住最後的那道防火牆：「Effectiveness is more important than Efficiency」。
「有效」是在最高壓，最惡劣的環境下，比「有效率」還重要的最高指導原則。
這就是我這次最致命的錯誤。為了能儘快把root cause給定位出來，我不知不覺拉高了"有效率"的重要性，降低了"有效"的條件及門檻。這種錯誤最致命的地方莫過於，它很容易說服自己，也說服在場所有的人。在時間壓力下，有一個錯誤的答案，也好過沒有答案原地不動來得好。
我確定這是在某些商管書中看過的內容，而且它很有說服力。
也許我可能沒有資格，因為這次的事情就可以指控它的對錯。但我可以確定的是，這件事會讓我認真的思考這句話的"正確服用姿勢"。「行動」是很迷人，但行動就是成本，人事是成本，而時間更是有錢也買不到的成本。
當我們面臨遠超過我們所學的領域的問題，承受著我們難以負荷的壓力時，我們越是要有那個能力，去直視我們心中的恐懼：我現在確實沒有方向，給不出能解決的時程，找不到root cause在哪裡。最糟的狀況會是什麼？如果我的下一步就是最後一步，我能否四平八穩的端出我們找到的結果？為什麼別人可以相信我們，為什麼我可以說服的了我自己？
同樣的問題，如果沒有時程或出貨的壓力，"理智"情況下，你應該做什麼？應該保持什麼水準要求自己或組員，確保這一切是「有效」的，而不只是「有效率」。
我當然不知道，最終這個題目會導引我們去發掘什麼真相出來。但確定的是，至少我自己看清了自己有什麼弱點，犯了什麼錯，挖出了什麼真相，以及我自己要怎麼調適心情，繼續面對挑戰。