一個 App 是怎樣誕生的？

01-05

從腦海里的一個想法，到應用商店裡一個可供大家下載的APP，是怎麼樣的過程？能詳細說說嗎？

我想題主是想詳細的了解一個app的生產過程。

下面以一個app從我的一個想法開始，到上線AppStore的過程做說明。

故事要從一次電影院的經歷說起。一個人去看電影，買票時，聽見前面的女生輕聲對身旁的男生說：居然有人一個人看電影。我發現身邊還有其他一些朋友也一個人看電影，但是大家可以一起去看電影的。於是我想到了做幫助大家結伴看電影的app。於是我把這個想法發布到 http://Shixian.com ：

根據前面的思路，迅速畫了一張草圖：

接下來我進一步的思考了這個產品的一些細節情況，發布到了網上。這期間就有一些同學開始關注我的項目。然後開始有幾個童鞋加入項目：

接著有一位同學做了稍詳細的產品原型圖：

然後我做出了第一版原型。

後來有了第一位工程師加入項目，並開始開發工作。

接著加入項目的人越來越多，設計師、客戶端工程師等。我們開始明確分工協作：

團隊穩定後，我們開發工作挺順利，不久後有了內測版。測試通過之後，提交AppStore審核：

審核通過之後，app就正式上線了：

https://itunes.apple.com/cn/app/yi-qi-kan-dian-ying/id833253010?mt=8 (二維碼自動識別)

這是整個產品開發的時間節點：

目前產品累積了過萬用戶。

以上整個流程，以及相關文件可以在這裡看到：一起看電影移動應用

總結起來，對於非技術人員來說，當你有一個想法，想要做成app的時候，要自己做出產品的原型是很重要的環節，這樣才容易吸引到其他技術人員和你一起來做這個app。

利益相關：http://Shixian.com 團隊成員。

哈哈，這個問題我之前剛好回答過，然後得到了大家的關愛。。。&<(?????)&>

那在這裡也再次分享一下。

————————————我就是隔離一下正文————————————————

此處應該有一個idea。

第一步：需求梳理、分析

針對這個idea來一場從內到外的洗禮，在此假設用戶需求分析已經確定 , 接下來根據提煉的真實用戶需求來確定產品需求。

產品經理將會根據溝通中的相關資料的word、ppt、jpg等等東西翻譯成邏輯語言，最簡單的就是產出一張產品功能腦圖或者一份功能列表。

▲產品功能腦圖

▲一份功能列表

第二步：產品原型圖繪製

初步產品功能需求梳理清楚之後，產品經理持續跟進，反覆溝通確定產品原型圖。

PS：我們出一般是全局流的圖，程序員哥哥們比較喜歡（白眼）

▲產品原型圖

同時根據具體的項目需求，會搭配一套產品業務流程的泳道圖

▲產品業務流程的泳道圖

常規的是用axure出一份帶簡單交互的原型

▲簡單交互的原型

簡單點，用墨刀做一份帶交互的原型。

▲墨刀帶交互的原型

第三步：UI設計

UI設計，包含風格稿和內頁設計。

風格稿會根據產品需求提供的目標用戶類型、客戶傾向、LOGO等信息，以及確定做風格稿的2-3個頁面的原型圖，來進行風格稿設計。

待風格稿確認後進行內頁設計，包括設計效果、頁面元素、彈出頁面等等

▲風格稿

所有頁面設計完後會統一發給客戶做進一步溝通，然後統一修改優化。

▲Zeplin

Zeplin能夠幫助前端更好地理解設計師意圖，而設計師又能快速得到前端反饋的協作，從而減少設計師與前端的溝通錯位，使得兩者在「界面元素」和「交互動作」上形成一致。

▲Zeplin

invision用於設計先行能減少後端技術工程問題，設計的迭代越快，軟體開發就越能在時間點的把控上做到極簡。

▲invision

設計定稿後並不是設計師的工作結束了，之後還有一段周期的切圖、標註工作。

▲標註

▲切圖

▲sketch

多維度運用zeplin、sketch、invision等等協作工具從細節上詮釋產品開發的每一個產品需求，在時間上保證高效，在結果上保證了產品技術層面與設計層面的完美融合以及項目的高效進度和最後的優質呈現。

第四步：項目經理技術負責人對接需求

項目經理對接上這些需求，第一個工作是細化需求，將這些翻譯成技術能更好理解地語言，搭配著原型圖或設計稿來召開技術會議，統一講解新項目的需求。

▲細化需求

第五步：技術方案架構設計

技術負責人在清楚了解整個項目的需求之後會開始構思整個項目的技術方案，根據產品需求，提供易擴展、可持續迭代的技術框架方案。

▲整個項目的技術方案

▲可持續迭代的技術框架方案

第六步：項目排期任務分解

同時，項目經理在和研發團隊溝通確認後對項目進行分解以及排期，以此來保證項目進度和質量。

▲項目管理

第七步：產品研發階段

這個階段就是各端技術按照排期規劃開始編碼，期間各種對接、調試以及撕逼。我不是程序猿，這塊就不多寫了，貼幾張他們技術wiki的截圖吧。

▲Wiki對接

Paw 讓測試 API 變得輕鬆愉悅，可以構建內部和外部的資源。它可以在不同的環境下進行測試，也可以引用來自其他請求響應的數據。

▲PAW

它可以定義不同的環境，於是可以輕鬆地在開發、臨時和生產環境中進行切換，而無需重新配置任何端點（endpoint）。並且還可以在一個請求的消息體中引用另一個請求中返回的值，這能夠節省大量時間。

第八步：交付測試階段

測試工程師基本全程跟進，從最早期對接完詳細產品需求之後就開始編寫測試用例

▲測試用例

然後配合項目各個裡程碑節點進行功能測試和性能測試，將問題按優先順序劃分統一反饋

▲測試過程

最後，按原計划上線

以上均是理想情況下，一個App必經的幾個階段的簡潔步驟說明，具體執行依然會根據需求穿插進行。

最最後，

歡迎大家關注我常駐的專欄FenzoTech - 知乎專欄，不定期會有相關經驗話題與大家一起分享討論。(? ??_??)?

講講我的App開發經歷。

這是我已經上線的app：iTunes 的 App Store 中的「看法中國法律資料庫」，看法-小米應用商店（Android版）。上線一年了，反響還不錯。

我不是專業的碼農，開發帶有玩票性質。寫這個App一方面源自多年來對計算機、編程的愛好，另一方面也是為了滿足自己工作中的需要。

大學時上的是法律系，但很喜歡計算機科學和編程，自己看了許多的書，也寫過一些小程序（俄羅斯方塊、Life Game什麼的，還畫過Mandelbrot的寶葫蘆）。工作後一有閑空，也還是忍不住再琢磨琢磨計算機和編程，琢磨懂一些東西後，心裡由衷的高興（記得看The Practice of Programming，理解了被譽為「計算機科學的一項偉大發明」的Hash後的那種感覺，還有理解了遞歸併感受到它的魔力後的那種感覺）。學習了正則表達式之後，更加體會到計算機的威力，發現計算機在文本處理方面可以有這麼大的作為，後來我的編程興趣就主要集中在計算機文本處理上。我學習了各種技巧，從正則表達式到更高級的Parser，還有NLP中的一些技術，並且不停的尋找現實中的一些問題操練這些技術（有段時間我常乾的事就是從網上找一些書的垃圾txt文件，寫程序進行清理、生成目錄、添加腳註等加工，然後生成latex文件、編譯成漂亮的pdf放在電紙書上看）。文本處理的活乾的多了，終於想到，為什麼不對工作中常常要遇到的文本——法律文本下手呢？

