在六年的app開發(fā)生涯中，我遇到了一些可能會(huì)導(dǎo)致app失敗的常見問題。當(dāng)然了，我不可能在此精確提煉出app成功的所有要素，因?yàn)槟亲銐蛭覍懸徽緯?。所以，為了簡潔易懂，我只講一些我親身經(jīng)歷的經(jīng)驗(yàn)教訓(xùn)。下面是我總結(jié)的一些典型問題，它們可能會(huì)成為你的app成功路上的絆腳石。

沒有商業(yè)意識(shí)

2014年我在Renaissance.io大會(huì)上發(fā)表了演講，要求與會(huì)者不要把自己僅僅定義為開發(fā)者，因?yàn)橐粋€(gè)單純的開發(fā)者一般不會(huì)考慮營銷、財(cái)務(wù)、法務(wù)、用戶支持及其他類似的商業(yè)經(jīng)營問題。

如果沒有上述這些關(guān)鍵元素的支撐，一款再好的應(yīng)用都可能在App Store里遭遇滑鐵盧。比如,特別是以前的時(shí)候,我非常專注于學(xué)習(xí)營銷知識(shí)——你可以看到App Savvy里約40%的文章都是關(guān)于營銷的——我在這篇文章也講過這一點(diǎn)。當(dāng)我們跟客戶打交道時(shí)，我們需要做的事情遠(yuǎn)不只設(shè)計(jì)和開發(fā)app。從***天起，我們就得考慮產(chǎn)品定位，幫助客戶爭取到風(fēng)險(xiǎn)投資（如果需要的話），開發(fā)app相關(guān)的網(wǎng)站，甚至充實(shí)用戶支持知識(shí)庫。每個(gè)成功app的背后都有全面的商業(yè)支撐。

范圍蔓延

如果你不想成功，***的方法就是把a(bǔ)pp揣在自己兜兒里。這種情況比人們想象的更常發(fā)生——不是只有做app時(shí)才會(huì)碰到——而其罪魁禍?zhǔn)拙褪欠秶?。范圍蠕變包括這些

行為：一是功能超出其本身設(shè)定的范圍；二是添加功能過多，或者是上述二者的結(jié)合。范圍擴(kuò)大發(fā)生的部分原因是，人們總是在心理上覺得“多就是好”。更多的功能意味著更多的下載量和更大的成功。就像我之前詳述的那樣，這種哲學(xué)在當(dāng)今的App Store里早就過時(shí)了。你應(yīng)該專注于把單個(gè)事情做***。當(dāng)你完成這件事之后，就可以將app發(fā)布出去了。

開發(fā)者變的盲目

App的范圍蠕變是開發(fā)者變盲目的一種癥狀。開發(fā)者有可能迷戀上某種特性，分心去搞一些新的東西，或是偏離了普通用戶的最重要訴求。求其根源，正因?yàn)樗麄冸x自己的想法太近了，所以自然地會(huì)生出一種偏離軌道的傾向。

有幾種方法可以避免這個(gè)問題。***，確保你的app有一個(gè)路線圖。路線圖需要指出你們接下來應(yīng)該致力于開發(fā)哪些功能、修復(fù)哪些bug等。對于手中的每一個(gè)app，我們都與客戶有一個(gè)共享的Trello board，并且做好至少未來2到3個(gè)版本的計(jì)劃。它與那些更詳細(xì)的開發(fā)追蹤工具各司其職。路線圖給未來潛在的功能留出了位置。

另外一種避免開發(fā)者變盲目的方式被Steve Blank描述為“從開發(fā)中走出來”……即用你的app與用戶互動(dòng)。開發(fā)者應(yīng)該去讀App Store里的評論，并且積極地提供用戶支持，或者努力去與用戶進(jìn)行交流。Basecamp博客在最近一篇文章中介紹了他們擺脫開發(fā)者盲目問題的方式。

要做到這一點(diǎn)，你需要經(jīng)常分析數(shù)據(jù)。依靠前端或后端的統(tǒng)計(jì)數(shù)據(jù)，開發(fā)者能夠很快地從盲目的狀態(tài)中走出來。數(shù)據(jù)能夠幫助開發(fā)者理解一些問題，比如他們面臨的bug僅限于重量級(jí)用戶（正如他們自己一樣）；或者讓開發(fā)者更容易發(fā)現(xiàn)一些問題，比如費(fèi)時(shí)間去開發(fā)一個(gè)沒人用的界面顯然意義不大。Google Analytics 、利用app制作開發(fā)報(bào)表的Mixpanel、像Parse那樣從后端直接可用的app，這些都是我們最熱愛的東西。

