畫流程圖是我的第一堂程式課內容，大學教授講了很多話，我記得的寥寥無幾，其中一句話是：你畫的出來就寫得出來。一直到現在流程圖是仍我最常用的輔助思考工具，不管是需求流程、系統架構流程、專案開發流程、操作流程...等，畫好之後可以協助自己梳理邏輯，也可以用在開會時確認大家對於系統的認知是否有落差，最後是可以協助接手系統的人快速進入狀況。

畫流程圖的工具有很多，我自己還是習慣使用cacoo

初始流程圖

一般收到需求之後，第一步要先釐清需求的目的、預期效益，了解緣由並確認PM想達到的效果跟提出來的需求是有相符的，再來評估可行性。同時要評估未來需求擴張的可能性和預留需求擴張的彈性。
這次我模擬的需求是『要能統計工作點數且不能讓每個統計層的點數超收。』
單就這一句，可以先畫個很大方向的流程示意圖：

然後再慢慢發想每個步驟,
可以搭配一個查詢API, 就算之後API沒有外接, 也可以留作自己檢查系統時的接口

限額設定的資料源從哪裡來？此時我會調整改用虛線來表示跟資料源取得資料的動作, 才不會跟流程混在一起

雖然需求很簡單，可是隨之而來要考量的還有：統計項目全統計可能會有幾項？有大量快速讀寫的需求嗎？要使用什麼儲存工具？對儲存工具操作的頻率會有多高？需要事先對儲存工具壓力測試嗎？諸如此類等等的各式各樣的問題都是在接收需求後要去思考的，所以有時候初始流程圖跟最後完成的流程會相差甚遠，我會在每個異動階段再去調整流程圖，讓流程圖可以符合程式開發的狀況。

初始API列表

根據初步流程圖可以先開兩個API接口：

• 異動點數資訊 - 接收公司各廠區＆人員的當次統計點數, 再統計到統計池中
• 查詢點數資訊 - 查詢目前統計狀況

API要使用的input/output參數會搭配上下游的資訊做參考，以這個需求來說，input要能收到可以明確切割統計項的資訊，output 要根據client端需要拿來應用的資訊設計，所以在開立spec之後，我會分別跟上下游端口確認彼此需要的資訊是否都能滿足。

評估工作時程

在需求確認完成之後就要先評估這個專案會在我手上花費多少時間，開發時程是依照個人的進度評估，以這兩支API來說我大概會這樣估：
API接口上下游溝通確認2hr, 工具選用評估1hr, 程式開發4hr, API測試1hr, 緩衝2hr, 這個需求評估時程大約會是10hr, 同時要檢視手上進行中的專案工時還有多少，以及可能會插件的項目可能有哪些，確認好各個優先順序之後再一起回報上去，接下來就是準備開發的前置作業了。