兩周前，我們談到了流程的標準化對於商業行為的長期運作的重要性。 甚至只是間小吃店也是一樣，因為若缺乏這東西的話，混亂、錯誤、衝突、與失敗就很可能出現在日常工作中。 但若回到以專案為主體的工作環境，相同的概念卻好像並不那麼容易可以帶入？

對小吃店而言，產品導向的施作流程(Product Oriented Processes)是有機會可以標準化，也應該要盡快被標準化。 像對麥當勞而言，從漢堡、薯條、到各類餐品，都有準備以及施作的流程。 薯條該切多厚、放入油槽要多久、灑鹽要灑幾下、怎麼裝袋，或一個漢堡要放幾片肉，幾片生菜、幾片番茄都有標準作業程序(SOP)來規範。 也因此，他們才可以透過同樣的方法快速在世界展店。

但在專案的場合下，我們通常從事的是如開發、研發、設計、創意、複雜工程、或是高度客製的一次性產出。 也因此，產出物本身，甚至產出「產出物」的過程每次可能都有差異，甚至可能差異還極大。 這也是為何很多人在聽到要為專案訂定流程時，通常都會充滿了高度的不以為然。

「寫這些是要做甚麼，專案根本不可能訂出甚麼標準流程的嘛！」

我可沒有要試圖洗腦大家說我們可在專案中訂出如麥當勞一樣的炸薯條流程；事實上我還完全同意上面那段的說法：專案是高度不確定性的東西，硬要把施作流程從頭到尾標準化下來是極度理想主義的想法(PS 也不是不可能、但這涉及專案屬性還有團隊成熟度)。 畢竟今天一個自己設計並製作的案子、跟一個別人發包OEM的案子做法多半會有不同；台北捷運跟高雄捷運也不可能做法完全一樣；而一個動作遊戲跟個RPG，更可能會有完全迥異的做法。所以，就算勉強把「產品導向的施作流程」鉅細靡遺的定了下來，下次在面對不同的客戶、不同的需求、不同的合作方式、不同的技術、不同的團隊下，一定會發現怎麼綁手綁腳無法使用，甚至可能在訂定中途就會讓人抱持著極大的懷疑了。所以，做這樣的東西並不切實際，這點是顯而易見的。

我同意上面的論述，但這可不表示我同意在專案世界中流程架構的思考與標準化是不需要的。

上面的結論，僅僅是因為很多人常把「標準化，」這件事情關注在錯誤的焦點上。 畢竟任何人在初次聽聞到要訂定「標準工作流程」時，往往都錯誤的把重心放在相對不重要且變動可能很大的「施作的流程」上。 但實際上最重要，也最立刻該規劃的，卻不在這裡。

比起小吃店，專案中的流程可分為三大項：

1. 產品導向之流程 (Product oriented Processes)

• 你也可以把這稱為執行流程。 這通常是我們為了完成產品、部分的產品組件、或是專案的特定交付產出(Deliverable)，所必須執行的一系列做法。大的如產品的階段(Phase)；細的則如設計流程、一個Modeling的製作流程、或接熱水器的接續流程。這是大部分人聽到要訂流程時，立刻會認為該定的。 事實上，這些流程有可能根據不同的專案有著全然不同的做法，也是相對上較難全面標準化的一部分。

1. 專案管理之流程 (Project Management Processes)

• 是專案進行中的主要管理流程。這流程的目的為確保專案品質、提升專案成功機率所必須進行的一連串相關活動。 如專案起始中所需要準備的文件有哪些？ 如何準備？、專案計畫時所做的網圖與排程或資源及成本規劃、團隊定期的資訊回報、專案負責人如何做進度的差異比對、或是如何了解專案的健康狀態等。專案開始前，應該要有一個這樣的管理架構。

1. 管理支援之流程 (Management supporting processes)

