8個步驟,一次完整的產品迭代

15天0基礎極速入門數據分析,掌握一套數據分析流程和方法,學完就能寫一份數據報告!了解一下>>

產品經理作為產品/功能的第一負責人,要操盤產品的整個生命周期維護,項目中也要擔任多個角色。日常產品迭代都要經歷哪些過程?本文作者對迭代過程進行了梳理,供大家一起學習和參考。

產品迭代流程圖:

一、需求管理

1. 需求獲取

需求獲取也稱為需求收集,該過程,產品經理要面對各種角色(需求方)提的形形色色的需求,需求質量也參差不齊,一般來源于以下渠道:

  1. 自己挖掘的需求;
  2. BOSS、合作商、甲方;
  3. 團隊成員:產品、運營、測試、開發等;
  4. 用戶反?。篈pp商城用戶評論、貼吧、百度知道、知乎用戶評論、產品自帶的用戶反饋、問卷調查、用戶訪談等。

雖然有的需求本身可能有問題或者是不合理的,作為產品經理要以一顆平常心、換位思考、嚴謹態度對待需求方,切忌直接懟回去需求!

遇到需求,無論咋樣,都不要過于激動或發脾氣,收集需求是產品的正常工作,以一顆平常心對待需求方,以后遇到的需求還會很多,不值得動不動就激動或者發脾氣;

需求方既然提出了這樣的需求,說明也是在使用中遇到的問題,產品要學會站在對方的角度思考問題,如果是你,你會不會遇到這樣的問題,學會體諒對方,如果是不合理需求,要耐心給需求方講清楚原委,讓對方也理解你,而不是上來就評估需求不合理;

真心對待每個需求方,要對自己說的話負責,如果一時無法評估需求是否合理,一定要先自己思考,謹言慎行;如果有不確定性,一定不要立馬回絕或者立馬回復確定接受這個需求,避免謹慎評估后出現與之前結論不一致的情況。

所以,一般建議接受需求方的需求,自己獨立思考評估后,給出需求方答復,盡量不要簡簡單單思考后就拒絕或答應,避免為后期挖坑。

2. 需求管理

從收集到需求,產品就已接入需求的全生命周期管理,需求管理會貫穿產品經理的職業生涯。有的需求是有價值確定要實現的,有的需求因為無價值或不合理而被pass掉的。

  • 對于有價值的需求,會繼續跟進全生命周期管理,包括產品定義、原型/交互設計、技術評審、研發、測試、上線;
  • 對于無價值或者不合理的需求,就會駁回,需求的生命就此終止。

3. 需求分析

面對各種需求方提出的形形色色的需求,不是所有需求都要去設計開發的,因為不是所有的需求都是有價值的需求,產品經理要做的就是要判斷需求的真偽,這就是產品經理要掌握的需求分析的技能。

  • 要駁回與產品定位相違背的需求;
  • 要過濾不合理或者小眾場景的需求;

以上需求都可以稱之為“偽需求”,識別偽需求是個長期培養的能力,對于產品新人或者剛入職的產品,在自己獨立思考需求后,多與老員工或者熟悉這個??櫚耐鹿低?,這是一種很好的學習方式,并且會學到很多其它知識。

過濾偽需求后,基本剩下都是有價值的需求,有價值就要立馬去做嗎?當然不是,開發資源有限,先做哪些需求后做哪些需求要有明確先后順序,即產品要給需求排優先級,常見的需求優先級確定標準有:

  1. 需求帶來的收益;
  2. 需求的用戶數量;
  3. 需求的使用頻率;

需求的收益越高,當然優先級就越高;需求的使用人數/用戶數量越多,需求的優先級就越高;需求的使用頻率越高,需求的優先級就越高。

4. 競品分析

當你確定要做某個需求時,不是直接就埋頭開搞了,而是要做競品調研,需求的解決方案會有很多種,自己想得不一定是最好的,也不一定是最適合自己產品的。

  • 選擇行業內類似3-5款產品;
  • 分析針對該痛點,競品是如何解決問題的,可以從用戶群體-使用場景-用戶痛點-解決方法角度思考分析;
  • 對比發現競品是如何做的,思考其背后的邏輯,自己的產品能否能借鑒競品的功能,或者有自己獨特的解決方案。

其實,調研競品,是為了避免“井底之蛙”的局面。

  • 避免自己一個人埋頭設計出問題,取長補短;
  • 提升設計效率,如行業已有很成熟的解決方案,為啥自己還要埋頭苦想呢,可以借鑒呀;
  • 培養敏銳的需求分析能力,解決方案切中要害,避免為以后挖坑。

二、產品/功能定義

需求確定要做了,就進入了產品設計階段,該階段要完成產品/功能的定義,即要完成功能設計,輸出的關鍵產物有業務流程圖、原型圖、PRD(產品需求文檔)。

1. 業務流程圖

業務流程圖是表示業務需求在系統各個??榧淞髯耐夾?,有用戶、信息的流向,以及有異常情況的處理。

通過業務流程圖能清晰了解功能會涉及哪些???、角色,以及詳細的輸入、輸出、任務等。后續將會針對如何畫業務流程圖專門講解,本文將不再贅述。

