app項目開發(fā)-app開發(fā)流程詳解

產品以解決用戶核心問題為目的。這里的一個關鍵詞，用戶核心問題。可以理解為需求，雖然兩者有區(qū)別，但是這樣畫上一個≈號，沒什么不妥。我們遇到了產品迭代為數(shù)不多步需求的為數(shù)不多個階段
1：項目需求
app項目開發(fā)之需求獲取
獲取需求的方式，也就是需求的來源：
1:商業(yè)需求-來自于商業(yè)化團隊，或者老板、合作商，外包團隊多見于甲方；
2:用戶反饋-來自于各大應用商店的用戶評論或應用自帶的用戶反饋，也可以是客服團隊的用戶反饋，問卷調查等；
3:團隊其他部門-來自包括但不限于測試、運營、開發(fā)、產品等團隊；
4:自身挖掘-產品線負責人體驗自身產品、對比競品、數(shù)據分析來得出的需求點。
身為產品經理在這個階段要做什么？簡單的收集和整理，就足夠了。
app項目開發(fā)之需求分析
顧名思義，不是所有的需求都是真正的需求，這就需要產品經理掌握需求分析的技能。首先是篩選，講一些明顯與產品定位背離的需求過濾。還有一部分需要過濾的需求，即不合理的需求或小眾化場景的需求。綜上可以統(tǒng)稱為偽需求，如何辨別真?zhèn)涡枨笫且粋€永恒的話題，作為一個初出茅廬的產品經理，以理解自己的產品為基礎，若不能很好的判斷。個人建議請教前輩，或了解這個產品的人，領導、同事，都是你可以咨詢請教的對象，但是也要注意方式，不是拿著一堆需求，聽他講，哪些哪些是偽需求。一定是你先進行嘗試，然后再拿有疑問的去請教。不恥下問，才能進步，這也是一種學習的方式，而且是很好的學習方式。為數(shù)不多步篩選過后，剩下的基本就是真需求了，我們已經完成了“做還是不做這個問題，這時候又會面臨一個問題“什么時候做，網上有許多具體的方法，比如四象限分析法，kano原型等等，這里就不一一贅述了，還是那句話，作為一個初入產品的年輕人，要學會不恥下問，不要指望一下子就會把一件事做的很好。
app項目開發(fā)之需求管理
學會如何管理好需求，對產品經理接下去的產品迭代有很大的幫助。創(chuàng)建一個自己的需求池，并保持不斷更新，從中發(fā)現(xiàn)產品迭代的方向。這里貼一個自己的產品需求池，放不了太多，大家諒解一下。表內包括了需求的收集和整理，也包括了需求的分析，還有需求的狀態(tài)和時間等記錄。
2:app項目開發(fā)之競品分析
當你從得到下個版本的需求以后，身為產品經理的你需要做什么。當然是對需要的功能進行設計規(guī)劃啦，這時就少不了做競品分析。注意，初入門的產品經理，一般都會被分配到一個小功能的優(yōu)化和迭代，所以像產品培訓班的對整個產品做所謂的深入分析，一般沒什么X用，很少見有應屆生或剛轉行的產品能負責從0-1的，況且從0-1，也不需要如此大費周折的長篇大論。
那么在真實工作中，我們需要的一份正確做法的競品分析，應該是什么樣的呢？
1:明確競品分析的目的；解決一個實際的問題，比如要做購物車的商品分享功能，想看看同行都怎么做？
2:選擇好競品分析的對象選擇細分行業(yè)的前二/三即可；比如對于淘寶公司來說：天貓，京東，就是不錯的選擇；
3:對比目標狀態(tài)的截屏，放到一起；橫向放置不同產品同一功能的截屏，縱向放置當前功能頁面的不同狀態(tài)；
4:在頁面合適的位置可以使截屏右側敘述優(yōu)缺點，和自己的思考與總結；
5:通過對比分析，得出自己的觀點，我們應該怎么搞？
3:app項目開發(fā)之原型
原型是產品經理很關鍵的一個輸出物，個人不推薦用墨刀或者mockplus等原型工具，還是喜歡用axure，當然更推薦有條件的同學使用sketch。我想講述的并不是如何使用這些工具，我想講述的，是一個產品新人，如何去產出原型。流程來到這里，你已經做足了功課，完成了競品分析，now，就是把需求落地的為數(shù)不多步，產出一個demo，也就是原型設計稿。這里引申出兩個問題：
你是否已經完美的完成了競品分析，明確需求的規(guī)劃和設計？是否已經決定參照哪一款競品或者已經有了自己的規(guī)劃和設計？
有自信鑒定的回答是好事，但是往往事與愿違。因為，經歷不足導致你還摸不透領導的想法，你還不知道需求到底想達到一個什么樣子的效果。怎么辦？如果在做競品分析的時候沒有和領導討論過。那我想較好的方法，就是參照競品，結合自己的產品，設計出多套原型稿，根據自己的思考和分析，推薦一套，并跟領導進行討論，在過程中講明各方案的優(yōu)劣。如果在競品分析時已經完成了和領導的溝通，也不要局限，至少產出兩套原型方案，再和領導溝通。如圖（比較粗糙。。突然找不到好點的了，將就下吧）：
再補充一點，許多產品經理在糾結做高保真還是低保真的問題上分歧很大，我對這個問題的看法是這樣的，在所限時間內，根據任務輕重緩急，能畫的高保真一點就高保真。我的許許多多迭代需求原型都是直接在原圖上進行修改的，效果看上去會很直接。高保真原型也有利于UI進行視覺優(yōu)化，可能有人要反駁我了，但站在UI的視角上，你給我一個很丑的原型，我連看都不想多看兩眼。能畫高保真，為什么不呢？對自己也是一種技能的提升，何樂不為。下圖貼自己的低保真，0-1的項目，任務重的情況下我也會畫低保真，但是效果上非常不會做的很差勁。
4:app項目開發(fā)之PRD文檔
prd文檔無疑是產品經理輸出內容的重中之重了，上下游交付，全靠這份文檔。這里小小diss一下pmcaff的高贊文，題目叫上下游都喜歡的XXX文檔。大概是這個名字，我看了以后很不是滋味，因為這樣的文章，包含的內容太多，任憑UI還是開發(fā)，不會有那么多時間，來看這種文檔。
prd文檔不是寫完上交，就可以了。要保持實時更新，特別是版本的需求變更等情況，要及時的記錄并更新，一是為了 不背鍋 ；二是為了等待下一位有緣人接盤的時候，需求出現(xiàn)偏差不知所措。
5:app項目開發(fā)之需求評審
APP開發(fā)公司指出在完成了原型和PRD文檔以后，需求評審就到了終于要交付的時候了。你要做到的就是告訴上下游，項目組的所有人，這個版本我們要做什么，為什么要做這個，設計是怎么樣的，預計上線時間等等。當然，這樣直接講，壓力難免有些大，而且，你怎么保證你寫的文檔沒有問題呢？so，我們來講一講需求評審的流程。
在確定方案并完成了初版的prd文檔v1.0之后，與產品線領導1對1，或產品組內部，進行需求評審。指出不足和有問題需要修改的點。大概流程就是你先講一遍，然后大家討論，自己做記錄，然后結束后抓緊時間講prd文檔進行完善。
然后的然后，在prd文檔v1.1會有專家組（boss們）對prd文檔進行專家評審，有問題則指出并修改，循環(huán)。沒問題則選良辰吉日，交付項目組其他成員（一般為設計團隊和開發(fā)團隊）。
第三輪，prd文檔v1.2，可以交付設計團隊和開發(fā)團隊了。無可避免的，會上大家會各自發(fā)表意見，會發(fā)生諸如，需求變更，需求延期等常見問題，身為產品經理的你，要記錄并整理，參與討論甚至主導討論，多站在對方的立場看待問題，并試圖說服別人 或者被別人說服 。同樣，需要快速產出prd文檔v1.3，確認無誤后，交付設計和開發(fā)團隊，進行下一階段。這里順帶提一句，如果是Axure完成文檔的小伙伴，建議在設計產出作品后，將prd文檔中的圖片進行替換，可能有人會說多此一舉或者麻煩，但是好處是顯而易見的，開發(fā)可以看得更明白更直接，問題會少很多。
至此，需求評審結束，prd文檔經過一系列的修改，完成歸檔。
6:app項目開發(fā)之對接UI & APP開發(fā)
這個話題也是產品屆經久不衰的話題了，不多做贅述，沒有什么意義。個人的意見是，在設計團隊，開發(fā)團隊，測試團隊，運營團隊，任何人在這個版本，或者你負責的某個功能上有疑問的時候，你都要及時出現(xiàn)，說明并解決問題。保證進度正常。至于如何和大家溝通，這個全憑自己，誰都教不了你，一句話：不會溝通，難以勝任產品經理。
補充一點：進入開發(fā)以后，產品經理可以就下一輪的版本迭代計劃進行籌備了，即開始接需求，然后就是循環(huán)往復了。
7:app項目開發(fā)之需求驗收
app開發(fā)公司批出：需求驗收不等同于測試，測試有專門的測試方法論和測試工具。產品的需求驗收，指的是對自己負責的功能點進行驗收，確認與設計稿是否一致，確認是否存在問題。這個流程非常重要，直接關系到了預想和實際的差距。這個階段多發(fā)的狀況，是在原先的基礎上進行優(yōu)化，這是很正常的，在不改變需求的情況下，更好的將需求落地。同樣，期間可以安排設計團隊走查，保證UI稿的正確性。同時，更新項目進度表，記錄并整理開發(fā)時間，進入測試流程。
8:app項目開發(fā)之上線跟蹤數(shù)據
一般APP上線流程：選擇一個小渠道進行灰度測試，以防不測。在確保一系列的數(shù)據正常沒有問題的情況下，再推廣到所有渠道，并開放升級。APP的一些重要數(shù)據：錯誤率、日活、新增、留存、新增事件點擊等等。一般對于新版本，關心的錯誤率和新增事件點擊。所以會做一個簡單的表格來做記錄。
完成每一輪的工作之后，都需要進行匯報，因為根據領導部門的要求，可能會要求加快項目進度或新增某些緊急需求，不要悶頭干活兩耳不聞窗外事。四通八達的產品經理，才是大家喜歡的產品經理。
以上就是app項目開發(fā)-app定制流程詳解全文，希望對大家有所幫助！