亚洲精品无码AV中文字幕,久久精品人妻综合AV,AV区无码字幕中文色

搜索

APP

起點課堂會員權益

職業體系課特權

線下行業大會特權

個人IP打造特權

30+門專項技能課

1300+專題課程

12場職場軟技能直播

12場求職輔導直播

12場專業技能直播

會員專屬社群

榮耀標識

發布

注冊 | 登錄

這4個產品新人寫PRD、競品分析容易遇到的問題，你能解決嗎？

起點課堂學習聯盟

2018-11-23

0 評論 12497 瀏覽 45 收藏

16 分鐘

《10天掌握產品經理必備7大文檔》是起點學院發起的幫助產品新人快速掌握產品崗相關文檔撰寫方法及規范的10日學習計劃。

在往期的學習中，同學們圍繞PRD、產品體驗報告等產品經理日常工作常用文檔相關的細節與導師進行了探討，里面的大部分，在產品新人剛剛開始接觸各類文檔撰寫的過程中，都常會遇到。我們從中精選了4個問答，分享給你，希望對你有所啟發。

第12期學習計劃將于11月26日開課，限時6.6折。點擊右側鏈接即可了解詳情>http://996.pm/MQjDW

一、PRD文檔如何維護？

【疑問】日常工作中PRD文檔是只維護一個文檔，還是一個版本維護一個文檔？

【解答】如果是一次版本的PRD肯定得獨立一個文檔，因為每個版本的開發內容都會不同，不可以把它覆蓋掉。

如果同一個版本的PRD，有可能會發生需求變更，需求升級之類的。這樣的話就可以在一個文檔里面去迭代你的PRD。所以不可能一概而論。同一版迭代的PRD是可以覆蓋掉的，主要看團隊的習慣。

涉及到文檔，如果能把歷史版本都保留當然是好事。但是多個版本需要對他們分別管理，避免研發人員對照的版本不是最新版本。管理歷史版本有個坑！所以傳遞一定要及時。

二、文檔相關的工作機制是如何進行的？

【疑問】學完課程后還有幾個問題，主要想了解文檔相關的工作機制：

一是關于文檔的完備性。

除了課程中的7種文檔外，還有沒有比較重要、有待學習的文檔？特別是7種文檔之間似有斷點：體驗報告、競品分析關乎認知，另外5種文檔用于執行，認知和執行之間應該還有“決策”，即了解市場和用戶、明確產品定位之后，拍板上馬哪些需求、拒絕哪些需求，決策環節是否也產生一些文檔？（比如：用戶研究、可行性研究、會議紀要等？）

二是關于文檔的效力，也關系到決策機制。

比如：PRD定下的需求，是否要通過更高層的批準才生效？領導能否任意改動需求？如果領導提的需求與產品定位相悖，或者被用戶研究結果否定，產品經理能否（以及如何）拒絕？項目進行中向領導匯報頻率有多高，一般用什么形式匯報（郵件、交互草圖還是別的）？

【解答】我們先來談談產品經理之于文檔以及這個課程的作用。

首先，產品經理之于文檔相當于獵人之于弓箭，農夫之于農具，本質上是工具問題。我們去經營一個職業則會有“魂、道、術、器”四個層級的經營心法。您的問題當中我隱約可感覺到以“器”“行道”，“馭術”的設想，有欠妥之處。

再談談本次課程的目的，主要是想通過幾類產品經理經常要面臨的場景，去講解一些文檔，希望大家認知，熟用。

談完這些看似虛無縹緲的理論，我再試著來回答你具體的問題：

【問題1】還有沒有其他文檔

答案：有的，比如：BRD、MRD、交互文檔、用戶體驗地圖、調查問卷、用戶訪談文檔，甚至會議記錄等等，數不勝數。但是有許多文檔，類似BRD、MRD對于新手PM來說使用場景較少，交互文檔之類的，在很多中小團隊都沒獨立出來，而是直接將交互需求融入到PRD。

【問題2】“認知”與“執行”斷點問題

答案：不存在您所說的“斷點”，因為“決策”的過程，通常是在“腦暴”、“討論”、“分析”、“驗證”的過程，而這些過程更注重結果，就是到底聽誰的。很少說，明明得出結論了，還非要拿出一個很標準的決策過程的文檔來。這樣違背互聯網短平快的方法論。除非是特別重大的決策，需要多級匯報，這樣的話，你就寫個PPT吧，沒有標準的論證文檔。

【問題3】拒絕哪些需求的問題

答案：這個問題，其實是一個需求管理的一個延伸。就是需求收集-需求排序-需求設計-需求開發，類似這樣的過程。排序和PK需要整個團隊參與，經過協商，PK，妥協等過程才會最終出來結果。所以這個仍然是一個過程量，不建議再去輸出什么文檔。而是所有團隊對價值的判斷（商業價值，開發成本，時間成本等）