我是做律師的，工作中經常要進行法律檢索，甚至需要隨時隨地進行法律檢索。在和客戶談話的過程中，或者身邊沒有電腦的時候，都可能會有問題需要立刻解答，需要做一個快速的法律研究，查閱核實一些法規和資料。在還沒有iPhone和android的年代，能做的就是把自己常用的法規和資料的txt文件分類整理成一個多層的文件夾，放在windows手機(CE系統)里，需要的時候翻出來看。但這本質上只是個電子書，主要是用來閱讀的，遠不能滿足法律檢索的需要。法律檢索需要能按關鍵詞搜索、快速在所有已有的數據中返回有意義的想要的結果，這需要的是一個資料庫系統，甚至一個垂直搜索引擎。但當時電腦上的法律資料庫系統尚且不太完美（法律資料庫國內做的最好的是北大法寶，我印象中直到2011年時，在它們的資料庫中進行全文檢索都需要等待三四十秒才能出現結果），而且智能手機還沒有興起（印象中2006、07年的時候，用個多普達的windows手機就已經很科技潮人了；iPhone和Android真正在中國流行起來也是在2010年以後），想要在手機上滿足這類需求，肯定是個奢望了。

2010年智能手機開始普及後，我發現市場上出現了一些法律信息類的app，但都差強人意（如同iPod出現以前的MP3播放器市場一樣）：有的實際上還只是電子書，只能瀏覽，不能檢索；有的也提供了檢索功能，但幾乎不可實用（提交一個檢索詞，等待了三十秒以後返回一堆無關的結果）；許多app一看就是不了解法律的人做的，不知道哪些法規和資料是重要的、法律職業用戶最需要的，收集的不全，還有許多過期失效的數據（對於認真的使用者來說，這是很要命的）；更重要的一點，即使一些認真去做的，也只是把電腦版的內容直接搬到了手機狹小的屏幕上，而沒有考慮過法律文本與普通的文本不同，有很好的結構性，把這種結構分析出來、利用起來以後，在手機的小屏幕上恰恰可以做到非常好的顯示效果和體驗（當在手機的方寸屏幕上翻滾著一篇幾萬字的法規要找到後面某章里的一段時，damned，就不能有個目錄嗎）。我發現，即使是一些專業做法律資料庫的公司，app也做的比較差勁，差強人意。2012年開始用iPhone之後，忍不住想，damned，難道自己不能寫一個真正好用、讓自己滿意的法律檢索app嗎？能擴展自己手頭設備的功能，而不僅僅是被動的使用，這不是一個hacker極大的樂趣么？於是就開始動手，一有閑工夫就一塊一塊的添磚加瓦實現。

實現這樣一個法律檢索app，需要有：被檢索的數據；檢索系統；交互界面。

被檢索的數據。這個實際上在我寫iOS App前就已經基本具備了。很早以前，我就有自己建立一個法律檢索系統的想法，為此我用python寫了一個爬蟲（後來改為用scrapy來定製了），從眾多可能出現法規的「熱點」網站爬取可能是法規資料的網頁。我還訓練了一個classifier，可以基本上自動的檢測一篇文本的內容是否可能是法規或法律資料，這樣用這個classifier就可以把無用的內容剔除出去。找到這些資料後，進行提煉，把多篇不同來源的可能是同一法規的文本進行diff和similarity分析，這樣基本能實現自動的校對（說「基本」是因為我留了一些人工介入的介面，機器對一些不易判斷的內容可以「詢問」人的意見），一定程度上確保法規文本的準確性。自動化的好處是，這個資料庫的新數據添加和維護需要很少的人力，要不然作為一個業餘的個人開發者肯定是沒時間來手工維護這個資料庫的。

為了更好的展示這些數據，我還寫了一個parser，來解析這些文本中的格式和結構。

數據有了，我又用sphinx搭建了一個檢索系統。

然後是iOS App的開發。我有C語言的基礎，但是對Objective-C和iOS編程環境完全不了解，看了兩本入門的教材後，主要就看Apple的開發文檔和示常式序，慢慢的也就熟了。因為是業餘開發，時間不多，斷斷續續連學習帶設計、開發到最後完成，將近用了一年的時間。最後經過蘋果AppStore的幾番審查，終於上線了。因為是玩票，也沒有做什麼推廣。令我高興的是，也許是「自己做自己吃」（Eat your own dogfood）的原因，能真正滿足像我這樣的用戶的需要，在一些專業用戶的小圈子裡竟然有了一些名氣，口口相傳的也有了不少下載量和好評。

然後就是一些android的用戶催促也開發一個android版的。我對android的編程環境又是完全不熟，但好在還有點Java的基礎。又經過同樣的近一年的學習、折騰，把android版也完成了，前一段時間也上線了。

在App里我做了In App Purchase，所以也產生了一些經濟收益；更開心的是收到用戶好評和讚揚的時候；同時自己在工作中也可以使用自己一手打造的工具來解決問題了，那種感覺非常棒。

更重要的是，實踐了多年來純粹基於興趣和愛好而掌握的技術，真正做出了有實際用戶的作品，滿足了他們的需求；同時這次試水也讓我看到了把計算機技術更廣更深的應用在法律領域的可能。

需要的人：

產品，前端開發，後台開發，UI，這些就能保證產品開發出來，根據預算和後期推廣還可以酌情增加測試、運營和推廣人員。

產品誕生記

1、公司大老闆說要做個什麼樣什麼樣的app出來；

2、產品做競品分析→小團隊一起討論，確定主打方向；

3、產品出原型→小團隊或者跟老大確定原型是否ok；

4、產品根據討論結果調整原型，然後出產品文檔；

5、整個團隊分析產品文檔，功能能否實現這些；

6、產品根據討論結果修改文檔和原型；

7、UI根據原型畫圖；

8、前、後台的技術分析產品文檔，根據文檔定介面；

9、前、後台搭底層框架；

10、UI出效果圖→小範圍討論，確定風格和細節等；

11、UI根據討論結果修改效果圖，同時先切一些圖給技術用；

12、與此同時，產品一直在畫後台的原型和寫後台的文檔

13、一兩個月之後第一個版本出來，測試→提bug→改bug→在測試，提bug→改bug。。。。。。

14、bug改到老闆或產品覺得ok了就能上線了。

我趁機來說說自己發布的第一個App（iOS平台）是怎樣誕生的。

我剛到北大的時候，工作的一部分就是開發iOS應用。使用北大的校園網需要先登錄IP網關。登錄網關可以通過訪問一個網頁實現，但用客戶端無疑更方便些。

北大計算中心針對幾個常見的操作系統平台都發布了網關登錄的客戶端，唯獨沒有iOS上的（後來知道他們其實也正在為iOS開發）。

我自己用iPhone，每次登錄網關都去開網頁讓我感到十分麻煩。於是我就想，為啥不自己寫一個呢？

作為程序員有一個優勢就是這樣：你覺得有什麼需求，可以自己寫代碼實現它。當然前提是能夠實現。

