如何成為更有影響力的工程師?

前陣子收到讀者詢問，假如平常做的都是一些小事，難有影響力，該怎麼辦? 例如前端工程師會焦慮自己總是在切版，切了半年一年感覺都沒有在進步；或者後端工程師會焦慮，自己總是在開發只做 CRUD 的 API，開發了半年一年仍在原地踏步。

沒有進步感可能會讓人擔心，不知道該如何升上資深，又或者未來想換工作時，會沒有太多內容可以寫在履歷上面。因此在這篇文章中，我們會來聊聊如何從小事開始，往成為更有影響力的工程師邁進。

推薦大家可以把這篇文章提到的點，當成檢視清單，並以此來自我檢核。如果有目前還沒有做到的，可以進一步設定目標來改善。

追求影響力前先追求可靠

如同先前在 追求高效前，先追求做好 一文談到的，追求高效之前先把事做好，類似的道理也適用在追求影響力，在追求影響力之前，推薦先追求成為一名可靠的工程師。因為只有當成為可靠，才會讓人建立對你的信任，進而願意交託影響力更大的事情給你。

如何判斷自己是否做到可靠?

你可能會問，什麼樣的工程師是可靠的工程師?

推薦可以用以下幾個指標來自我衡量

交付品質高不高：寫的程式碼是否高品質? 在提交給 QA 測試時，是否能確保不會漏洞百出、充滿 bug?
沒有踩不該踩的底線：在軟體工程的領域有很多底線是不該踩的，舉例來說，在 如何把關好上線流程? 一文談到的上線時該遵守的規範，如果你一時偷懶、求快，而沒有遵守該走的流程，這時若出意外了，然後發現是因為你沒有照該走的流程，這對於信任的傷害會非常大。
給的承諾是否兌現：如果在估時的階段答應能交付，在實際時限到了後，是否如期交付? 答應做的事是否都有做到? 承諾必達是建立信任的根基，假如今天答應要做的事情都沒有做到，一次兩次後，會逐漸讓別人失去對你的信任。
該告知的都有告知：在團隊合作時，如果有任何改動，是否確保所有合作對象都有收到通知? 是只有告知，還是確保對方有接收到?
是否有先預判未來狀況：當做一件事情時，是否有多想未來可能會有的不同狀況? 還是每次都是東補一個漏洞、西補一個漏洞?

很多人會覺得自己在工作上，都做類似的事情，卻沒有去仔細檢視自己是否把事情做到可靠。當你能做到足夠可靠，讓人相信你、對你放心，會更容易去爭取進階的事情來做。

不要成為 0.1x 工程師

上面談到這些檢核自己是否可靠的指標，其實也是在衡量自己是否是 0.1x 工程師。多數人可能很常聽到業界有所謂的 10x 工程師，那些人比起其他人有 10 倍的產出，所以被稱為 10x。

但事實上，在光譜的另一個端點，有所謂的 0.1x 工程師，這類工程師不僅沒有做到自己該有的產出，還反倒讓團隊整體產出往下掉，導致團隊有了這類工程師後，不僅沒有加乘，反而產出變 0.1 倍。

之所以會這樣，是因為當今天某個工程師出的包，影響往往不會只是自己，而會是整個團隊。以上面提到的「交付品質不高」，如果因為這點導致出錯，導致線上已經部署的東西要回滾，這後續將導致要發一個新的 PR，所以團隊其他人要抽出時間幫忙審查，進而導致他們能做別的事情的時間減少，這就會讓團隊的整體產出下降。

因此，除了檢視自己是否可靠，反面的角度來看，請盡可能避免成為 0.1x 工程師。

同一個問題，有不同影響力的解法

前一段落談到，要爭取更進階的事情來做，需要先在當前的負責項目中，做到可靠讓人信任。然而，事實上很多時候，同樣一個問題，不同的解決方法，可能帶來不同的影響力。換句話說，你可能不需去爭取新的事情，而是可以從已經在做的事情開始，然後切入不同的角度，藉此來提高自己的影響力。

舉例來說，假如今天收到某個監控警報，得知某個新功能上線後，效能沒有達到團隊在效能面設定的標準。這時可能有以下幾個不同的反應：

第一層次：看到相關警報後，像是當沒看到一樣略過，心裡想不要被其他人注意到就好
第二層次：看到警報後，花了一點時間找原因，然後順手解決掉問題
第三層次：第一時間跟團隊告知，然後解決問題，解決完後再次跟團隊同步
第四層次：第一時間跟團隊同步、解決問題，然後寫下文件與團隊分享
第五層次：除了第四種做到的事外，還進一步思考目前系統中，有沒有可能有其他類似的潛在問題，並全盤檢查是否有造成系統性問題的根因
第六層次：除了第五種做到的事外，還進一步思考為何最初會有這問題、可以如何根治，並帶團隊一同優化流程或寫程式的實作方式，確保未來不會出現類似問題

可以看到，同樣一個問題，可以有多種不同層次的行為，這些行為能夠帶來的影響力也不同。當你開始覺得自己平常做的事情，都已經是自己熟悉的，覺得缺乏挑戰與成長，不妨可以試著往下一個層次的行為挑戰。以下我們逐一來解說如何做到不同層次。

第二層次：自我要求

從第一層次要進到第二層次，需要有自我要求，對於看到的問題，不會輕易放過。這種自我要求應該要貫徹在工作中的各個面向。舉例來說，在為什麼要 Code Review? 如何做 Code Review? 一文中，有談到如果完成程式碼，要在 PR 的訊息中，寫出改動的內容，如果你沒有這種自我要求，且團隊中沒有其他人要求你這樣做，很可能導致你一直用不完整的方式做事，久而久之成為習慣，這將難以持續成長。

第三層次：團隊視角

從第二層次要進到第三層次，需要進一步有團隊視角，需要看到自己以外的其他人。在現代軟體開發工作中，多數都是以團隊出發，因為單靠一個人，很難在短時間內完成一個複雜系統。因此，在做任何事情時「腦中有想到團隊其他成員」會是很重要的。當發生問題時，解決後有同步到團隊，就是多了團隊視角的行為。

以上面談到的程式碼審查 (code review) 為例，如果多思考團隊這個角度，不自我要求可能會有更大的負面影響。例如你是初階工程師，資深的人看到你的 PR 可能會覺得你做事不詳盡；如果你是資深工程師，團隊的初階工程師看到，可能會覺得「團隊中的資深開發者都這樣做，那我這樣做也沒關係」，這會讓團隊的整體做事品質都下降，是需要避免的。

閱讀更多

在看完前三個層次的分析後，如果你對後面三個層次的分析感興趣，我們在E+ 成長計畫的主題文中，都有完整解說。感興趣的讀者，歡迎加入後閱讀。

對更深入了解這個主題，以及其他前後端開發、軟體工程、AI 工程主題感興趣的讀者，歡迎加入 E+ 成長計畫一起成長 (連結)。