app項目（mù）開發-app開發流程詳解

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