創(chuàng)業(yè)公司實現(xiàn)了0-1，但是怎么實現(xiàn)從1-100就需要內(nèi)修好項目管理了。本文通過在公司搭建項目流程的角度對整個創(chuàng)業(yè)公司項目流程搭建進行了復(fù)盤。

一、創(chuàng)業(yè)公司的痛

創(chuàng)業(yè)公司往往在流程管理上還沒有規(guī)范，這就導(dǎo)致了

1. 項目拖延導(dǎo)致沒有音訊
2. 交付超時，影響商務(wù)對外輸出

通過項目管理完善對接流程，起到如下作用：

1. 確保溝通明確，使得產(chǎn)品端能夠根據(jù)商務(wù)的需求提供高質(zhì)量交付物
2. 明確交付物細節(jié)，避免對接問題導(dǎo)致的溜單問題
3. 對流程文檔化，方便后續(xù)項目復(fù)用
4. 開始對項目進行敏捷管理

二、對接流程說明

流程可以根據(jù)需求的類型分為四部分：DEMO需求、產(chǎn)品需求、接口需求、迭代BUG需求。

1. DEMO需求

DEMO需求是指商務(wù)找到了有意向的甲方，需要由產(chǎn)品端提供DEMO供商務(wù)演示，這部分的需求沒有交付的流程，主要工作集中在產(chǎn)品部、項目部。

一般公司沒有現(xiàn)成業(yè)務(wù)線時需要制作DEMO，因此公司內(nèi)部需要評估是否需要拓展該業(yè)務(wù)線，如果該業(yè)務(wù)向本身就不適合開展的話，那么就應(yīng)該反饋給商務(wù)，這個業(yè)務(wù)DEMO無法交付。

這其中評估考量有：

1. 是否存在足夠的商業(yè)空間值得投入資源。
2. 技術(shù)能力是否滿足需要
3. 內(nèi)部資源投入與商業(yè)空間的權(quán)衡
4. 是否涉及監(jiān)管合規(guī)
5. 與當前排期是否沖突
6. ……

2. 產(chǎn)品需求

成品需求是指商務(wù)已經(jīng)完成了合同簽訂，明確需要交付產(chǎn)品的了，是優(yōu)先級最高的需求。在這個需求中需要各個部門一起協(xié)作，完成產(chǎn)品從設(shè)計到交付的全部工作，給到用戶的是一個交付的完整產(chǎn)品。

整個項目周期跨度一般較大，并且設(shè)計多部門協(xié)作，因此需要做好文檔的記錄以及項目的管理。

產(chǎn)品先確認需求清單，明確哪些是可以做的，討論后確定開發(fā)需求。確定好需求后產(chǎn)品就會開始原型設(shè)計，完成原型設(shè)計后通過商務(wù)與業(yè)務(wù)方確認需求樣式后，在公司內(nèi)部進行需求評審。完成需求評審，確定好開發(fā)方案和負責(zé)人后，需求就進入了開發(fā)階段。

開發(fā)完成后，測試會開始產(chǎn)品的接口、功能、系統(tǒng)測試，如果在測試階段發(fā)現(xiàn)問題就會反饋開發(fā)進行修改。如果是產(chǎn)品設(shè)計的問題，就由產(chǎn)品進行修改。測試通過后產(chǎn)品會開始驗收產(chǎn)品，驗收通過的會提供驗收報告。

之后開發(fā)會提供接口說明文檔、功能部署文檔給運維，由運維進行部署。部署完成后，產(chǎn)品提供產(chǎn)品使用說明書及交付清單，之后由業(yè)務(wù)方開始驗收工作。

3. 接口需求

接口需求是指外部業(yè)務(wù)方只需要我們開發(fā)功能的接口，接入業(yè)務(wù)方自己的系統(tǒng)。

這種情況也通過商務(wù)-產(chǎn)品-開發(fā)這種流程進行對接，這里面的考量為：

1. 接口需求也涉及到業(yè)務(wù)應(yīng)用，因此由產(chǎn)品明確接口的業(yè)務(wù)需求，能避免接口開發(fā)過程中的需求溢出問題
2. 該接口是否我們技術(shù)已經(jīng)支持
3. 接口需求也需要占用開發(fā)資源，產(chǎn)品需要評估與開發(fā)中需求的沖突情況

4. 迭代需求

迭代需求是指產(chǎn)品的功能迭代、BUG修復(fù)、功能回滾等需求。一般來源于業(yè)務(wù)方反饋，或者業(yè)務(wù)線本身的迭代路線圖中。這些工作

5. 項目會議

在整個項目組運行過程中會有很多會議，在會議開始前，會議發(fā)起人要明確好會議的參與者、會議的討論內(nèi)容和會議的目的，并提早做好會議通知、會議室準備。

在會后要寫會議紀要，避免會議結(jié)束后，大家遺忘會議結(jié)論。

6. DEMO評審會

