PRUM股份有限公司的 masa。
今天要針對主要在開發任務前卡住手、感到不知所措的初學工程師，說明一種以「任務拆解」為核心的做法。
即使在充滿不確定性的開發現場，只要把任務拆小來思考，提早動手，即使只有 60 分也先產出，就能一邊控制不安，一邊穩健前進。
我相信，這對於覺得「任務被分配下來了，但不知道從哪裡開始……」的初學工程師，以及未來想成為工程師的人，都會有幫助。希望能多少提供一些靈感。
為什麼面對新任務時會卡住？
說到底，為什麼我們一面對新任務就會焦慮到當機呢？那是因為開發現場總是與 不確定性 形影不離。
系統開發總是伴隨著「不做看看就不知道」的不確定性。幾乎不會有完全相同的東西在完全相同的條件下被製作出來，因此過程中很容易發生預料之外的狀況。
再加上，既然是工作，就必須在有限的「預算」「人力」「時程」之內交出成果，這本身就是一種限制。
「如果趕不上交期怎麼辦」「如果因為我而延誤怎麼辦」的壓力，加上「不做看看就不知道」的不安，兩者合在一起，初學工程師的思緒就很容易在任務面前停住。
1. 拆解到能解決的大小
為了攻略這隻名為 不確定性 的怪物，現場的前輩們幾乎像呼吸一樣頻繁在做一件事，那就是 任務拆解。
現場常用技法：WBS（Work Breakdown Structure，工作分解結構圖）
這是把大型目標拆小，整理成自己能理解到「今天要做什麼」的程度的圖。它有助於明確化待辦事項，也能檢查工作是否有遺漏或重複。
例如，若只是把「做出商品搜尋 API」當成一大塊，根本不知道要做什麼。我一開始也卡在同樣的地方。
所以要把任務拆得更小，小到連國中生都能知道「今天該做什麼」的程度。
例如，可以這樣拆：
- 閱讀規格文件，列出搜尋所需的條件（關鍵字、價格區間等）
- 確認資料庫中商品資料存在哪些資料表
- 撰寫用來取得資料的 SQL，並在工具中試著執行
- 輸出到 log 並確認結果，進行驗證
怎麼樣？是不是比起「做出 API」來說，門檻低了很多？
透過拆解任務，會讓「該先從哪裡下手」變得清楚，便能不再猶豫，一步一步往前進。
即使這樣還是偏大的塊，最開始更重要的是再往下拆，直到能落到實際寫程式的層級。
2. 盡早動手
這時候不建議做的，就是一直只吸收基礎知識、卻不動手。這麼做會讓開發完全無法推進，最糟還可能導致延誤交期。當然，若基礎知識幾乎是零，要直接動手也確實不容易。
因此，先和自己約定以下兩件事：
- 把基礎知識等輸入學習控制在 2 小時以內
- 之後就專注於動手實作
這樣一來，就能做到「邊做邊想」。
不管你花 10 小時吸收多少基礎知識，在實際寫程式時，幾乎一定會遇到超出那 10 小時學到的問題。以經驗來說，這點絕對沒錯。
既然如此，還不如先用相對較短的時間把基本知識學起來，接著一邊動手一邊思考，這樣處理任務會更有效率，自己的成長速度也會更快。
3. 先拿 60 分就交一次
初學工程師很容易犯的錯，就是想著「等到完全做好再給前輩看」。
「因為程式碼還很亂」
「因為還有錯誤，等修好後再討論」
就這樣一個人悶著頭做，拖了一段時間後才報告：「其實進度沒有很多……」老實說，三年前的我也常常這樣。
在專案中，能力好的工程師會活用以下 4 種風險應對策略來降低風險。
4 種風險對應策略
- 迴避：乾脆不做可能出問題的事
（例：避開沒用過的困難函式庫，改用有實績的簡單方案；為了不麻煩別人，自己一個人把知識補到完美） - 降低：即使出問題，也讓影響變小
（例：撰寫測試程式碼，在正式發布前找出 bug；提早把問題整理出來） - 轉嫁：不自己全扛，交給其他人或服務
（例：不自己管理伺服器，改用 AWS 這類雲端服務；請前輩幫忙一部分） - 接受：以會出問題為前提，事先做好準備
（例：為了日後出現問題時能迅速還原，先做好備份）
完美主義的人常常想靠一個人用 100% 的 迴避 來處理風險，但這很危險。尤其初學工程師多半比較單純，因為想著「想幫上忙」「不想給忙碌的前輩添麻煩」，很容易變成這種 100%「迴避」型。
我認為初學工程師更應該意識到 降低 與 接受。
要先接受「自己一個人不可能什麼都懂」這件事（接受），並且為了把損害降到最低，盡早開始、提早找出 bug，或是找出自己無法單獨解決的地方（降低）。
也就是說，先拿 60 分就把成果交出去 這件事很重要。
「這部分我已經懂了，但這個錯誤的原因還無法完全縮小範圍，卡住了。」
我覺得在這種狀態下就可以送出 PR（Pull Request，程式碼審查請求）。不需要完美，先用 60 分交出去，得到前輩的建議後再修正，反而會快非常多。我認為這樣最終對自己和團隊都會更好。
最後
當你能把任務拆小，並且以 60 分的完成度提早回報、提早討論，這不只對教你的前輩來說是安心，對整個團隊來說也是最大的安全感來源。
先花 10 分鐘，試著把眼前的任務拆解，踏出一小步吧。只要不慌，按照自己的步調一個一個解決，就沒問題！
PRUM 95% 以上的工程師都是無經驗錄用。
如果有興趣，也歡迎來企業網站逛逛。
▶ 企業網站
我們也有營運整理對工程師有幫助文章的網站。如果有興趣，也歡迎看看。
▶ 對工程師有幫助的文章網站
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
