前情提要：
S & K 從笑CC公司那邊得知了，測試程式的最終目的是需要通過做100次的選項，頓時覺得不妙

抽絲剝繭

K身為菜鳥，立馬扛起了這個艱難的任務，馬上就說100次這個測試他可以處理。

S反而很冷靜的跟他說，你不要急，我們先從single的來試試，看一下錯誤訊息長怎樣。

結果按下紅色按鈕後，只見程式從ready -> 5% -> 15% -> 25% -> 35% -> 36% -> 37%就停住了。

大家還是看的一頭霧水，畢竟這些測試的過程跟客人一開始反應的效能問題完全無法聯想起來。

只好再向W請教，想不到W支支吾吾的東扯西扯，完全沒有給出正面的回應，便說著晚點確認清楚後再回信。

這下看來，笑CC公司那邊應該一開始就打著把複製問題的工作交給穩當當公司，W那邊可能實際上連跑測試程式的經驗都沒有。

不過東西都已經到S & K這邊了，也只能透過W再去確認。

片刻之後，就收到了W的回信，信上表示這個現象就是GKJ公司客人那邊遇到的問題。

目前他們每一次執行都會無法執行到100%。

S & K首先找來了硬體工程師RD，對方表示就憑這個測試程式他完全不知道該怎麼辦才好。

最後只好動員負責這個產品的主要軟硬體工程師RD們一起開會，會議上大家七嘴八舌都在想辦法讓debug的主角不要變成自己。

眼看這個會議已經開了，兩三個小時，大家從七嘴八舌變成鴉雀無聲，FW工程師的主管後來跳出來說，客人一開始說的主機板FW升級與頻寬，我們這邊真的沒有頭緒。不如我們這邊試試提供一個debug版的FW，讓S & K更新之後再複製一次問題，也許能收集到什麼有用的資訊。

大家聽到不用自己動手，紛紛又開始替這個debug版的FW出起意見啦，一下子說要打開什麼選項，一下子說要加什麼判斷之類的。

到了隔天，很快的K將debug的FW更新到主機上，並迅速的再跑一次測試程式。

不愧是集合了眾人意見的debug FW，光是印出來的log檔就有快5MB。

大家拿到log檔後，立馬又到會議室集合一起討論。這時硬體工程師RD那邊表示，從log檔看來影像加速卡在開始執行測試程式前就有一些異常，導致測試程式開始執行一段時間之後，它與主機板的通訊便會中斷，需要重新建立。

因此立馬與FW工程師討論關於通訊介面的速度與緩衝區大小目前的預設值，並提出新的建議設定，然後基於這些變更再提供一版新的debug FW。

技術問題解決了，但是人的問題就...

之後S & K拿著套用新設定的debug FW，很順利的將測試程式一次跑到100%。

立馬很開心的通知W這個好消息，並同時K也履行他的承諾，在苦命的跑著他的100次測試。

「33, 34, 35, 36...天啊，雖然一切順利，但是有夠無聊，希望中途不要斷掉就好....學姐，經過的時候小心不要跘倒呀！」

正當K跑到第90次的時候，W發信來了，信上表示GKJ公司想知道100次測試的結果，以及是否能夠提供debug FW給他們同步測試。

在業務與RD都同意的情況下，大家也覺得讓GKJ公司一起測試是比較保險的做法，便將debug FW給了出去，連帶著100次都完美跑完的這個結果一起。

這次輪到笑CC公司的小美發信過來問候了，信上說著GKJ公司那邊對於這個結果很滿意，感謝穩當當公司同仁們的大力支持，並且想了解這個debug FW與原來的FW之間有什麼設定上的差異導致這個問題被解決，作為以後他們周邊設備調整的參考。

大家這時候反而覺得奇怪了，一開始GKJ公司便說其他廠商建議修改影像加速卡的頻寬，請我們也協助修改同樣的設定，怎麼會在我們搞清楚要怎麼做之後，又來問我們實際上做了什麼？

因此，這時候大家決定回答的保守一點，除了一些回信的客套話以外，關於FW設定問題這邊的回覆，就順著客人一開始的話講，回答他我們也是修改影像加速卡的頻寬就好。

這個回覆送出去，過了大約一個星期的時間小美和W都沒有再多做回信，S & K倒是連忙把機台與影像加速卡相關的設備寄回給笑CC公司，深怕還有做不完的實驗。不過客人光是有debug FW就能滿足需求了嗎？真是滿頭問題！不過大家也覺得反正一開始這些東西就不是在我們產品的規劃之中，找到問題並解決掉後，就當作多個經驗吧。

沒想到，又過了一星期，小美突然發信來告訴大家，上次的debug FW雖然可以解決實驗室裡的問題，但是目前GKJ公司的產線還是無法正常的運作，似乎還有別的問題需要解決，並再次提到了GKJ公司那邊想進一步了解debug FW
設定的事。

事情發展到這個地步，大家已經開始有一點搞不清楚最終的訴求是什麼了。

好像產線的機台無法運作很重要，但是也沒有接到需要去現場協助debug或是再做troubleshooting的要求，反倒是一直來追問debug FW的設定是什麼。

對於一個無法解決他們產線問題的debug FW設定，了解這個設定有比解決新的產線問題重要嗎？

在這個業界打滾許多的硬體工程師RD說，以往我們也有遇過不少例子，客人打著反應POC問題的名義，實質上想從廠商那邊得到一些"經驗"，最後把這些經驗分享給他們心中已經內定的廠商的例子。

於是最後這個特別的案例便在眾人決議以業務面上能獲得最大利益的方式，由業務代表做後續的討論。

就暫時先不往技術面去做回覆了。

技術面的問題只要在問題能複製，有對應的錯誤訊息可以除錯的前提後，找到解決方式或是workaround都比較偏向時間或成本問題。

但是有許多以技術問題為包裝的其他目的，需要大家仔細推敲背後的目的與這些要求的合理性，並小心的劃分好處理的界線，才不會最終落得好心做壞事，影響自己也影響公司的利益。