DEMO評審會是為了判斷這個DEMO是否需要做，這種情況一般針對的是內(nèi)部有異議的業(yè)務(wù)線情況。如果商務(wù)自身決定不做DEMO的，就不用發(fā)起DEMO評審了。

如果商務(wù)覺得有必要開一條業(yè)務(wù)線時，需要內(nèi)部產(chǎn)品、技術(shù)等建議時，發(fā)起DEMO的評審。

7. 需求評審會

需求評審會的目的是確定需求方案是否合理，并確定需求的方案是否存在遺漏，以及實現(xiàn)需要的工作量。因此需求評審會內(nèi)容會偏多，并且是需求進入開發(fā)階段前最后一道把關(guān)。

需求評審會有產(chǎn)品經(jīng)理發(fā)起，需要開發(fā)人員、測試人員參與，針對需求設(shè)計的細節(jié)進行一一確認。

8. 需求排期會

需求排期時針對需求數(shù)量超過工作能力要求時而設(shè)立的。目的就是通過對比需求質(zhì)檢的優(yōu)先級順序，確定開發(fā)的優(yōu)先級。

需求排期會由產(chǎn)品產(chǎn)品組內(nèi)部進行，最后生成一個需求優(yōu)先級排序結(jié)果作為以后一個時間段內(nèi)的工作輕重參考。

9. 問題解決方案討論會

在項目開發(fā)過程中肯定會有出現(xiàn)問題，這可能是缺資源、性能滿足不了需求、需要額外的接口等。

如果出現(xiàn)問題都先反饋到負責(zé)的產(chǎn)品處，由產(chǎn)品協(xié)調(diào)資源進行解決。

如果超過了產(chǎn)品能力的范圍，由產(chǎn)品發(fā)起相關(guān)人員，一起討論問題的解決方案。

10. 需求上線會議

需求完成開發(fā)，并完成測試驗收后就會開始準備上線工作了。一個系統(tǒng)都是多個服務(wù)的組合，就比如APP就涉及到APP、后端服務(wù)、數(shù)據(jù)源、運營平臺等。因此上線也存在先后順序的問題。不然就可能會出現(xiàn)用戶打開后，沒有內(nèi)容甚至報錯的情況。

11. 項目復(fù)盤會

項目完成了上線并不是一個需求的結(jié)束。在磕磕絆絆中大家慢慢得到了成長，良好的總結(jié)問題習(xí)慣能夠讓大家一起走的更遠。

項目的復(fù)盤會議，產(chǎn)品經(jīng)理需要先總結(jié)這個需求過程中的各種問題，按問題的類型進行分類，流程問題、技術(shù)問題、產(chǎn)品設(shè)計問題等，針對不同問題的類型進行總結(jié)。

三、文檔內(nèi)容說明

在整個項目實施過程中會有很多文檔，寫文檔是需要明確寫不是目的，目的是：

1. 做到件件有交代，避免大家口口相傳中的信息丟失
2. 作為后續(xù)工作復(fù)盤中的依據(jù)
3. 給后續(xù)項目復(fù)用提供資料
4. 幫助業(yè)務(wù)方更好的使用我們的產(chǎn)品

1. DEMO需求要求

Demo需求的要求的目的是和產(chǎn)品說明清楚，這個demo的要求，需要演示的時間以及演示的方式，可以提供的物料等。Demo需求要求不是重要的文檔，所以不用明確文檔的形式，只需要一個簡單的表格即可。例如：

2. 需求清單

需求清單是整個項目在實施過程中的依據(jù)，產(chǎn)品需要依據(jù)清單設(shè)計需求，開發(fā)需要根據(jù)清單實現(xiàn)系統(tǒng)性能要求，測試要根據(jù)清單進行測試。因此這個文檔要求：

• 高可讀性，能滿足產(chǎn)品、開發(fā)、測試等各個崗位的理解
• 信息必需是明確的，不能是模糊的說法，涉及到數(shù)據(jù)的需要明確

• 需求需要根據(jù)模塊進行分類，方便B端業(yè)務(wù)線功能迭代時，統(tǒng)籌規(guī)劃
• 需求需要有明確的優(yōu)先級定義，方便B端排期時安排
• 需求清單處理功能的列表還應(yīng)該包含整個產(chǎn)品的系統(tǒng)性能要求

需求清單流程：

1. 商務(wù)與業(yè)務(wù)方簡單對接，完成需求清單
2. 產(chǎn)品根據(jù)需求清單，整理功能確認點反饋
3. 開發(fā)根據(jù)接口需要，整理接口確認點
4. 商務(wù)完成業(yè)務(wù)方對接，內(nèi)部開始產(chǎn)品開發(fā)

有的公司有項目經(jīng)理負責(zé)對接項目清單，也有公司直接產(chǎn)品經(jīng)理與業(yè)務(wù)方對接項目清單，這里為了避免公司內(nèi)部與外部業(yè)務(wù)方多對多的情況導(dǎo)致需求遺漏。因此采用統(tǒng)一出口，統(tǒng)一入口的方式。這里面的優(yōu)劣勢情況會根據(jù)公司業(yè)務(wù)情況進行跳轉(zhuǎn)。

