產(chǎn)品開發(fā)無疑是一件復(fù)雜的事情，在其“不可知”的過程，到底哪些是最為關(guān)鍵的階段，管理好那些核心過程能夠有助于提高產(chǎn)品的競爭力？本文中，筆者為我們揭曉了這些問題的答案。

01

據(jù)說，軟件開發(fā)領(lǐng)域有一個數(shù)據(jù)，50%以上的項目都會出現(xiàn)進度延期，多數(shù)新產(chǎn)品開發(fā)項目都像是“腳踩西瓜皮，滑到哪里是哪里”，真正能夠按照計劃完成的研發(fā)項目少之又少。

上文《產(chǎn)品經(jīng)理怎么規(guī)劃產(chǎn)品發(fā)展路徑》解答了我們?yōu)槭裁纯偸前l(fā)布不對路的產(chǎn)品，下一步我們要解決的問題就是研發(fā)過程管理的問題，特別是新產(chǎn)品的研發(fā)項目。

• 第一個問題是：如何把握哪些關(guān)鍵性節(jié)點能有效管理進度？
• 第二個問題是：研發(fā)過程中存在那些坑，以及如何解決這些坑？

第一個問題的答案，看上去非常明顯——無非是對關(guān)鍵節(jié)點的管理，在PMP的管理理念中就是對關(guān)鍵里程碑的輸入、輸出的管理。

著名軟件工程專家B.Boehm在1983年提出了軟件工程的七條基本原理，其中三條分別是：

1. 用分階段的生存周期計劃進行嚴格的管理。
2. 堅持進行階段評審。
3. 實行嚴格的產(chǎn)品控制。

第四條則是——結(jié)果應(yīng)能清楚地審查。

把軟件的開發(fā)過程拆分成多個階段，使得每個階段的任務(wù)相對獨立，就可以實現(xiàn)不同職責(zé)和崗位的角色進行協(xié)作，從而降低了整個軟件開發(fā)過程的困難度和復(fù)雜度。

每個階段都可以采用科學(xué)的管理技術(shù)和良好的技術(shù)方法，而且在每個階段結(jié)束之前都可以從技術(shù)和管理兩個維度進行審查，合格之后才正式進入下一階段的工作（事實上部分工作存在并行性，而非僵死的串行機制，但下游成果是否符合設(shè)定的目標取決于上游的設(shè)計），這就保證了整個過程有條不紊地進行，既保證了質(zhì)量，也提供了軟件產(chǎn)品的可維護性。

但關(guān)鍵是如何進行階段性劃分呢？

我的觀點是：4個評審點和一個驗收點。

（1）需求評審

對需求的評審，回答的“我們要解決的問題是什么？”這個關(guān)鍵問題。如果不知道問題是什么，就試圖去解決這個問題，只能是白白的浪費時間，最終的結(jié)果也很可能毫無意義。

這個階段，必須要提出關(guān)于問題性質(zhì)、來源、目標和規(guī)模的系統(tǒng)性解釋，澄清含糊不精的地方，改正理解不正確的地方，確保用戶（客戶）與研發(fā)團隊的理解一致性。

（2）交互評審

對“交互”的評審，回答的關(guān)鍵問題是：“概括地說，應(yīng)該如何解決這個問題？”

之所以用“交互”這個詞來表述是因為只有交互才更讓人可覺察、感受針對問題的具體解決方案。

這個階段，通常會用到流程圖、原型圖、狀態(tài)圖等工具來描述整個產(chǎn)品的各種可能性，估算每一種方案的成本、效益以及體驗，充分權(quán)衡更重方案的利弊。

事實上，隱藏在交互背后是接口、數(shù)據(jù)層的復(fù)雜邏輯，這也是最容易被輕視的問題，因為它不可見。

（3）視覺評審

對視覺的評審，則是考慮如何建議規(guī)范性和一致性設(shè)計語言。

“美丑”是一個個體的主觀感受，我們往往容易陷入“太丑”的泥潭中而不能自拔。在軟件開發(fā)過程中，視覺設(shè)計需要建立一套專業(yè)的規(guī)范和機制，不能單純依賴直覺。

（4）用例評審

用例評審是針對產(chǎn)出成果設(shè)定其度量的標準，如何檢驗交付物與用戶需求的滿足程度。

