在流程不明確的狀態下，團隊成員只能憑藉自己的直覺做事；如果彼此對一件事的認知不同就容易造成誤會，甚至爆發不必要的衝突。

在流程不明確的狀態下，團隊成員只能憑藉自己的直覺做事；如果彼此對一件事的認知不同就容易造成誤會，甚至爆發不必要的衝突。

以筆者過去的工作經驗來說，如果工作流程只靠口頭制定、團隊默契，在沒有明確的文字規範下，大家真的無所適從，當新人加入時還需要更長的磨合期。

而制定團隊的工作流程，能夠讓成員了解自己在各階段要負責的任務；儘管一開始的工作流程可能很粗糙，但只要有了第一版，流程就能在日後的實踐中不斷優化與完善。

由於「為什麼軟體團隊需要制定工作流程」這個議題的涵蓋範圍較廣，所以筆者會拆分成「專案啟動、初始任務、專案執行」等幾個主題進行分享，今天這篇文章先介紹「專案啟動」時要做的事。

內文以「Web 開發」為範例，不同行業請酌情參考。

▋STEP 1：需求訪談＆初步規劃

這個階段的目標是「初步確認需求、討論需求可行性、讓客戶認可 Wireframe 流程」。

1. 由「PM」與客戶討論需求，在收集完需求後，將其以心智圖（Mind Map）的方式呈現。
2. 接著請「UI/UX」依造需求設計 Wireframe。
3. 待 Wireframe 完成後，「Tech Lead、PM、UI/UX」一起開個會，初步確認流程以及功能的可行性，並討論是否有需要調整的部分。

有些客戶會提出一些會異想天開 or 奇怪的需求，如果在初步規劃就發現這些問題，在反駁的同時請給予對應的建議，比如：

• 我想要一頁顯示 1000 筆資料方便搜尋：有些人還是習慣用「眼睛」來搜尋，但這樣的效率極差，當資料量大的時候還要翻頁；筆者建議與客戶進一步討論他實務上會搜尋的「欄位」有哪些，也許「篩選」功能更符合期待。
• 我想要把過去一年的出貨訂單匯出至 Excel 來統計數據：客戶過去可能習慣用 Excel 函數來分析數據，但這個功能實際上可以做成系統的「儀表板」。

▋STEP 2：確認具體需求＆完善規劃

這個階段要將「原本模糊的規格具體化、完成 Prototype 設計」。

1. 在客戶確認完需求及Wireframe 的內容都沒問題後，請「UI/UX」開始設計 Mockup。
2. 由「Tech Lead」確認 Mockup 上的細節是否都有考慮到（ex：哪些欄位適合拿來搜尋、不同權限看到的畫面、有哪些元件可以設計為共用模組）。
3. 待 Mockup 上的功能＆流程都確認沒問題後，請「UI/UX」開始設計 Prototype。

血淚史提醒：
專案初始的設計盡量從 Wireframe 開始，就算專案規模較小也不要直接畫 Mockup；因為在前期客戶的需求會時常變動，就算突然加大投資，小專案變成大專案也是很常見的，若使用 Mockup 會需要花更多的時間在調整上面。

▋STEP 3：向團隊成員說明

在需求與流程相對穩定後，接下來就要與「團隊成員同步資訊」。

1. 由「PM」向團隊成員說明系統的功能與流程，確保大家理解這個專案要完成的目標（這邊建議先用心智圖說明架構，再用 Prototype 模擬實際流程）。
2. 由「Tech Lead」向工程師團隊提醒各功能在設計上要注意的細節（ex：哪些欄位要設計 Auto-Complete、是否有特別的 Validation Rules、某些功能需要提前 Survey 避免卡關）。

這個階段主要是讓團隊成員對每個 Feature 都有具體認知，然後評估自己感興趣 or 擅長的 Feaure，若發現有沒碰過的技術也能提前研究。

▋小結

專案啟動時，「Tech Lead、PM、UI/UX」在各階段都要做好把關。

相信有實務經驗的讀者，都很清楚「明確的需求、具體的流程」對工程師來說有多麼重要；如果一切都非常模糊，那後續開發一定會遇到各式各樣的問題。

在團隊成員都了解專案的目標後，為了保證後續開發順利，我們還有一些「初始任務」要做，這部分筆者會在下一篇文章與大家分享。

☛ 如果想更深入認識我，可以 Follow 筆者的技術部落格 。
☛ 如果對工程師的職涯感到迷茫，筆者最近出版的新書 也許能給你帶來不同的觀點。

這篇文章 為什麼軟體團隊需要制定工作流程？「專案啟動」時可以做這3步驟！ ｜專家論點【林鼎淵】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。