我認為登錄網關的網頁無非是向某個伺服器發了個請求，完全可以寫程序去發送這個請求。當時本著「瀏覽器能做我就能做」的原則，

開始去抓取並分析用網頁登錄網關時瀏覽器與伺服器通信的數據，直至找到關鍵部分。之後在程序里模擬這個過程，就實現了網關登錄。

接下來無非就是寫一個簡單的界面，點擊一個按鈕就觸發登錄過程。於是，我在自己的iPhone上可以方便登錄網關了！

我把這個應用程序稱為「IPGateway」，也就是IP網關。

至此，我是不是可以說，這個App就誕生了？它確實已經是一個在iOS下運行的App，並實現了它的功能。但由於它還沒到「應用商店裡一個可供大家下載的APP」，

所以還得有一個進一步完善和發布的過程。

自己能用了之後，我想別人肯定也有這個需求。於是我就考慮把自己開發的網關登錄程序發布到App Store供大家方便地下載。俗話說，「家醜不外揚」，

自己用的程序界面可以不好看，但真決定要發布出去時，還是適當美化了一下。此外，還實現了其他控制網關的功能，加了些設置項，

然後弄了個彩蛋，算是像模像樣的一個發布版了。

所花的時間前前後後不超過一周。實現自己用的登錄功能其實只用了兩三天時間。我把發布版提交給了App Store審核。由於他們不在北大校園網內，

無法實際使用我提交的App，就要求我拍一段演示視頻給他們看。我照做了，他們也就通過了。

等IPGateway在App Store上線後，我在北大未名BBS上的Apple版面發了條帖子告訴大家，說有一個網關登錄的App可以用了。由於是第一個，得到了很好的反響。

後來，官方也發布了iOS版網關登錄客戶端，甚至更晚的時候還另有一個類似的網關程序發布，但都已經是追隨者了。

到現在距離IPGateway第一版上線已經過去一年多了，從下載量和收到的用戶反饋來看，我的這個App在北大（它的目標市場）還是蠻流行的。

最近iOS7出來，我也把IPGateway升級到了2.0版，以適應扁平化風格的系統。

總結來看，從我有一個想法，到最終發布這個App，並沒有用太長時間。

這也是因為我這個App功能比較簡單，複雜的App肯定會需要更多時間和精力。但麻雀雖小五臟俱全，這畢竟是完整的一個過程。

從中我想也可以提取一些經驗，供參考：

1. 發現需求。找到一個未滿足的需求很重要，這往往是一個機會。這個需求可能是特定群體的，但只要有目標市場就值得做。

2. 抓住機會，迅速行動。一旦晚了，很可能已經有別人做出你想做的東西了。

3. 就App本身來說，完成一件事並完成的很好，就會受到歡迎。

IPGateway之後，我又做了其他的App，將來也可能會做更多的App。我的App信息可參見下面的鏈接：

1. 發現需求。

用evernote記錄下來，先放放，過段時間頭腦不發熱了再審視下這個需求是否真的有價值。

2. 用xmind腦圖分析下這個需求是否靠譜。

看看能否實現，評估下這個app的方方面面，看看這個idea是否值得花時間去實現。

3. 打開xcode，開始編寫。用ruby或者python搭好後台。（漫長的編碼）

4. 打開ps、ai，繪製界面元素

5. 寫完收工，上傳到app store，後端部署到伺服器。

下一個app。

#########

舉例說明，順便賣下廣告，歡迎下載，尤其歡迎付費下載，還有幾個有趣的app正在開發中，敬請關註：

iTunes 的 App Store 中的「腦神跡背單詞II Pro

如何發現這個創意的？

有段時間我學習英語，發現了美國人都用一個軟體叫羅塞塔石碑。通過這個軟體，我發現了屋漏先生髮布在天涯的一個文章叫學習外語的誤區。由此我了解了互動沉浸式學習法，但是羅塞塔石碑的單詞量是個問題，我又研究了腦記憶的原理，結合互動沉浸學習法和台灣一所大學腦記憶實驗的論文，發明了這個單詞記憶法。

如何實現這個app？

買台ipod touch（便宜，iphone太貴不捨得買）

把自己的pc整成黑蘋果。（開始從遠景論壇學的，現在我推薦tonymacx86這個網站）

到亞馬遜買兩本書《iphone開發基礎教程》、《objective-c 2.0程序設計》

花兩個月業餘時間讀完（前提條件是你必須首先得會一門程序語言，比如php，否則我估計2個月時間困難）

註冊apple idp開發資格，繳納99美金。

下載xcode，開始編碼。不懂就google+ stack overflow

編碼時間……（n多個日日夜夜……這裡我想說下為何很多程序員對只差程序員這個問題很反感，我估計是因為編程確實是一件高腦力+高體力結合的工作，任何一個簡單的想法想實現，都必須由程序員在每個最小的細節開始一行代碼一行代碼的搭建，多辛苦我估計跟工地搬磚差不多，所以編程叫搬磚……這個只有程序員自己清楚。在外行眼裡似乎程序員巴拉巴拉鍵盤程序就寫好了！但是其實一點也不輕鬆，如果不是真愛，我想做程序員一定非常痛苦）

完工。上傳。

iTunes 的 App Store 中的「閃電記賬Pro

如何發現這個創意的？

用過的記賬軟體實在太繁瑣，索性我就直接寫了一個最簡單直接的。

iTunes 的 App Store 中的「睡眠時聽的下雨聲」

如何發現這個創意的？

我自己很喜歡下雨的時候睡覺，就寫了這個app

iTunes 的 App Store 中的「放鬆的海浪聲播放器 (自然錄音高品質音軌並帶有24小時倒計時器)」

如何發現這個創意的？

海浪聲播放器。就著雨聲app的框架，快速完成。也許有人需要。

Escape from Death Ship on the App Store on iTunes

如何發現這個創意的？

抄襲軟哈東的遊戲習作，順便學習下cocos2d-SWIFT

腦神跡背單詞II

免費版

iTunes 的 App Store 中的「閃電記賬 Lite

免費版

iTunes 的 App Store 中的「Relaxing audio player Collection (natural sound of the waves and rain )」

量販版

如果你是創始人。

1.突然有一個idea在你腦海里爆炸，你覺得一個基於社區互換二手物品的商業模式目前在市場上是空缺的，你覺得要做

2.你拉來了一群志同道合或沒有工作的小夥伴，決定開干！

3.一開始只有你，一個做技術的，一個做產品加運營的。你們開始從PEST分析到SWOT分析，從用戶場景到交互體驗，從首版的核心功能到商業模式，一輪輪激烈討論你們定下來初步方案，出PRD和MRD和BP等等任何能夠讓你們覺得豐滿踏實的東西

4.同時你一邊統籌工作一邊去拉（騙）投資，做技術的又是前端又是交互又是美工又是測試，產品一邊壓抑自己對產品功能的幻想一邊被你丟一堆調研和分析工作

5.你們任勞任怨早8晚10的干著，慢慢團隊壯大了。這個時候你的錢不夠燒了，創業可能結束，app做不出來咯！如果你夠幸運騙到了錢，太棒了至少可以苟延殘喘半年

6.創業公司不穩定，人來人去，但是APP日漸豐滿。原型圖堆積如山，白板筆不知道換了多少只