這個階段的關(guān)鍵任務(wù)是寫出正確的容易理解、容易維護的場景檢測邏輯，包括各種正常和異常的數(shù)據(jù)狀態(tài)，邏輯狀態(tài)，正向和逆向的場景狀態(tài)等。研發(fā)團隊應(yīng)該在產(chǎn)品開發(fā)過程中達成對用例的覆蓋度和顆粒度的評審，而且整個過程越早越好。

同時，用例本身是動態(tài)維護的，要及時更新維護并在團隊內(nèi)達成一致。

（5）驗收發(fā)布

產(chǎn)品驗收是為了最終交付而進行的成果驗證和歸檔，包括收集項目完整的記錄，確保產(chǎn)品滿足用戶和商業(yè)需求，并將相關(guān)文檔進行歸檔，還包括項目的審計。

這個是最終的環(huán)節(jié)，它是一種集中審核的過程，它包括合同的收尾和管理的收尾，事實上也非常復(fù)雜的一個過程。一定有不少人想要控訴驗收環(huán)節(jié)的血淚史，往往是以為已經(jīng)干完了“該干的事情”，結(jié)果不是新增需求，就是沒有達成合同目標，根本就不可能驗收。

產(chǎn)品開發(fā)過程的每一個階段，都存在著重大風(fēng)險，PM們一定要有清醒的認識，也要努力在項目管理的專業(yè)領(lǐng)域上有所建樹。

不管是2B還是2C的項目，不管是內(nèi)部項目還是外包項目，不管你的組織采用何種開發(fā)模式，必須牢牢監(jiān)控產(chǎn)品開發(fā)過程的關(guān)鍵節(jié)點和關(guān)鍵交付成果。

需求評審，是針對目前已收集的來自各個渠道的想法、意見、需求和建議等，通過恰當(dāng)?shù)墓ぞ哌M行匯總、梳理、分析和排序后，所最終得出的當(dāng)下或未來需要完成的產(chǎn)品工作。

輸入

新產(chǎn)品或產(chǎn)品迭代過程中的需求來源渠道，通常包括用戶、競爭對手、供應(yīng)商、銷售終端。也包括上一個迭代有計劃遺留或者臨時被裁剪的問題、功能，以及bug。

另外還有一個重要的渠道，就是產(chǎn)品本身驅(qū)動的新的設(shè)計理念，新的技術(shù)框架。

產(chǎn)品經(jīng)理應(yīng)該建立一個便于維護的需求池，及時收集和處理來自多個渠道的“需求”。

評審

需求評審階段通常都有產(chǎn)品經(jīng)理或項目經(jīng)理發(fā)起，主要是針對”可行性“評審，確保團隊在某一個時期內(nèi)有能力完成具體的需求，而不是提出不切實際的行動方案。

整個過程用到的工具包括需求池、KANO模型、四象限法則、交集分析法、思維導(dǎo)圖、泳道圖、原型圖、里程碑。

輸出

需求評審最終輸出包括4個文檔：

1. 更新的產(chǎn)品需求池：需求評審后必須更新產(chǎn)品的需求池清單，有些需求會被拒絕，有的需求會被納入迭代計劃，有的需求會調(diào)整優(yōu)先級，產(chǎn)品經(jīng)理必須確保維護了一個完整清晰的需求列表。

2. 用戶故事板：用場景故事的方式管理用戶需求，有助于激發(fā)團隊的創(chuàng)造力，從而找到更優(yōu)的解決方案。

3. 業(yè)務(wù)流程框架：在低保真階段，產(chǎn)品經(jīng)理需要快速的呈現(xiàn)問題的解決方案，不要過早的的陷入細節(jié)性問題，而應(yīng)該嘗試尋找更多的解決方案。

4、產(chǎn)品迭代路徑：任何一次需求的評審，都可能對產(chǎn)品的迭代路徑發(fā)送改變，要及時在團隊中同步產(chǎn)品路徑的更新，它設(shè)計從市場到品牌、到運營到售后的全過程。

需求評審，是定義問題的過程，交互評審則是針對問題的具體解，強調(diào)是針對明確問題的產(chǎn)品功能性實現(xiàn)。經(jīng)過產(chǎn)品功能的交互評審后，我們已經(jīng)正式進入這一迭代過程的開發(fā)階段。

