在一個項目中，流程管理是最基礎且有效的管理手段。通過審時度勢的看待資源現狀，從而確立最優化項目流程方法。在規避無用流程的同時，又能以宏觀角度去把控整個項目運轉效率。
在項目流程相對固化的今天，如何優化流程去輔助項目進行這一議題，成為了越來越多產品人考慮的關鍵所在。
流程管理是項目環節中所用到的一種管理方法，需要在項目開展前確定、在項目過程中遵守、在項目結束后優化。它的核心原則為：
遵循因地制宜，選擇適合項目推動的流程；切勿本末倒置，流程管理只是項目落地的工具
為了梳理清楚流程管理的整體思維框架，便于宏觀對其進行了解，于是匯總了相關的知識脈絡，如下圖所示：
前言
一般情況下，在我們日常工作中，會常見兩種流程管理方法。除此以外，也還會出現依托于這兩種之上的變形方法。但歸根結底，只要使用的流程適合團隊項目的開展，那么它就是好的流程。不是所有方法都能與項目情況所契合，所以這需要一個產品經理具有洞察本質并且善于變通的能力
不管項目流程如何進行，都無法降低需求評審的存在價值。這是一個讓產品經理愛恨交織的會議：愛在可以舌戰群雄實現自我價值，恨在如果思考不充分會演變成一場撕逼大戰。但無論如何都可以確定的是，需求評審在一個項目中扮演至關重要的角色
1.流程分類
項目流程的種類有很多，但大致上分為兩類：日常型和復雜型
1、復雜型
所謂復雜型項目流程，指的是項目從需求環節到開發周期直至上線，所經歷的流程如下所示：
立項會議 → 需求評審 → 設計評審 → 測試評審 → 上線
在上述流程中，主要是通過4個評審會議去完成需求向功能的轉變。其目的是通過多輪評審溝通，確保需求到功能的轉化與預想一致
1.1 立項會議
顧名思義，立項會議的召開就標志著一個項目的成立。作為項目流程的第一步，它的作用主要是為了給各方領導講解項目內容，讓他們給把把關，順帶爭取資源。在此過程中，最好可以鼓舞人心，點燃成員激情。需要介紹的內容為以下6個方面：
項目背景（用戶需求場景）
項目意義、目的
需求內容
項目計劃（項目整體規劃）
項目節點（里程碑、上線等各個節點時間）
溝通計劃（如何溝通，比如周例會、早會等）
在介紹完以后，我們還需要給本次項目確定一個有意義的“名字”，這樣會讓團隊成員更有代入感和凝聚力
1.2 需求評審
這部分內容是整個項目的重中之重，所以會在后文中詳細剖析
1.3 設計評審
設計評審主要是站在開發的角度，去評審功能如何實現等問題，把開發設計具象化。雖然大多數情況下，聽不懂他們講的實現原理都是些什么，但是可以借助設計評審去驗證需求實現是否與目標一致
此舉的目的是保證需求實現無歧義，以防開發過后才發現好多內容與預想大相徑庭、更有甚者背道而馳。同時，可以在評審過程中，進一步完善需求評審時遺漏的瑕疵
在設計評審過后，就正式進入了開發階段。后端開發人員會敲代碼寫接口，前端開發人員會根據已有的UI切圖標注信息，去搭建頁面的可視化顯示內容
1.4 測試評審
最后一步主要是由測試人員講解測試用例，在此環節，你就會驚嘆于測試人員看待問題的全面性。他們可能會列出所有你沒考慮過的細節問題、異常情況、邊界狀況等等。其實和設計評審也有異曲同工之妙，再次核實需求實現的是否與預想一致
在測試環節，常用的方法有：壓力測試、性能測試、冒煙測試等。有這些檢測方法為我們保駕護航，使得我們提供給用戶的產品一定是安全可信賴的
測試流程一般為：開發完畢后先自測，測完沒問題后會把代碼從開發環境提交到測試環境。在測試環境中可以更直觀的發現問題所在，測試人員不斷的發現BUG并提交給相對應的開發人員去解決，這可能會是一個相對漫長的過程
當然，如果沒有嚴重問題且時間緊急的情況下，也允許帶著小問題上線。因為好多問題都是無關痛癢的邊緣內容，而且相較延期可能錯過的機會，BUG的存在就相對無足輕重了
2、日常型
相較復雜型流程而言，日常型更注重的是快速迭代、化繁為簡的工作流程。事實上，流程只是輔助完成工作的方向標，所以面對日常敏捷型迭代或者開發，可能就不會用到上面那種厚重繁瑣的流程了
這種流程的缺點就是可能開發完成后才發現問