7.東西終於要出來了，你調用一批人趕緊去尋找種子用戶，要麼拿錢利誘，要麼不要臉撒潑打滾求關照，終於有了一些願意配合的人

8.APP出來了，開始內測。兩種情況：爛的跟一坨屎一樣，你們覺得自己跟傻逼一樣信心滿滿就整出來了這麼個破東西，騙來的種子用戶的情緒就跟冷冷的冰雨一樣拍在你們心坎里，你們結束了；恭喜你哦，你們的APP雖然很粗糙但是好歹種子用戶覺得還湊合，給了些意見你們屁顛屁顛拿回去改產品

9.你們的產品開始優化升級，用戶越來越多，從幾十到幾百到幾千，你們很開心。畢竟社區交換二手貨不是剛需，屬於較為垂直的應用

10.但是壞消息來了——產品開始覺得APP的功能應該更豐富以吸引用戶，員工們覺得既然產品做的不錯我們是不是該稍微加薪了？投資人覺得你這APP做的是還可以，但是你得讓他看到盈利的希望不然他就不會繼續投了

11.你彷徨了。你知道功能多了可能做無用功，每次都做一點點優化和改動是最好的，但是產品經理需要滿足自己的虛榮和成就感。你知道兄弟們真的苦，尤其是做技術的因為你一句話經常就加到深夜，但是你實在加不起工資。你知道投資人說的沒錯，但是你覺得自己需要更多的時間去尋找目前看來最合適的盈利模式，而且你覺得用戶量大了再談盈利會更好

12.你沒有能夠妥善處理好，團隊開始出現問題，跟了你很久的老人走了，你在他們看不到的時候痛哭流涕，你開始質疑自己、質疑初衷；你居然通過畫餅的辦法說服了產品，通過團建和個人魅力說服了技術組，居然跟投資人講情懷和理想燃起了他的熱血，恭喜你你順利度過一個大難關

13.你們修改了APP，開始準備上線。這個時候運營同學被你派出去跑各大渠道，打探審核機制和上線的優惠

14.產品居然沒能過審核？因為裡面的跟錢相關的內容被卡得比較嚴格呢，打回來改！

15.終於特么的審核通過了！運營同學費勁力氣地跟某個應用市場要到了首發推薦位，整整一個星期呢！

16.首發活動真棒！用戶過萬了，日活居然也有快一千，技術組的工作終於常態化了，團隊成員鬆了一口氣，你仰天長笑，卻發現鏡子里的自己多了那麼多白髮

app的誕生到上線大概就是這樣。一個APP起碼需要幾個人用幾個月才能做出來，然後上線準備要一段時間。

微微跑題，如果只談APP誕生也太淺薄了所以就多聊了些。如果有人願意看，我會寫後面的故事。

==========================================================================

11-25更新

本來打算寫後面的故事的，但是覺得寫下去就應該是創業而不是創造app了。

其實app從一個idea到一個成熟的具象化的產品的過程不是非常複雜，不明白樓上們那麼多配圖意義何在。。乾淨利落把事情講明白不就得了么。

確定方向——調研——PRD——設計——測試——調整——測試版上線——用戶反饋——調整——正式上線——用戶反饋——添加功能——用戶反饋……迭代優化

說下我的把想法做成創業產品－「會會」（下載請移步會會 - 職業人的社交工具）的經歷吧。

產生做「會會」這個產品的想法時，我還在大街網。去大街也是因為我有做職業社交的情節，國內也沒有其他做的好的公司。大街裡面有一些比較熟的人，上一個參與的創業項目做不下去了，就去了大街。

今年2月份的時候，發現了一個新上線的App叫「請吃飯」。3月份的時候，又在想新的idea，又看到了「請吃飯」，心想就深度體驗一下吧。後來還真約到了一個妹子，見面過程不說了，總之因為約到的人不太對，感覺不是很好。但突然覺得這個模式挺有意思的。陌生人，直接見面聊，可以選離得近方便的報名參加，少了很多磨嘰的環節。男人們肯定主動，姑娘們呢，也順便蹭飯什麼的。後來和同事閑扯聊天，說這個關係可以用到招聘上來啊。主動的是招聘方（＝男人），請夠檔次的候選人（＝美女）吃個飯，其實挺好的。大家不是都愁找不到好人么？熟悉中高端招聘業務的應該知道，對於候選人來說，都不會投簡歷，也不太會直接去接受面試。一般大牛，都是朋友推薦介紹給招人的老闆，先吃個飯喝個咖啡認識認識，看看合不合適，再談其他。很多時候，心想，不為求職，多認識個老闆交個朋友也好。對於求賢若渴的老闆來說，認識個大牛，有機會遊說也就行了，至少還能交流下業務什麼的。

可惜的是，這個主意，當時在公司內部，雖然被很多同事認可，卻並未獲得老闆的支持，內心各種怨念。同時，「老闆請吃飯」的念頭揮之不去，覺得依靠這個直接約的點子去做職業社交或者高端招聘，其實是個很好的點，甚至比做異性交友、約炮更好。

當然，即便「請吃飯」那個app，從一個產品人的角度看有很大提升空間，而且異性交友起用戶量更容易，我也從來沒想過抄一個「請吃飯」的念頭。一來不喜歡做全版抄襲跟風的事，二來確實對做異性社交產品沒太大興趣。

於是心裡萌生了自己創業去做這個點子的想法。

後來和認識的做投資的朋友聊了聊想法，他也忽悠我出去創業就做這個。

4月份，打定注意出去自己幹了！一邊做調研驗證自己的想法，一邊準備組織團隊，一邊把產品框架原型做了。

不過3～4月份這段時間，隨著對產品思考的深入，我決定拋棄「老闆請吃飯」這個概念，堅決不做招聘這個業務；而是在這個基礎之上做「吃飯聊聊」這個概念的職業社交產品，也就是後來的「會會」。

話說「會會」這個名字，也是我花了2個多月的時間琢磨才想好。發現沒有重名、工商註冊可行，最後才決定的——並快速申請註冊好了商標知識產權。

5月份，團隊的小夥伴基本確定。找到了之前的同事，她在開自己的設計工作室，就把第一套UI外包了。

然後我開始準備找錢。這個時候壓力還是很大的。因為團隊的小夥伴基本上都被你忽悠動了，決心辭職了。如果沒投資我的積蓄很難養得起團隊，不能讓他們和你喝西北風啊。

見了大概十來個投資經理／合伙人，有幾個談了第二輪，基本有些眉目。

6月中旬的時候，團隊的小夥伴們都辭職出來，基本湊齊了人做iOS產品。更重要的事，這個時候，投資終於談妥了。感謝投資人在我還只有一個ieda一個簡陋的不行的BP的時候，就給予了我信任，給我一筆天使投資。

第一版UI設計也完成了，開干！

嗯，那會兒還沒有LOGO，用了一個很醜圖標佔位，囧。

7月份的時候，偶然拉到另外一個遠在深圳的小夥伴回京和我做Android版本，以及另一個隨之而來的小夥伴——只是他倆都算是新手。後台開發差不多可用了，iOS有了雛型。

8月份，借了1個Android工程師，和新到崗的2個小夥伴一起開發。

9月份，iOS和Android都已經有了demo。然後從9月～10月，陸陸續續找了一些朋友當小白鼠，讓他們使用提供各種反饋意見。我們接著改進產品。10月16日，第一個版本通過App Store審核。但因為我覺得產品還不夠好，所以沒有對外發布，接著改進。

