我們為什么選擇工作流。
一直感覺很難對那些從未接觸過工作流的同學們解釋清楚。
還記得有一個活動中，有人提問：“工作流到底是做什么的？”回答的同志希望根據具體的實例解釋一下，就反問他：“你們公司的報銷流程是怎么走的？”結果提問的同志直接說：“直接找財務啊。”引得下面一陣喧嘩：“不用領導簽字就可以隨便報銷啊。”
那個提供的同志心里一定感覺很無辜：“我也不知道公司的請假流程應該找誰啊，大家每次都直接給財務了。”其實對于小公司來說，里邊工作的人本來不多，可能都是報銷這種事情都是這樣兩步完成了，可實際上真實的流程應該是這樣：
大家對圖中的環節估計不會有什么異議，只是對于直接拿發票找財務報銷的人來說，中間的核實部分變成了完美的黑盒，他不了解，也沒有必要去了解報銷的整個過程，站在當事人的角度，他只要最后知道這次報銷能拿到多少錢就可以了。
對
于一個公司的內部事務來說，這樣就最好的，員工沒有必要去了解每個環節是如何進行的，但是在為這種公司進行軟件開發時無疑要面臨著掉進陷阱的危險。假設你
只對員工進行需求調研，他會只給你發票的單據，告訴你報銷流程就是找財務。如果再去找財務進行需求調研，他會告訴你只要看一下沒問題就可以報銷了，最有可
能略過，也可能是最關鍵的特別情況需要經過老板審核的步驟，這個步驟可能是5000元以上必須經老板過目，也可能是特殊事項需要老板簽字，但是因為公司日
常不會出現很多這種情況而被人們無意識的忽略掉，有可能到程序開發到中段時才突然想起來，然后就需要把流程重改。
說到這里，那么使用了工作流就可以避免出現這類需求變更問題嗎？
答
案是否定的，軟件開發時的需求變更常常是因為客戶對本身業務要求和業務流程的不熟悉所導致的，軟件開發的過程常常伴隨著流程的梳理和細化，這也是為什么很
多程序員都說：“這個項目做完了，我比他們公司里的人都懂業務了。”其實不是你比他們還懂業務，真正辦公的時候你還是會被各種情況沖的頭昏腦脹，但是因為
你在軟件開發的過程中對各個部門之間的依賴和關聯進行了完全的梳理，所以對各個部門之間的數據流和業務流了解的更為通透。
話
說回來，工作流雖然不能解決因為客戶對本身業務的深化而造成的需求變更問題，但是它確實可以把這個風險提前，我們知道，風險總是越早解決越有利，因為當我
們一張張單據化為流程圖時，客戶也能夠更好的參與到流程的解讀中來，通過流程圖可以加快業務的深化，提早暴露出之前沒有考慮到的問題，便于我們盡快的盡早
的解決。
那么我們直接用visio不就可以了？何必使用工作流呢？
答案是
visio也可以，只要可以限制圖形中的語義，不要讓客戶任意發揮，就完全可以實現工作流的效果。為什么要限制語義呢？因為只有流程圖可以直接映射為開發
完成的程序，對流程圖的細化才是真正有意義的，否則客戶畫了一張完全無法用程序實現的圖形，我們該怎么辦呢？工作流一般都提供了自己定義的一套語義，大多
都是以XML格式保存的，只要以此為基礎畫出的流程圖都是可以轉換為實際程序的，再加上與客戶的溝通，讓客戶和程序員對流程中每個環節的理解保持一致，就
可以盡量避免理解上的偏差，減少修改和返工現象。
但是工作流的學習曲線太高了，原本程序中我只需要設置幾個狀態位就可以解決問題，值得興師動眾的配上工作流嗎？
對
這個問題的回答還需要對實際情況進行分析，小型系統中，你只需要制作一個CMS，不同的管理員負責不同版塊內容的審批，這種邏輯簡單，流程固定的需求確實
沒有必要使用工作流，使用了工作流反而會加大開發和維護的復雜度，使用狀態位模擬FSM有限狀態機也完全可以實現。但是在復雜的業務情況中可能存在著同步
并行，多路決策，循環遍歷等情況，這種情況下使用狀態位就無法滿足客戶的業務需求，因此隨著業務需求復雜度的上升，我們必然需要選擇功能更強大的武器來解
決這一系列的問題。