從「寫功能」到「設計流程」

今天想來跟大家聊聊關於流程設計這件事。在這篇文章中，我也會根據自身的經驗，分享我從以下幾個面向，來看待及解決設計流程這件事：

• 為什麼我們會需要設計流程？
• 流程實際上設計的目的為和？
• 我個人在實務開發中，是如何思考流程、拆解問題，並將其轉化為程式結構的

接下來就讓我們依照順序介紹下去吧

為什麼我們會需要設計流程？

不論是個人 Side Project，還是工作上的產品開發，在開發專案時，通常都會圍繞著一個或多個「核心功能」展開。

這些功能，往往能代表這個專案的整體主軸及價值。然而，這些功能在大多時候都不太單純，通常由多個步驟組成，裡面可能包含條件判斷、狀態變化，甚至牽涉到像金流交易這類「不能出錯」的關鍵邏輯。

也正因為如此，核心功能在真正設計以及執行上沒這麼容易且直觀。在沒有清楚流程的情況下，我們很容易落入一種開發模式：

• 邊寫 Code 邊想下一步邏輯
• 邊測試新功能邊補足條件
• 用直覺去拼湊邏輯

短期內的大部分功能也許都可以順利完成，但隨著專案的需求逐漸增加，問題就會逐漸浮現：

• 需要條件判斷的地方越來越多
• 各個功能狀態之間開始互相衝突
• Bug 難以追蹤回溯與修復

最終，你會發現一件事，那就是你不是在維護功能，你只是單純在對抗流程失控。這時候，我們流程設計的目的與價值就會凸顯出來：

流程設計的目的，是在正式執行行動之前，先把複雜的邏輯「整理成可理解、可預測的結構」。

我們透過先理清整體功能流程，讓複雜的邏輯變得清晰，讓後續的實作變得可控。換句話說，流程設計並不是多做一步或是浪費時間，相反的他是必要的，是透過理清功能的整體流程，來清楚解正確地完成較複雜的邏輯。

流程實際上設計的目的為和？

在我們理解「為什麼我們需要流程」之後，下一個關鍵的問題是：

流程設計，實際上是為了達成什麼？

我們看完標題可能會直覺認為流程的目的就只是「把事情排好順序」。但在實務開發中，流程的價值遠不止於此。以下是幾種常見的流程設計的目的：

1. 讓複雜的邏輯變得更可控

當專案經過一段時間的更新後，整體邏輯會開始逐漸變得複雜。在這種情況下，很多需要新增的功能，出現的問題往往不是「做不到」，而是可能出現「不確定性」或是「失控」。

我們可以透過流程設計，把可能失控的行為收斂成一條可預測的路徑。

2. 明確定義「狀態」與「階段」

透過明確地定義流程中的「狀態」與「階段」，來讓整個流程有系統性。同時，也讓流程本身擁有一套可以被理解與溝通的「語言」。

這不只是單單分類而已，而是當流程可以被清楚拆分時，就可以更容易預想並理清，在各個狀態或階段中會發生的任何事。

可以說流程的目的之一，就是讓系統的每一刻都有明確身份。

3. 確保順序的正確性

在實際的執行流程中，其實我們也是透過參考需求的順序來執行的。因此我需要透過需求來規劃流程順序，並在完成規劃後在依照正確性、可行性來做調整。

如果流程的順序沒有被明確定義，很容易變成會造成順序混亂、跳過或重複執行、或是出現意想不到的結果。

流程順序的核心就是，確保每一件事情，都在正確的時間點發生。

4. 提升可維護性與擴展性

在缺乏流程設計的情況下，程式專案很容易逐漸演變成難以維護的狀態，可能容易有以下問題：

• 到處都是 if / else，邏輯難以追蹤
• 事件彼此高度耦合
• 修改一個地方，壞三個地方，或是根本不知道壞哪裡

但當流程被設計出來後，我們可以透過流程本身來進行判斷：

• 這個錯誤，可能出現在流程中的哪一段
• 新增部分功能時，不需要全部重新測試，只需要插入某個階段
• 重構時不容易破壞整體邏輯

5. 作為團隊之間的共同語言

在團隊開發的情境中，流程不只是工程上的設計工具，更是一種溝通的基礎，讓不同角色能用同一套結構理解系統。