3. 原型設(shè)計文檔

在產(chǎn)品環(huán)節(jié)需要針對功能需求設(shè)計原型，比如：運營后臺功能、前端展示等。

原型設(shè)計作為產(chǎn)品經(jīng)理的基本功，不再贅述。

4. 需求文檔

需求文檔是公司內(nèi)部項目實施的說明文檔。需求文檔是開發(fā)工作的依據(jù)。

5. 測試報告

根據(jù)需求的情況會有不同的測試任務(wù)，不同的測試任務(wù)會有不同的測試報告。例如在接口需求中就會有接口測試報告，迭代和BUG中就會有服務(wù)的測試報告，涉及到產(chǎn)品交付的還會有系統(tǒng)測試報告。

測試報告是運維發(fā)布上線的依據(jù)，如果沒有測試報告，運維就不能把服務(wù)發(fā)布上線。

6. 接口說明文檔

接口文檔是開發(fā)給接入者提供的說明文檔，也是產(chǎn)品交付后業(yè)務(wù)方二次開發(fā)的依據(jù)，在公司內(nèi)部開發(fā)的接口，需要開發(fā)完成后上傳到公司內(nèi)部文檔管理的平臺上，做好留檔。因此需要明確接口的內(nèi)容，包括：

1. 入?yún)ⅲ喝雲(yún)⒆侄蔚恼f明、入?yún)⒌膬?nèi)容說明、入?yún)⒌念愋汀⑹欠癖靥畹?/li>
2. 返參：返參字段的說明、返參的內(nèi)容說明、返參的類型，是否必填等
3. 正確請求示例
4. 錯誤提示說明
5. 認證方式
6. ……

7. 驗收報告

驗收報告是產(chǎn)品經(jīng)理驗收需求后提供的報告，意思是產(chǎn)品滿足產(chǎn)品經(jīng)理設(shè)計的要求。驗收包括了兩部分，一塊是界面交互驗收，另一塊是功能驗收。在驗收環(huán)節(jié)，產(chǎn)品應(yīng)該盡可能的模擬用戶使用產(chǎn)品，或者也可以找項目組的同學(xué)進行體驗驗收。

8. 產(chǎn)品使用說明文檔

B端項目產(chǎn)品在交付的同事需要提供一份高可讀性的產(chǎn)品使用說明文檔。在文檔中需要說明清楚整個產(chǎn)品的功能邏輯，并針對整個產(chǎn)品使用操作進行詳細的圖文說明。

產(chǎn)品使用說明文檔需要注意的是：

1. 避免開篇就開始將細節(jié)。應(yīng)該先從整體講解這個產(chǎn)品的用處，整體涉及模塊及各模塊的作用
2. 內(nèi)容應(yīng)該采用總分總的結(jié)構(gòu)進行描述，方便用戶理解
3. 注意概念說明，業(yè)務(wù)方的使用者對功能不一定理解，因此需要注意概念性名詞的解釋
4. 涉及到復(fù)雜操作的，務(wù)必帶上截圖

9. 交付清單

交付清單是指產(chǎn)品完成開發(fā)后，需要向業(yè)務(wù)方反饋的所有交付物清單。交付清單應(yīng)該是表格式的，明確交付物的名稱、形式、數(shù)量等信息。交付物包括實體的硬件、電子版文檔、虛擬的接口、產(chǎn)品的安裝包等等

10. 部署文檔

需求完成開發(fā)，測試驗收后就會需要運維進行發(fā)布。在復(fù)雜需求中涉及到多個模塊，因此發(fā)布上線是一個復(fù)雜的工作。開發(fā)在完成開發(fā)時，需要向運維提供完整的部署文檔，并在發(fā)布上線前，由大家一起確定發(fā)布上線的順序及服務(wù)啟動的關(guān)系。

四、特殊情況說明

1. 需求修改、補充

已經(jīng)開始開發(fā)的：

需求已經(jīng)開始開發(fā)的，遇到了需求修改補充的，需要判斷修改是否對原需求是推到重來的情況。是推倒重來的需求就應(yīng)該及時調(diào)整需求的優(yōu)先級順序，對需求進行調(diào)整了。如果是錦上添花的修改，那么根據(jù)開發(fā)進度進行評估是插入還是作為迭代需求更新進需求池。

還沒進行開發(fā)的：

產(chǎn)品評估需求改動的量，如果可以則修改需求設(shè)計

2. 需求延期

需求可能由于其他更高優(yōu)需求插隊、技術(shù)難度等導(dǎo)致延期。需求延期導(dǎo)致的交付延期，開發(fā)應(yīng)該提早向負責(zé)需求的產(chǎn)品進行反饋，在反饋時需要明確說明延期的原因、預(yù)計延期時間、預(yù)計交付的時間，方便產(chǎn)品及時與商務(wù)溝通，避免違約導(dǎo)致合同賠償問題。

本文由 @南風(fēng)追憶 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash ，基于 CC0 協(xié)議