不論我們是瀑布式開發(fā)還是敏捷開發(fā)，項目中都會遇到各種各樣的問題，這時候，如何解決呢？

相信很多剛剛接觸產(chǎn)品的新人一定搜索過“產(chǎn)品經(jīng)理和項目管理的區(qū)別是什么”這個問題。

在很多小公司，項目經(jīng)理和產(chǎn)品經(jīng)理都是一個人兼任。這經(jīng)常會讓人誤以為項目經(jīng)理和產(chǎn)品經(jīng)理工作性質(zhì)相同。同時在無形中也拉低了項目經(jīng)理和產(chǎn)品經(jīng)理工作的專業(yè)性，給人一種“工作難度不高，隨便一個人都能做”的錯覺。

我一開始也認為項目經(jīng)理只是把控項目進度而已，產(chǎn)品經(jīng)理當(dāng)然能夠兼任項目經(jīng)理的工作。但真正工作后，尤其是獨立做過這么多項目之后，我發(fā)現(xiàn)產(chǎn)品經(jīng)理和項目經(jīng)理是完全不同的工種。而且產(chǎn)品經(jīng)理和項目經(jīng)理的工作都同樣具有專業(yè)性，很難簡簡單單地讓一個人兼任。

很多人認為產(chǎn)品經(jīng)理的工作只是畫畫原型，組織組織評審。但其實不是，產(chǎn)品經(jīng)理其實在整個項目流程中都是非常忙碌的。在項目前期，產(chǎn)品經(jīng)理需要沉下心來用戶調(diào)研、思考方案、產(chǎn)出各種文檔，確認好基礎(chǔ)方案后，需要組織各式評審，根據(jù)各方反饋來不斷完善方案。

當(dāng)然這還是在時間充裕的情況下，如果時間不充裕，產(chǎn)品經(jīng)理的忙碌程度要加倍：

• 方案進入開發(fā)時，產(chǎn)品需要不斷回答開發(fā)和測試的疑問，面對意外的技術(shù)問題，還需要快速給出替代方案。
• 項目開發(fā)結(jié)束，這時候產(chǎn)品經(jīng)理還需要和測試一起發(fā)現(xiàn)問題。
• 項目上線了，產(chǎn)品經(jīng)理還需要在現(xiàn)（熬）場（夜）支（陪）持（伴）。
• 通宵完了，產(chǎn)品經(jīng)理還不能像開發(fā)、測試一樣直接請假休息，產(chǎn)品經(jīng)理還需要掙扎起來做一些后續(xù)的工作，例如錄入數(shù)據(jù)、產(chǎn)出培訓(xùn)手冊等等。

上述說了那么多，主要是想說明產(chǎn)品經(jīng)理在整個項目過程中是非常忙碌的。產(chǎn)品工作已經(jīng)讓產(chǎn)品經(jīng)理焦頭爛額了，更不要說在整個項目過程中還需要騰出精力來控制項目進度、協(xié)調(diào)項目成員溝通等工作。如果產(chǎn)品經(jīng)理兼任項目經(jīng)理工作，勢必會分散自己工作的精力。所以我認為產(chǎn)品經(jīng)理和項目經(jīng)理的人員應(yīng)該分開來，各司其職，讓項目更好更快地上線。

但是這不意味著產(chǎn)品經(jīng)理不需要了解或者負責(zé)項目管理的相關(guān)工作。項目經(jīng)理大多同時會負責(zé)多個項目，他只能把控項目的大致進度。而在項目過程中，項目的一些項目經(jīng)理負責(zé)不到的時段“空白時段”，需要產(chǎn)品經(jīng)理介入，幫助開發(fā)、測試快速有效地解決問題。

項目經(jīng)理在項目管理中，所管理的角色有產(chǎn)品、開發(fā)、測試、運維等等全部角色。與項目經(jīng)理把控全局不同，產(chǎn)品經(jīng)理在項目中的管理方向，更偏向于對產(chǎn)品和開發(fā)、測試合作過程中的自我管理和產(chǎn)品方向的把控。

瀑布式開發(fā)和敏捷開發(fā)

比較知名的開發(fā)方式有兩種：瀑布式開發(fā)、敏捷開發(fā)。