產品的設計，不能只考慮功能，還得照顧到運營。尤其是社交產品，必須要足夠的用戶，才能產生吸引力和價值。所以一直到11月份，配合運營的規劃，還做了一些產品的功能和後台的東西。為產品添加引導廣告位；另外，我們的報名可以分享到微信，而且可以不用下載App，在微信里就能完成報名。一方面便於產品里的邀約擴散傳播，另外也增加了用戶價值。

直到11月22日，我們覺得能拿出去見人的iOS版本通過審核，在23日周日才對外公布。

現在的產品截屏是這樣：

iOS版

Android版

通過朋友的推薦和傳播，一天時間嘩啦啦就進來上千人。然後開始真的不需要渠道資源和廣告推銷的自然增長起來。到這幾天還有很多人托朋友過來找我要邀請碼。

貼一下我另外一篇軟廣「讓社交，不再只是約炮」當中對於會會的期望：

移動互聯網與傳統的互聯網業務相比，應當不再是將人們越來越多的束縛在虛擬的網路世界，而是可以連接人們線下真實生活的紐帶。大家需要的社交App，不應該是在線上莫名其妙的添加一堆素未蒙面的「好友」，而是真正能夠與對方建立真誠的聯繫。
我相信，無論哪一種溝通的形式，最終都無法取代人與人之間真誠的見面溝通。不論是短消息、圖片還是語音、視頻通話，都不如兩人坐在咖啡桌前的對話，能夠碰撞出更多知識的火花；也不如在餐桌上的交流，能夠相互建立起真摯的認同和信任。
所以，我希望「會會」打造的是一個可以讓人們面對面真誠溝通的平台，雖然它是個基於移動互聯網的app，卻能讓人們走出虛擬的線上網路，走到線下直接深入的交流。
說的通俗一點，就是可以直接「約」。
各類社交App上短消息／語音有一搭沒一搭的聊天，有時候反而降低了交流的效率，你再焦急也得不到及時反饋。當你需要幫助的時候，哪怕四處托朋友，也未必能夠迅速找到你想認識的人。所以還不如公開發個邀約，讓那些位置離得近的，彼此感興趣的，能夠在業務上有交集的人，能簡單快速的見個面。
不論是在國貿、中關村還是其他地方，我希望會會可以讓更多在同一商圈、甚至同一個寫字樓里工作的人，不再只是點頭之交或擦肩而過，而是能夠高效匹配的的見面結識，深入交流。通過會會，你借用平常一頓飯、一杯咖啡的時間，就可以拓展人脈圈子，認識到能解決你問題的專業人士、可以互幫互助的小夥伴，甚至是下一個十億美金公司的創業合伙人。
原文地址：
讓社交，不再只是約炮 - 一個產品經理的世界 - 知乎專欄

很久很久，常常要花上好多好多年的時間。

我的腦子裡面的各種想法一直很多，所以走上了程序員這條路。

在知乎，那麼多有點子的人要找技術合作夥伴；可我自己就是程序員，而且是相當優秀的程序員！這個條件很好吧，那我總能實現很多自己的想法吧？

不。

正因為自己是技術專家，我才知道大多數想法是多麼不靠譜。我被很多親戚找過，很多同學找過，被很多同事找過，被很多鄰居找過，他們跟我說: 「你是技術專家，我有一個絕妙的點子，只要我們合作，就可以做成下一個騰訊，怎麼樣？」然後用貪婪的目光看著我。

當然，也並不都是這麼誇張。做成騰訊誰都知道不大可能，但是大賺一筆是沒問題的。更常見的是: 「幫我寫個軟體吧，我很需要! 」

剛開始我只笑著搖搖頭。到後來，沒辦法，說不通，我得躲。我害怕了，我不敢跟周圍的人有太深入的交往，每個人都把我看作他們的搖錢樹。所以，我不得不離開了很多公司，換過好幾個城市，半年換一個電話號碼...

－－－－－－－－－－－－－－－－

先扯個不著邊際的開頭，有人氣明天就繼續。

----------------------------------------------------

贊同的人不多，現在才過來繼續。很多天了。上次是9月2日，今天是9月18日。

舉幾個具體的例子吧。從手機上下圍棋開始說起。

我喜歡下圍棋，一直就想能夠隨時隨地下圍棋。為此，2003年底我還買了華碩很小的8.9寸的筆記本；2009年還買了韓國的5寸的觸摸屏電腦，連無線上網卡上tom玩。但是攜帶不方便，上網速度慢，屏幕太小，而且tom本身不是為觸摸屏設計的，隨身下棋還得靠手機。

2001年的時候摩托羅拉的A6288剛出來，搭載GPRS, 搭載java ME，四階灰度顯示。我當時做SP這個行業，接觸到這款手機，我又很喜歡下圍棋，當時就一直想做一個能夠隨時隨地下棋的軟體(當時還不叫應用)。可是那時候主流的還是wap，而java ME的支持很弱。考慮過各種方案，甚至考慮過在pc上裝一個軟體來驅動聯眾(當時還沒有QQ), 然後在手機上遠程操控。可想而知，技術難度高，使用複雜，設備太貴，體驗極差。所以沒有動手。動手也是白忙活。

2004年的時候，手機已經都是彩屏，而且java ME成為了趨勢，硬體條件上應該足夠。那時候也已經有各種java版的牌類遊戲在手機上出現，但是體驗不佳。當時在班車上跟一個喜歡下圍棋的同事天天討論，我認為當時那種105*105的屏幕已經足夠下圍棋，他堅持認為太小。只要五個像素一個棋子嘛，能看清就行。

所以我就不停關注各種新出來的手機屏幕解析度。後來有132*176, 176*208, 176*228, 屏幕越來越大；看來好像足夠提供很好的下棋體驗了。但是還得解決伺服器的問題，聯眾並沒有公開協議啊，難道我去破解協議？那樣不靠譜啊，始終是不正規的東西。當時TOM很熱，而且TOM是韓國人開發的，估計協議不太會突然變化太大，所以我也嘗試抓包想分析，但是沒分析出來。

－－－－－－－－－－－－－－－－－

就在這個時候，那個同事說，他以前玩過開源的NNGS, 可以自己在linux上架設NNGS的。我不懂linux，但是多虧他的提醒，我去查NNGS相關的資料，發現國內有幾個已有人氣的圍棋對弈伺服器是採用的NNGS, 而歷史悠久的IGS和NNGS的協議基本上兼容。那麼我只要做一個支持IGS的客戶端而已，這個不太難。當時我在市場部，事情也不多，就利用業餘時間開始學習Java ME，一天以後可以顯示對局了，然後慢慢解決吃子的問題，解決走棋的問題，一周以後，一個能下棋的客戶端誕生了。

你說快，快不快？才一個星期，而且還是現學現賣。可是，從有這個想法，到慢慢變成了一個能夠實現的想法，經過了4年的時間。得等環境慢慢變，各種條件慢慢具備。

然後，買來手機測試，不停調試解決各種bug, 直到做完善做得自己滿意，大半年過去了。

但這才僅僅是一個開始。

--------------------------------------------------------

有人氣我就明天繼續。

--------------------------------------------------------

好吧這麼多票了！繼續。

