創業公司實現了0-1，但是怎麼實現從1-100就需要內修好項目管理了。本文通過在公司搭建項目流程的角度對整個創業公司項目流程搭建進行了覆盤。
一、創業公司的痛
創業公司往往在流程管理上還沒有規範，這就導致了
- 項目拖延導致沒有音訊
- 交付超時，影響商務對外輸出
通過項目管理完善對接流程，起到如下作用：
- 確保溝通明確，使得產品端能夠根據商務的需求提供高質量交付物
- 明確交付物細節，避免對接問題導致的溜單問題
- 對流程文檔化，方便後續項目複用
- 開始對項目進行敏捷管理
二、對接流程說明
流程可以根據需求的類型分為四部分：DEMO需求、產品需求、接口需求、迭代BUG需求。
1. DEMO需求
DEMO需求是指商務找到了有意向的甲方，需要由產品端提供DEMO供商務演示，這部分的需求沒有交付的流程，主要工作集中在產品部、項目部。
一般公司沒有現成業務線時需要製作DEMO，因此公司內部需要評估是否需要拓展該業務線，如果該業務向本身就不適合開展的話，那麼就應該反饋給商務，這個業務DEMO無法交付。
這其中評估考量有：
- 是否存在足夠的商業空間值得投入資源。
- 技術能力是否滿足需要
- 內部資源投入與商業空間的權衡
- 是否涉及監管合規
- 與當前排期是否衝突
- ……
2. 產品需求
成品需求是指商務已經完成了合同簽訂，明確需要交付產品的了，是優先級最高的需求。在這個需求中需要各個部門一起協作，完成產品從設計到交付的全部工作，給到用戶的是一個交付的完整產品。
整個項目週期跨度一般較大，並且設計多部門協作，因此需要做好文檔的記錄以及項目的管理。
產品先確認需求清單，明確哪些是可以做的，討論後確定開發需求。確定好需求後產品就會開始原型設計，完成原型設計後通過商務與業務方確認需求樣式後，在公司內部進行需求評審。完成需求評審，確定好開發方案和負責人後，需求就進入了開發階段。
開發完成後，測試會開始產品的接口、功能、系統測試，如果在測試階段發現問題就會反饋開發進行修改。如果是產品設計的問題，就由產品進行修改。測試通過後產品會開始驗收產品，驗收通過的會提供驗收報告。
之後開發會提供接口說明文檔、功能部署文檔給運維，由運維進行部署。部署完成後，產品提供產品使用說明書及交付清單，之後由業務方開始驗收工作。
3. 接口需求
接口需求是指外部業務方只需要我們開發功能的接口，接入業務方自己的系統。
這種情況也通過商務-產品-開發這種流程進行對接，這裡面的考量為：
- 接口需求也涉及到業務應用，因此由產品明確接口的業務需求，能避免接口開發過程中的需求溢出問題
- 該接口是否我們技術已經支持
- 接口需求也需要佔用開發資源，產品需要評估與開發中需求的衝突情況
4. 迭代需求
迭代需求是指產品的功能迭代、BUG修復、功能回滾等需求。一般來源於業務方反饋，或者業務線本身的迭代路線圖中。這些工作
5. 項目會議
在整個項目組運行過程中會有很多會議，在會議開始前，會議發起人要明確好會議的參與者、會議的討論內容和會議的目的，並提早做好會議通知、會議室準備。
在會後要寫會議紀要，避免會議結束後，大家遺忘會議結論。
6. DEMO評審會
DEMO評審會是為了判斷這個DEMO是否需要做，這種情況一般針對的是內部有異議的業務線情況。如果商務自身決定不做DEMO的，就不用發起DEMO評審了。
如果商務覺得有必要開一條業務線時，需要內部產品、技術等建議時，發起DEMO的評審。
7. 需求評審會
需求評審會的目的是確定需求方案是否合理，並確定需求的方案是否存在遺漏，以及實現需要的工作量。因此需求評審會內容會偏多，並且是需求進入開發階段前最後一道把關。
需求評審會有產品經理發起，需要開發人員、測試人員參與，針對需求設計的細節進行一一確認。
8. 需求排期會
需求排期時針對需求數量超過工作能力要求時而設立的。目的就是通過對比需求質檢的優先級順序，確定開發的優先級。
需求排期會由產品產品組內部進行，最後生成一個需求優先級排序結果作為以後一個時間段內的工作輕重參考。
9. 問題解決方案討論會
在項目開發過程中肯定會有出現問題，這可能是缺資源、性能滿足不了需求、需要額外的接口等。
如果出現問題都先反饋到負責的產品處，由產品協調資源進行解決。
如果超過了產品能力的範圍，由產品發起相關人員，一起討論問題的解決方案。
10. 需求上線會議
需求完成開發，並完成測試驗收後就會開始準備上線工作了。一個系統都是多個服務的組合，就比如APP就涉及到APP、後端服務、數據源、運營平臺等。因此上線也存在先後順序的問題。不然就可能會出現用戶打開後，沒有內容甚至報錯的情況。
11. 項目覆盤會
項目完成了上線並不是一個需求的結束。在磕磕絆絆中大家慢慢得到了成長，良好的總結問題習慣能夠讓大家一起走的更遠。
項目的覆盤會議，產品經理需要先總結這個需求過程中的各種問題，按問題的類型進行分類，流程問題、技術問題、產品設計問題等，針對不同問題的類型進行總結。
三、文檔內容說明
在整個項目實施過程中會有很多文檔，寫文檔是需要明確寫不是目的，目的是：
- 做到件件有交代，避免大家口口相傳中的信息丟失
- 作為後續工作覆盤中的依據
- 給後續項目複用提供資料
- 幫助業務方更好的使用我們的產品
1. DEMO需求要求
Demo需求的要求的目的是和產品說明清楚，這個demo的要求，需要演示的時間以及演示的方式，可以提供的物料等。Demo需求要求不是重要的文檔，所以不用明確文檔的形式，只需要一個簡單的表格即可。例如：
2. 需求清單
需求清單是整個項目在實施過程中的依據，產品需要依據清單設計需求，開發需要根據清單實現系統性能要求，測試要根據清單進行測試。因此這個文檔要求：
- 高可讀性，能滿足產品、開發、測試等各個崗位的理解
- 信息必需是明確的，不能是模糊的說法，涉及到數據的需要明確
- 需求需要根據模塊進行分類，方便B端業務線功能迭代時，統籌規劃
- 需求需要有明確的優先級定義，方便B端排期時安排
- 需求清單處理功能的列表還應該包含整個產品的系統性能要求
需求清單流程：
- 商務與業務方簡單對接，完成需求清單
- 產品根據需求清單，整理功能確認點反饋
- 開發根據接口需要，整理接口確認點
- 商務完成業務方對接，內部開始產品開發
有的公司有項目經理負責對接項目清單，也有公司直接產品經理與業務方對接項目清單，這裡為了避免公司內部與外部業務方多對多的情況導致需求遺漏。因此採用統一出口，統一入口的方式。這裡面的優劣勢情況會根據公司業務情況進行跳轉。
3. 原型設計文檔
在產品環節需要針對功能需求設計原型，比如：運營後臺功能、前端展示等。
原型設計作為產品經理的基本功，不再贅述。
4. 需求文檔
需求文檔是公司內部項目實施的說明文檔。需求文檔是開發工作的依據。
5. 測試報告
根據需求的情況會有不同的測試任務，不同的測試任務會有不同的測試報告。例如在接口需求中就會有接口測試報告，迭代和BUG中就會有服務的測試報告，涉及到產品交付的還會有系統測試報告。
測試報告是運維發佈上線的依據，如果沒有測試報告，運維就不能把服務發佈上線。
6. 接口說明文檔
接口文檔是開發給接入者提供的說明文檔，也是產品交付後業務方二次開發的依據，在公司內部開發的接口，需要開發完成後上傳到公司內部文檔管理的平臺上，做好留檔。因此需要明確接口的內容，包括：
- 入參：入參字段的說明、入參的內容說明、入參的類型、是否必填等
- 返參：返參字段的說明、返參的內容說明、返參的類型，是否必填等
- 正確請求示例
- 錯誤提示說明
- 認證方式
- ……
7. 驗收報告
驗收報告是產品經理驗收需求後提供的報告，意思是產品滿足產品經理設計的要求。驗收包括了兩部分，一塊是界面交互驗收，另一塊是功能驗收。在驗收環節，產品應該儘可能的模擬用戶使用產品，或者也可以找項目組的同學進行體驗驗收。
8. 產品使用說明文檔
B端項目產品在交付的同事需要提供一份高可讀性的產品使用說明文檔。在文檔中需要說明清楚整個產品的功能邏輯，並針對整個產品使用操作進行詳細的圖文說明。
產品使用說明文檔需要注意的是：
- 避免開篇就開始將細節。應該先從整體講解這個產品的用處，整體涉及模塊及各模塊的作用
- 內容應該採用總分總的結構進行描述，方便用戶理解
- 注意概念說明，業務方的使用者對功能不一定理解，因此需要注意概念性名詞的解釋
- 涉及到複雜操作的，務必帶上截圖
9. 交付清單
交付清單是指產品完成開發後，需要向業務方反饋的所有交付物清單。交付清單應該是表格式的，明確交付物的名稱、形式、數量等信息。交付物包括實體的硬件、電子版文檔、虛擬的接口、產品的安裝包等等
10. 部署文檔
需求完成開發，測試驗收後就會需要運維進行發佈。在複雜需求中涉及到多個模塊，因此發佈上線是一個複雜的工作。開發在完成開發時，需要向運維提供完整的部署文檔，並在發佈上線前，由大家一起確定發佈上線的順序及服務啟動的關係。
四、特殊情況說明
1. 需求修改、補充
已經開始開發的：
需求已經開始開發的，遇到了需求修改補充的，需要判斷修改是否對原需求是推到重來的情況。是推倒重來的需求就應該及時調整需求的優先級順序，對需求進行調整了。如果是錦上添花的修改，那麼根據開發進度進行評估是插入還是作為迭代需求更新進需求池。
還沒進行開發的：
產品評估需求改動的量，如果可以則修改需求設計
2. 需求延期
需求可能由於其他更高優需求插隊、技術難度等導致延期。需求延期導致的交付延期，開發應該提早向負責需求的產品進行反饋，在反饋時需要明確說明延期的原因、預計延期時間、預計交付的時間，方便產品及時與商務溝通，避免違約導致合同賠償問題。
題圖來自 Unsplash ，基於 CC0 協議
閱讀更多 人人都是產品經理 的文章
