產品開發

產品開發趨勢!敏捷開發、瀑布式開發,產品經理如何解決問題?

【推薦原因】


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


  

瀑布式開發

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

敏捷開發

強調靈活性,充分利用了每個開發者的優勢,旨在調動每個人的工作熱情。  敏捷開發Scrum敏捷開發中有三大角色:Product Owner(產品負責人)、Scrum Master(流程管理員)、Scrum Team(開發團隊)。
大家根據產品需求列表進行開發,同時在整個開發過程中開展各種簡短的會議,了解每位成員前一天的工作以及遇到的問題。通過這種細小結構的會議和管理,實現對整個項目進度的管控。 Scrum敏捷開發更靈活,更強調每位成員對項目的參與和了解
瀑布式開發只需要項目經理對整個項目流程進行把控,而敏捷開發則是產品負責人、流程管理員、開發負責人形成「三足鼎立」的形式,對整個項目進行把控。
產品經理在項目中遇到的問題在項目開發過程中,和開發、測試的合作過程中,產品經理很容易會遇到一些問題。這個時候需要產品經理根據實際情況,及時調整溝通流程。
  
產品、開發、測試消息不協同在開發過程中,經常會出現這樣的情況:測試找到產品反應一個問題,產品給測試解答後,產品再去告訴開發,確定了後再告訴測試。反之如果開發有問題,產品也需要去不斷地通知測試。在這個消息傳達的過程中,產品經理在很大程度上是一個「傳話筒」。
這樣不僅極大地分散了產品經理的精力,同時還會讓其他人誤以為產品就是傳話的,削弱產品經理的專業性。遇到小問題時,可以簡單地通知一聲。但是稍複雜的問題,在傳達時很容易出現信息失誤。所以在討論問題時,應該把相關的開發、測試湊在一起,共同討論問題現狀和解決方案。
在這個過程中,產品可以了解開發的技術難度,開發也可以知曉產品的方案思考。這樣的話,減少了產品傳話的概率,提高了消息協同的效率。當然,在開發時,任何改動的需求都應該在確定後發在項目群裡,通知所有項目成員。
    
如何讓產品以外的人了解方案Scrum敏捷開發中,產品負責人在Product Backlog(產品需求池)中,需要描述好User Story。在開發時,任何改動的需求都應該在確定後發在項目群裡,通知我認為產品在向開發、測試講解需求、功能時,需要善用User Story,讓開發、測試有代入感地去認同這個需求的合理性。
尤其是SaaS產品的需求,開發、測試自身不是用戶,對用戶也不了解,很難理解用戶的想法和需求。這個時候需要產品向他們描述用戶故事,讓他們更了解這個方案的設計思路。
 
文章資料來源為【知乎】,經TC彙集整理,部分內容為TC創作,未經授權不得轉載。圖片來源:Pexels
編/Abby

TC Summary


常見開發方式:

  1. 瀑布式開發:遵循既定步驟的,嚴格定義了各開發階段的輸入和輸出。同時在項目過程中,注重文檔的展示和留存。不管是產品還是開發測試,各個階段都有相應的文檔留存,這樣對於需求有跡可循。
  2. 敏捷式開發:大家根據產品需求列表進行開發,同時在整個開發過程中開展各種簡短的會議,了解每位成員前一天的工作以及遇到的問題。

《延伸閱讀》


TC的IG
上會有更多相關職場成長懶人包,立即追蹤不錯過任何成長機會!

想持續接收到最精華的文章,可按這裡加入 TC Incubator的LINE@

 

Close Menu