我們更為常見的做法是兩個評審點結(jié)合在一起，這并沒有苛刻的區(qū)分標志，但兩個階段有本質(zhì)的差異。

輸入

1. 用戶故事板：清晰的用戶場景可幫助團隊還原真實的場景，從而反思產(chǎn)品的解決方案，提升產(chǎn)品體驗。

2. 流程圖：包括業(yè)務(wù)流程、數(shù)據(jù)邏輯和狀態(tài)轉(zhuǎn)換關(guān)系。

3. 產(chǎn)品PRD：PRD文檔不要過于在意“四種寫法茴香”，原型+備注的方式的效率非常高，如果你需要一份模板，可以在這篇文章里面找到：徹底拋棄WORD！教你用Axure快速輸出高質(zhì)量的PRD。

4. 迭代路徑：要及時在團隊中同步產(chǎn)品路徑的更新。

評審

交互的評審，是針對解決方案的完整性檢查，包括場景、邏輯、用戶、內(nèi)容的完整性，也包括交互的閉環(huán)體驗檢查。

同時，在這個應(yīng)該，還需要分解完整的工作任務(wù)，評估整個迭代過程的資源需要和進度可行性。

事實上，進度的評估在需求階段就已經(jīng)開始，之所以需要反復(fù)評審是基于需求變更和解決方案優(yōu)化的考慮。

輸出

1、產(chǎn)品PRD：經(jīng)過評審的PRD，仍然可能存在細節(jié)性的補充和完善，產(chǎn)品經(jīng)理有責(zé)任維護一份完整清晰的在線PRD。

2、版本里程碑：團隊應(yīng)當(dāng)用”PBS“的思路取代”WBS“，明確各項任務(wù)具體的資源復(fù)盤和時間節(jié)點。

3、產(chǎn)品需求池：任何階段的評審，都可能帶來新的問題和需求，它們可能來自團隊本身的創(chuàng)造力，有助于提升團隊的使命感和責(zé)任心，有些情況下，由評審而帶來的需求可能極大的改善產(chǎn)品。

視覺和交互應(yīng)該分開兩個不同的階段考慮，有助于團隊專注解決具體的問題。

輸入

見交互評審的”PRD“。

評審

視覺設(shè)計的評審，更容易陷入主觀直覺判斷，”太丑“是最容易想到的詞匯，它往往取決于第一感官感受，而往往忽略實際用戶的使用場景。

所以，在視覺設(shè)計過程中更需要明確產(chǎn)品的調(diào)性，如何建立一致性和規(guī)范性的設(shè)計思路，這更多取決于設(shè)計師本身的技能和美學(xué)素養(yǎng)。

輸出

視覺設(shè)計可能帶來迭代進度的影響，特別是復(fù)雜的動畫設(shè)計往往需要更多的研發(fā)資源和時間，產(chǎn)品經(jīng)理需要考慮資源和時間的投入產(chǎn)出比。

在某些情況下，過于復(fù)雜的設(shè)計容易得不償失。

要使最終用戶對產(chǎn)品感到滿意，最有力的舉措就是對最終用戶的期望加以明確闡述，以便對這些期望進行核實并確認其有效性。

測試用例反映了要核實的需求。然而事實上，我們通常都難以確保核實所有的需求（測試用例可能無法覆蓋全部的需求范圍），如何找到對關(guān)鍵性的需求關(guān)系到項目的成敗。

測試的深度和廣度，都對項目產(chǎn)生影響，隨著測試用例數(shù)量的增加，團隊對產(chǎn)品質(zhì)量和測試流程也就越有信心。這把雙刃劍的另外一面是，意味這需要投入更多的資源和時間，測試工作量與測試用例的數(shù)量成比例。

輸入

見交互評審的PRD、視覺文檔。

評審

1. 業(yè)務(wù)層：包括本次迭代過程中所涉及的全部場景、流程、數(shù)據(jù)、內(nèi)容的完整以及異常情況的處理，相比于正向流程的用例，逆向流程的測試往往更為關(guān)鍵。

業(yè)務(wù)層的測試覆蓋度是產(chǎn)品的核心，直接決定產(chǎn)品是否滿足用戶的需求。