瀑布式開發(fā)是傳統(tǒng)的、老舊的開發(fā)，它需要嚴(yán)格遵守預(yù)先計劃的需求、分析、設(shè)計、開發(fā)、測試的步驟順序進行。各個步驟的成果作為衡量進度的方法，例如衡量產(chǎn)品需求的成果是產(chǎn)品經(jīng)理的PRD，衡量分析的成果是開發(fā)和設(shè)計的分析文檔，衡量開發(fā)的成果當(dāng)然就是開發(fā)團隊的開發(fā)進度等等。

瀑布式開發(fā)是遵循既定步驟的，嚴(yán)格定義了各開發(fā)階段的輸入和輸出。同時在項目過程中，注重文檔的展示和留存。不管是產(chǎn)品還是開發(fā)測試，各個階段都有相應(yīng)的文檔留存，這樣對于需求有跡可循。

但是在實際情況中，現(xiàn)在很多公司對產(chǎn)品的采用快速迭代的方法，遵循《精益創(chuàng)業(yè)》中提到的MVP原則：開發(fā)團隊通過提供最小化可行產(chǎn)品獲取用戶反饋，并在這個最小化可行產(chǎn)品上持續(xù)快速迭代，直到產(chǎn)品達到一個相對穩(wěn)定的階段。

那這個時候，瀑布式開發(fā)就顯得過于按部就班、流程僵化了。更為靈活的敏捷開發(fā)受到大家的歡迎。在這其中，最有名的Scrum敏捷開發(fā)更是被很多公司采用。敏捷開發(fā)強調(diào)靈活性，充分利用了每個開發(fā)者的優(yōu)勢，旨在調(diào)動每個人的工作熱情。

Scrum敏捷開發(fā)中有三大角色：Product Owner（產(chǎn)品負責(zé)人）、Scrum Master（流程管理員）、Scrum Team（開發(fā)團隊）。大家根據(jù)產(chǎn)品需求列表進行開發(fā)，同時在整個開發(fā)過程中開展各種簡短的會議，了解每位成員前一天的工作以及遇到的問題。通過這種細小結(jié)構(gòu)的會議和管理，實現(xiàn)對整個項目進度的管控。Scrum敏捷開發(fā)更靈活，更強調(diào)每位成員對項目的參與和了解。

瀑布式開發(fā)只需要項目經(jīng)理對整個項目流程進行把控，而敏捷開發(fā)則是產(chǎn)品負責(zé)人、流程管理員、開發(fā)負責(zé)人形成“三足鼎立”的形式，對整個項目進行把控。

產(chǎn)品經(jīng)理在項目中遇到的問題

在項目開發(fā)過程中，和開發(fā)、測試的合作過程中，產(chǎn)品經(jīng)理很容易會遇到一些問題。這個時候需要產(chǎn)品經(jīng)理根據(jù)實際情況，及時調(diào)整溝通流程。

問題1：開發(fā)人員不會認真看PRD

在項目開發(fā)中，會有一些開發(fā)不認真看PRD，對方案和細節(jié)都不了解。這會導(dǎo)致在開發(fā)過程中，開發(fā)、測試頻頻找產(chǎn)品經(jīng)理確認需求。這不僅會讓產(chǎn)品人員焦頭爛額，同時還會影響整個開發(fā)效率和開發(fā)質(zhì)量。

開發(fā)們不認真看PRD的原因有很多，一個是個人習(xí)慣的原因，喜歡先憑著感覺寫，到時候測試側(cè)出問題再改；還有一個是在評審時，不管是PRD評審還是技術(shù)評審，這種大會形式，很難讓開發(fā)有效地去研讀PRD、熟悉功能。

在這種項目經(jīng)理無法把控到的“空白模塊”，產(chǎn)品經(jīng)理可以小結(jié)構(gòu)地去優(yōu)化流程。在評審前，產(chǎn)品經(jīng)理應(yīng)該把PRD提前把PRD發(fā)出來，讓開發(fā)和測試有時間對PRD進行研讀和分析，這樣在評審時，就能將一些重要問題提前暴露出來。

在項目經(jīng)理組織的評審會議完成后，產(chǎn)品經(jīng)理應(yīng)該找到對應(yīng)模塊的開發(fā)、測試人員，牽頭組織一次小型會議，向開發(fā)、測試更詳細地講解PRD上的功能以及業(yè)務(wù)邏輯。

這個時候由于會議人數(shù)少，且都是具體人員，這時候大家就可以把各自的疑問和PRD上的問題提出來，產(chǎn)品收集反饋，后續(xù)盡快完善PRD。

