先別急著對需求回應

最近輔導一些工程師朋友，發現了一些人在工作上的抱怨是個死迴圈，經常會把問題丟回去給其他人，不認為是自己的問題。

如果產品開發合作的 PM 沒有參與過類似解決方案的當前開發的產品，經常會搞不清楚一些程式邏輯性和操作邏輯性，也會無法掌握技術成本。這時就很需要工程師去提出「解決方案」，而不能像螺絲釘一樣想著會有人幫你想做法。

收到需求的第一反應，不該是「這個很難做」

我看見不少工程師在收到需求的當下第一個反應是「這個很不好做啦！」、「這會做很久喔～我要時間！」、「這個會有問題，不可行！」，但為什麼不是由你想出一個技術解決方案提供呢？兼具「開發效率」和「優良互動體驗」的解決方案只要開發的人才知道，特別是在公司規模不大的情況更是如此。一個成熟的工程師應該是能夠替公司解決問題的，而不是一昧提出異議，而無法給予建議。

但也不是所有人都該被這樣要求

當然我也知道有許多比較任性的公司，總是想要請比較 junior 的工程師去達成「又快」、「又好」這兩個要求。但事實上這些需求理解和溝通是需要經驗值的累積與培養，剛踏入這個領域的新鮮人光應付工作需求就很吃力了，更別說談解決方案和處理複雜的問題。

做一陣子之後，要能看到需求背後的問題

倘若你已經是工作一陣子的技術者，那你應該嘗試去思考需求背後究竟想要解決什麼使用者議題，配合並且提出解決方案。也要知道成本控管，評估工作背後要花費的時間。而不是「可能要很久」這種模稜兩可的答覆，這對於專案管理人員可以說超級困擾的。

估時程是要刻意練習的

但是估時程是一個需要刻意練習的，剛開始會覺得「根本估不準」，但即使如此還是得練習估。再一次又一次的練習中修正與調整，慢慢可以抓到自己的工作節奏和速度，自然就可以更精準的評估時程。到現在只要是我熟悉的工作幾乎可以誤差控制在提早20%內，這也是長年練習的成果。萬一遇到不熟悉的技術和工作內容就需要「前置評估」，先評估方案的難度與複雜度。更甚至花1～2天寫 POC 確認方案可行性，後面不但能避免投入過多的資源在不可行的方案上，也能提高時程估算的精準程度。

工作哲學一時半刻講不完，有機會再從別的議題講起吧～