過去幾個月中，我在TechCrunch上撰寫的每周專欄都是關于“移動”的某個方面。毫無疑問，無論是平臺、用戶量還是消費者的關注點，都在向移 動轉移。不過，對于初創公司而言，考慮到應用分發的嚴酷現實，以及消費者面臨著太多類似應用的轟炸，在當今市場中采取“移動優先”策略卻是一種冒險。于是 拋出了這個疑問：“對于當今新成立的初創公司，采取移動優先策略是個好選擇嗎？”

在這篇文章中，我將會分享一些情況，在這些情況下采取移動優先策略要么沒有必要，要么會讓初創公司陷入困境。今天我將扮演魔鬼代言人，抵擋移動的強 風，重新審視初創公司可以（或應該）從web開始的一些原因，即便他們最終演化成移動形態。帶著這樣的思想，讓我們開始討論，以下列舉不分先后順序：

在某些市場里，移動優先策略根本沒必要或不可行。想想那些目標客戶為大公司里整天使用臺式機或筆記本工作的員工的產品。誠然，這塊細分人群發展速度 不如移動領域，但我們要重申，什么都比不上移動領域的發展速度。特別的是，產品的目標用戶如果是大公司員工，或在信息技術方面（尤其是移動領域）重視安全 的用戶，或需要重度輸入創造內容（比如寫作或數據錄入）的用戶，這些地方移動優先策略就要吃憋了。瞄準這類消費者的應用及解決方案***以“web優先”起 步，再向移動端發展。

相對而言， web開發人員要比移動開發人員容易招聘一些。如今的招聘市場中，經驗豐富、能力足夠的iOS及Android工程師及設計師相當緊缺。如果這些家伙想要 更進一步的話，要么是做創始人，要么是接近成立一家公司。如果團隊中沒有移動開發人員的話，專注于web會讓招聘工作容易一些。

更快的迭代、測試周期，更快地提高市場契合度。搭建好web工程師團隊，開發好web應用，相對于從移動端起步從很多方面來說都是一條更加理智的道 路。入職管理就是一塊移動應用很難搞定的區域，而web應用就輕松得多。對初始功能進行分層，在后端搭建堆棧，開發團隊和用戶能夠運行更加精確的測試，來 查看哪些功能正常，哪些功能不正常。我們都知道，在移動端這樣的開發自由度是難以想象的，而且開發、用戶測試、反饋的周期都要更長，因此成本也更大。

Web為品牌塑造及病毒式營銷打下了堅實的基礎。如果一個web團隊有幸摸到門路，接近了推向市場的目標，開發web要比開發移動具備一些先天優 勢。首先，web用戶經常會帶著他們的數據或圖形信息登錄其它網站，從而讓分享和邀請變得更加容易。更多人使用web端的產品，也增加了更多人接觸到該品 牌、探索產品的可能性。這種認知在產品擴展到移動端時將會是無價之寶，原因在于使用web產品的那些受眾更有可能直接下載移動應用，而不是在隨機的分發渠 道中發現它。

移動端可以視作擴展，但并非基礎。當一個網站或web軟件產品向移動端擴展時，它能夠以更加直接的信息驅動當前用戶使用移動應用。當然，首先開發團 隊需要招聘不僅能融入現有團隊、而且對用戶如何在移動端使用該服務有著明確概念的移動工程師及設計師。到了這個程度時，我們的期望是：團隊做好了向移動端 擴展的準備，表現出一些能夠取得成功的因素，資金充裕，用戶對移動產品存在需求。

還有更多的原因來說服你為什么新公司需要在移動優先策略上三思而后行?？赡?ldquo;移動后行”是一條更合理的道路。當然，某些產品或服務確實是為移動而生 ——比如Uber——要么需要從移動起步，要么需要在快速的web測試后迅速擴展到移動端。不過，對于大部分不斷涌入市場、讓消費者看花眼的應用來說，采取“移動優先”策略一直是、也仍然是一種誘人且冒險的做法?？倳幸恍┚F隊能夠一開始就在多個平臺上搭建大型系統，這些家伙要么是資金充裕，要么是經 驗豐富，能夠打持久戰。但不是每個團隊都能享受到這樣的奢侈。相反地，大部分團隊都面臨著更加根本性的生存問題，盡管現在移動領域“光彩耀人”，未來相當 長一段時間也會是這樣，但進入移動領域并不意味著一定要從那里開始。