透過明確的流程，使各部門或是不同角色之間，可以建立一套共通的理解方式，降低合作時的認知落差，降低溝通成本。

舉例來說，以一個電商網站為例，假設團隊提出一個新需求：

「我們應該在開始階段後跳出廣告」

乍看之下很簡單，但不同角色可能會有完全不同的理解：

• PM 認為：應該在使用者登入會員後顯示廣告
• 前端認為：應該在使用者一進入網站時就顯示廣告
• 後端認為：應該在使用者進站時就先準備好資料，隨時提供顯示

這顯示出同一功能但在不同角度得理解會不盡相同，甚至導致結果與預期不一致。

但當流程被清楚建立後，我們就可以用更具體的方式來做溝通，讓需求從可以被「模糊描述」轉變為精確的「可定位的需求」。

總結來說，流程設計的目的，是為了讓系統從「混亂的可能性」，變成「可預期的結果」。

我個人在實務開發中，是如何思考流程、拆解問題，並將其轉化為程式結構的

我自己在實際開發過程中，流程設計很少是單一個人的決策（除非是個人 Side Project），基本都是透過團隊共同討論，逐步建立出來的，但基本上葛個人開發流程也可以依照團隊開發去執行。

具體來說，在我的實務開發經驗中，通常會透過以下幾個步驟來拆解與設計流程：

1. 明確了解此次功能所需及目標

流程設計的第一步，來自於「理解需求」。

所以通常會由提出需求的人（例如 PM 或產品端）先說明這次要新增的功能與目標。透過這個流程，我們可以更直接了解需求。如果對於需求有相關疑問，也可以在當下釐清任何不明確的地方。

透過這一步，盡可能在一開始就把問題問清楚，降低後續反覆溝通的成本。

2.初步設立及規劃此次功能執行的階段

在了解需求後，接下來會與團隊一起討論：這個功能應該如何被拆分成不同階段來完成。這個過程通常需要花一些時間做規劃上的溝通，因為團隊需要先建立共識：

• 整個流程會經過哪些主要階段
• 每個階段的大致目標是什麼

3.釐清每個階段應該負責的行為

在階段劃分完成後，接下來會針對每個階段做更細部的討論。到這階段，我們就會有很明確定義：

• 每個階段需要完成的任務
• 負責的人員或角色
• 在什麼條件下，才能進入下一個階段

這一步已經是在確認每個階段狀態、人員責任、以及狀態之間的轉換規則。

4.提前發現或排除可能的例外與錯誤路徑

在實務中，大家都心知肚明一件事：計畫趕不上變化！

因此，在流程討論或實際執行過程中，只要出現原本未預期的情況（例如意外錯誤、與原先專案架構有衝突、需求邏輯變更或需求不明確），團隊通常會依照既有的溝通流程（SOP）進行討論。

必要時，甚至會重新回到步驟一重新開始討論。

透過以上的做法，讓流程不再只是模糊的想像，而是可以被清楚描述、討論，並最終落實為程式結構的一套設計方法。

總結

這次和大家分享了我在實務上，對於「流程設計」的一些經驗及做法。分享內容多半來自工作中的實際流程，以及我個人的學習歷程。

經過這些時間的學習及操作，我認為，建立一套屬於自己的開發思維，是每位工程師都非常重要的一件事。

其實在剛開始學習程式時，我是直覺流派的，心想不就是完成一些簡單功能。但在隨著功能變多時不斷碰壁，之後，才逐漸意識到比起「寫得出來」，更重要的是「寫得清楚」。

也正因為我踩過這些坑，提早認知錯誤並修正，讓我在後續的團隊合作以及正式工作中，能更有系統地拆解問題、設計流程，讓自己的整體開發過程變得更加順暢。

所以，如果你是剛開始接觸開發的新手，我真的真的建議：

在真正動手寫程式之前，先學會如何設計流程。

養成這個習慣，會對未來的你幫助甚多，能幫你省下非常多時間，也能讓你的程式更穩定、更容易維護。

最後，感謝你的閱讀🙏。如果這篇內容對你有幫助，也歡迎持續關注後續的分享。那我們就下篇文章見🙋‍♂️。