2. 交互層：主要針對產(chǎn)品操作體驗的測試，包括文案引導(dǎo)、操作跳轉(zhuǎn)、導(dǎo)航布局等等，交互層是體驗的核心。

3. 視覺層：用例通常只能檢測完整性，這個環(huán)節(jié)更考驗設(shè)計師而不是測試員。

輸出

1. 測試用例：用例是評估測試結(jié)果的度量基準和分析缺陷的標準，編寫測試用例應(yīng)有規(guī)范的文檔模板，且應(yīng)當(dāng)符合團隊的規(guī)范要求。測試工程師必須基于用例在產(chǎn)品驗收階段輸出完整的測試報告。

作為產(chǎn)品迭代的珍貴文檔，測試用例需要更新完善，要及時發(fā)現(xiàn)和補充用例編寫的不全面，盡可能的減少漏測的可能性。

然而，現(xiàn)實中的情況是測試用例常常被忽視，甚至被隨意丟棄。

2. 版本里程碑：測試用例的評審極可能帶來里程碑的變更，用例本身不僅僅是對交付成果的測試，實際上也是產(chǎn)品設(shè)計的檢測，用例編寫和評審的階段就應(yīng)該盡可能的發(fā)現(xiàn)設(shè)計本身的缺陷和漏洞，而不是只能對交付物。

產(chǎn)品驗收是核查項目計劃規(guī)定范圍內(nèi)各項工作或活動是否已經(jīng)全部完成，可交付成果是否令人滿意，并將核查結(jié)果記錄在驗收文件中的一系列活動。

輸入

見”評審的PRD“、”評審的視覺文檔“、”評審的測試用例“。

評審

產(chǎn)品的驗收需要通過多次完成，從debug版本到beta版在到release版是一個復(fù)雜的過程。

產(chǎn)品經(jīng)理必須主導(dǎo)整個完成，從產(chǎn)品的功能到交互的體驗，以及視覺都必須細致進行評審，這個階段應(yīng)當(dāng)組織開發(fā)、設(shè)計、測試對bug影響的范圍、嚴重程度進行多輪評估，并給出具體的解決和改善方案。

輸出

驗收發(fā)布階段的最重要文檔包括3份：

1. 版本更新日志：闡述具體的功能更新。

2. 更新的產(chǎn)品需求池：產(chǎn)品經(jīng)理必須重視對問題和bug的處理措施，在評估和平衡資源、進度和質(zhì)量以后，在團隊內(nèi)部同步更新產(chǎn)品需求清單，確保對遺留的問題有清晰的備案和計劃措施，而不是試圖掩蓋可能存在的問題。

3. 迭代總結(jié)：對本次迭代做一個小結(jié)，即可凝聚團隊，也是提升團隊技能水平的措施。

對軟件產(chǎn)品開發(fā)過程的管理，是對整個過程“完成了什么，如何完成的，結(jié)果如何成功，是好還是壞”的系統(tǒng)性描述，整個領(lǐng)域有很多的理論體系幫助我們優(yōu)化和改善我們的工作，但軟件開發(fā)在某種程度上存在一些重大的挑戰(zhàn)，從而使其變得與眾不同。

這個過程需要不斷的迭代和完善，不要幻想有一種方法可以一蹴而就打造一個“理想國”，而是隨機應(yīng)變，審時度勢，慢慢的規(guī)范、調(diào)整，使之符合現(xiàn)實的各種制約條件——你所在組織的資源、策略和文化。

產(chǎn)品經(jīng)理在面對不同的產(chǎn)品，不同的組織下，需要充分考慮到環(huán)境的特殊性，過程管理的方法隨之千差萬別，在有些時候還存在大量的偶發(fā)性事件，你需要時刻準備適應(yīng)由于未知和不確定的原因所帶來的額外工作。

不同的組織，甚至有完全不同的產(chǎn)品成功的定義標準，是按時并在預(yù)算內(nèi)完成算是成功嗎？未必如此?；蛟S是客戶滿意度？對你個人而言，如何把手上的項目達成目標，確保這個項目給企業(yè)帶來的效益比花費多，就是一種成功。

#專欄作家#

杜松，公眾號：產(chǎn)品微言，人人都是產(chǎn)品經(jīng)理專欄作家。專注于人工智能方向，擅長產(chǎn)品規(guī)劃和架構(gòu)設(shè)計。

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

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