插一段題外話：技術人員常有把一切都當成技術問題的毛病。j2me當初是沒有縮放圖片功能的；所以棋子我是用畫圓的函數畫出來的，這樣可以做到無級縮放。拿給別人看的時候我還很得意，縮放給別人看。

後來我自己天天路上用，才覺得畫出來的棋子實在難看。甚至，j2me的api，畫出來都是多邊形，根本不圓！於是為了讓自己用得更舒服一點，我換成了png圖片的棋子。至於縮放，很簡單，我預先把png圖片縮放成各種尺寸打包好就行了。

---------------------------------------------------------

我在市場部幹了一年，工作不是很順心，還是很想把自己做的圍棋推廣出去。我的上司看了很感興趣，他說有一些關係可以找聯想合作，找海爾合作；但是光客戶端不行，得有伺服器；光圍棋不行，得有聯眾那樣的象棋、麻將、拖拉機都有。

這個...不砸個上千萬，真做不到啊。

----------------------------------------------------------

而作為一個圍棋愛好者，我深知這個圈子人很多，而且大家都有手機，而且都漸漸支持Java ME了...做出來一年了，實在不忍心

《從想法到實踐，一個App是如何誕生的？》

　　下午，知乎上的一個私信我，問我「我是一名大二的會計專業學生我想做一款App」問我該怎麼做。這個問題其實很多人問，但是也沒有一個人出來回答，雖然網上有很多這樣的答案，但是大多數都是廣告，我今天就根據自己的項目經歷，寫寫從從想法到實踐，如何開發一個App，希望能幫助那些做App的入門者。

　　做一個App一般分為五個步驟，第一個是有想法，第二是整理產品需求，形成產品文檔，第三是設計產品模型，第四是界面設計或者UI設計，第五是招聘開發人員進行開發，或者外包，第六是上線運營推廣，下面我就分別解釋下，每一個步驟該怎麼做。

　　第一步：完善你的想法

　　很多人看到別人的App做的這麼好，而且做的很不錯，也會自己想著做一個App，比如有的人想做一個綠色食品的App，有的人想做運動的App，有的人想做個釣魚的App，想法是每個人都會有的，而且千奇百怪，不過很多人的想法都是不完善的，很多人的想法都是片面而不成系統的，也有的人是一時頭腦發熱的，不成熟的，所以說想把想法做成App，首先一定要問自己，是否真的特別想做這個App，是不是這個App不做出來就不睡覺，想做App的決心到底有多大？只有有了特別堅強的決心和信念，這個App才有可能被做出來，因為大家並不知道，做成一個App有很多無法想像不到的困難。

　　有了決心之後，再做App才有動力，這個需要做的就是，完善你的想法。比如我們想做一個綠色食品的App，我們要把這個App的名字，App的類型，面向人群，以及功能，都要想清楚了。

　　先是起名，最好是與眾不同的，具有唯一記憶性的功能，別起行業名字，比如你起個家電App，或者商城App，沒有人知道是那個公司的，因為名字太大眾化了。要給App起個唯一記憶型的名字，還有就是方便用戶搜索的時候，書寫方便，比如京東，天貓之類的，都是書寫很方便的。

　　其次，就是App的類型，是購物類型的，還是諮詢類型的，還是社交類型的，還是工具類型的，這個也要想清楚，App的類型會關係到App的功能，如果是商城的App，肯定有商品展示，商品購買，支付等功能，如果是社交類型的，肯定有用戶關係，用戶交流方面的功能，所以功能也要想清楚。

　　再次是面向人群，我們做一個App，不能說給所有人用，因為那樣相當於沒有方向，就像無命題作文和有命題作文相比，有命題作文更好寫。面向的人群，要細分的很清楚，不能只說是男人或者女人，還要把人群的具體屬性說清楚，比如我的綠色食品App面向的人群種類是什麼職業的，收入多少，對食品安全比較關注的，同時對綠色食品有較高消費能力的人群，這樣定位下來，基本就是25歲以後的人群了，因為25歲之後，很多人都有一定的經濟實力，對綠色食品來說，能消費的起了。說了這麼多，意思就是人群的定位要非常的精準。最後，就是App的功能，就是大致的功能有哪些？比如商城是要有用戶支付功能的，還要有商品展示功能，還要有用戶系統，當然了也可不要用戶系統，隨時提交地址，預定也行，這個也要想清楚了。

　　第二步：整理產品需求成書面化

　　等你的想法都完善了，關於App的第一步想法也完善了，第二個步驟就開始了，那就是書面化。人與人的交流，不能只靠想法，每個人對同一句話的理解都是不一樣的，比如說，你想做個App，技術人員想到的是要寫代碼，產品人員想的是功能，投資人想的這個App能不能賺錢，值得不值得我投資，所以不同職業的人對同一個想法的理解都是不一樣的，所以你要把你的想法整理成書面化，就是整理成產品文檔。

　　產品需求文檔包含你的所有想法，比如產品名稱，產品類型，人群定位，產品簡介，功能簡介等等，產品需求文檔是對一個產品的書面化定義和解釋，一個好的產品文檔，能讓所有人腦補出一個產品的模型來，產品文檔的說明和描述越全越好，就像你遇到一個漂亮的女孩，但是你只說她很漂亮，很多人無法理解有多漂亮，但是你如果通過各種書面化語言描述出來，大家才能想像到真正的美麗。很多著名的小說家在寫到美麗的女孩時候，都會有一個全身，遠近，以及細緻的描寫，這樣才能給人代入感，產品文檔也是如此。

　　下面是我通過百度搜索的一個新聞類App產品需求文檔案例：

　　1.產品背景介紹

　　2. 產品介紹

　　2.1．產品開發背景原因

　　2.2．產品信息介紹

　　2.3．產品用戶定位

　　2.4．產品中的角色

　　3.產品信息結構圖

　　4.功能需求

　　4.1．管理賬戶-

　　4.2．用戶賬戶

　　4.3．用戶設置

　　4.4．個人中心

　　4.5．欄目功能

　　4.6．內容添加功能

　　4.7．評論功能

　　4.8．搜索功能

　　4.9．分享功能

　　4.10．圖片欄目

　　4.11．補充說明

　　5.非功能需求介紹

　　5.1．運行環境

　　5.2．可用性

　　5.3．可擴展性

　　5.4．安全性

　　5.5．介面

　　6.交互邏輯

　　6.1．客戶端界面邏輯

　　6.2．管理後台界面邏輯

　　這個產品文檔包含幾個模塊，產品的背景介紹，產品介紹，產品結構，產品功能，邏輯功能等，當然這個還不是最全的，最全的還會有更多。我們可以對照這些產品文檔的模板，把我們的想法書面化成具體的需求。這樣做的好處是減少我們在後期的設計和開發上的溝通成本。特別是有的App開發前很多功能都沒有想清楚，邊做邊改，最後產品把技術激怒了，辦公室發生PK事件，很多時候，我們想的一些小功能，對於技術來說，可能要寫一個月，甚至更長時間，一旦一個功能發生變動，涉及到技術方面的邏輯修改和變動更多。很多創始人在初期沒有做好這些東西，導致後期App上線時間一拖再拖，最後直接把團隊都拖死了，所以說，清晰完整的產品需求文檔，對一個App的後期發展都是非常好的。

　　第三步：設計產品模型