【問題4】文檔的效力問題

答案：當需求已經到達“PRD”的時候，它一定已經是通過了大家的認可，需要進入開發階段了。而所謂的“審批”肯定是在此之前。有可能會涉及到需求變更，那也是在大家討論認可的情況下，去變更，去更新文檔版本，周知各部門。

【問題5】如何拒絕領導需求

答案：沒有標準答案，國際難題?？茨愕臏贤芰?，看你自己的反省能力，看你的說服能力。

這里提供一個大概的流程：

發現領導的需求不靠譜的時候，首先先自我反省一下，它真的不靠譜嗎？萬一我自己錯了呢？領導可能站在更高更遠的角度去審視產品，而產品經理經常會被所謂的“用戶體驗”耽誤了。
自己去論證，最好有明確的數據支持，再去下結論，說領導的需求不靠譜。
前兩步都過了，想辦法說服領導，需要技巧，溝通技巧，需求情商。
如果領導昏庸，最好的做法，聯合其他部門，看技術或運營能不能用一些緩兵之計，做一些表面上迎合領導，卻不傷害用戶的折中方案。再有就是冷處理，不建議和領導直接沖突。

【問題6】用什么形式匯報

答案：不限定，能達到匯報目的（比如只是讓領導指定進度說明你在干活，或者需要申請資源）就可以?；蛘吒鶕I導喜好（有些領導就喜歡PPT，有些領導喜好口頭匯報）

總而言之，明白了產品過程的“魂，道，術，器”，不要混淆過程，不要只依賴工具，不要認死理，才能成長。

三、維護需求池時如何拆需求顆粒

【疑問】拆分需求顆粒應該根據什么原則？

【解答】在說“原則”之前，咱們先聊聊為什么需要把細化顆粒度大的需求。

原因有三：

第一，需求池具有“記錄”屬性。有時候在臨時接到一個籠統的需求，需要迅速記錄下來，沒時間寫細，需要先記錄下來。而這種需求的“籠統性”你無法預測。有時候可以很大，大到追加一個大的模塊，一個大的體系。
第二，需求池具備“協作”屬性，不同PM之間需要通過需求池傳遞信息，太籠統的需求傳遞信息一定會有問題。
第三，需求池具備“跟進”屬性，哪些需求什么進度了，哪些需求需要安排畫原型畫UI等等。

了解了需求池的這些屬性之后，你就應該知道在細化的時候需要注意哪些原則了：

先界定哪些需要有必要去拆解，就是籠統的，影響你去完整記錄，影響你去協作，影響你去跟進的。
每條需求具備功能的獨立性，比如類似“增加積分體系”這類需求。你必須寫清楚，“積分獲取方式”“積分消耗方式”“積分政策”等待。
統一的需求屬性，比如有點需求需要畫原型，有的不需要。你不能把“優化個人中心的布局”和“優化個人中心加載速度”這樣的需求合并成“優化個人中心”。

四、產品體驗報告里的競品分析怎么寫？

【疑問】請問產品體驗報告里面的競品分析需要寫的很詳細么？如果不需要，我們主要對比競品的哪些點就夠了呢？

我在做產品體驗報告的時候，就市場現狀分析模塊，競品分析模塊的時候，就忍不住去看很多競品，然后不自覺的去區分，他們的定位、市場份額、下載量、交互風格、主要亮點等等，然后查著查著，感覺思維就被發散了。

【解答】產品體驗報告也是有不同使用場景的，不同的場景有不同的目的性，側重點。

當你在寫這份體驗的目的性包含有對競品的洞察的時候，你可以針對競品多做一些分析，這樣也是有必要的。因為產品體驗報告的核心主角是“當前產品本身”，而競品分析的核心主角是“當前產品的競品”。

所以你就算是寫了很多競品的東西，最終也建議你要回歸到“當前產品”來，比如根據當前產品的競品發展情況，推敲出“當前產品”需要在策略上做哪些改進。

總而言之，在產品體驗報告中去做競品分析，目的是為了服務于對當前產品的理解和建議。這樣你就不會亂了。

第12期《10天掌握產品經理必備7大文檔》將于11月26日開課，除了我們熟知的產品體驗報告、競品分析、PRD外，還教你需求池相關文檔、項目排期表、項目郵件等產品經理常用、卻少有相關學習資料的文檔的撰寫方法。

不僅幫你快速提升產品工作相關的文檔撰寫能力，更幫你規范化日常文檔，提升工作效率。

限時6.6折。點擊右側鏈接即可了解詳情>http://996.pm/MQjDW