問題2：產(chǎn)品、開發(fā)、測試消息不協(xié)同

在開發(fā)過程中，經(jīng)常會出現(xiàn)這樣的情況：測試找到產(chǎn)品反映一個問題，產(chǎn)品給測試解答后，產(chǎn)品再去告訴開發(fā)，確定了后再告訴測試。反之如果開發(fā)有問題，產(chǎn)品也需要去不斷地通知測試。

在這個消息傳達的過程中，產(chǎn)品經(jīng)理在很大程度上是一個“傳話筒”。這樣不僅極大地分散了產(chǎn)品經(jīng)理的精力，同時還會讓其他人誤以為產(chǎn)品就是傳話的，削弱產(chǎn)品經(jīng)理的專業(yè)性。

遇到小問題時，可以簡單地通知一聲。但是稍復(fù)雜的問題，在傳達時很容易出現(xiàn)信息失誤。所以在討論問題時，應(yīng)該把相關(guān)的開發(fā)、測試湊在一起，共同討論問題現(xiàn)狀和解決方案。在這個過程中，產(chǎn)品可以了解開發(fā)的技術(shù)難度，開發(fā)也可以知曉產(chǎn)品的方案思考。

這樣的話，減少了產(chǎn)品傳話的概率，提高了消息協(xié)同的效率。

當(dāng)然，在開發(fā)時，任何改動的需求都應(yīng)該在確定后發(fā)在項目群里，通知所有項目成員。

問題3：如何讓產(chǎn)品以外的人了解方案

Scrum敏捷開發(fā)中，產(chǎn)品負責(zé)人在Product Backlog（產(chǎn)品需求池）中，需要描述好User Story。

我認為產(chǎn)品在向開發(fā)、測試講解需求、功能時，需要善用User Story，讓開發(fā)、測試有代入感地去認同這個需求的合理性。尤其是SaaS產(chǎn)品的需求，開發(fā)、測試自身不是用戶，對用戶也不了解，很難理解用戶的想法和需求。這個時候需要產(chǎn)品向他們描述用戶故事，讓他們更了解這個方案的設(shè)計思路。

例如：

開發(fā)問我為什么小程序中管家的新增帶看功能可以補錄以前的新增帶看，這個補錄的意義在哪里，忘了提交帶看就忘記了，反正帶看也不計入業(yè)務(wù)。

我當(dāng)時告訴他：如果租客在看房后對這套房子不感興趣，那不補錄帶看任務(wù)確實沒什么問題，對整個系統(tǒng)沒什么影響。但是如果租客看完房子后，想要簽約這個房子。目前簽約的前提條件是有帶看記錄。那這個時候這個補錄帶看的任務(wù)就是必要的。所以補錄帶看這個任務(wù)的口子是要留著的。

在面對一些不符合常規(guī)認識的功能，產(chǎn)品經(jīng)理在描述時，需要給出具體的、存在的場景。這樣聽的人就很容易理解這個功能的設(shè)計。

總結(jié)

其實產(chǎn)品經(jīng)理在項目中做的項目管理，都是為了讓開發(fā)、測試能夠快速、準(zhǔn)確地了解需求和改動。主要的項目管理工作，當(dāng)然還是項目經(jīng)理來主持，產(chǎn)品經(jīng)理只是輔助項目經(jīng)理，填補項目中關(guān)于產(chǎn)品的管理空白。

當(dāng)然，這些建議也不一定是完全正確的，畢竟管理這件事需要根據(jù)不同的人來進行調(diào)整。產(chǎn)品經(jīng)理應(yīng)該在實際項目中，根據(jù)開發(fā)、測試人員的具體情況，去實行不同的管理方法。

這就需要產(chǎn)品經(jīng)理在一次一次的項目中不斷地發(fā)現(xiàn)問題、總結(jié)問題、想出改善方案、實施方案、不斷改進，最終形成自己的流程和做事方法。

#專欄作家#

異彩，微信公眾號：一只蝸牛慢慢跑，人人都是產(chǎn)品經(jīng)理專欄作家。從事房產(chǎn)管理系統(tǒng)的產(chǎn)品工作，關(guān)注To C產(chǎn)品的交互設(shè)計、運營、結(jié)構(gòu)設(shè)計和商業(yè)模式。在成為一名優(yōu)秀的產(chǎn)品人的路上努力前行。

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

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