太少或沒有測試期

在正式發(fā)布之前，Gmail作為內(nèi)部項(xiàng)目在谷歌員工之間已經(jīng)使用好幾年了。此后，它開始面向公眾發(fā)布，從一開始只有被邀請的人才能體驗(yàn)，逐步發(fā)展到***每個(gè)人都能注冊使用。

我們應(yīng)該感謝Google倡導(dǎo)了測試（beta）這個(gè)概念，特別是公測。很多人不記得了，但是Google當(dāng)年對Gmail的測試可是長達(dá)五年之久。對于大多數(shù)開發(fā)者而言，這種時(shí)間安排幾乎是不可能——或者起碼是不怎么好的。但是它也很有用，因?yàn)槿绻欢ㄒ稿e(cuò)的話，測試期長點(diǎn)總比短點(diǎn)好。

一個(gè)常見的錯(cuò)誤是，我看到很多app創(chuàng)業(yè)者根本不考慮任何測試問題。他們的計(jì)劃往往太過激進(jìn)，發(fā)布日幾乎緊接著完成日。這樣的話，他們根本沒有時(shí)間來根據(jù)反饋改進(jìn)體驗(yàn)、調(diào)整優(yōu)化、潤色打磨或者進(jìn)行其他bug修復(fù)。最終，這將導(dǎo)致發(fā)布的app質(zhì)量不過關(guān)。

那么有人會(huì)問，***的測試期是多久呢？呃，好吧，這個(gè)話題夠我另寫一篇論文的了。一般而言，我們建議至少要花整個(gè)開發(fā)期間的20%時(shí)間去測試一款差不多完成了的app。

這意味著，如果你計(jì)劃用5個(gè)月來發(fā)布一款app，那至少要用1個(gè)月來進(jìn)行產(chǎn)品測試。在這段時(shí)間內(nèi)，你不能再開發(fā)任何新功能了。如果可以的話，你應(yīng)該讓產(chǎn)品有盡量長的測試期。不過當(dāng)然了，這并不適用于所有人。

缺少遠(yuǎn)見

很多App Store創(chuàng)業(yè)者有一種“上線等于成功”的思想。也就是說，將應(yīng)用提交給App Store后就可以坐等收錢了。然而，世界上沒幾個(gè)憤怒的小鳥、Instagram和Uber這樣的應(yīng)用。實(shí)際上，這些應(yīng)用的開發(fā)者們也是糾結(jié)了好久才找到了正確的路。[Rovio大約花了六年時(shí)間才創(chuàng)造出了憤怒的小鳥。Instagram剛開始的時(shí)候是一個(gè)跟現(xiàn)在功能完全不搭邊的應(yīng)用。Uber的開發(fā)進(jìn)程超級(jí)慢，因?yàn)樗麄冃枰獎(jiǎng)?chuàng)建自己的基礎(chǔ)架構(gòu)以及對模型進(jìn)行求證。

理想的測試期長度和app開發(fā)路線圖的必要性都說明了，你必須要有遠(yuǎn)見而不是一心只盯著上線。如果你花光了所有的錢和時(shí)間卻還只停留在上線這個(gè)階段，恐怕就得考慮拎包回家了。當(dāng)今市場的一個(gè)經(jīng)驗(yàn)法則是，你至少需要一年的時(shí)間來證明你的想法。一年聽上去的確不短，因此在考慮了自己想法的格局大小之后，很多app創(chuàng)業(yè)者都決定進(jìn)行融資。

結(jié)論

對所有準(zhǔn)備進(jìn)入app store的人而言，本文都應(yīng)該有一定啟發(fā)。有不少活躍在Twitter、Medium、podcasts或者其他地方的開發(fā)者群體，他們經(jīng)常會(huì)分享一些自己的經(jīng)驗(yàn)，這對

我們很有幫助。再次強(qiáng)調(diào)，沒有什么靈丹妙藥能保證你成功?？墒?，所有這些錯(cuò)誤，如果你能謹(jǐn)記于心并小心避免的話，你會(huì)看到你的app——也是你的夢想——它正踏實(shí)地走在通往成功的路上。