產品開發趨勢！敏捷開發、瀑布式開發，產品經理如何解決問題？

【推薦原因】

不論我們是瀑布式開發還是敏捷開發，項目中都會遇到各種各樣的問題，這時候，如何解決呢？很多人認為產品經理的工作只是畫畫原型，組織組織評審。但其實不是，產品經理其實在整個項目流程中都是非常忙碌的。
在項目前期，產品經理需要沉下心來用戶調研、思考方案、產出各種文檔，確認好基礎方案後，需要組織各式評審，根據各方反饋來不斷完善方案。今天介紹比較知名的兩種開發方式:瀑布式開發、敏捷開發。

瀑布式開發

瀑布式開發是傳統的、老舊的開發，它需要嚴格遵守預先計劃的需求、分析、設計、開發、測試的步驟順序進行。各個步驟的成果作為衡量進度的方法，例如衡量產品需求的成果是產品經理的PRD，衡量分析的成果是開發和設計的分析文檔，衡量開發的成果當然就是開發團隊的開發進度等等。
瀑布式開發是遵循既定步驟的，嚴格定義了各開發階段的輸入和輸出。同時在項目過程中，注重文檔的展示和留存。不管是產品還是開發測試，各個階段都有相應的文檔留存，這樣對於需求有跡可循。
但是在實際情況中，現在很多公司對產品的採用快速迭代的方法，遵循《精益創業》中提到的MVP原則：開發團隊通過提供最小化可行產品獲取用戶反饋，並在這個最小化可行產品上持續快速迭代，直到產品達到一個相對穩定的階段。
那這個時候，瀑布式開發就顯得過於按部就班、流程僵化了。更為靈活的敏捷開發受到大家的歡迎。在這其中，最有名的Scrum敏捷開發更是被很多公司採用。

敏捷開發

強調靈活性，充分利用了每個開發者的優勢，旨在調動每個人的工作熱情。敏捷開發Scrum敏捷開發中有三大角色：Product Owner（產品負責人）、Scrum Master（流程管理員）、Scrum Team（開發團隊）。
大家根據產品需求列表進行開發，同時在整個開發過程中開展各種簡短的會議，了解每位成員前一天的工作以及遇到的問題。通過這種細小結構的會議和管理，實現對整個項目進度的管控。 Scrum敏捷開發更靈活，更強調每位成員對項目的參與和了解。
瀑布式開發只需要項目經理對整個項目流程進行把控，而敏捷開發則是產品負責人、流程管理員、開發負責人形成「三足鼎立」的形式，對整個項目進行把控。
產品經理在項目中遇到的問題在項目開發過程中，和開發、測試的合作過程中，產品經理很容易會遇到一些問題。這個時候需要產品經理根據實際情況，及時調整溝通流程。

產品、開發、測試消息不協同在開發過程中，經常會出現這樣的情況：測試找到產品反應一個問題，產品給測試解答後，產品再去告訴開發，確定了後再告訴測試。反之如果開發有問題，產品也需要去不斷地通知測試。在這個消息傳達的過程中，產品經理在很大程度上是一個「傳話筒」。
這樣不僅極大地分散了產品經理的精力，同時還會讓其他人誤以為產品就是傳話的，削弱產品經理的專業性。遇到小問題時，可以簡單地通知一聲。但是稍複雜的問題，在傳達時很容易出現信息失誤。所以在討論問題時，應該把相關的開發、測試湊在一起，共同討論問題現狀和解決方案。
在這個過程中，產品可以了解開發的技術難度，開發也可以知曉產品的方案思考。這樣的話，減少了產品傳話的概率，提高了消息協同的效率。當然，在開發時，任何改動的需求都應該在確定後發在項目群裡，通知所有項目成員。

如何讓產品以外的人了解方案Scrum敏捷開發中，產品負責人在Product Backlog（產品需求池）中，需要描述好User Story。在開發時，任何改動的需求都應該在確定後發在項目群裡，通知我認為產品在向開發、測試講解需求、功能時，需要善用User Story，讓開發、測試有代入感地去認同這個需求的合理性。
尤其是SaaS產品的需求，開發、測試自身不是用戶，對用戶也不了解，很難理解用戶的想法和需求。這個時候需要產品向他們描述用戶故事，讓他們更了解這個方案的設計思路。

文章資料來源為【知乎】，經TC彙集整理，部分內容為TC創作，未經授權不得轉載。圖片來源:Pexels
編/Abby