不論我們是瀑布式開發(fā)還是敏捷開發(fā)，項目中都會遇到各種各樣的問題，這時候，如何解決呢？相信很多剛剛接觸產品的新人一定搜索過“產品經(jīng)理和項目管理的區(qū)別是什么”這個問題。 在很多小公司，項目經(jīng)理和產品經(jīng)理都是一個人兼任。這經(jīng)常會讓人誤以為項目經(jīng)理和產品經(jīng)理工作性質相同。同時在無形中也拉低了項目經(jīng)理和產品經(jīng)理工作的專業(yè)性，給人一種“工作難度不高，隨便一個人都能做”的錯覺。 我一開始也認為項目經(jīng)理只是把控項目進度而已，產品經(jīng)理當然能夠兼任項目經(jīng)理的工作。但真正工作后，尤其是獨立做過這么多項目之后，我發(fā)現(xiàn)產品經(jīng)理和項目經(jīng)理是完全不同的工種。而且產品經(jīng)理和項目經(jīng)理的工作都同樣具有專業(yè)性，很難簡簡單單地讓一個人兼任。 很多人認為產品經(jīng)理的工作只是畫畫原型，組織組織評審。但其實不是，產品經(jīng)理其實在整個項目流程中都是非常忙碌的。在項目前期，產品經(jīng)理需要沉下心來用戶調研、思考方案、產出各種文檔，確認好基礎方案后，需要組織各式評審，根據(jù)各方反饋來不斷完善方案。 當然這還是在時間充裕的情況下，如果時間不充裕，產品經(jīng)理的忙碌程度要加倍：
- 方案進入開發(fā)時，產品需要不斷回答開發(fā)和測試的疑問，面對意外的技術問題，還需要快速給出替代方案。
- 項目開發(fā)結束，這時候產品經(jīng)理還需要和測試一起發(fā)現(xiàn)問題。
- 項目上線了，產品經(jīng)理還需要在現(xiàn)（熬）場（夜）支（陪）持（伴）。
- 通宵完了，產品經(jīng)理還不能像開發(fā)、測試一樣直接請假休息，產品經(jīng)理還需要掙扎起來做一些后續(xù)的工作，例如錄入數(shù)據(jù)、產出培訓手冊等等。
瀑布式開發(fā)和敏捷開發(fā)
比較知名的開發(fā)方式有兩種：瀑布式開發(fā)、敏捷開發(fā)。 瀑布式開發(fā)是傳統(tǒng)的、老舊的開發(fā)，它需要嚴格遵守預先計劃的需求、分析、設計、開發(fā)、測試的步驟順序進行。各個步驟的成果作為衡量進度的方法，例如衡量產品需求的成果是產品經(jīng)理的PRD，衡量分析的成果是開發(fā)和設計的分析文檔，衡量開發(fā)的成果當然就是開發(fā)團隊的開發(fā)進度等等。 瀑布式開發(fā)是遵循既定步驟的，嚴格定義了各開發(fā)階段的輸入和輸出。同時在項目過程中，注重文檔的展示和留存。不管是產品還是開發(fā)測試，各個階段都有相應的文檔留存，這樣對于需求有跡可循。 但是在實際情況中，現(xiàn)在很多公司對產品的采用快速迭代的方法，遵循《精益創(chuàng)業(yè)》中提到的MVP原則：開發(fā)團隊通過提供最小化可行產品獲取用戶反饋，并在這個最小化可行產品上持續(xù)快速迭代，直到產品達到一個相對穩(wěn)定的階段。 那這個時候，瀑布式開發(fā)就顯得過于按部就班、流程僵化了。更為靈活的敏捷開發(fā)受到大家的歡迎。在這其中，最有名的Scrum敏捷開發(fā)更是被很多公司采用。敏捷開發(fā)強調靈活性，充分利用了每個開發(fā)者的優(yōu)勢，旨在調動每個人的工作熱情。
Scrum敏捷開發(fā)中有三大角色：Product Owner（產品負責人）、Scrum Master（流程管理員）、Scrum Team（開發(fā)團隊）。大家根據(jù)產品需求列表進行開發(fā)，同時在整個開發(fā)過程中開展各種簡短的會議，了解每位成員前一天的工作以及遇到的問題。通過這種細小結構的會議和管理，實現(xiàn)對整個項目進度的管控。Scrum敏捷開發(fā)更靈活，更強調每位成員對項目的參與和了解。
瀑布式開發(fā)只需要項目經(jīng)理對整個項目流程進行把控，而敏捷開發(fā)則是產品負責人、流程管理員、開發(fā)負責人形成“三足鼎立”的形式，對整個項目進行把控。
產品經(jīng)理在項目中遇到的問題
在項目開發(fā)過程中，和開發(fā)、測試的合作過程中，產品經(jīng)理很容易會遇到一些問題。這個時候需要產品經(jīng)理根據(jù)實際情況，及時調整溝通流程。問題1：開發(fā)人員不會認真看PRD
在項目開發(fā)中，會有一些開發(fā)不認真看PRD，對方案和細節(jié)都不了解。這會導致在開發(fā)過程中，開發(fā)、測試頻頻找產品經(jīng)理確認需求。這不僅會讓產品人員焦頭爛額，同時還會影響整個開發(fā)效率和開發(fā)質量。 開發(fā)們不認真看PRD的原因有很多，一個是個人習慣的原因，喜歡先憑著感覺寫，到時候測試側出問題再改；還有一個是在評審時，不管是PRD評審還是技術評審，這種大會形式，很難讓開發(fā)有效地去研讀PRD、熟悉功能。 在這種項目經(jīng)理無法把控到的“空白模塊”，產品經(jīng)理可以小結構地去優(yōu)化流程。在評審前，產品經(jīng)理應該把PRD提前把PRD發(fā)出來，讓開發(fā)和測試有時間對PRD進行研讀和分析，這樣在評審時，就能將一些重要問題提前暴露出來。 在項目經(jīng)理組織的評審會議完成后，產品經(jīng)理應該找到對應模塊的開發(fā)、測試人員，牽頭組織一次小型會議，向開發(fā)、測試更詳細地講解PRD上的功能以及業(yè)務邏輯。 這個時候由于會議人數(shù)少，且都是具體人員，這時候大家就可以把各自的疑問和PRD上的問題提出來，產品收集反饋，后續(xù)盡快完善PRD。問題2：產品、開發(fā)、測試消息不協(xié)同
在開發(fā)過程中，經(jīng)常會出現(xiàn)這樣的情況：測試找到產品反映一個問題，產品給測試解答后，產品再去告訴開發(fā)，確定了后再告訴測試。反之如果開發(fā)有問題，產品也需要去不斷地通知測試。 在這個消息傳達的過程中，產品經(jīng)理在很大程度上是一個“傳話筒”。這樣不僅極大地分散了產品經(jīng)理的精力，同時還會讓其他人誤以為產品就是傳話的，削弱產品經(jīng)理的專業(yè)性。 遇到小問題時，可以簡單地通知一聲。但是稍復雜的問題，在傳達時很容易出現(xiàn)信息失誤。所以在討論問題時，應該把相關的開發(fā)、測試湊在一起，共同討論問題現(xiàn)狀和解決方案。在這個過程中，產品可以了解開發(fā)的技術難度，開發(fā)也可以知曉產品的方案思考。 這樣的話，減少了產品傳話的概率，提高了消息協(xié)同的效率。 當然，在開發(fā)時，任何改動的需求都應該在確定后發(fā)在項目群里，通知所有項目成員。問題3：如何讓產品以外的人了解方案
Scrum敏捷開發(fā)中，產品負責人在Product Backlog（產品需求池）中，需要描述好User Story。 我認為產品在向開發(fā)、測試講解需求、功能時，需要善用User Story，讓開發(fā)、測試有代入感地去認同這個需求的合理性。尤其是SaaS產品的需求，開發(fā)、測試自身不是用戶，對用戶也不了解，很難理解用戶的想法和需求。這個時候需要產品向他們描述用戶故事，讓他們更了解這個方案的設計思路。 例如：開發(fā)問我為什么小程序中管家的新增帶看功能可以補錄以前的新增帶看，這個補錄的意義在哪里，忘了提交帶看就忘記了，反正帶看也不計入業(yè)務。 我當時告訴他：如果租客在看房后對這套房子不感興趣，那不補錄帶看任務確實沒什么問題，對整個系統(tǒng)沒什么影響。但是如果租客看完房子后，想要簽約這個房子。目前簽約的前提條件是有帶看記錄。那這個時候這個補錄帶看的任務就是必要的。所以補錄帶看這個任務的口子是要留著的。在面對一些不符合常規(guī)認識的功能，產品經(jīng)理在描述時，需要給出具體的、存在的場景。這樣聽的人就很容易理解這個功能的設計。
總結
其實產品經(jīng)理在項目中做的項目管理，都是為了讓開發(fā)、測試能夠快速、準確地了解需求和改動。主要的項目管理工作，當然還是項目經(jīng)理來主持，產品經(jīng)理只是輔助項目經(jīng)理，填補項目中關于產品的管理空白。 當然，這些建議也不一定是完全正確的，畢竟管理這件事需要根據(jù)不同的人來進行調整。產品經(jīng)理應該在實際項目中，根據(jù)開發(fā)、測試人員的具體情況，去實行不同的管理方法。 這就需要產品經(jīng)理在一次一次的項目中不斷地發(fā)現(xiàn)問題、總結問題、想出改善方案、實施方案、不斷改進，最終形成自己的流程和做事方法。愛盈利-運營小咖秀(www.jza6.com) 始終堅持研究分享移動互聯(lián)網(wǎng)App運營推廣經(jīng)驗、策略、全案、渠道等純干貨知識內容；是廣大App運營從業(yè)者的知識啟蒙、成長指導、進階學習的集聚平臺；
想了解更多移動互聯(lián)網(wǎng)干貨知識，請關注微信公眾號運營小咖秀（ID: yunyingshow）
【轉載說明】 若上述素材出現(xiàn)侵權，請及時聯(lián)系我們刪除及進行處理：[email protected]