• 主要是針對特殊事件的處理流程。 在專案進行中或是公司常態運作中為因應特定狀況或事件(Event)的處理程序。 這些流程將根據事件的觸發而才啟動使用，如文件管理流程(文件產出時或是接收時該怎麼做？怎麼管理文件版本？)、議題管理流程(造成專案可能停頓或是影響的問題發生時的通報及處理規則)、產出物管理(東西做好了該收到哪裡、怎麼保管、誰保管？ 東西改版了該怎麼辦？)、或是變更管理(誰可以改變專案範疇？何時可以變、何時之後不行變？怎麼樣進行變？)等。 這是大部分人初期不會去思考的流程，但是這卻是管理順利與否的一項關鍵。

在任何專案開始之前，專案管理之流程(Project Management Processes)、以及管理支援之流程(Management Supporting Processes)應該要能先被定義出來。 這些管理或是處理事件的規則，將是避免專案混亂的關鍵基礎。 所謂定義出來並不表示我們一開始要規定到很細，但最少得要有個粗略的架構能讓團隊面對問題時不要不知所措。畢竟一個基層的工程師、動畫師、設計師，不應該浪費他們的時間去思考「發生了一個問題我該通報誰」這種鳥事；他們也不該去擔憂「文件做好了該存放到哪裡」、何時該回報工作進度、阿貓或阿狗都跑來說要多加一個Model時，我是不是都應該要答應他們呢？ 或是到哪裡去要求跨部門的支援需求或人員調度。 第一線人員的時間應該要能更專注於真正有產出、有價值的活動上。何況，退一步來想，就算讓第一線人員浪費時間去擔憂這類議題，大家做法可能都不一致。 反到會出現一堆不同格式、不同版本、不同的回報方法、不同的紀錄工具，這只會更造成嚴重的團隊混亂。

這些混亂不是專案一定會有的問題，而是在專案負責人若事先沒有思考怎麼管理我們自己下，才會產生的必然後果。所以專案的管理者或是負責人，在專案開始前一定要幫團隊做「一個框架」，讓團隊可以在既定的規則下發揮創意，而非無所適從。 讓團隊能在案子開始後，花較少的心思煩惱到底該跟誰回報或是該怎麼了解狀態，而能把重心放在他們該專注的產出上。

所以，流程制定的目的並不是限制團隊創意的自由；相反的，是要提供一個讓團隊可以真.正.自.由發揮創意的框架與舞台。

畢竟下一次，我們做的產品可能變，面對的客戶可能變，但是管理的大架構將持續固定的(如文件管理、訊息發佈、多久應該回報進度、怎麼回報進度、有問題發生時該跟誰通報、怎麼通報、做出來的產出物或是零件應該怎麼存放、怎麼找之前的版本等)，而且也應該優先固定。 或許第一次無法定的很詳細，但在案子進行中，這些規則、作法、工具等都可以慢慢依照狀態來修改或增減，規則的細制度也可以隨著經驗累積，專案次數的增加而變得越來越完備。這樣就算我們下次做的是不相同的案子，我們還是能確保團隊能快速轉移焦點並凝聚團結，而不會產生焦慮、衝突、或是溝通誤解等鳥事。

至於執行專案的方法，則應該等到案子確定了，需求也確定了，專案利害關係人的看法、想法都摸清楚了、團隊能用的技術都澄清了。 我們才根據每次的需要量身訂做 (這些會進入我們的專案執行計畫書、以WBS以及甘特圖的方式呈現)。

而這些施做的方法可能一開始並不夠純熟。 但畢竟團隊一定是具備這領域背景的人才(不然怎麼會一起做專案)，就算方法不好也不至於慘到哪裡去。第一次第二次可能不夠優雅，但是只要管理框架存在，各專才的人就自然可以自由思考、調整、在他自己的專業下讓事情逐漸精進。 只要我們框架穩定、再持續專注於技術這領域，長期下來我們自然會走向如All Star團隊般的快速、優雅與自信。

但如果我們不這樣，只是想靠技術來彌補管理架構的缺乏，最後我們將哪裡也去不了的。