產品迭代流程以及產品要做的事
寫這篇文章的原因是，看到許多想成為產品經理的同學，特別是pmcaff南通大學的某位小同學，願意並努力去成為一名產品，通過培訓班的方式，去增加自己的產品知識，去實踐產品的工作。固然是好的，但是看到他們寫的東西以後，真的很想告訴他們，產品跟培訓班講的不是一個東西。那些長篇大論的分析文，可能會成為你的敲門磚，但是絕對不是你的金剛鑽。你會發現等你真正解除到產品工作以後，你會無從下手。分析永遠是分析，模板永遠是模板。分析不能落地，就是0，模板永遠只是個框架，走不出來就是死衚衕。抽空會不斷更新文章，目前計劃寫兩篇，其一為產品迭代流程，其二為從0-1的產品流程。
產品迭代流程：
一、需求
1、 需求獲取
2、 需求分析
3、 需求管理
二、競品分析
三、原型
四、Prd文件
五、需求評審（包括修改需求）
六、對接UI，對接開發
七、需求驗收
八、上線，跟進資料
回到正題，如何主導產品線的迭代。個人習慣，一圖流。（圖片來自lisanke的一位產品實習生），借用一下，侵刪。
sanke1.png
一、 需求
產品以解決使用者核心問題為目的。這裡的一個關鍵詞，使用者核心問題。可以理解為需求，雖然兩者有區別，但是這樣畫上一個≈號，沒什麼不妥。
我們遇到了產品迭代第一步需求的第一個階段：需求獲取
獲取需求的方式，也就是需求的來源：
1、商業需求-來自於商業化團隊，或者老闆、合作商，外包團隊多見於甲方；
2、使用者反饋-來自於各大應用商店的使用者評論或應用自帶的使用者反饋，也可以是客服團隊的使用者反饋，問卷調查等；
3、團隊其他部門-來自包括但不限於測試、運營、開發、產品等團隊；
4、自身挖掘-產品線負責人體驗自身產品、對比競品、資料分析來得出的需求點。
身為產品經理在這個階段要做什麼？簡單的收集和整理，就足夠了。
隨後是產品迭代第一步需求的第二個階段：需求分析
顧名思義，不是所有的需求都是真正的需求，這就需要產品經理掌握需求分析的技能。首先是篩選，講一些明顯與產品定位背離的需求過濾。還有一部分需要過濾的需求，即不合理的需求或小眾化場景的需求。綜上可以統稱為偽需求，如何辨別真偽需求是一個永恆的話題，作為一個初出茅廬的產品經理，以理解自己的產品為基礎，若不能很好的判斷。個人建議請教前輩，或瞭解這個產品的人，領導、同事，都是你可以諮詢請教的物件，但是也要注意方式，不是拿著一堆需求，聽他講，哪些哪些是偽需求。一定是你先進行嘗試，然後再拿有疑問的去請教。不恥下問，才能進步，這也是一種學習的方式，而且是很好的學習方式。第一步篩選過後，剩下的基本就是真需求了，我們已經完成了“做還是不做”這個問題，這時候又會面臨一個問題“什麼時候做”，網上有許多具體的方法，比如四象限分析法，kano原型等等，這裡就不一一贅述了，還是那句話，作為一個初入產品的年輕人，要學會不恥下問，不要指望一下子就會把一件事做的很好。
最後是產品迭代第一步get需求的第三個階段：需求管理
學會如何管理好需求，對產品經理接下去的產品迭代有很大的幫助。建立一個自己的需求池，並保持不斷更新，從中發現產品迭代的方向。這裡貼一個自己的產品需求池，放不了太多，大家諒解一下。表內包括了需求的收集和整理，也包括了需求的分析，還有需求的狀態和時間等記錄。
微信圖片_20180528162435.png
二、競品分析
當你從得到下個版本的需求以後，身為產品經理的你需要做什麼。當然是對需要的功能進行設計規劃啦，這時就少不了做競品分析。注意，初入門的產品經理，一般都會被分配到一個小功能的優化和迭代，所以像產品培訓班的對整個產品做所謂的深入分析，一般沒什麼X用，很少見有應屆生或剛轉行的產品能負責從0-1的，況且從0-1，也不需要如此大費周折的長篇大論。
那麼在真實工作中，我們需要的一份正確做法的競品分析，應該是什麼樣的呢？
1.明確競品分析的目的；解決一個實際的問題，比如要做購物車的商品分享功能，想看看同行都怎麼做？
2.選擇好競品分析的物件選擇細分行業的前二/三即可；比如對於淘寶公司來說：天貓，京東，就是不錯的選擇；
3.對比目標狀態的截圖，放到一起；橫向放置不同產品同一功能的截圖，縱向放置當前功能頁面的不同狀態；
4.在頁面合適的位置可以使截圖右側敘述優缺點，和自己的思考與總結；
5.通過對比分析，得出自己的觀點，我們應該怎麼搞？
同樣來自lisanke，連結在下面，有詳細的講，也有模板。
連結：https://www.zhihu.com/question/23601989/answer/317794141
三、原型
原型是產品經理很關鍵的一個輸出物，個人不推薦用墨刀或者mockplus等原型工具，還是喜歡用axure，當然更推薦有條件的同學使用sketch。我想講述的並不是如何使用這些工具，我想講述的，是一個產品新人，如何去產出原型。流程來到這裡，你已經做足了功課，完成了競品分析，now，就是把需求落地的第一步，產出一個demo，也就是原型設計稿。這裡引申出兩個問題：
你是否已經完美的完成了競品分析，明確需求的規劃和設計？
是否已經決定參照哪一款競品或者已經有了自己的規劃和設計？
有自信鑑定的回答是好事，但是往往事與願違。因為，經歷不足導致你還摸不透領導的想法，你還不知道需求到底想達到一個什麼樣子的效果。怎麼辦？如果在做競品分析的時候沒有和領導討論過。那我想最好的方法，就是參照競品，結合自己的產品，設計出多套原型稿，根據自己的思考和分析，推薦一套，並跟領導進行討論，在過程中講明各方案的優劣。如果在競品分析時已經完成了和領導的溝通，也不要侷限，至少產出兩套原型方案，再和領導溝通。如圖（比較粗糙。。突然找不到好點的了，將就下吧）：
TIM截圖20180530141127.png
再補充一點，許多產品經理在糾結做高保真還是低保真的問題上分歧很大，我對這個問題的看法是這樣的，在所限時間內，根據任務輕重緩急，能畫的高保真一點就高保真。我的許許多多迭代需求原型都是直接在原圖上進行修改的，效果看上去會很直接。高保真原型也有利於UI進行視覺優化，可能有人要反駁我了，但站在UI的視角上，你給我一個很醜的原型，我連看都不想多看兩眼。能畫高保真，為什麼不呢？對自己也是一種技能的提升，何樂不為。下圖貼自己的低保真，0-1的專案，任務重的情況下我也會畫低保真，但是效果上絕對不會做的很差勁。
TIM截圖20180530141826.png
四、PRD文件
prd文件無疑是產品經理輸出內容的重中之重了，上下游交付，全靠這份文件。這裡小小diss一下pmcaff的高贊文，題目叫上下游都喜歡的XXX文件。大概是這個名字，我看了以後很不是滋味，因為這樣的文章，包含的內容太多，任憑UI還是開發，不會有那麼多時間，來看這種文件。這裡還是貼一下lisanke老師的一則文章，侵刪。
連結：https://www.zhihu.com/question/19685255/answer/364925819
這裡貼一下前專案組小夥伴的一些文件，各有各的特色，但是無一例外，都是不錯的文件（開發挺喜歡看著，然後拿著文件罵需求啥時候改了這種）。
111.png
上圖展示的僅僅是某個功能的prd文件單頁，prd遠遠不止這些內容，下面貼一個一般prd需要的目錄，詳細的在上面lisanke老師的連結裡也有，看官們選擇性閱讀。圖如下：
1111.png
最後，prd文件不是寫完上交，就可以了。要保持實時更新，特別是版本的需求變更等情況，要及時的記錄並更新，一是為了不背鍋；二是為了等待下一位有緣人接盤的時候，需求出現偏差不知所措。
五、需求評審
在完成了原型和PRD文件以後，需求評審就到了終於要交付的時候了。你要做到的就是告訴上下游，專案組的所有人，這個版本我們要做什麼，為什麼要做這個，設計是怎麼樣的，預計上線時間等等。當然，這樣直接講，壓力難免有些大，而且，你怎麼保證你寫的文件沒有問題呢？so，我們來講一講需求評審的流程。
在確定方案並完成了初版的prd文件v1.0之後，與產品線領導1對1，或產品組內部，進行需求評審。指出不足和有問題需要修改的點。大概流程就是你先講一遍，然後大家討論，自己做記錄，然後結束後抓緊時間講prd文件進行完善。
然後的然後，在prd文件v1.1會有專家組（boss們）對prd文件進行專家評審，有問題則指出並修改，迴圈。沒問題則選良辰吉日，交付專案組其他成員（一般為設計團隊和開發團隊）。
第三輪，prd文件v1.2，可以交付設計團隊和開發團隊了。無可避免的，會上大家會各自發表意見，會發生諸如，需求變更，需求延期等常見問題，身為產品經理的你，要記錄並整理，參與討論甚至主導討論，多站在對方的立場看待問題，並試圖說服別人或者被別人說服。同樣，需要快速產出prd文件v1.3，確認無誤後，交付設計和開發團隊，進行下一階段。這裡順帶提一句，如果是Axure完成文件的小夥伴，建議在設計產出作品後，將prd文件中的圖片進行替換，可能有人會說多此一舉或者麻煩，但是好處是顯而易見的，開發可以看得更明白更直接，問題會少很多。
至此，需求評審結束，prd文件經過一系列的修改，完成歸檔。
六、對接UI，對接開發
這個話題也是產品屆經久不衰的話題了，不多做贅述，沒有什麼意義。個人的意見是，在設計團隊，開發團隊，測試團隊，運營團隊，任何人在這個版本，或者你負責的某個功能上有疑問的時候，你都要及時出現，說明並解決問題。保證進度正常。其實話語之間，都凝結為一句話，別人在加班，你也就老老實實待著吧，乖。
至於如何和大家溝通，這個全憑自己，誰都教不了你，一句話：不會溝通，難以勝任產品經理。
補充一點：進入開發以後，產品經理可以就下一輪的版本迭代計劃進行籌備了，即開始接需求，然後就是迴圈往復了。
七、需求驗收
需求驗收不等同於測試，測試有專門的測試方法論和測試工具。產品的需求驗收，指的是對自己負責的功能點進行驗收，確認與設計稿是否一致，確認是否存在問題。這個流程非常重要，直接關係到了預想和實際的差距。這個階段多發的狀況，是在原先的基礎上進行優化，這是很正常的，在不改變需求的情況下，更好的將需求落地。
同樣，期間可以安排設計團隊走查，保證UI稿的正確性。
同時，更新專案進度表，記錄並整理開發時間，進入測試流程。下圖貼一個自己的專案進度表吧，看起來更加直接一點。
TIM截圖20180531133541.png
八、上線，跟蹤資料
一般APP上線流程：選擇一個小渠道進行灰度測試，以防不測。在確保一系列的資料正常沒有問題的情況下，再推廣到所有渠道，並開放升級。
APP的一些重要資料：錯誤率、日活、新增、留存、新增事件點選等等。
一般對於新版本，最關心的錯誤率和新增事件點選。所以會做一個簡單的表格來做記錄。同樣，我們以錯誤率為例。如圖：
TIM截圖20180531134242.png
每個產品對於錯誤率的標準不同，數值僅供參考，個人接觸下來那麼多APP產品，錯誤率≤0.5%為良好。
完成每一輪的工作之後，都需要進行彙報，因為根據領導部門的要求，可能會要求加快專案進度或新增某些緊急需求，不要悶頭幹活，兩耳不聞窗外事。四通八達的產品經理，才是大家喜歡的產品經理。
最後，雖然更新完了，還是說幾句吧，不是所有人都適合做產品經理，不要被“門檻低，就業簡單，工作輕鬆，收入高”等培訓班的招生金句矇騙了。本人做過開發，做過實施，最後轉行做了產品，也算是瞭解網際網路常識，剛開始做起產品來，都感覺力不從心，什麼都做不好。比如非科班出生的應屆生或者轉行人員來說，連“SDK是什麼”“介面是什麼意思”“A/B測試是什麼”等等這些常識性問題都不瞭解，我覺得起碼你離網際網路產品經理，還有很長的路要走，離你想要的高收入，也絕對是漫漫長路。靜下心來，一步一步來，嘗試做真正產品經理的工作內容，“人人都是產品經理”，只是一個書名而已。
歡迎交流，郵箱：Pen[email protected]
關注點贊，留言任選其一你所需要的模板，我會擇日傳送於你。為什麼任選其一呢，我覺得還是自己動手做一做，比較好啦。