　　一旦整理好產品文檔，就要設計出產品模型了，產品模型比產品文檔更加直觀和清晰，產品模型是對產品的一種立體呈現，就像我們遇見一個漂亮的美女，小說家的描述只能給人想像力，而畫家的畫面呈現更加具有立體感，立體感的美麗更加直觀和清晰。

　　產品模型會讓所有的人一看就明白，大家可以看下圖：

　　高質量的產品模型包含產品的所有頁面、系統、以及配色。產品模型的設計一般用Axure RP、Balsamiq Mockups、Pencil Project等軟體，其中Axure RP用的人比較多，產品模型設計完成後，這樣一個App的前期工作基本就完成了。

第四步：界面設計

完成了產品模型設計之後，借下來的工作就是界面合計和素材設計，這個需要美術設計師來完成，當然最好招聘一些有經驗的設計師，因為此前在我和我們的設計師溝通的時候，忽然發現有經驗的和沒經驗的設計師區別很大，這個主要表現在沒經驗的設計師，只能完成配色和設計，不會考慮到設計背景和行業特性，以及創新性和用途，所以大多設計出的界面和素材，都顯得硬邦邦的，比如說一個單頁的設計，設計出來後五顏六色的，不適合做單頁。但是有經驗的設計師呢，會根據用途和場景，設計更加自然的作品，比如我們要做個綠色App的設計，這個設計背景是綠色，用戶是喜歡綠色食品的，使用場景也是和綠色相關，所以在設計上肯定要和綠色相關，不能說綠色食品的App一打開是個紅色的或者其他喜慶的顏色，看著不像一個App，或者讓用戶無法和綠色想關聯。

設計的最終目的都是讓一個作品和她的用戶和場景，能自然的融合在一起，界面設計，在專業術語上稱為UI設計，所以大家如果招聘設計師的時候，可以看看其他公司對UI設計師的要求，招聘自己需要的設計師。

　　第五步：招聘技術人員進行App開發

　　有了產品模型和產品文檔，下面就是把產品文檔和模型發給技術進行開發，目前開發App有幾種方法：

　　第一種是原生模式開發，根據不同系統的開發分為android、ios版本，早期我們曾經開發過windows phone版本和塞班版本，不過目前主流的是android、ios版，因為windows phone和塞班已經game over了。

　　第二種開發模式是混合開發模式，就是H5和原生相結合的方式，一部分代碼寫在本地端，加強交互，提高用戶體驗，一部分寫成網頁的形式，方便修改。目前有很多這樣的混合開發工具，技術朋友們，可以去網路上搜索自己喜歡的工具進行使用。

　　第三種模式就是：輕應用模式，類似H5網頁以及百度的輕應用，這樣的更加方便，但是交互和獨立性很差。

　　第四種是：網頁生成方法和模板套用，很多網站提供網頁直接生成App功能，還有就是很多做App開發的外包公司，做了一套模板，每次只要更換名字和樣式，就是一個App，不過第四種App質量更差，用戶體驗基本談不上。如果你是真心想做一個App的話，不建議大家使用。

　　還有最後一種開發模式，就是外包了。這個大家最好找靠譜的外包公司，因為在外包的過程中，有很多問題，程序的bug和架構問題都會為App將來的發展埋下後患，還有就是App的上線進度不好把控，開發中的問題很多，很多創業公司幾乎都跨不過開發這道坎，就已經死亡了，所以能開發一個App上線，算是App創業成功的第一步了。

　　第六步：上線運營推廣

　　App開發完成後，下面面臨的事情就是上線運營推廣和維護，這個算是App創業的第二步，第二步是決定一個App創業者是否成功的重要條件，當下的App數量超過300萬，但是90%都無人問津，剩下的App只要10%才有用戶注意到，所以說能把一個App運營推廣成功才是最重要的。

　　App運營推廣目前成本非常高，競爭激烈。這個目前的行業現狀，但是如果你的App只是和硬體交互，屬於補充類型的App，倒是無所謂，目前娛樂、社交等類型的App早已經是紅海一片，沒有大量資金的創業者很難在做成功。

　　我曾經收集整理了一篇《2015最新國內十大應用商店廣告報價表》的文章，大家可以看看，具體方式是關注移動互聯網微信號：ydhlwdyq 後回復：051，即可看到。目前高質量用戶的應用商店價格報價在2-10萬/天，如果一個App要想在應用商店獲得高質量的用戶，一個月的投入費用在60-300萬元。所以說，運營和推廣才是決定一個App未來發展的關鍵。

　　最後一步就是，人才招聘。上面說的這些都是從一個想法到App上線運營推廣的流程，所有的流程都是需要人來完成的。如果你自己不懂，你就需要自己來招聘人才，具體人才招聘怎麼招聘，可以通過各個渠道，比如拉勾網，BOSS直聘等互聯網垂直行業來招聘人才。

　　把一個想法變成一個App，會遇到很多想像不到的困難，不僅需要決心還要人脈和資源，當然最重要的還是資本。所以說，如果想做個App，一定要要把文章中的這些點都想到了，同時明確自己的責任，建立一個靠譜的團隊才能成功，當然你如果把這些都想到並做好了，你就是一個成功的App項目經理了。

作者：移動互聯網李建華，微信：ydhlwdyq，10年移動互聯網行業人士，專註2B2C的渠道推廣和品牌推廣，未經許可禁止轉載，否則將追究你的法律責任。

http://weixin.qq.com/r/pnXt9XjEaiUVrTyW9yC0 (二維碼自動識別)

看到這個問題，我就不得不回答下了，因為我剛剛和一個夥伴做好一個android APP，名字叫做最美歌詞，既然樓主想知道一個APP從想法到實現的過程，那聽我緩緩道來

（一）想法產生

我本人是一個喜歡聽音樂的人，上個暑假我在用網易雲音樂（我不是打廣告）的時候，用了網易雲音樂的歌詞分享功能，當時我突然想到，像我這樣喜歡背歌詞的人，要是有一個專門的歌詞社區來一起和志同道合的人一起談論歌詞，分享自己認為最美的歌詞的地方多好，介於本人在學校自學android開發，有過好幾個APP項目經驗，又是一個以後想當產品經理的人，於是馬上把這個想法記到印象筆記中，第二天去找相關資料，發現基於歌詞的社交APP沒有搜到什麼，有的也是一些風格是android2.3風格的應用，又逛遍有關歌詞的百度貼吧，人人小站，豆瓣小組.....基本確定歌詞社交的需求是存在的，而目前沒有相關APP，於是說干就干，拉上實驗室的開發隊伍（由於本人以前就做過幾個APP項目，也在大賽得過獎，可以組織起開發人員），正式開始了最美之路。

（二）需求確定

我認為有一個好的創意是不夠的，你需要把一個點，擴展成一個個具體的需求，於是在網上找了個鐘跟歌詞有關的資料，以及問了在哪些歌詞貼吧，小組中的人，文他們希望APP哪些需求，然後大致完成APP的需求概要設計書。

（三）產品設計

然後產品經理癮上來的我，不分晝夜的想了一個星期，終於對於APP說要得到的需求合理安排設計，初步完成APP的原型，

（四）APP開發

