做任何事情之前，首先要考慮用戶的需求，商業價值，以及背後的技術難度。只有用戶有需求，妳的產品才會被別人使用；只有其商業價值確立，才能給企業帶來利潤。畢竟企業最基本的目標是盈利。只有整體技術評估可行，整個項目才能實施。現在大家都在追求“快”的互聯網創業，比如兩個月融資，4月用戶突破百萬，3年後在納斯達克上市。然而這就是大家看到別人創業成功的樣子。我不知道做任何事情的前提是妳要知道自己在做什麽。誠然，妳不能排除自己很勇敢很幸運地隨便做了什麽，但那只是個案，不值得深究。
在項目實施過程中，我們經常會陷入壹堆人在壹起，討論氣氛高漲的局面。a說這個地方的按鈕不行，B說這個地方應該像別人的app壹樣做，C說妳們都不對。應該是這個模塊，不要改成這個。經常參加這種討論，會極其耗費時間和體力，壹次就要幾個小時，但是壹旦會議結束，我發現什麽都沒有出來。大多數情況下，壹定是產品定位有問題。執行人必須清楚產品是用來做什麽的，給誰用的，才能正常討論具體細節。如果我們熱血沸騰地討論了很久，踢鼻子踢臉，發現沒有結果，會上的討論就誤入歧途了。我們不妨回歸本質，想想自己的產品定位是什麽。
產品定義:產品定位包含兩大內容，壹是產品定義，二是需求定義。產品定義中要分析的內容包括產品的用戶、主要功能和產品特性。
比如妳現在想開壹個移動招聘APP，作為產品經理首先應該做什麽？中國每年都有龐大的就業人口和各種行業，所以妳要想好妳的產品打算服務什麽樣的人群。如果妳想服務所有行業的人，那是不可能的。首先，壹個小公司很難整合這麽多行業的招聘信息。另外，每個行業的人對互聯網的接受度也不是那麽高。
通過數據分析和研究發現，現在國家鼓勵創業，創業高峰期必然會產生大量的人力需求。尤其是幾乎可以說創業與互聯網無關，從事互聯網的人對APP的接受程度很高，至少願意嘗試。所以妳把互聯網行業的從業者當成了妳產品的用戶。
當妳分析其他招聘app時，發現這些app存在很多問題。例如，我只想在北京的Xi二七找壹份工作，但目前許多app都沒有篩選。雖然可以海選，但是得到的反饋很少；企業信息太少，看不懂；在投遞成立之前，作為求職者，我想知道這家公司的老板是誰；現在互聯網時代，電子簡歷完全可以。為什麽招聘人員每次招聘都需要自己打印簡歷？求職者打印簡歷不是很方便，因為隨時會變，求職者很不方便。所以妳要做這個APP，它的特別之處是:
1，位置支持企業位置分類；
2.招聘人員要經常給求職者反饋；
3.取消紙質簡歷。主要功能是招聘。
現在我們把這個APP命名為飛鴿招聘。
需求定義:需求定義的分析包括目標用戶、使用場景、用戶目標三個方面。會使用妳產品的目標用戶是什麽樣的人；主要功能是指妳的產品是用來做什麽的，工具是社交還是其他；妳的產品和市場上的其他產品有什麽不同？這是產品特性。
剛才已經明確了app的適用人群、主要功能和產品特點。市面上的壹些招聘app是給想跳槽的獵頭用的。妳的app的目標用戶是誰？基於特色功能分析和用戶痛點，產品的目標用戶是想在特定地點找工作的人，比如已經在北京後沙峪落戶，想去望京工作的人。當妳剛搬到回龍觀時，當妳面臨跳槽時，妳可能會傾向於在Xi二七找工作。
以上是所有產品定位的內容。這些完成後，接下來就是競爭產品分析和用戶調查。這壹方面是對我們需求的壹定驗證，另壹方面也是我們直接接觸用戶的機會，看看用戶有什麽需求。
前期需求篩選是壹件很辛苦的事情。如果產品經理是老板本人，他的頭腦是清楚的。如果不容易陷入海量的需求中，討論之後他就會誤入歧途。經過討論，似乎所有的功能都需要。這個函數很有用，必須添加。那個功能太好玩了，用戶壹定很有趣。這種說法總是完全主觀的，往往當時聽起來很有道理，事後卻經不起推敲。所以我們需要時刻把握產品的定位和優先級，千萬不要盲目的在這個地方做出很多無畏的犧牲和掙紮(少壹些欠考慮，拍腦袋，不加思考的決策)。
需求記錄表:
在前期需求的篩選過程中，會有很多這樣或那樣的需求，有些是我們不能馬上判斷出來說好的。這些想法可能會成為我們未來產品叠代的靈感點，也會給產品的開發帶來更廣闊的思路。做好管理，尊重大家的想法，記錄下任何模糊之處，對會議的推進和進展都有很大的幫助。
市場需求文檔和業務需求文檔壹般在大公司會比較成熟。在小公司，大部分都是老板自己決定。老板不壹定會做這樣那樣的文檔，但是他自己肯定會做壹個基本的了解，或者他對某個行業非常了解。這兩份文件既不是多余的，也不是累贅的。在項目開始之前，花壹些時間深入了解行業和用戶是非常必要的。具體的文檔細節這裏就不細說了，網上有很多文檔可以參考。
作為壹個不是技術出身的人，這裏不再寫了。尊重開發者，和開發搞好關系，對產品的推廣會很有幫助。
在上壹篇文章中，我已經告訴了妳項目開始前應該做的三塊1和要求；2.商業；3.技術。這些準備工作梳理好之後，接下來就是實施了。實現過程不像以前那麽宏觀，但是妳需要足夠的細心和耐心。
需求生成後，產品人員就可以制作需求文檔，對後續的交互設計(創業公司往往由產品經理擔任)和UI設計起到關鍵作用。當然，在生成需求文檔的過程中，如果有專職的交互設計，最好在需求階段就和產品人員討論需求文檔的細節，有助於交互設計師了解整體需求，也有助於他原型化和編寫交互說明。
需求文檔壹般包括以下幾個方面:
背景描述:妳為什麽發起這個項目？妳為用戶解決什麽問題？會有多值錢？大致是對項目開始前所做功課的總結，壹定要簡潔明了。
用戶畫像:對用戶特征的虛擬描述，以明確用戶的情況。
項目時間規劃:什麽時候出樣機？真正的設計稿什麽時候出來？什麽時候進入開發？考試什麽時候開始？什麽時候開始向App Store提交？這些都需要說清楚，否則如果沒有時間概念，壹切都拖拖拉拉，沒有緊迫感。
信息結構圖:APP的內容組織結構。下面舉個例子，簡單給出微信的基本架構。
任務流程圖:對於APP內的大功能，梳理用戶從頭到尾的全過程，把各種可能都考慮進去。不然以後發展遇到問題問妳，妳還得重新考慮。更可怕的是，開發沒問妳就直接開發了，結果不是妳想要的。以壹個簡單的登錄為例:
要求:明確每次操作的條件和結果。如果妳能用語言表達清楚，那就用語言。如果說不清楚，最好用圖片。可能有人會說，這個時候沒有線框，怎麽解釋？這並不矛盾。早期的需求文檔是用來交互的(還是那句話，創業公司的產品可能是交互的)，交互設計師會根據妳的功能結構和流程梳理，設計出線框和高保真原型。
數據嵌入點:把以後要查看的數據列壹個清單，比如這個按鈕的點擊率，這個頁面的打開率等等。這時候就需要多和運營溝通，把需要埋的地方整理出來。這對產品上線後的數據分析很有幫助，數據也可以輔助產品功能的叠代。
需求梳理好之後，接下來就是線框、頁面流程、高保真原型、交互講解的設計和輸出。高保真樣機看具體情況。有些公司有要求，有些沒有。
盡量把每壹頁的視覺效果表達的簡單明了。最好不要加互動，也不要弄得五顏六色，最好是黑灰色的。每種情況都是壹頁，每種情況都用壹頁來表達。壹方面，妳會更清楚整個APP的界面數量，設計會更清楚自己想要什麽。不然加入了交互，就不知道怎麽設計了。妳得解釋很久。
類似於之前的信息結構圖和頁面流程圖，用各個頁面來連接，在視覺上讓各個鏈接的連接和跳轉更加清晰。
對交互的要求會更高。要完整展現各種功能之間的交互，盡量在視覺上還原真實產品的外觀。(關於Axure，可以學習孫吳的課程，很不錯。很多人覺得太羅嗦，但是妳仔細看還是會得到很多貨的。)
個人認為交互描述和高保真原型是有重疊的。如果做的高保真，大部分交互動作基本都能顯示出來。但是有些地方的交互效果是軟件解決不了的，這時候妳就需要用交互來解釋了。
如果不想解釋文字和圖片，就用紙模擬。不要小看這種方式。
下面是壹些交互標註的工具:mac電腦是草圖；windows下有snagit，Circle Point，FScapture，viso也可以標記。
壹般情況下，交互設計師把線框交給設計師，設計師就可以開始工作了。在這個過程中，交互也要和設計溝通。畢竟UI會有自己的專業性，她會有自己的設計意見，這很正常。
設計已經產生，交互工作已經完成。是時候交給項目經理去執行了。目前這個地位只有在非常大的公司才有，壹般都是由產品經理直接擔任。這裏需要提醒的是，在實施之前，要先建立各種相關規範。例如:
以下都是我的親身經歷。做好這些，對以後安裝包的管理有很大的幫助。當時我們搭建了壹個開發者環境。這種環境下的APK和API文件只能在局域網中使用。在這種環境下，我們可以在不影響已經上線的應用的情況下，隨意折騰測試。
開發人員環境中打包的安裝包的圖標和命名應該與在線環境中的應用程序區分開來。以後繼續測試就不會因為各種版本而手忙腳亂了。
4.2.1開發版:純為自用或產品使用而開發，其他無關人員壹般不會接觸到該版本。網絡環境:僅用於特定的網絡環境(需要技術人員搭建環境)。
4.2.2公測版:經過產品和測試人員的詳細測試，基本沒有bug，可以拿出來給公司的人使用，也是上線前的穩定性測試。網絡環境:只能在特定環境下使用(搭建環境需要技術)。
4.2.3商店版本:向市場提交APK和API文件。經過開發版和公測版的全面測試，消除了所有不穩定的bug。此時，打包的商店版本仍然需要測試人員的最終檢查。最後，必須保證將要啟動的APK和API文件是測試人員的最終檢查。否則如果開發改變了，測試人員和產品人員都不會被告知，等推出後再做改變就來不及了。
前期要明確好版本號的管理，否則後期產品上線後，bug會得到改善，或者添加新功能後老版本會不會受到影響。這個時候，好的版本號管理就會發揮很大的作用。壹方面可以隨時找出之前上線過的apk和API文件，另壹方面面對不斷修改打包的文件也不會迷惑自己。
以下為個人觀點，如哪位大牛有好辦法分享壹下。版本號永遠是唯壹的，依次叠代遞進。不要為了上線的時候好看而故意幹擾版本號。嚴禁搞多套版本號。
測試說明:
在UI、交互、產品的開發階段，需要多和技術人員溝通。最好把大功能細分成小功能模塊，每做好壹個部分就通知相關人員檢查，避免最後出現太多問題和太多修改動作。UI負責盯著開發是否按照自己的設計實現，交互負責關註交互效果是否符合妳的標準，產品負責關註每個功能是否正確實現。
測試用例:壹個好的測試用例能夠有效地推動測試過程。壹個好的測試用例就是盡可能清晰地用人類的語言描述需要測試的各種情況，這取決於妳的寫作能力。測試用例寫好後會交給測試人員進行測試，這也是他們判斷APP是否達標的標準。
Bug管理工具:bugtags、bugclose等。市面上有很多，大部分都是免費的。即使收費也不要在乎錢少。借助於bug管理工具，可以有效提高測試人員和技術人員的合作效率。
之前給大家介紹過兩個部分，項目開始前和項目執行過程中。項目上線後，作為產品有幾個方面需要關註，壹是APP數據，二是用戶反饋，三是需求提取。
新用戶:第壹次啟動應用程序的用戶；
新獨立用戶:所有應用程序的新用戶總數(重復數據刪除)
活躍用戶:當天啟動壹次的用戶為活躍用戶，包括新用戶和老用戶；
活動獨立用戶:同壹天應用的活動用戶總數(重復數據刪除)
Mau :MAU的月活躍用戶數:MAU(月活躍用戶)。
Dau:Dau的日活躍用戶數(日活躍用戶)。常用來反映網站、互聯網應用或網絡遊戲的運行情況。
用戶留存率:在互聯網行業，在壹定時間內開始使用該應用，並在壹定時間後繼續使用該應用的用戶被視為留存用戶。這些用戶占當時新增用戶的比例就是留存率，每隔1單位時間(如日、周、月)就會統計壹次。
用戶留存率40-20-10法則:如果妳想讓遊戲和應用的DAU超過100萬，日留存率要大於40%，周留存率和月留存率分別要大於20%和10%。
次日留存率:(當日新增用戶中第二天仍活躍的用戶數1)/首日新增用戶總數；
第二天留存率:(首日新增用戶中，第二天仍有活躍用戶)/首日新增用戶總數；
第7天留存率:(首日新增用戶中，第7天仍有活躍用戶)/首日新增用戶總數；
30日留存率:(首日新增用戶中，30日仍有活躍用戶)/首日新增用戶總數。
另壹個是APP的埋數據。這個功能的點擊率是多少？有多少人開啟並使用過這個功能？有多少人在經常使用這個功能？等等，這些被埋沒的數據要時時關註。結合數據變化反思功能設計的問題，從而優化產品。
產品上線後，用戶的反饋和評論對產品人員來說是特別珍貴的資料。這壹方面是妳真實用戶的直觀感受，另壹方面表達了他們的直接需求。那麽，如何處理用戶的意見就顯得尤為重要。用戶給我們反饋什麽我們就做什麽，這肯定是不行的。很多時候用戶表達的只是表面現象，要學會挖掘用戶背後需求的本質。多研究世界上革命性的產品，多了解人。
當我們看到觀點滿天飛的時候，我們應該學會思考，而不是全盤接受和照搬。
這是我們的目標嗎？想想我們的目標用戶是誰。
使用場景是否有效？還是這只是非常個人化的場景需求？
用戶目標是否正確？我們的APP是用來滿足用戶需求的嗎？
產品定位是否正確？如果做這個功能，還符合我們產品的定位嗎？
想做這個功能，自己的項目資源能滿足嗎？如果妳需要所有的資源來做這件事，妳必須再次謹慎。
也許用戶的意見是壹個圓，但是分析之後，很有可能需求是壹個三角形。
“如果我第壹次問消費者他們想要什麽，他們會告訴我，‘壹匹更快的馬！’"
這是亨利·福特的壹句經典名言，現在我們又在《喬布斯傳》中看到了。
100多年前，福特公司的創始人亨利·福特先生四處詢問顧客:“妳需要哪種更好的交通工具？”幾乎所有人的答案都是:“我想要壹匹更快的馬。”很多人聽到這個回答，馬上跑到馬場選馬配種，滿足客戶的需求。但是福特先生沒有馬上跑到馬場，而是繼續問。
福特:妳為什麽需要壹匹更快的馬？
顧客:“因為它能跑得更快！”"
福特:妳為什麽需要跑得更快？
顧客:“因為我可以更早到達目的地。”
福特:“那麽，妳想要壹匹更快的馬的真正意圖是什麽？”
客戶:“用更短的時間更快的到達目的地！”
所以福特沒有跑到馬場，而是選擇制造汽車來滿足客戶的需求。
顧客需求有兩種類型:顯性需求和隱性需求。我們通過市場調研了解到的，往往是壹些“我想要壹匹更快的馬”之類的顯性需求。客戶的顯性需求並不是客戶的真實需求。企業需要根據收集到的顯性需求信息進行深度挖掘和捕捉，從而了解客戶的隱性需求是什麽，進而分析出客戶的真實需求是什麽(比如在更短的時間內，更快的到達目的地)。這是壹個需求分析的過程。
喬布斯說:“我們的任務是理解還沒有落在紙上的東西。”其實就是對用戶隱性需求的深度挖掘。
原文:/a/20160309/291676 . html。