建站
咨詢
售后
建站咨詢
新聞中心
在六年的app開發(fā)生涯中，我遇到了一些可能會導致app失敗的常見問題。當然了，我不可能在此精確提煉出app成功的所有要素，因為那足夠我寫一整本書了。所以，為了簡潔易懂，我只講一些我親身經(jīng)歷的經(jīng)驗教訓。下面是我總結(jié)的一些典型問題，它們可能會成為你的app成功路上的絆腳石。
10年積累的網(wǎng)站制作、網(wǎng)站設(shè)計經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認識你，你也不認識我。但先制作網(wǎng)站后付款的網(wǎng)站建設(shè)流程，更有延津免費網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
沒有商業(yè)意識
2014年我在Renaissance.io大會上發(fā)表了演講，要求與會者不要把自己僅僅定義為開發(fā)者，因為一個單純的開發(fā)者一般不會考慮營銷、財務(wù)、法務(wù)、用戶支持及其他類似的商業(yè)經(jīng)營問題。
如果沒有上述這些關(guān)鍵元素的支撐，一款再好的應(yīng)用都可能在App Store里遭遇滑鐵盧。比如,特別是以前的時候,我非常專注于學習營銷知識——你可以看到App Savvy里約40%的文章都是關(guān)于營銷的——我在這篇文章也講過這一點。當我們跟客戶打交道時，我們需要做的事情遠不只設(shè)計和開發(fā)app。從***天起，我們就得考慮產(chǎn)品定位，幫助客戶爭取到風險投資（如果需要的話），開發(fā)app相關(guān)的網(wǎng)站，甚至充實用戶支持知識庫。每個成功app的背后都有全面的商業(yè)支撐。
范圍蔓延
如果你不想成功，***的方法就是把app揣在自己兜兒里。這種情況比人們想象的更常發(fā)生——不是只有做app時才會碰到——而其罪魁禍首就是范圍蔓延。范圍蠕變包括這些
行為：一是功能超出其本身設(shè)定的范圍；二是添加功能過多，或者是上述二者的結(jié)合。范圍擴大發(fā)生的部分原因是，人們總是在心理上覺得“多就是好”。更多的功能意味著更多的下載量和更大的成功。就像我之前詳述的那樣，這種哲學在當今的App Store里早就過時了。你應(yīng)該專注于把單個事情做***。當你完成這件事之后，就可以將app發(fā)布出去了。
開發(fā)者變的盲目
App的范圍蠕變是開發(fā)者變盲目的一種癥狀。開發(fā)者有可能迷戀上某種特性，分心去搞一些新的東西，或是偏離了普通用戶的最重要訴求。求其根源，正因為他們離自己的想法太近了，所以自然地會生出一種偏離軌道的傾向。
有幾種方法可以避免這個問題。***，確保你的app有一個路線圖。路線圖需要指出你們接下來應(yīng)該致力于開發(fā)哪些功能、修復哪些bug等。對于手中的每一個app，我們都與客戶有一個共享的Trello board，并且做好至少未來2到3個版本的計劃。它與那些更詳細的開發(fā)追蹤工具各司其職。路線圖給未來潛在的功能留出了位置。
另外一種避免開發(fā)者變盲目的方式被Steve Blank描述為“從開發(fā)中走出來”……即用你的app與用戶互動。開發(fā)者應(yīng)該去讀App Store里的評論，并且積極地提供用戶支持，或者努力去與用戶進行交流。Basecamp博客在最近一篇文章中介紹了他們擺脫開發(fā)者盲目問題的方式。
要做到這一點，你需要經(jīng)常分析數(shù)據(jù)。依靠前端或后端的統(tǒng)計數(shù)據(jù)，開發(fā)者能夠很快地從盲目的狀態(tài)中走出來。數(shù)據(jù)能夠幫助開發(fā)者理解一些問題，比如他們面臨的bug僅限于重量級用戶（正如他們自己一樣）；或者讓開發(fā)者更容易發(fā)現(xiàn)一些問題，比如費時間去開發(fā)一個沒人用的界面顯然意義不大。Google Analytics 、利用app制作開發(fā)報表的Mixpanel、像Parse那樣從后端直接可用的app，這些都是我們最熱愛的東西。
太少或沒有測試期
在正式發(fā)布之前，Gmail作為內(nèi)部項目在谷歌員工之間已經(jīng)使用好幾年了。此后，它開始面向公眾發(fā)布，從一開始只有被邀請的人才能體驗，逐步發(fā)展到***每個人都能注冊使用。
我們應(yīng)該感謝Google倡導了測試（beta）這個概念，特別是公測。很多人不記得了，但是Google當年對Gmail的測試可是長達五年之久。對于大多數(shù)開發(fā)者而言，這種時間安排幾乎是不可能——或者起碼是不怎么好的。但是它也很有用，因為如果一定要犯錯的話，測試期長點總比短點好。
一個常見的錯誤是，我看到很多app創(chuàng)業(yè)者根本不考慮任何測試問題。他們的計劃往往太過激進，發(fā)布日幾乎緊接著完成日。這樣的話，他們根本沒有時間來根據(jù)反饋改進體驗、調(diào)整優(yōu)化、潤色打磨或者進行其他bug修復。最終，這將導致發(fā)布的app質(zhì)量不過關(guān)。
那么有人會問，***的測試期是多久呢？呃，好吧，這個話題夠我另寫一篇論文的了。一般而言，我們建議至少要花整個開發(fā)期間的20%時間去測試一款差不多完成了的app。
這意味著，如果你計劃用5個月來發(fā)布一款app，那至少要用1個月來進行產(chǎn)品測試。在這段時間內(nèi)，你不能再開發(fā)任何新功能了。如果可以的話，你應(yīng)該讓產(chǎn)品有盡量長的測試期。不過當然了，這并不適用于所有人。
缺少遠見
很多App Store創(chuàng)業(yè)者有一種“上線等于成功”的思想。也就是說，將應(yīng)用提交給App Store后就可以坐等收錢了。然而，世界上沒幾個憤怒的小鳥、Instagram和Uber這樣的應(yīng)用。實際上，這些應(yīng)用的開發(fā)者們也是糾結(jié)了好久才找到了正確的路。[Rovio大約花了六年時間才創(chuàng)造出了憤怒的小鳥。Instagram剛開始的時候是一個跟現(xiàn)在功能完全不搭邊的應(yīng)用。Uber的開發(fā)進程超級慢，因為他們需要創(chuàng)建自己的基礎(chǔ)架構(gòu)以及對模型進行求證。
理想的測試期長度和app開發(fā)路線圖的必要性都說明了，你必須要有遠見而不是一心只盯著上線。如果你花光了所有的錢和時間卻還只停留在上線這個階段，恐怕就得考慮拎包回家了。當今市場的一個經(jīng)驗法則是，你至少需要一年的時間來證明你的想法。一年聽上去的確不短，因此在考慮了自己想法的格局大小之后，很多app創(chuàng)業(yè)者都決定進行融資。
結(jié)論
對所有準備進入app store的人而言，本文都應(yīng)該有一定啟發(fā)。有不少活躍在Twitter、Medium、podcasts或者其他地方的開發(fā)者群體，他們經(jīng)常會分享一些自己的經(jīng)驗，這對
我們很有幫助。再次強調(diào)，沒有什么靈丹妙藥能保證你成功?？墒牵羞@些錯誤，如果你能謹記于心并小心避免的話，你會看到你的app——也是你的夢想——它正踏實地走在通往成功的路上。
當前標題：就這樣么玩，你的APP一定會死
分享網(wǎng)址：http://www.dlmjj.cn/article/dhjeegj.html