2. 原型圖

產品原型圖是將需求轉化成產品的一個過程示意圖,通過原型來表達需求點和流程邏輯,同時向UI和技術去表達產品的概念和實現的內容。

產品原型圖常用Axure、墨刀、Skerch繪畫。個人推薦使用Axure,簡單易懂,產品主要通過原型圖表達清楚頁面元素、頁面邏輯,以最簡單的形式表達即可。

強調一下,原型圖只是表達想法的工具,能讓設計、開發易懂就好,不必要做得有多炫酷、多么逼真,炫酷的設計成本高,但是投入產出比不一定高。

3. PRD

產品需求文檔是產品經理日常工作中最重要的輸出內容,PRD的質量直接決定了需求質量及后續人員的工作效率。

設計、研發、測試的工作均要以PRD為準,PRD漏洞百出和書寫不清晰,會導致需求評審效率低下,后續設計、研發、測試會頻繁和你確認細節及邏輯,更嚴重的是因為產品考慮不清楚,導致功能出現故障。所以PRD最重要的是清楚、全面的表達功能細節及邏輯。

PRD整體要遵循“由淺入深,由粗到細”的原則。

  1. 要介紹清楚需求背景、需求收益等,讓設計、研發、測試先清楚簡單的背景信息,要讓他們覺得這個需求是有價值的,有做的必要;
  2. 要介紹清楚需求目標,即要完成這個需求,需要做哪些關鍵事項,給研發總覽需求涉及的功能???功能點;
  3. 業務流程及原型,圖形化展示功能點及邏輯,相比大段文字,圖形化展示更容易讓研發讀懂“要做什么”;
  4. 功能詳述,針對業務流程所涉及的各個??橄晗感鶚齬δ芟附?,細化到文案字體大小。

以上四個???,整體由淺入深,一環套一環,讓設計、研發、測試輕松讀懂你的PRD。

三、交互/視覺設計

產品/功能定義完成后,要將PRD提交給交互設計師、視覺設計師,由設計師完成交互設計及視覺設計,最終會將PRD、交互設計稿、視覺設計稿統一提交給研發,由研發完成整個功能的開發工作。

交互設計師專注于界面的布局以及業務邏輯流程設計,現在多把app動效的設計也歸于交互設計師做,目的是為了更好的了解用戶心理為用戶服務,讓整個產品流程體驗順暢舒適。

視覺設計比較單純,主要會和交互設計合作共同設計界面,用色彩和樣式來滿足用戶的視覺需求和情感需求。

四、技術評審

在設計師完成交互及視覺設計后,就到了需求交付給研發的時候了,產品要將PRD、交互設計稿、視覺設計稿統一提交給研發。

交付之前,要由產品牽頭組織需求評審,邀請設計、研發、測試參與評審,產品給大家演示講解交互、視覺以及詳細的功能介紹,中間任何同事有疑問均可提出,由產品回答,遇到的爭議點由產品、設計、研發、測試一起商量確定最終方案。

評審完成后,技術負責人反饋評審結果及大致開發排期。爭議點較多、問題較大的需求,可能就評審不通過了;有個別小毛病的,可能評審通過;完全沒有問題的,當然也評審通過。評審通過后,研發進入開發流程;如果沒有評審通過,產品繼續完善需求,等待下一次評審。

針對需求評審過程中的疑問點、爭議點以及各方確定的最終方案,產品都要做好記錄,評審后,產品完成PRD內容修改,注意版本的迭代及標注。

五、研發

產品/功能進入研發,產品要做好項目管理、進度把控,其中就涉及關鍵時間點的把控及跟進,要和研發、測試共同商定開發時間、提測時間、聯調時間、上線時間,針對事先確定的時間安排做好維護及跟進工作,隨時關注各方工作進度。

如果研發過程有任何問題及風險,要及時暴露,評估是否影響工作進展;如果沒有特殊情況,建議不要頻繁變動各研發時間節點。

六、測試

1. 測試用例撰寫

研發過程中,測試人員就要根據PRD、交互稿、視覺稿完成測試用例撰寫。

測試用例是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果,用于核實是否滿足某個特定軟件需求。

2. 測試用例評審

由測試人員牽頭發起,并邀請產品、設計師、研發參與,測試主導完成用例講解,過程中有任何問題,都可以提出,疑問點由各方共同商討確定最終方案。

評審完成后,測試人員要完成用例內容修改及完善,并周知各位相關人員。

3. 提測與測試

研發完成后,由研發負責人申請提測,測試人員介入。按照事先多方已達成一致的測試用例測試,過程中發現的問題要及時跟產品、研發同步,研發完成bug修復,產品要跟進bug修復;修復完成后,由測試人員繼續測試,直至沒問題為止。

4. 測試環境測試報告

測試人員完成測試后,要輸出測試報告,并周知各方人員,測試報告要體現關鍵結論、風險點、測試內容。測試報告也會作為上線申請的關鍵依據,即測試通過后,研發方可申請上線。

七、上線

1. 上線申請

由研發牽頭提出上線申請,由領導審批后方可執行上線,并周知產品、設計師、測試等相關人員。

