在最近的案子裡交期第一次DELAY了。
這是一次CO WORK。
我跟年輕工程師一起寫軟韌體產品規劃，上傳雲端的一個程序。
我的工作是身兼PM，先把目前的工作項目抓出，然後訂上交期與查核里程碑。
而昨天是有關韌體的一個FORMAT格式完成的里程碑，由於之前開發順利，所以我前七天確認過他可以正常上傳和下載顯示之後就沒有去關心了，認為應該查核點的時間到了他就能把上傳功能完成。
但經過了七天，我昨天去做功能查核的時候，一開始他說之前就試過了沒問題，於是我開始每項參數做查核。
沒想到不只是上傳有問題，光是下載參數的部分有些的參數就是假的，不會作動。
然後上傳的命令也是，由於軟體上需要交握，所以我請他在上傳命令後需要回一個處理狀態給我。
結果是有的時候這個命令會卡住，有的時候這個命令不會作動，測試時他一次不成功還按了兩三次。
這讓我有點生氣，因為每天晨會幾乎都是回報說目前狀況正在修改中，然後就沒有然後了。
也就是七個工作天內還沒做出來還沒有求救，交期DELAY也不痛不癢。
我們好好的談了談，他雖然有測試，但沒有像我一樣針對這65個下載參數一一去驗證到底數值正確性是否正常。然後就對上傳功能的部分一直試錯。
由於一直有問題他也抓不出來，就想要一直自己搞，結果搞了7天。
我的看法是這樣只是給自己找藉口，也許自己有些地方的確不夠熟，但應該不能當作是得過且過的方式等人家來抓你毛病再托出。
剛好韌體大前輩下班前過來關心，我就順勢把他抓過來指導抓問題，結果一眼就先點出關鍵，針對MCU的處理上給了一些時序控制的基礎建議，而且驗證方面還需要鉤示波器看波型驗證自己想法是否正確。
這些一聽都是韌體開發經驗上的累積才會有的，年輕工程師可能有時求快求好，前人延續的CODE就直接沿用不求理論運行，但遇到問題時不知怎麼解決也不敢問，怕自己被人看沒有不會維護。
總之，正視問題才能解決問題，本周的週會我想要先講述這個概念。
(話說大學長果然是刀子嘴豆腐心，幫完我這邊還去看另外兩個小朋友工作進度，嘴裡說你沒說我就當你會了，實際上也是很關心...真好)
