獨立產品研發系列文章第二篇
上篇文章從 iOS 開發的視角介紹了獨立 App 從確定需求、開發、上線中所用到的一些資源。因為各項資源的限制，也只能完成一些僅上架於蘋果 Appstore 的工具類 App。
這篇文章就著眼於一個具備完善功能的全平台產品的研發，研發過程中我們碰到的一些問題及其解決方案。在這裡給大家分享一下我是如何一步步構建自己 公眾號、小程式 + App 完整產品生態 的。
1、產品目標
產品目標往大了說，是指產品實現的價值。即使有使用者場景存在，但做出來的產品沒有價值（不能盈利，使用者量極少），那也就沒有存在的必要。
甚至再大點，從 產品的願景 講起...
打住，先不用考慮這麼多，不然你的產品可能就只能存在於你的不停設想中了。
在資源有限，人力有限，投入有限的情況下，我們的產品目標就很明確了，它要解決哪些問題？或者它需要完成的功能！
比如說，我在做 檔案管理器 的時候，MVP 的產品目標就很明確：實現手機和電腦之間的檔案傳輸。
在完成了 MVP 需求之後，自然而然的帶來了一些其他需求，有的來自我自己的產品計劃，更多的來自於使用者回饋：
- 1.0.0 完成手機和電腦之間的傳輸
- 1.1.0 實現圖片、影片、音頻檔案的預覽或者播放
- 1.2.0 實現檔案分組、移動、刪除、壓縮、分享功能
- 1.3.0 最佳化播放器
- 1.4.0 完成安全驗證功能：手勢驗證碼、生物認證
- 2.0.0 添加App 內購買功能
- 2.1.0 完成檔案掃描功能
- ....
明確一個目標，它不需要很大，但可以實施，一次聚焦一個點，錯了也先堅持下去（不做完你怎麼知道是錯的呢 ◔ ‸◔？），把它完成，然後復盤。
2、產品原型
在上篇文章中，我有提到自己其實嘗試了很多原型設計工具，最後結論是 設計原型的時間都足夠自己使用 xib 將頁面搭建完成了。
在這裡推翻一下自己 ,,Ծ‸Ծ,,
在做個人工具類 App，且毫無後續規劃，只想著將其完成上線時，確實會帶來這種想法。
隨著產品的迭代，這種毫無原型規劃，做一步考慮一步的處理方式，會給自己未來的開發造成很大的困擾。設計原型的過程其實是梳理產品邏輯的過程。
3、專案管理
在經歷了獨立的 iOS App 開發上架之後，我發現了一個很嚴重的問題。就是 毫無專案管理概念，有時間了做一下，想起來了做一下，偷懶了就不做了。
因為是自己的產品，自己設計，自己開發，且 MVP 版本大概率沒有付費使用者，也就沒有給使用者負責的心態。
這其實會嚴重阻礙專案進度，長期的無計劃開發，還會造成專案流產。
在公司，經歷了幾年的迭代管理，發現使用專案管理工具進行個人專案的管理還是行之有效的。當我們有了明確的產品目標，有了對應邏輯自洽的原型，進而將任務進行拆解，就順理成章了。
這裡我用的是 coding.net 來進行專案管理，同時它也可以用來做程式碼託管。
將任務項按照小時的粒度拆分，一方面方便任務管理，另一方面也方便測試 case 的編寫。在正式編碼前，我目前的習慣是先將測試 case 寫完，這很有必要。
原型是對產品邏輯的梳理，測試 case 則是對研發細節的梳理，完整的測試 case 可以引導我們完成正確的業務邏輯 ✅，也能避免很多業務錯誤 ❌。
4、技術選型
好了，到目前為止，我們做的都是一些準備工作，仍然沒有進入到開發中。很關鍵的問題在於，開發只有自己，要完成文章開頭的目標：公眾號、小程式 + App 完整產品生態。
我們需要同時具備小程式、iOS 開發、Android 開發技能。編程語言的上手難度不高，問題在於同樣的業務，需要三次開發成本。這顯然不太現實。
通常情況下，我們可能會選用 web 來實現多平台的使用體驗，甚至於拋棄 App，只做公眾號 + 小程式生態。在產品初期，產品需求快速驗證的情況下，這種方式也是非常可取的一種方案。
其實，稍微搜索一下就會發現，市面上還是有挺多跨平台技術實現的。要做到 App + 小程式，三端一套程式碼，可以用 Uni-App 來實現。它使用的是 Vue.js 前端框架，iOS 和 Android 則借助了 Weex 實現。
用於做一些個人產品，或者小型商業化產品足夠了。
5、資料管理
小程式 + App 的實現方案解決了之後，還有另外一個關鍵問題，資料存哪？
如果只是一個工具類產品，那麼資料存在 App 本地即可。但我們的目標是一個具備完善使用者體系的資訊平台，甚至於較為複雜的使用者 UGC 社區怎麼辦呢？
Uni-App 提供了自己的 uniCloud 服務，使用 js 即可完成伺服器開發工作，小程式和 App 可以免域名使用伺服器。
在這裡，我選用了另外一種做法，將資料託管到 serverless 平台 LeanCloud，小程式和 App 透過 LeanCloud 的 js sdk 存取託管資料庫。
其開發版可支撐 3 萬次 / 天的免費 Api 存取，同時也提供簡訊服務。可以順利完成使用者體系建設、使用者資料上傳、平台資料的拉取。
當超過開發版的存取次數之後，說明你的產品也有了一定規模的使用者量，相信這時候，流量帶來的收入也足夠你開通按量付費的商用版了。
資料來源之騷操作
如果你想做一個天氣 App，或者咨詢類 App，沒有天氣和資訊類資料怎麼辦呢？
國內有很多 Api 市場平台，比如：
等等
這些市場一方面提供了收費 Api 服務，另一方面也提供免費的 Api。
如果你的產品有很好的流量變現方式，可以考慮使用收費 Api。
如果沒有，可以考慮白嫖。但 100 次的試用，測試階段就很快消耗完了。怎麼辦呢？
這裡就可以將 serverless 資料庫託管平台 leancloud 和 Api 商城結合起來使用，以每日天氣為例，如果 serverless 資料庫託管平台沒有查詢到資料，則可以請求 Api 商城，之後將資料存入到資料庫託管平台。
可是，100 次還是不足以覆蓋所有城市怎麼辦呢？發揮白嫖精神，多申請幾個平台吧。
6、上線營運
至此，我們搞定了小程式、App 以及 Server 的開發工作。上線怎麼辦呢？
小程式比較好說，微信公眾平台 按照引導一步步申請小程式即可。
iOS 上架需要一個付費的開發者賬號，這是一個門檻，長期營運的話，還是建議在蘋果開發者官網申請一個賬號，現在申請比較簡單，蘋果手機下載 Developer App 就可以付費了。
Android 上架則需要軟體著作權了，正常申請可能需要 1-2 兩個月，也可以付費找三方中介完成。
繼續發揮白嫖精神，App 和 小程式設定的一些營運位，圖片或者音影片資源存放在什麼地方呢？
公眾號媒體資料庫可以解決這個問題。將圖片和音影片資源存到公眾號後，取得原連結，App 和 小程式即可存取了。
7、取得收益
較為簡單的流量變現方式就是 廣告 了。
可現在各平台對於流量主的接入要求越來越高，個人開發者基本很難完成廣告接入。
Uni-App 提供了一鍵接入功能，具體可以參考 文檔。
公眾號積累粉絲後，也可以開通文章內廣告位。
小程式達成 1000 個 UV 存取後，可開通流量主權限。
8、小結
至此我們就完成了文章開頭介紹的 公眾號、小程式 + App 完整產品生態。
按照以上步驟，我也完成了三個產品的操作，可以掃碼體驗下：