2. 上線驗收

完成上線后,產品、設計師、測試均要參與線上測試及驗收。若完全沒有問題,則驗收通過;若發現簡單可修改的問題,由研發修改后執行二次發布;若發現有重大的業務邏輯問題,要各方確認后回退版本,即上線失敗,完成優化后,申請下次上線。

3. 生產環境測試報告

由測試人員牽頭完成,測試報告中同樣要體現關鍵結論、風險點、測試內容。測試報告作為判別上線是否成功的唯一依據,要及時周知各方人員。

4. 上線通知

上線成功或者失敗,均要及時通知需求方及利益相關方。

八、跟蹤數據及優化

產品/功能上線后,產品要及時關注生產數據,并做好數據分析工作。以數據為依據評估產品/功能是否達到預期效果,如果沒有達到預期效果,產品要牽頭做好復盤工作,即因為啥導致的,輸出完善的舉措和計劃,并切實執行,避免同類型的問題的出現。

總結

產品經理作為產品全生命周期的操盤者,要跟進產品迭代的全流程:需求管理、產品/功能定義、交互/視覺設計、技術評審、研發、測試、上線、跟蹤數據及優化。

產品經理在項目中擔任起需求管理、產品設計、項目管理、數據分析等多個角色,遇到問題,要及時復盤并完善任何問題環節,成為一名合格的產品經理。

 

作者:瑞陽(Rain),個人微信公眾號:產品經理的那點事兒。電商中后臺產品經理,先后負責B端營銷工具產品設計、移動分銷體系構建、派單系統產品設計及產品全生命周期管理維護。

本文由 @瑞陽(Rain)原創發布于人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基于 CC0 協議

給作者打賞,鼓勵TA抓緊創作!
評論
歡迎留言討論~!
  1. 歡迎關注作者公眾號:產品經理的那點事兒

    回復
  2. 比較完整的瀑布式產品研發流程介紹,對于新手產品經理還是很有幫助的?;叵肫鹱約焊杖胄惺?,老大帶著走完所有的流程。當時的老大說,作為產品經理,任何和產品有關的事情,都是你的事情。每一個功能的發布,自己都要完成上線前的測試和上線后的驗收。
    這里給瑞陽大佬提個小小的建議,在發布前,增加一個驗收環節。產品經理和需求方共同驗收,一來確保迭代計劃中的功能點沒有被遺漏,二來確保功能點按驗收標準完成開發。
    讓新人在入行時,就培養起一份責任心。

    回復
    1. 您提的建議非常好,這個“驗收”有所遺漏,感謝哈

      回復
  3. 希望以后多總結這種入門類文章,很受益,已關注,真心不錯

    回復
    1. 感謝支持,以后會多多輸出原創文章的哈。也歡迎關注公眾號:產品經理的那點事兒

      回復
    2. 回復
    3. 1

      回復
    4. 0

      回復
  4. 太空洞

    回復
    1. 以后會多增加案例的,感謝建議

      回復
  5. 有沒有相關示例圖啊,感謝??

    回復
    1. 可以加我微信,隨時溝通,rain2398422210

      回復
  6. 很不錯的一篇產品生命周期演說,收藏一波,作者??????

    回復
    1. 謝謝,歡迎多交流

      回復
  7. 我覺得有些問題有待商榷。需求分析過于簡單,除了運用四象法則 還要聯系用戶群體,使用場景,目的,解決了什么問題。
    產品輸出并確定后開始評審還是設計輸出并確定后開始評審
    選擇敏捷開發或瀑布流開發利用問題。

    回復
    1. 您好,很高興與您交流。1、需求分析中涉及到的用戶群體、使用場景是分析的過程,最后歸結到最直接影響優先級與是否做的 核心因素還是價值與影響面,價值有用戶價值與商業(收益)價值,影響面要看使用的人有多少、以及使用頻率。2、產品方案其實應該包含詳細的功能描述、交互/視覺設計,只不過這兩個內容一般是不同的人員負責,對于開發來說,這都是產品側的輸出內容,都確定好之后來評審(但是有的企業可能有所區別)。3、敏捷開發涉及更多的是項目經理的職責,對于大多非技術出身的產品經理來說,了解技術開發的是有限的,雖要了解參與項目管理,但主要不是產品經理能決定的。感謝溝通哈

      回復
  8. 流程非常清晰,學到了????

    回復
    1. 謝謝,歡迎關注公眾號:產品經理的那點事兒

      回復
  9. 學到了超多干貨!贊??

    回復
    1. 謝謝~

      回復
  10. 工作中沉淀的經驗總結,感謝分享

    回復
    1. 謝謝~

      回復
  11. 干貨~經驗總結,很強的實操性,感謝作者。

    回復
    1. 謝謝(*°?°)=3

      回復
  12. 感謝

    回復
  13. 好棒 新人表示感謝

    回復
    1. 謝謝~

      回復
  14. 總結的很棒!產品設計及研發全流程,一文讀懂產品經理日常需求職責及流程??

    回復
    1. 謝謝,感謝關注~

      回復
  15. 更多干貨,歡迎關注作者公眾號:產品經理的那點事兒

    回復