真正的難點來了，絕大部分的想法永遠只是想法，於是產品經理化身工程師，開始和一個搞技術的同學一起開發，我主要負責UI，和一些常規開發，而他負責技術難點，兩個人暑假在學校實驗室里忘我開發。真正開發起來，計劃永遠趕不上變化，設想的功能因為技術難點無法解決或者我們技術根本搞不定，只能放棄，改變方案，但是每次改變都不是輕易說改變的，我又需要根據現在的技術和需要實現的功能做一個平衡，想個三四天，再做一個原型出來。

沒辦法，對於學生創業者，技術才是制約發展的最重要因素

下面貼做完後我們的應用

是不是感覺改變好大，我們算是一邊做，我一邊不斷修改原型的，這貌似暴露了我這個產品經理的不專業，沒辦法，還是大學生，一步一步都是新手，又一開始把餅攤的太大了，只能每天晚上都想方案，現在想想真的是蠻拼的，自己對產品的喜愛還是很強的吧。

（五）上線推廣，運營（如果有社交內容）

目前應用準備上線，產品經理又化身運營人員，開始苦逼的找應用市場，找首發機會，無奈大部分應用市場首發都需要企業開發者，我都把360的首發要求都做好了（閃屏加logo),應用推薦仿360手機助手，結果申請的時候，說不是企業開發者，想哭的心都有了，於是把logo和推薦又去掉。唉，目前正在各大應用市場上線，不要以為APP做出來了就是成功了，把APK往應用市場一丟就完事，你的應用被別人下載，而且一直被人使用才是真的成功。這裡也希望看到的知友們，多多推薦最美歌詞，分享的鏈接為分享－最美歌詞

（六）根據相關數據來準備第二版改進點

我在APP里加入了友盟的統計，準備根據APP上線後的數據再對APP進行第二版的改進。

希望我的經歷能幫到你，

最後貼下最美歌詞官網

最美歌詞官網大家多多支持下

如果題主跟我一樣是個會一點設計的全棧的話. 那麼過程大概是這樣的:

起因. 啊這個應用好棒, 但是為毛沒有這個功能呀! 或者啊妹的為毛就沒個像樣的可以干這個的應用!

然後就開始構思, 可能是先在草稿本上, 或者直接在軟體上畫些個草圖.

然後嗯就一邊開發一邊調整設計和功能需求 (嘿嘿嘿, 自己的東西老改需求也不會煩).

然後一個應用就誕生, 隨後就上架了...

比如說我的詞焙背單詞, 以及現在已經退役的 A+ Dictionary (Google Dictionary 的改良版), 科學上網工具 X-Wall, 等等.

但是,,, 如果題主不是全棧的話,,, 這個過程可能就是這樣的:

起因. 同上.

然後就開始構思, 自己開始在草稿本上畫草圖.

覺得不錯了, 拉攏程序員和設計師, 期間坎坷無數, 不再具體展開了. 大概就是, 如果你不是是個設計師就要, 是個程序員就要的人的話, 最大的問題是你看得上的設計師和程序員沒興趣跟你一起做...

不過假設你終於是找到人了, 程序員開始思考軟體架構和解決方案, 設計師開始設計草圖. 大家還可以一起頭腦風暴想出更多絕妙的點子.

So far so good. 這個時候設計師出圖了, 程序員說不行這個不好做, 然後設計師又跑回去改. 你一聽說覺得為什麼不好做啊於是找程序員理論, 程序員說了一堆你也不大懂的東西然後你好像明白了的樣子說好吧那就改改吧. 於是設計師改好了交給程序員, 程序員開始實現了. (如果程序員是新手, 他很可能做了大半才發現做不下去了, 時間成本刷刷的...)

實現了一半的時候突然你們又冒出來了一個絕妙的點子, 設計是說沒問題馬上我就去改. 程序員坐不住了, 啊啊啊說改就改啊, 這一改我原來寫的基本就都不能用了得重來啊. 你跟設計師都很疑惑妹的不就是加了個小東西么. 於是程序員很耐心地解釋為什麼加這麼個小東西會帶來架構上的變化然後你跟設計師大概就懂了於是說那好沒關係, 重來就重來! 程序員默默地說了聲你妹.

終於程序完成了大半, 設計師一看, 咦, 這個地方不對我不是這麼設計的. 你一看貌似沒什麼問題嘛, 設計師便耐心地解釋了一圈, 你也基本上相信嗯是有這麼一點問題於是程序員你再改改? 程序員覺得嗯我也該是精益求精地人於是就改改吧.

終於改好了...

終於上線了...

等等,,, 貌似太順利了故事不是應該曲折一點么?!

原諒我忘了幾個假設.

你是靠譜的 PM.

設計師是靠譜的設計師.

程序員是靠譜的程序員.

需求只改了那麼一兩次...

或者假設即便你們都是新手但還是順利地讓應用上線了... 那麼...

咦為什麼我的應用沒人用...

O.O

掃了一眼頂上的回答，感覺都是說個人經歷的，我覺得這種問題還是把它理論化體系化會更好一點吧

以下是我的看法

在假設有一個idea的情況下，一個常規產品流程應該分4個階段：

1.需求確認階段

2.產品設計階段

3.產品開發階段

4.產品運營階段

接下來細說

1.需求確認階段

在已經有一個idea的情況下，首先要確認需求，需求分兩個部分，一個是用戶需求，一個是公司需求。用戶需求的話很簡單，就是這個產品能為用戶帶來什麼，或者用戶為什麼要用它。公司需求的話我覺得公司對不一樣的產品的需求是不一樣的，就比如

有的公司對產品的需求是賺錢（例子太多不舉了）
有的公司對產品的需求是更多用戶，當然不能賠錢，這一種產品和上一種絕大部分是重合的（比如課程格子）
有的公司對產品的需求是即使前期賠錢，也要更多的用戶（嘀嘀打車）
有的公司對產品的需求是除了常規需求之外，必須得到大量數據，比如某功能使用者的年齡，性別，時間段等

至於用戶需求分析的話方法就比較多了，流程大概如下所示

行業背景分析
SWOT分析
競品分析
市場調查/用戶調研
用戶角色建模/場景建模
使用KANO模型來細化需求
需求管理，根據公司資源及目標決定功能是現在做還是放到迭代中

在這個階段的輸出產物應該是MRD，BRD，角色建模.doc，需求list.xls

2.產品設計階段

在確定了用戶需求和公司需求之後就進入到了產品設計階段，在產品設計的階段我把它分成如下幾個小階段

信息架構設計
產品流程設計（邏輯圖）
視覺設計
原型設計
可用性測試

輸出產物為：PRD，信息架構圖.mmap，流程圖.vsd，UI.psd，prototype.rp

同時在12階段，必須有開發團隊介入，4結束之後，必須要讓老大介入，確認產品團隊，開發團隊，老闆這三個方面全部滿意之後，再進入下一階段

3.產品開發階段（有時候會和產品設計階段交叉進行）

寫代碼
寫代碼
產品經理持續跟進
寫代碼
寫代碼
測試階段（包括可用性測試）

輸出產物：index.html/main.apk等

4.產品運營階段

這裡就沒有明確的流程了，簡單地說就是

關注用戶反饋
分析數據以便在下次迭代中提升用戶體驗
宣傳推廣

輸出產物：數據.xls

當然在如上四個階段中也不是那麼嚴格的，在各種地方都有可能出現以下場景

if(老闆滿意度==false勸說效果==false){

重新設計;

}